Eur Cidin Manual v6 - 0

ICAO EUR DOC 005
INTERNATIONAL CIVIL AVIATION ORGANIZATION
EUR CIDIN MANUAL

Sixth Edition
Published by the European and North Atlantic Office of ICAO
April 2011
EUR CIDIN MANUAL
Record of Amendments and Corrigenda

No.
AMENDMENTS
Date
Date
applicable
entered
Entered
by
11/4/03
June 2004
eb
13/4/04
June 2004
eb
No.
Sixth Edition
Page i of v
CORRIGENDA
Date
Date
applicable
entered
Entered
by
14/04/2011
EUR CIDIN MANUAL
Amendments to CIDIN Manual
Amendment
Subject(s)
Adopted
1st Edition
Introduction of guidance material for CIDIN Implementation

in the EUR Region.
June 1990
2nd Edition
Major review, including update of the Manual to take account

of new Annex 10 format.
August 2002
1st
Amendment
Review of testing terminology as well as test cases in

Appendix D.
Revision of Chapters 9 & 10 and Appendix D.
Description of network management interface in Chapter 1.
April 2003
2nd
Amendment
Introduction of Network management application interface

procedures (Chapter 9 and Appendix D).
Refinements in Chapters 8, 10 and Appendix F.
April 2004
3rd Edition
New edition to consolidate 1st and 2nd Amendments.
June 2004
4th Edition
New edition to introduce Chapters 12 and 13 and Appendix H.
July 2005
5th Edition
New edition to introduce Chapter 6 Transport Layer,

paragraph 6.2.9.1 and Chapter 10 Operational Procedures,
paragraph 10.2.3
September 2006
6th Edition
Incorporation of CP-CIDINM-10-001,
Incorporation of CP-CIDINM-10-002,
Minor editorial changes and reformatting
April 2011
Sixth Edition
Page ii of v
14/04/2011
EUR CIDIN MANUAL
Table of Contents
Record of Amendments and Corrigenda .........................................................................................................i
Amendments to CIDIN Manual ..................................................................................................................... ii
Table of Contents............................................................................................................................................ iii
1.
Introduction ............................................................................................................................................ 1
1.1 PURPOSE OF THIS MANUAL ....................................................................................................................... 1
1.2 A COMMON NETWORK FOR VARIOUS APPLICATIONS ............................................................................... 2
1.2.1
Existing Services ............................................................................................................................. 2
1.2.2
CIDIN architecture .......................................................................................................................... 3
1.3 OPTIONAL PARAMETERS AND X.25 VERSION ......................................................................................... 10
2.
Physical Layer (1)................................................................................................................................... 1
2.1 STANDARDS AND RECOMMENDED PRACTICES .......................................................................................... 1
2.2 GUIDANCE MATERIAL .............................................................................................................................. 1
3.
Link Layer (2)......................................................................................................................................... 1
3.2.1
Data Link Layer Functions .............................................................................................................. 1
3.2.2
Frame Structure and Formats .......................................................................................................... 2
3.2.3
Transparent Transmission of Bit Strings ......................................................................................... 3
3.2.4
Link States and Modes .................................................................................................................... 3
3.2.5
Numbered Frames and Flow Control .............................................................................................. 4
3.2.6
Error Detection and Recovery ......................................................................................................... 5
3.2.7
Parameters ....................................................................................................................................... 6
4.
Network Layer (3a) ................................................................................................................................ 1
4.1.1
PVC Procedures .............................................................................................................................. 1
4.1.2
Packet Format.................................................................................................................................. 1
4.1.3
Logical channels.............................................................................................................................. 2
4.1.4
Receiving Unknown Packets and Packets of Less Than Three Octets in Length ........................... 2
4.1.5
Procedure for Initialisation .............................................................................................................. 2
4.1.6
Procedure for Data Transfer ............................................................................................................ 3
4.1.7
Procedure for Reset ......................................................................................................................... 6
4.1.8
Procedure for Restart ....................................................................................................................... 8
4.1.9
Procedure When Link Layer is Out of Order ................................................................................ 10
4.1.10
Diagnostic Code Values ................................................................................................................ 10
4.1.11
Resetting Cause Field Values ........................................................................................................ 11
4.1.12
Restarting Cause Field Values ...................................................................................................... 12
4.2 GUIDANCE MATERIAL ............................................................................................................................ 12
4.2.1
X.25 Packet Layer Functions ........................................................................................................ 12
4.2.2
X.25 Packet Formats ..................................................................................................................... 15
4.2.3
RESTART Procedure .................................................................................................................... 16
4.2.4
RESET Procedure ......................................................................................................................... 16
4.2.5
Flow Control ................................................................................................................................. 19
4.2.6
Error Detection .............................................................................................................................. 19
4.2.7
SVC Set Up and Clearing Procedures ........................................................................................... 19
4.2.8
VC management and SVC implementation .................................................................................. 19
4.2.9
Parameters ..................................................................................................................................... 19
5.
CIDIN Network Layer (3b) ................................................................................................................... 1
5.1.1
The CIDIN Packet protocol Layer .................................................................................................. 1
5.1.2
The CIDIN Packet Header Format .................................................................................................. 1
5.1.3
CIDIN Packet Procedures ............................................................................................................... 3
5.2.1
Functions of the CIDIN Network Layer .......................................................................................... 5
5.2.2
CIDIN Packet Formats .................................................................................................................... 5
Sixth Edition
Page iii of v
14/04/2011
EUR CIDIN MANUAL
5.2.3
Routing and Relay ........................................................................................................................... 6
5.2.4
Multiple Dissemination ................................................................................................................... 7
5.3 STANDARDS AND RECOMMENDED PRACTICES ON SVC IMPLEMENTATION .............................................. 9
5.3.1
Virtual Circuit Management ............................................................................................................ 9
5.3.2
Virtual Circuit Initialisation .......................................................................................................... 10
5.3.3
Call Establishment ........................................................................................................................ 10
5.3.4
Data Transfer ................................................................................................................................. 15
5.3.5
Disconnection ................................................................................................................................ 15
5.3.6
Reception of a RESET Indication Packet ...................................................................................... 16
5.3.7
Reception of an INTERRUPT Indication Packet .......................................................................... 16
5.3.8
Security and Reliability Aspects ................................................................................................... 17
6.
Transport Layer (4) ............................................................................................................................... 1
6.1.1
The Transport Protocol Layer ......................................................................................................... 1
6.1.2
The Transport Protocol.................................................................................................................... 1
6.2.1
Functions of the CIDIN Transport Layer ........................................................................................ 8
6.2.2
Entry Centre (Ae) ............................................................................................................................ 8
6.2.3
Exit Centre (Ax) ............................................................................................................................ 10
6.2.4
CIDIN Transport Protocol Formats ............................................................................................... 12
6.2.5
Message Identification and Addressing......................................................................................... 12
6.2.6
Acknowledgement Procedures ...................................................................................................... 14
6.2.7
Error Handling .............................................................................................................................. 14
6.2.8
Form of the Service Interface to the Transport Layer ................................................................... 15
6.2.9
Enquiry (ENQ) procedures............................................................................................................ 17
6.2.10
Flow Control ................................................................................................................................. 17
6.2.11
Parameters ..................................................................................................................................... 17
7.
The AFTN Interface ............................................................................................................................... 1
7.1 INFORMATION MAPPING ............................................................................................................................ 1
7.2 LOGICAL VIEW ......................................................................................................................................... 1
7.3 AFTN HEADER AND MESSAGE PART........................................................................................................ 1
7.4 ADDRESS MAPPING ................................................................................................................................... 2
7.5 PRIORITY MAPPING ................................................................................................................................... 2
7.6 ERROR HANDLING ..................................................................................................................................... 3
7.7 ERRORS REQUIRING OPERATOR ACTION .................................................................................................... 3
8.
Statistics .................................................................................................................................................. 1
8.1 FUNCTIONAL AREAS ................................................................................................................................. 1
8.2 APPLICATION LAYER STATISTICS............................................................................................................... 1
8.3 LAYER 4 STATISTICS ................................................................................................................................. 1
8.4 LAYER 3B STATISTICS ............................................................................................................................... 2
8.5 LAYER 3A/2 STATISTICS ............................................................................................................................ 2
8.6 ADDITIONAL STATISTICS ........................................................................................................................... 2
9.
Testing ..................................................................................................................................................... 1
9.1 INTRODUCTION ......................................................................................................................................... 1
9.2 SCOPE ....................................................................................................................................................... 1
9.3 GENERAL PRINCIPLES ............................................................................................................................... 1
9.4 CIDIN TEST STRATEGY ............................................................................................................................ 1
9.5 DESCRIPTION TECHNIQUE ......................................................................................................................... 2
9.6 PERFORMANCE OF THE TESTS ................................................................................................................... 5
9.7 CONFORMANCE TESTING .......................................................................................................................... 6
9.7.1
General ............................................................................................................................................ 6
9.7.2
Physical Layer ................................................................................................................................. 6
9.7.3
Data Link Layer .............................................................................................................................. 6
9.7.4
X.25 Network Layer ........................................................................................................................ 7
9.7.5
CIDIN Network Layer .................................................................................................................... 9
9.7.6
CIDIN Transport Layer ................................................................................................................. 10
9.7.7
Application Interface ..................................................................................................................... 12
9.8 INTEROPERABILITY TESTING................................................................................................................... 13
9.9 TESTING PHASES IN CIDIN ..................................................................................................................... 16
9.9.1
Conformance testing (single layer - local) .................................................................................... 16
Sixth Edition
Page iv of v
14/04/2011
EUR CIDIN MANUAL
9.9.2
Conformance testing (Single layer - remote) ................................................................................ 16
9.9.3
Interoperability testing (bilateral) .................................................................................................. 17
9.9.4
Interoperability testing (quadrilateral)........................................................................................... 17
9.9.5
Network extension ........................................................................................................................ 18
10. Operational Procedures ......................................................................................................................... 1
10.1 INTRODUCTION OF NEW CIDIN COM CENTRES IN THE INTERNATIONAL NETWORK ................................ 1
10.1.1
Preconditions ................................................................................................................................... 1
10.1.2
Stepwise approach ........................................................................................................................... 1
10.1.3
Routeing arrangements for the Ax of the new COM Centre ........................................................... 1
10.1.4
Introduction of the operational AFTN Routeing Tables ................................................................. 1
10.2 QSP PROCEDURE IN CIDIN OPERATIONS .................................................................................................. 3
10.2.1
Introduction ..................................................................................................................................... 3
10.2.2
Message Types ................................................................................................................................ 3
10.3 ROUTING UPDATE PROCEDURE IN THE CIDIN NETWORK ......................................................................... 4
10.3.1
Purpose of the procedure ................................................................................................................. 4
10.3.2
Procedure and Documentation ........................................................................................................ 4
11. Quality of Service ................................................................................................................................... 1
11.1 INTRODUCTION ......................................................................................................................................... 1
11.2 REQUIREMENTS ........................................................................................................................................ 1
11.3 ENABLERS ................................................................................................................................................. 1
11.4 STANDARD PERFORMANCE MEASUREMENT METHOD ................................................................................ 2
11.4.1
Capacity assessment of a switch ..................................................................................................... 2
11.4.2
Transit time assessment ................................................................................................................... 2
Attachment A: Change Control Mechanism of the EUR CIDIN Manual ............................................... 1
A.1 PROCEDURE FOR DR ................................................................................................................................. 1
A.2 PROCEDURE FOR CP.................................................................................................................................. 1
A.3 TEMPLATE FOR DEFECT REPORTS / CHANGE PROPOSALS ......................................................................... 2
Sixth Edition
Page v of v
14/04/2011
EUR CIDIN MANUAL
1.
1.1
Introduction
Purpose of this Manual
1.1.1
1.1.2
Chapter 1
The objectives of the CIDIN manual are to:
Provide guidance to implementers and users,
Define uniquely the requirements placed on an implementation of the CIDIN

protocols so that implementations may be compatible with each other,
Review the rationale of the protocols,
Define tests to be performed on protocol implementations, and
Describe the interfaces of applications to CIDIN.
The manual is organised into the following format:
Chapter 1 provides an overview of CIDIN and the ISO 7 layer model. Appendix
B details optional parameters of the CIDIN protocol layers.
Chapter 2 describes the physical layer.
Chapter 3 describes the link layer
Chapter 4 describes the network layer. Appendix F contains guidance

information on the implementation of SVCs.
Chapter 5 describes the CIDIN network layer. Appendix G contains detailed

profile information for PVCs and SVCs.
Chapter 6 describes the transport layer. Appendix E contains information on

interface primitives of the state transition diagrams which describe the functions
of the transport layer.
Chapter 7 describes the AFTN interface.
Chapter 8 describes the statistical requirements for CIDIN.
Chapter 9 describes the test strategy for routing implementations. Appendix D

contains detailed material corresponding to this chapter.
Chapter 10 provides information relating to the operation of the CIDIN network.
Chapter 11 provides information relating to Quality of Service.
Sixth Edition
Page 1 of 10
14/04/2011
EUR CIDIN MANUAL
1.2
A Common Network for Various Applications
1.2.1
Existing Services
1.2.1.1
The conventional AFTN represents a large investment in equipment and operations.

Nevertheless it is capable of supporting only one type of application, i.e. those applications
which can communicate via the transmission of AFTN messages. Other types of
applications such as:
interactive computer applications (response times in seconds),
conversational mode between terminals (session relationship between users),
transmission of facsimile data (binary data, not characters), and
file transfer applications (large messages and data volumes)
cannot be supported by AFTN even though the locations of these aeronautical applications
coincide with those normally served by AFTN stations.
1.2.1.2
The installation and maintenance of networks dedicated to one special application is an

inefficient use of valuable resources such as switches, operating personnel etc. There is a
potential cost benefit in a common ICAO network.
1.2.1.3
CIDIN allows the possibility of data interchange between computers and between
terminals and computers.
Applications which fall in this category are:
Air Traffic Services,
Aeronautical Information Service,
Operational Meteorological Service and
Search and Rescue Service.
1.2.1.4
The implementation of CIDIN has significantly improved the operation of the Air
Navigation Services. It is possible that applications as yet not identified will be
implemented using the service provided by CIDIN.
1.2.1.5
Although ICAO is concerned with international data interchange standards, individual

States are equally concerned with any special interfacing or equipment costs that such
standards might impose on national plans. The goal is to minimise interface costs and to
avoid the provisioning of special national facilities significantly different from
international facilities.
Chapter 1
Sixth Edition
Page 2 of 10
14/04/2011
EUR CIDIN MANUAL
1.2.2
CIDIN architecture
1.2.2.1
The Reference Model for Protocol Layers
1.2.2.1.1
The design of CIDIN follows existing standards for data communications and fits into the
ISO 7 layer model. However, because of the design history of CIDIN, it spans two layers
of the model i.e. layers 3 and 4. Because of this, layer 3 has been subdivided into two
layers: 3 (network) and 3b (CIDIN Network).
1.2.2.1.2
Current international communications protocol standardisation work is based on the

Reference Model for Open Systems Interconnection. The concepts of the Reference Model
are contained in the ISO standard ISO 7498 (and its various addenda) and in the
corresponding CCITT recommendation X.200.
1.2.2.1.3
A system, which can communicate with other systems, is an implementation of a collection

of different functions or procedures. (The implementation can be in hardware, software or
in manual procedures.) The basic concept of the Reference Model is to separate the
functions into a number of groups or layers. It describes which communication functions
belong to which layer, without defining any specific communication procedures to execute
the functions. This structure, however, lays down the framework or architecture for the
definition of procedures.
1.2.2.1.4
There are good reasons for dividing the functions in this way:
The rules for communication between a layer in one system and the
corresponding layer in another system (a "protocol") are independent from the
rules for other higher or lower layers. A protocol therefore belongs to a specific
layer and may perform only the functions allowed there. This reduces
considerably the number of different protocols which have to be defined and
implemented. Protocols belonging to the same layer can be easily compared.
The functions resident in the lower layers are basic and hardware-oriented. The
functions in the upper layers are more user- or application-oriented. In principle
it is possible to change the protocol in one layer without affecting the protocols
being used in other layers, allowing considerable system flexibility.
The separation of communication functions into layers with reduced

functionality simplifies the task of defining the protocols.
1.2.2.1.5
The set of functions, which a protocol layer provides to the layer above it (its "user"), is
called the "service" of the layer. Addressing according to the Reference Model takes place
between points ("service access points") at the service interface. In general, it is the task of
a layer to take the service provided to it by the layer below and turn it into a more
application-oriented service for the user of the layer. A service according to the Reference
Model is, however, only an abstract concept and there are no strict requirements for
implementing the service interface corresponding to a particular layer and protocol.
1.2.2.1.6
On the other hand, the protocol executed between two parts of a layer in different systems
(i.e. "the peer-to-peer protocol" or the protocol between two "peer entities") must obey the
same rules in both implementations. The rules are expressed by the exchange of logical units
of data called "protocol data units", PDUs. It follows from the basic principles of the model
that the PDUs of one layer are encapsulated into the PDUs of the layer below it for
transmission. This leads to a nested structure for the PDU headers. When protocol
implementations are tested for compatibility, the adherence to the protocol rules and the
correct coding of the PDUs must be investigated.
1.2.2.1.7
In order to structure the functions of a layer in a more logical way, the Reference Model
allows the separation of a layer into "sub-layers". For example, the structure of the network
Chapter 1
Sixth Edition
Page 3 of 10
14/04/2011
EUR CIDIN MANUAL
layer according to the ISO shows three sub-layers with well defined functions. The principles
defined for the layers of the Reference Model apply correspondingly to sub-layers as well.
1.2.2.1.8
These basic concepts of the Reference Model are illustrated in Figure 1.1.
System A
System B
Users of
Users of
the system
the system
N-service
N-service
Peer-to-peer protocol
of layer (N)
layer N
(N-1)-service
(N-1)-service
layer N-1
Peer-to-peer protocol
of layer (N-1)
physical connection
Figure 1.1 Concepts Used in Connection with the Reference Model for Open Systems
Interconnection
1.2.2.2
The Functions of the Layers
1.2.2.2.1
The Reference Model for Open Systems Interconnection identifies seven distinct layers
with the following functions.
1.2.2.2.2
The application layer is the highest layer and contains the user functions which the system
is designed to perform. The functions of the other layers are subordinate to the application
functions.
Chapter 1
The presentation layer is responsible for negotiating the form in which the
application data are expressed (data syntax) and ensures that the applications are
communicating in the same "language".
The session layer manages the logical relationships between users over time
("sessions") together with synchronisation and dialogue aspects.
Sixth Edition
Page 4 of 10
14/04/2011
EUR CIDIN MANUAL
The transport layer is responsible for the reliable transport of data from end
system to end system independently of the network resources used.
The network layer manages the transmission of data through the network(s)
used with the associated tasks of routing, flow control, error recovery etc.
The link layer has the task of transmitting data across the individual physical
connections in the network.
The physical layer as the lowest layer is concerned with physical interfaces
(interchange circuits and their electrical characteristics).
1.2.2.2.3
The Reference Model recognises two types of relationships between users on some layers,
viz. connection-oriented and connectionless. A connection-oriented relationship involves a
fixed association between communicating partners and can consist of connection
establishment, data transfer and disconnection phases. A connectionless relationship does
not maintain this fixed association.
1.2.2.2.4
In terms of the Reference Model, CIDIN provides its users with a connectionless transport
service.
1.2.2.2.5
CIDIN does not contain implementations of protocols above the transport layer. Applications
using CIDIN are responsible for providing these functions themselves (concerning the
application "AFTN", see section 1.2.2.4).
1.2.2.2.6
CIDIN does not maintain fixed relationships between its users since the service is
connectionless. For applications such as interactive dialogue, a session relationship must be
established by the user (e.g. in a session protocol).
1.2.2.2.7
Since CIDIN provides a transparent transport service, it is "open" in the sense that any
application can use it if the service characteristics are suitable.
1.2.2.3
The CIDIN Protocols
1.2.2.3.1
Figure 1.2 illustrates the architecture of the CIDIN protocols using the concepts of the
Reference Model. In the example, the upper figure shows the spatial relationships between
CIDIN centres and the lower figure the logical relationships between protocol layers.
1.2.2.3.2
The example shows two entry/exit centres (A and C) and a relay centres (B) used for
transmitting a message (a transport PDU) through CIDIN from A to C or vice versa. The
message is not multiply disseminated. The functions of the CIDIN centres (entry/exit or
relay) refer to this particular message: for another path through the network the functions
could be distributed differently.
1.2.2.3.3
The transport protocol (layer 4) is not "seen" in the relay centres: the data expressing the
transport protocol are processed transparently there. This is a necessary feature of the
transport layer since it only has end-to-end significance.
Chapter 1
Sixth Edition
Page 5 of 10
14/04/2011
EUR CIDIN MANUAL
B
Boundary
of CIDIN
Messages
Messages
3b
3b
3a
3a
1
B
routing and relay

functions
A, C = Entry/exit centres
B=
Relay centre performing PVC termination functions in level 3a and

relay functions in level 3b
Figure 1.2 The Functions of CIDIN Centres Related to Protocol Layers

1.2.2.3.4
The network layer (layer 3) consists of the two sub-layers layers 3a and 3b. Layer 3a is a
"network access protocol" while layer 3b is necessary to raise the level of functionality of
the network layer to the required service.
1.2.2.3.5
The two sides of a relay centre operate independently from each other except at their
topmost layer 3b where a bridge (shaded area) joins the two sub-layer entities. The
principal function of this bridge is routing of CIDIN packets.
1.2.2.3.6
In a CIDIN relay centre the two layer 3a entities have no direct relationship. Routing is done
on the next higher sub-layer, in the bridge in sub-layer 3b.
1.2.2.3.7
The connection between centres B and C is shown in the figure to be implemented with a
leased line. As indicated in para.2.2.3, this may also be implemented via a PSN. In this case,
the protocol layers 1, 2 and 3a become network access protocols, accessing the PSN, rather
than being protocols between the centres B and C as in the figure. The protocol on layer 3b
Chapter 1
Sixth Edition
Page 6 of 10
14/04/2011
EUR CIDIN MANUAL
will not be affected by this change, i.e. it remains a protocol between centres B and C and is
transmitted transparently by the PSN.
1.2.2.3.8
Layers 1 to 3a in CIDIN correspond to the CCITT recommendation X.25 for PVCs and
optionally, SVCs. Layers 3b and 4 are special ICAO protocols: no other internationally
standardised protocols fulfil at the moment the requirements of CIDIN on these layers.
Because the CIDIN transport layer provides a transparent transport service to its user,
implementations of the OSI standard protocols for layers 5 and 6 can be used in the
applications supported by CIDIN.
1.2.2.3.9
Major users of CIDIN, interfacing to it with software on top of the transport layer, are the
conventional AFTN and OPMET. Other applications are necessary for network management
i.e. the communication of information relating to network congestion, network configuration,
re-routing, degradation in quality of service, service messages, etc. This message exchange
can be between CIDIN operators and/or network management applications. The design of
CIDIN does not, in principle, restrict the range of other possible user applications which can
be supported.
1.2.2.3.10 The names of the logical information units (PDUs) on the respective layers are as follows:
layer 4 :
CIDIN message
layer 3b:
CIDIN packet
layer 3a:
X.25 packet
layer 2 :
data link frame
1.2.2.4
The AFTN Interface
1.2.2.4.1
Amongst the many possible applications which can be supported, the conventional AFTN
is a special user of CIDIN. AFTN manual teletypewriter procedures, as defined in Annex
10, form essentially a transport protocol according to the classification of the Reference
Model; the higher layer functions being performed manually. For reasons of efficiency, the
CIDIN transport and packet protocols reflect aspects of AFTN message coding. When
transporting an AFTN message, some items of the AFTN message must be mapped onto
the CIDIN transport and packet headers in the entry centre and mapped out of the CIDIN
transport and packet headers at the exit centre. The transport service user called the "AFTN
interface" performs this mapping.
1.2.2.4.2
Figure 1.3 illustrates this situation (compare Figure 1.2) without the intermediate relay
centres. Two CIDIN entry/exit centres are shown together with their associated AFTN
centres and stations. The figure does not imply that AFTN and CIDIN functions should be
implemented on the same or on different equipment; this is a local matter, which does not
need to be standardised. The shaded box represents the interfacing function performing the
mapping. This can be implemented together with the AFTN functions or with the CIDIN
functions.
1.2.2.4.3
Apart from the mapping which is explicitly described in this manual, AFTN messages are
conveyed transparently by CIDIN.
1.2.2.4.4
The format of the AFTN messages is specified in ICAO Annex 10 Volume II. For these
messages the MCF value 2 has been allocated. The fifth character of the Ae/Ax shall be
A.
Chapter 1
Sixth Edition
Page 7 of 10
14/04/2011
EUR CIDIN MANUAL
Transport of AFTN messages via CIDIN:
AFTN
Interface
AFTN
centre
AFTN
Interface
4
3b
3b
3a
3a
CIDIN
entry/exit
centre
CIDIN
entry/exit
centre
AFTN
centre
Logical Equivalent:
Leased Line
Figure 1.3 Logical View of the AFTN Interface to CIDIN
1.2.2.5
The Network Management Interface
1.2.2.5.1
Network Management Messages (commonly referred to as operator messages) enable

operators of CIDIN centres to exchange free-text information within the framework of
CIDIN network management. Unlike the AFTN application, there is no requirement for
destination addressing.
1.2.2.5.2
The structure of the CUDF for Network Management Messages is:
CUDF
Message part
nm_identifier
nm_function +
message_type
Value / Specification
(NM)
OP
message_body
1{line}24 maximum 1968 characters
line
cr + lf + {ia5_printable_characters}80
Note 1: cr carriage return (ia5 encoding)

lf line feed (ia5 encoding)
Chapter 1
Sixth Edition
Page 8 of 10
14/04/2011
EUR CIDIN MANUAL
1.2.2.5.3
For these messages the MCF value 1 has been allocated. The fifth character of the Ae/Ax
shall be M. The value of the priority parameter is from 1 to 8 as determined by the
sending operator.
1.2.2.5.4
A description of the Network Management application parameters is presented in

Appendix B. The format of various types of CIDIN network management messages
(operator, routing, statistics) is specified in appropriate sections of this Manual.
1.2.2.6
The OPMET Interface
1.2.2.6.1
Distribution of alpha-numerical meteorological products (OPMET) is another application

which is supported by CIDIN. Unlike AFTN, there is no special requirement for
destination addressing; rather there are requirements for the mapping of OPMET data onto
the CIDIN User Data Field.
1.2.2.6.2
The format of the OPMET messages is specified in WMO document 386. The structure of
the CUDF for messages in OPMET format is:
Message part
Modified starting line
Abbreviated heading
CUDF
Text (IA-5 only)

End of message signals
Component of the message part

Start of heading (SOH)
Alignment function
Data designators
ICAO location indicator
International date-time group
Optional BBB group
Alignment function
Text of a meteorological bulletin (15000 octets max.)
Alignment function
End-of-text (ETX)
1.2.2.6.3
For these messages the MCF value 3 has been allocated. The fifth character of the
Ae/Ax shall be O. The priority value of OPMET messages is from 1 to 8.
1.2.2.6.4
The format of OPMET operator messages (including MCF) is identical to that of CIDIN
network management messages. However, the fifth and sixth characters of the Ae/Ax are
MM. The priority of OPMET operator messages is 6.
1.2.2.6.5
A description of the CIDIN OPMET and CIDIN OPMET operator message parameters is
presented in Appendix B.
1.2.2.7
The ATN Subnetwork Interface
1.2.2.7.1
When CIDIN is used as an ATN subnetwork, the CIDIN transport service assumes the socalled ATN Subnetwork Access Role. A particular subnetwork dependent convergence
function (CIDIN SNDCF) has been defined for the adaptation of the CIDIN transport
service to the requirements of the ATN inter-network layer. A given ATN Network
Protocol Data Unit is mapped onto one or more CIDIN User Data Fields. Neither the
destination address feature nor the network acknowledgements of the CIDIN are used.
1.2.2.7.2
The CIDIN SNCDF is specified in the ICAO Document 9705-AN/956. Related Guidance
Material, especially for the modelling of the access to the CIDIN transport service, is
provided in ICAO Document 9739-AN/961.
1.2.2.7.3
For the ATN subnetwork role of the CIDIN, the MCF value 4 has been allocated. The
CIDIN priorities 2, 5 and 7 are used. There is no special recommendation for the fifth to
eighth characters of the Ae/Ax used.
Chapter 1
Sixth Edition
Page 9 of 10
14/04/2011
EUR CIDIN MANUAL
1.2.2.7.4
1.3
A description of the CIDIN ATN subnetwork parameters is presented in Appendix B.
Optional Parameters and X.25 Version
1.3.1
The network layer adheres to CCITT X.25 (1980) although this does not restrict the usage
of later versions if experience shows backward compatibility with older CIDIN centres.
1.3.2
A number of configurable parameters are associated with CIDIN. Their values depend on
network design and operating experience. The recommended values are contained in
Appendix B.
Chapter 1
Sixth Edition
Page 10 of 10
14/04/2011
EUR CIDIN MANUAL
2.
2.1
Physical Layer (1)

Standards and Recommended Practices
2.1.1
Analogue or digital transmission means are used for the conveyance of CIDIN data. The
transmission speed shall be agreed bilaterally; it shall be determined according to the data
volume and available infrastructure.
2.1.2
The physical link protocol shall be as described in section 8.6.2 of ICAO Annex 10,
Volume III.
2.2
Guidance Material
2.2.1
The physical layer is the lowest layer and has no service provider. Its function is to make
the data transmission capability of the circuits available to the data link layer in the CIDIN
centre.
2.2.2
Aspects of the data transmission service are:
2.2.3
Transparency
Any bit sequence can be transmitted and received
Full duplex operation
Simultaneous transmission and reception is possible
Line synchronism
Timing signals are provided by the circuit and not by the user
Error detection
The user is notified in the case of physical errors, e.g. circuit failure or loss of
synchronism.
In general, physical circuits for the transmission of data in CIDIN are provided by a
network carrier (e.g. PTT). This means that standards for the interface between the Data
Terminal Equipment (DTE) and the Data Circuit-Terminating Equipment (DCE) have to
be observed. Depending upon the type of circuit or public data network used, specific
CCITT standards for the physical interface are required:
V.24/V.28 describes the interface between DTE and DCE for data transmission via an
analogue circuit, i.e. the way in which the modem is controlled by the DTE and the
electrical characteristics of the signals.
Note. The range of interchange circuits defined in the Recommendation V.24 relates to
various applications and alternative implementations. Thus, in a particular case, only a
subset of interchange circuits will be applicable.
X.21 (including X.24 and X.27) contains a description of the physical interface
between DTE and DCE for synchronous operation on Public Data Networks (PDN).
Note. The PDN may be a packet or circuit switched network.
X.21bis describes the V.24 based physical interface to a PDN.
Chapter 2
Sixth Edition
Page 1 of 2
14/04/2011
EUR CIDIN MANUAL
2.2.4
Chapter 2
The way in which the interface to the physical circuit is made available to the data link
layer in a CIDIN centre is a local matter not subject to standardisation within CIDIN.
Sixth Edition
Page 2 of 2
14/04/2011
EUR CIDIN MANUAL
3.
3.1
Link Layer (2)

3.1.1
Packets to be transferred between two CIDIN switching centres or a CIDIN switching

centre and a PDN shall be formatted into data link frames.
3.1.2
Each data link frame shall consist of a data link control field (DLCF), possibly followed by
a link data field, and shall be terminated by a frame check sequence and flag (being the
second part of the DLCF). If a link data field is present, the frame shall be denoted as an
information frame.
3.1.3
X.25 packets shall be transmitted within the link data field of information frames. Only one
packet shall be contained in the link data field.
3.1.4
The data link protocol shall be as described in section 8.6.4 of ICAO Annex 10, Vol. III.
3.2
Guidance Material
3.2.1
Data Link Layer Functions
3.2.1.1
3.2.1.2
The data link layer provides its users with the capability of sending and receiving bit
strings. Some of its characteristics are:
Transparency
Any bit sequences can be sent and received.
Timing independence
The user is not required to send or receive information continuously but can use the service
randomly according to requirements. The service is "balanced" in the sense that the users
on both sides of the link have equal rights
3.2.1.3
3.2.1.4
Chapter 3
Data integrity
The data link layer effectively guarantees to its users that the bit strings sent and received
are free from bit errors. The probability that bit errors are not detected is very low.
Link establishment
The layer establishes and maintains the logical relationship with its partner
entity
Notification of link failures
The user is notified when the link has failed or has been re-established after a
failure.
The protocol used for the data link layer in CIDIN is a particular variant of the ISO High
Level Data Link Control procedures (HDLC), called LAP-B (Link Access Procedure,
Balanced Class) by CCITT. It is used in a point-to-point configuration. The term
"balanced" means in this context that the communicating DTE and DCE share equal status
with respect to sending and receiving. LAP-B forms layer 2 of the CCITT
Recommendation X.25.
Sixth Edition
Page 1 of 6
14/04/2011
EUR CIDIN MANUAL
3.2.2
Frame Structure and Formats
3.2.2.1
The data units which form the basis of the protocol (protocol data units, PDUs) are called
"frames" (see Figure 3.1). Only complete frames have any significance in the protocol. The
delimiter which marks the beginning and end of a frame is the special bit sequence
01111110, called a flag.
3.2.2.2
The flag is also used to fill the gap between the transmission of frames. The transmission
sequence on the line is therefore:
<flags><frame><flags><frame>
Where:
<flags> represents a sequence of zero or more flags.
3.2.2.3 The structure of a frame is:

F A C information_field FCS F'
Where:
F and F' are flags, F' being optional if another frame follows immediately;
A is an address field;
C is a control field; and
information field represents user data. It is a sequence of octets up to a
maximum length of 259 octets.
FCS is a "frame check sequence"
Data Link
Control Field
Data link Control Field
Flag
Address
Control Field
Frame Check
Sequence
User Data
Figure 3.1 Frame Structure

3.2.2.4
The control field contains a "command" or "response" together with sequence numbers
where applicable. A response is, in general, a reply to a command. A "poll bit" is used in a
command to request a reply from the partner; a "final bit" is an indication whether a
response is a reply to such a request.
3.2.2.5
The address octet may have two values:
Address A
Address B
3.2.2.6
Chapter 3
Bit 8
0
0
0
0
0
0
0
0
0
0
0
0
1
0
Bit 1
1
1
All other address values are invalid. Allocation of addresses is by bilateral agreement
between concerned States (see Parameters, section 3.2.7). Addresses are used to
distinguish between commands and responses: a CIDIN centre uses its own address when
sending a response and the address of its partner when sending a command. See Figure 3.2
for an example. A CIDIN centre consists logically at the data link layer of two parts
Sixth Edition
Page 2 of 6
14/04/2011
Flag
EUR CIDIN MANUAL
("combined"): a "primary" part sends commands and receives responses while a

"secondary" part receives commands and sends responses.
3.2.2.7
3.2.3
The FCS consists of a 16 bit sequence derived from all the preceding bits in a frame
according to a particular algorithm. It is used to show when bit errors have occurred in the
transmission of a frame. The probability that bit errors have occurred without this being
indicated by the FCS is very low.
Transparent Transmission of Bit Strings
3.2.3.1
The information part of a frame can be any bit string. This includes the possibility of the
bit combination for a flag. In order to maintain the integrity and identity of a frame, a flag
must be recognised exclusively as a delimiter. The method for transmitting the bit
combination for a flag without the function of a flag is called "bit stuffing" and operates as
follows.
3.2.3.2
If, when sending information other than flags, a station recognises a continuous sequence
of 5 1-bits, an additional bit set to 0 is inserted into the sending sequence.
3.2.3.3
If, when receiving, a station recognises a sequence of five 1-bits followed by a 0-bit, the 0bit is removed from the bit sequence.
3.2.3.4
This procedure guarantees that any bit string can be transmitted. Figure 3.3 shows the
logical relationships between the bit-stuffing, FCS and flag procedures.
3.2.4
Link States and Modes
3.2.4.1
A link is either in the idle or active state. The idle state is the initial state when the link is
brought into operation, e.g., when one of the stations is still being initialised. The active
state is entered when both stations are transmitting bit sequences recognised by the
procedure. Within the active state, the procedure distinguishes between two modes. The
non-operational and operational modes are called asynchronous disconnected mode
(ADM) and asynchronous balanced mode (ABM) respectively. The modes are
"asynchronous" since the CIDIN centres perform their own timing and scheduling at layer
2 and are co-ordinated only by the elements of the procedure. ABM is "balanced" since the
communicating CIDIN centres have equal status: they are distinguished only by the
differing addresses.
3.2.4.2
The transition of the link between ADM and ABM is affected by the exchange of
"unnumbered" frames i.e. frames which contain no sequence numbers referring to other
frames. The mode transition takes place in general when the CIDIN centre initiating it has
sent an unnumbered command and has received an unnumbered response as a reply. Either
CIDIN centre can initiate a mode transition. The situation in which both centres initiate the
transition simultaneously is known as a contention.
Chapter 3
Sixth Edition
Page 3 of 6
14/04/2011
EUR CIDIN MANUAL
Commands
Primary
Secondary
Responses
Commands
Secondary
Primary
Responses
CIDIN centre with

address A
CIDIN centre with

address B
Command
(B)
Command
(A)
Response
(A)
Response
(B)
Command (B) and

poll bit set
Response (B) and poll

bit set
Command (A) and
poll bit set
Response (A) and
final bit set
Figure 3.2 Example of Combined Operation in the Data Link Layer
3.2.5
Numbered Frames and Flow Control
3.2.5.1
The "numbered" frames are transmitted in operational mode (ABM). The purpose of the
numbering is to permit a sequencing of the frames and to allow one centre to refer to the
frames sent by its partner. The sequence numbers are coded as binary numbers in three bits
and therefore obey the rules of modulo 8 arithmetic.
3.2.5.2
The numbered frames are classified into information and supervisory frames. An
information or I-frame is used to transmit user data while the supervisory frames are used
to control the exchange of I-frames. An I-frame (always a command) carries in its control
field a send sequence number indicating the position of the frame in the string of user data
sent on the link.
3.2.5.3
The sequence numbers provide a means for acknowledging I-frames by the receiving
centre. An acknowledgement gives the sequence number of the next I-frame expected by
that receiving centre thereby implicitly acknowledging all I-frames with send sequence
numbers less than this number. A sending centre may not have more than a certain number
of I-frames unacknowledged. This maximum number of outstanding I-frames is known as
the "window" of a link and is a measure of the buffering capacity on layer 2 of the centres
communicating on it. In order that the I-frames can be identified uniquely with the
sequence numbers, the window size must be less than the modulus of the arithmetic used.
Chapter 3
Sixth Edition
Page 4 of 6
14/04/2011
EUR CIDIN MANUAL
For example, satellite links with their relatively long transmission delays require large
windows and extended numbering.
Sender
A,C and info
fields
Receiver
FCS Correct
A,C and info fields
FCS indicates
transmission error
FCS generation and

checking procedure
FCS recalculated
and compared
with transmitted
FCS
Bit stuffing
procedure
Any sequence of
6 1-bits in
original data
recreated
FCS generated
Sequence of 6
1-bits modified
Frame unpacked
Frame packed
between flags
Flag generation
and detection
Invalid frames
rejected
transmission circuit
Figure 3.3 Relationship between Bit Stuffing, FCS generation/checking and Flag
Processing
3.2.5.4
3.2.6
If the data transmission is taking place in both directions simultaneously,

acknowledgements can be included in the I-frames since the I-frame also contains a
receive sequence number. The supervisory frames also make use of the receive sequence
number for flow control purposes. The supervisory frame "receive not ready" (RNR), for
example, can be used as an acknowledgement but also to indicate that the receiving centre
is temporarily unable to receive further I-frames. Such a command or response would
normally be initiated by a higher protocol layer which is having difficulties in coping with
the data flow. A sending centre can request the sending of a flow control response by
setting the poll bit in a command to 1.
Error Detection and Recovery
3.2.6.1
The LAP-B protocol is capable of detecting a wide range of error conditions and provides
recovery procedures.
3.2.6.2
Bit transmission errors are detected with high probability with the FCS and recovery is
performed by the various elements of the protocol. An invalid frame with no detected bit
errors is rejected explicitly and recovery is performed by other elements of the protocol.
Procedure errors, such as the transmission of a PDU which is logically out of sequence, are
handled by re-initialising the link, e.g. by re-entering ABM. This can be associated with a
Chapter 3
Sixth Edition
Page 5 of 6
14/04/2011
EUR CIDIN MANUAL
loss of user data. The missing send sequence number indicates the loss of an I-frame;
recovery is normally performed with the reject procedure. Missing responses are detected
with time-out procedures.
3.2.7
Parameters
3.2.7.1
Window size
This is the maximum number (k) of information frames that a station may have
unacknowledged. The recommended value for k is 7.
3.2.7.2
Duration of time-out function T1

T1 is the time after which a frame can be retransmitted. T1 must be greater than the time
normally necessary for the sending of a command and the reception of the corresponding
response. The recommended value for T1 is 3 seconds.
3.2.7.3
Repetition counter N2
N2 is the maximum number of times a frame can be retransmitted after the time-out T1.
The recommended value for N2 is 5.
Chapter 3
Sixth Edition
Page 6 of 6
14/04/2011
EUR CIDIN MANUAL
4.
Network Layer (3a)
4.1
4.1.1
PVC Procedures
4.1.1.1
Each CIDIN packet to be transferred on CIDIN circuits between CIDIN switching centres
shall be formatted into one X.25 packet. When PDN circuits are used, it shall be permissible
to format the CIDIN packet into more than one X.25 packet.
4.1.1.2
The integrity of each CIDIN packet shall be preserved by the X.25 packet protocol by
mapping each CIDIN packet onto one complete X.25 packet sequence, as defined in CCITT
Recommendation X.25 (1981/1984).
4.1.1.3
Each X.25 packet shall consist of an X.25 packet header, possibly followed by a user data
field (UDF).
4.1.1.4
The X.25 packet protocol is based on the application of permanent virtual circuit (PVC)
procedures. A permanent virtual circuit shall be defined as a logical path between two CIDIN
switching centres. If a packet switched data network is used to interconnect two CIDIN
switching centres, the procedure shall provide full compatibility with the procedures to be
followed for PVCs according to CCITT Recommendation X.25 (1981/1984). A packet
switched data network providing an X.25 interface to a CIDIN switching centre may offer a
number of options. The following options shall be selected if available:
4.1.1.5
4.1.2
a)
maximum user data field length of 256 octets; and
b)
default window size of seven, or maximum available.
The following descriptions shall apply to the packet layer procedures for permanent virtual
circuits.
a)
A permanent virtual circuit (PVC) is a logical path which conveys data solely from
one PVC termination centre to a single distant PVC termination centre via an
assigned logical channel on each of one or more data links.
b)
A PVC termination centre is a centre which introduces data into, and receives data
from a PVC.
c)
An octet is a group of 8 consecutive bits.
d)
In the over-all centre architecture, packet layer procedures are considered to exist
above the link procedures and below the transport layer procedures.
Packet Format
4.1.2.1
The packet format used shall be one of the following:
4.1.2.2
Data packet (Figure 4.1), comprising:
Chapter 4
a)
the general format identifier;
b)
the logical channel identifier, comprising a logical channel group number and a
logical channel number;
Sixth Edition
Page 1 of 3
14/04/2011
EUR CIDIN MANUAL
c)
the packet type identifier, including the packet receive sequence number P(R), the
packet send sequence number P(S), and the more data bit M which has no
significance on CIDIN circuits and shall be set to zero;
d)
the user data field, comprising up to 256 octets and ending on an integral octet
boundary.
Note.- Data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 that limit the user data
field to not more than 128 octets may require the use of the m bit. Later versions of
Recommendation X.25 will be reviewed as they are released to ascertain whether or not
they should be adopted.
4.1.2.3
4.1.2.4
4.1.2.5
4.1.2.6
4.1.2.7
RECEIVE READY packet (RR) (Figure 4.2), comprising:

a)
b)
c)
the packet type identifier, including P(R).
RECEIVE NOT READY packet (RNR) (Figure 4.3), comprising:

a)
b)
c)
the packet type identifier, including P(R).
RESET REQUEST packet (Figure 4.4), comprising:

a)
b)
c)
the packet type identifier;
d)
the resetting cause field (see 4.1.11 below);
e)
the diagnostic code (see 4.1.10 below).
RESET CONFIRMATION packet (Figure 4.6), comprising:

a)
b)
c)
d)
transmission order within each octet.
RESTART REQUEST packet (Figure 4.5), comprising:

a)
Chapter 4
Sixth Edition
Page 2 of 3
14/04/2011
EUR CIDIN MANUAL
4.1.2.8
b)
c)
d)
the restarting cause field;
e)
the diagnostic code (see 4.1.10 below).
RESTART CONFIRMATION packet (Figure 4.7), comprising:

a)
b)
c)
the packet type identifier.
4.1.2.9
Each packet shall be completely contained in the link data field of a frame.
4.1.2.10
Only one packet shall be contained in the link data field of a frame.
4.1.2.11
The octets of each packet shall be transferred beginning with octet 1.
4.1.2.12
The bits of each octet shall be transferred beginning with bit 1.
4.1.2.13
The first bit transferred of the logical channel group number, logical channel number, P(R)
and P(S) shall be the arithmetically least significant bit.
transmission order of bits within each octet

8
7
6
5
general format
identifier
0
0
0
1
3
2
1
logical channel
group number
logical channel number
Packet type identifier

P(R)
P(S)
User data field

*
(<= 256 octets )
octet
sequence
1
3
0
4
<=259
* Data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may limit the user
data field to not more than 128 octets. Later versions of Recommendation X.25 will
be reviewed as they are released to ascertain whether or not they should be adopted.
Data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may limit data
packets to not more than 131 octets. Later versions of Recommendation X.25 will be
reviewed as they are released to ascertain whether or not they should be adopted.
Figure 4.1 Reset request packet format
Chapter 4
Sixth Edition
Page 3 of 3
14/04/2011
EUR CIDIN MANUAL

8
7
6
5
general format
identifier
0
0
0
1
3
2
1
logical channel
group number

P(R)
packet type identifier

0
0
0
0

8
octet
sequence
1
7
6
5
general format
identifier
0
0
0
1
2
1
P(R)
3
2
1
logical channel
group number
7
6
5
4
3
2
1
general format
logical channel
identifier
group number
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
1
4
0
diagnostic code
1 1
1
0
1
restarting cause field
0
0
0
0
0
0
diagnostic code
Figure 4.4 Reset request packet

format
7
6
5
general format
identifier
0
0
0
1
3
2
1
logical channel
group number
Figure 4.6 Reset confirmation

packet format
4.1.3
1
4
0
5
octet
sequence
1
7
6
5
4
3
2
1
general format
logical channel
identifier
group number
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
3
1
Octet
sequence
1
Figure 4.5 Restart request

packet format

8
octet
sequence
1
0 1
1
0
1
resetting cause field

0
0
1
0
octet
sequence
1
Figure 4.3 Receive not ready

packet format

7
6
5
general format
identifier
0
0
0
1
3
2
1
logical channel
group number
0
0
0
0
Figure 4.2 Receive ready

packet format

1
1
1
1
1
Figure 4.7 Restart confirmation packet format
Logical channels
4.1.3.1
Each data link shall carry up to 4 096 logical channels also called virtual circuits (VC).
4.1.3.2
Each logical channel shall be designated by a logical channel identifier, a number between
0 and 4 095, inclusive, which equals the logical channel group number multiplied by 28
and added to the logical channel number.
Chapter 4
octet
sequence
1
2
Sixth Edition
Page 2 of 2
14/04/2011
EUR CIDIN MANUAL
4.1.3.3
On each data link used to construct a VC, a logical channel identifier between 1 and 4 095,
inclusive, shall be assigned solely to that VC.
4.1.3.4
The logical channel identifier assigned to a VC on each data link shall not be required to be
identical to the logical channel identifiers assigned to the same VC on other data links.
4.1.3.5
On each data link, and when specified by the procedures described below, a centre shall
transfer RESTART REQUEST and RESTART CONFIRMATION before transferring any
other packets.
4.1.3.6
On each logical channel, and when specified by the procedures described below, a centre
shall transfer RESET REQUEST and RESET CONFIRMATION before transferring any
other packets on that logical channel.
4.1.3.7
A logical channel shall be in one of the following states:
4.1.3.8
4.1.4
a)
unassigned, indicating the logical channel has not been assigned to carry a VC;
b)
restart, indicating that the procedure for restart has been initiated but not completed;
c)
reset, indicating that the procedure for reset has been initiated but not completed;
d)
flow control ready, indicating that the procedure for data transfer is being executed.
In the event of a restart, reset, reset time-out procedure error, outage or restoration of
service, the operator shall be informed, along with the meaning of resetting cause fields
and diagnostic codes as required.
Receiving Unknown Packets and Packets of Less Than Three Octets in Length
4.1.4.1
Unknown packets, packets of less than three octets in length and over-long packets are
non-valid packets.
4.1.4.2
A centre, which receives a packet with a general format identifier not equal to one of the
general format identifiers specified in 4.1.2 above, shall discard the packet.
4.1.4.3
A centre, which receives a packet of less than two octets in length, shall discard the packet.
4.1.4.4
A centre, which receives a packet of at least two, but less than three octets in length shall:
4.1.4.5
4.1.5
a)
if the logical channel is in the unassigned, restart or reset state, discard the packet;
b)
if the logical channel is in the flow control ready state: execute the procedure for reset
with the resetting cause field indicating "local procedure error" and the diagnostic
field indicating "packet type invalid when in flow control ready state".
A centre which receives a packet with a packet type identifier not defined in 4.1.2 above
shall:
a)
if the logical channel is in the unassigned, restart or reset state, discard the packet;
b)
if the logical channel is in the flow control ready state: execute the procedure for reset
with the resetting cause field indicating "local procedure error" and the diagnostic
field indicating "packet type invalid".
Procedure for Initialisation
Chapter 4
Sixth Edition
Page 2 of 20
14/04/2011
EUR CIDIN MANUAL
4.1.5.1
4.1.6
To simultaneously initialise all logical channels conveyed over a single data link, a centre
shall execute the procedure for restart with the diagnostic code indicating "no additional
information".
Procedure for Data Transfer
4.1.6.1
The following descriptions shall apply to the data transfer procedure:

a)
The transfer lower window edge is the oldest P(S) number associated with the
transfer (outgoing) direction of packets whose corresponding data packet has not yet
been acknowledged by a P(R) transferred from the receiving centre.
b)
The receive lower window edge is the oldest P(S) number associated with the receive
(incoming) direction of packets whose corresponding data packet has not yet been
acknowledged by a P(R) transferred from the receiving centre.
c)
The window size W is the maximum number of packets which shall be transferred in
a given direction on a logical channel before waiting for an acknowledgement from
the receiving centre of the data packet with P(S) equal to the transfer lower window
edge.
4.1.6.2
The data transfer procedure shall operate on each logical channel in the flow control ready
state, independently from any other logical channel on that data link.
4.1.6.3
The data transfer procedure shall operate in each direction of data flow, independently
from the opposite direction of data flow.
4.1.6.4
When a logical channel enters the flow control ready state, the receive and transfer lower
window edges shall be set to 0.
4.1.6.5
W shall normally be 7 but other window sizes may be negotiated on a bilateral basis.
Note.- Public data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may require W to be
some other value between 2 and 6, inclusive. Later versions of Recommendation X.25 will
be reviewed as they are released to ascertain whether or not they should be adopted.
4.1.6.6
Arithmetic on lower window edges, P(S) and P(R) shall be performed modulo 8.
4.1.6.7
Receiving data packets
4.1.6.7.1
A centre which receives a data packet on a logical channel which is not in the flow control
ready state shall discard the data packet.
4.1.6.7.2
A centre shall expect the first data packet received after a logical channel enters the flow
control ready state to contain P(S) equal to 0.
4.1.6.7.3
A PVC termination centre which receives a data packet which is less than or equal to the
maximum established length for data packets, and which contains P(S) equal to the next
expected value of P(S), and which contains P(S) less than the receive lower window edge
plus W, shall:
Chapter 4
a)
increment its next expected value of P(S) and, if this value differs from the receive
lower window edge by more than one-half W, execute the procedure to update the
receive lower window edge given in 4.1.6.13;
b)
queue the data packet for processing by the transport layer procedures;
Sixth Edition
Page 3 of 20
14/04/2011
EUR CIDIN MANUAL
c)
if the P(R) is greater than or equal to the transfer lower window edge, and less than or
equal to the P(S) to be assigned to the next data packet for transfer:
1) set the transfer lower window edge to equal P(R);
2) consider all unacknowledged data packets which have been transferred with P(S)
less than the new value of the transfer lower window edge as acknowledged and
delivered to the next centre;
d)
4.1.6.7.4
4.1.6.7.5
4.1.6.7.6
if the P(R) is not greater than or equal to the transfer lower window edge, and not less
than or equal to the P(S) to be assigned to the next data packet for transfer: execute
the procedure for reset with the resetting cause field indicating "local procedure error"
and the diagnostic code field indicating "invalid P(R)".
A centre which receives a data packet which is less than or equal to the maximum
established length for data packets, and which contains P(S) equal to the next expected
value of P(S), and which contains P(S) equal to or beyond the receive lower window edge
plus W, shall:
a)
discard the data packet;
b)
execute the procedure for reset, with the resetting cause field indicating "local
procedure error" and the diagnostic code indicating "invalid P(S)";
A centre which receives a data packet which is less than or equal to the maximum
established length for data packets, and which contains P(S) not equal to the next expected
value of P(S), shall:
a)
b)
procedure error" and the diagnostic code indicating "invalid P(S)".
A centre which receives a data packet greater than the maximum established length for
data packets shall:
a)
b)
procedure error" and the diagnostic code indicating "packet too long";
4.1.6.8
Transferring RECEIVE NOT READY
4.1.6.8.1
A centre which is becoming temporarily unable to accept further data packets shall transfer
a RECEIVE NOT READY with P(R) equal to the receive lower window edge.
4.1.6.9
Receiving RECEIVE NOT READY
4.1.6.9.1
A centre which receives a RECEIVE NOT READY on a logical channel which is not in
the flow control ready state shall discard the RECEIVE NOT READY.
4.1.6.9.2
A centre which receives a valid RECEIVE NOT READY shall:

a)
1)
Chapter 4
set the transfer lower window edge to equal P(R);
Sixth Edition
Page 4 of 20
14/04/2011
EUR CIDIN MANUAL
2)
consider all unacknowledged data packets which have been transferred with P(S)
3) stop transferring data packets until a RECEIVE READY is received or the logical
channel re-enters the flow control ready state;
b)
than or equal to the P(S) to be assigned to the next data packet for transfer, execute
and the diagnostic code field indicating "invalid P(R)".
4.1.6.9.3
A centre which receives a non-valid RECEIVE NOT READY shall execute the procedure
for reset, with the resetting cause field indicating "local procedure error" and the
appropriate diagnostic code.
4.1.6.10
Transferring RECEIVE READY
4.1.6.10.1 A centre which was becoming temporarily unable to accept further data packets and thus
transferred one or more RECEIVE NOT READYs, and which subsequently has become
able to accept further data packets, shall transfer a RECEIVE READY with P(R) equal to
the receive lower window edge.
4.1.6.11
Receiving RECEIVE READY
4.1.6.11.1 A centre which receives a RECEIVE READY on a logical channel which is not in the flow
control ready state shall discard the RECEIVE READY.
4.1.6.11.2 A centre which receives a valid RECEIVE READY shall:
a)
1) set the transfer lower window edge to equal P(R);
2) consider all unacknowledged data packets which have been transferred with P(S)
3) resume transferring data packets;
b)
than or equal to the P(S) to be assigned to the next data packet for transfer, execute
and the diagnostic code field indicating "invalid P(R)";
4.1.6.11.3 A centre which receives a non-valid RECEIVE READY shall execute the procedure for
reset, with the resetting cause field indicating "local procedure error" and the appropriate
diagnostic code.
4.1.6.12
Transferring data packets
4.1.6.12.1 The first data packet transferred in each direction after a logical channel (re-enters the flow
control ready state shall have P(S) equal to 0, and each subsequent data packet shall have a
P(S) equal to the P(S) of the preceding data packet plus one.
4.1.6.12.2 When transferring a data packet, the procedure for updating the receive lower window
edge shall be executed and the P(R) shall then be set equal to the value of the receive lower
window edge.
Chapter 4
Sixth Edition
Page 5 of 20
14/04/2011
EUR CIDIN MANUAL
4.1.6.12.3 A data packet shall not be transferred when the P(S) is equal to or beyond the transfer
lower window edge plus W.
4.1.6.13
Procedures for updating the receive lower window edge (see 4.1.6.7.4 a) and 4.1.6.7.5 a))
4.1.6.13.1 A PVC termination centre shall set the receive lower window edge to equal the next
expected P(S).
4.1.6.13.2 A centre which has changed the value of the receive lower window edge, and which cannot
send a data packet, and which remains temporarily unable to accept further data packets,
shall transfer a RECEIVE NOT READY.
4.1.6.13.3 A centre which has changed the value of the receive lower window edge, and which cannot
send a data packet, and which is able to accept further data packets, shall transfer a
RECEIVE READY.
4.1.7
Procedure for Reset
4.1.7.1
The procedure for reset shall be used to reinitialise a logical channel.
4.1.7.2
A centre shall not initiate the procedure for reset when the logical channel is in the restart
or unassigned state.
4.1.7.3
A centre shall initiate the procedure for reset as follows:

a)
discard all packets waiting to be transferred or acknowledged on the logical channel;
b)
cause the logical channel to enter the reset state;
c)
transfer a RESET REQUEST;
d)
start a 180-second timer T22; and
e)
if the centre is a PVC termination centre for the PVC assigned to the logical channel,
notify the CIDIN packet layer that the PVC assigned to the logical channel is not
usable.
4.1.7.4
Receiving RESET REQUEST
4.1.7.4.1
A centre which receives a valid RESET REQUEST when the logical channel is in the flow
control ready state shall:
a)
discard all packets waiting to be transferred or acknowledged on the logical channel;
b)
immediately transfer a RESET CONFIRMATION;
c)
cause the logical channel to re-enter the flow control ready state;
d)
and the resetting cause field is out of order or network out of order, notify the
CIDIN packet layer that the PVC is not usable; and
e)
if the centre is a PVC termination centre for the PVC assigned to the logical channel
and the resetting cause field is network operational or remote DTE operational,
notify the CIDIN packet layer that the PVC is usable.
if the centre is a PVC termination centre for the PVC assigned to the logical channel
and the resetting cause field is DTE originated and the corresponding resetting
diagnostic indication is DTE not operational, notify the CIDIN packet layer that the
PVC is not usable; and
f)
Chapter 4
Sixth Edition
Page 6 of 20
14/04/2011
EUR CIDIN MANUAL
g)
the resetting cause field is DTE originated and the corresponding resetting
diagnostic indication is DTE operational, notify the CIDIN packet level that the
PVC is usable.
Note.- Procedures regarding operator initiated resetting are described in 4.1.7.5.6 below.
4.1.7.4.2
A centre which receives a valid RESET REQUEST shall:

a)
cancel T22;
b)
cause the logical channel to enter the flow control ready state;
c)
notify the CIDIN packet layer that the PVC assigned to the logical channel is usable.
4.1.7.4.3
A centre which receives a RESET REQUEST when the logical channel is in the restart or
unassigned state shall discard the RESET REQUEST.
4.1.7.4.4
A centre which receives a non-valid RESET REQUEST shall:

a)
if the logical channel is in the flow control ready or reset state, execute the procedure
for reset with the resetting cause field indicating "local procedure error" and the
appropriate diagnostic code.
b)
if the logical channel is in the restart or unassigned state, discard the RESET
REQUEST.
4.1.7.5
Receiving RESET CONFIRMATION
4.1.7.5.1
A centre which receives a RESET CONFIRMATION when the logical channel is in the
flow control ready state shall, execute the procedure for reset with the resetting cause field
indicating "local procedure error" and the diagnostic code indicating "packet type invalid
when in flow control ready state".
4.1.7.5.2
A centre which receives a valid RESET CONFIRMATION when the logical channel is in
the reset state shall:
a)
cancel T22;
b)
cause the logical channel to enter the flow control ready state;
c)
notify the CIDIN packet layer that the PVC assigned to the logical channel is usable.
4.1.7.5.3
A centre, which receives a RESET CONFIRMATION when the logical channel is in the
restart or unassigned state, shall discard the RESET CONFIRMATION.
4.1.7.5.4
A centre which receives a non-valid RESET CONFIRMATION shall:
Chapter 4
a)
if the logical channel is in the reset state, execute the procedure for reset with the
resetting cause field indicating "local procedure error" and the diagnostic code.
b)
if the logical channel is in the flow control ready state, execute the procedure for reset
with the resetting cause field indicating "local procedure error" and the diagnostic code
indicating "packet type invalid when in flow control ready state".
c)
if the logical channel is in the restart or unassigned state, discard the RESET
CONFIRMATION.
Sixth Edition
Page 7 of 20
14/04/2011
EUR CIDIN MANUAL
4.1.7.5.5
When T22 expires, the centre shall execute the procedure for reset with the resetting cause
field indicating "local procedure error" and the diagnostic code indicating "timer expired
for reset".
Note.- After unsuccessful retries, the logical channel should be considered out of order.
The RESTART procedure should only be invoked for recovery if re-initialisation of all
logical channels is acceptable.
4.1.7.5.6
Recommendation.- Operator control of PVCs
4.1.7.5.6.1 It should be possible to render a PVC usable or not usable by operator command.
4.1.7.5.6.2 A PVC may be rendered not usable by initiating a RESET REQUEST with the resetting
cause field indicating DTE originated and the diagnostic code indicating DTE not
operational. A PVC may be rendered usable by initiating a RESET REQUEST with the
resetting cause field indicating DTE originated and the diagnostic code indicating DTE
operational. Both local and remote DTEs will stop or start sending packets on the PVC
respectively.
4.1.7.5.6.3 If the DTE initiating a RESET REQUEST to render a PVC not usable receives packets
whilst in a not usable state, it may reassert the not usable state by initiating a RESET
REQUEST with the resetting cause field indicating DTE originated and the diagnostic
code indicating DTE not operational.
4.1.7.5.6.4 If a PVC has been rendered not usable by the remote DTE, it may be rendered usable by
any of the following:
4.1.8
a)
reception of a RESET INDICATION with the resetting cause field indicating DTE
originated and the diagnostic code indicating DTE operational;
b)
reception of data from the remote DTE;
c)
reception of a RESET REQUEST with the resetting cause field indicating remote
DTE operational, network operational or network DTE operational;
d)
reception of a RESTART INDICATION.
Procedure for Restart
4.1.8.1
The procedure for RESTART shall be used to reinitialise a link.
4.1.8.2
A centre shall initiate the procedure for restart as follows:
4.1.8.3
Chapter 4
a)
transfer a RESTART REQUEST;
b)
discard all packets waiting to be transferred or acknowledged on each logical

channel;
c)
cause each logical channel to enter the restart state;
d)
start a 180-second timer T20; and
e)
if the centre is a PVC termination centre, notify the CIDIN packet layer that all PVCs
assigned to logical channels carried on the data link are not usable.
Receiving RESTART REQUEST
Sixth Edition
Page 8 of 20
14/04/2011
EUR CIDIN MANUAL
4.1.8.3.1
4.1.8.3.2
A centre, which receives a RESTART REQUEST with a logical channel identifier equal to
0 and whose logical channels are not in the restart state, shall:
a)
discard all packets waiting to be transferred or acknowledged;
b)
discard all packets waiting to be transferred or acknowledged;
c)
cause each logical channel assigned to carry a PVC to re-enter the flow control;
d)
cause each logical channel not assigned to carry a PVC to re-enter the unassigned
state;
e)
for each PVC assigned to a logical channel carried on the data link, if the centre is a
PVC termination centre, notify the CIDIN packet layer that a restart is occurring.
A centre, which receives a valid RESTART REQUEST with a logical channel identifier
equal to 0 and whose logical channels are in the restart state, shall:
a)
cancel T20;
b)
cause each logical channel assigned to carry a PVC to enter the flow control ready
state;
c)
cause each logical channel not assigned to carry a PVC to enter the unassigned state;
d)
PVC termination centre, notify the transport layer procedure that a restart is occurring.
4.1.8.3.3
A centre which receives a RESTART REQUEST with a logical channel identifier equal to
0 shall execute the procedure for restart with the appropriate diagnostic code.
4.1.8.3.4
A centre, which receives a RESTART REQUEST with a logical channel identifier not
equal to 0 shall:
a)
if the indicated logical channel is in the flow control ready state, execute the
procedure for reset with the resetting cause field indicating "local procedure error" and
the diagnostic code indicating "restart packet received with non-zero logical channel
identifier".
b)
if the indicated logical channel is in the restart, reset or unassigned state, discard the
RESTART REQUEST.
4.1.8.4
Receiving RESTART CONFIRMATION
4.1.8.4.1
A centre, which receives a RESTART CONFIRMATION with a logical channel identifier

equal to 0 and whose logical channels are not in the restart state, shall execute the
procedure for restart with the diagnostic code indicating "packet type invalid when not in
restart state".
4.1.8.4.2

equal to 0 and whose logical channels are in the restart state, shall:
a)
cancel T20;
b)
cause each logical channel assigned to carry a PVC to enter the flow control ready
state;
cause each logical channel not assigned to carry a PVC to enter the unassigned state;
c)
Chapter 4
Sixth Edition
Page 9 of 20
14/04/2011
EUR CIDIN MANUAL
d)
PVC termination centre, notify the CIDIN packet layer that all PVCs assigned to logical
channels carried on the data link are usable.
4.1.8.4.3

equal to 0 shall execute the procedure for restart with the appropriate diagnostic code.
4.1.8.4.4

not equal to 0 shall:
4.1.8.4.5
a)
if the indicated logical channel is in the flow control ready state, execute the
procedure for reset with the resetting cause field indicating "local procedure error" and
the diagnostic code indicating "restart packet received with non-zero logical channel
identifier";
b)
if the indicated logical channel is in the restart, reset or unassigned state, discard the
packet.
When T20 expires, the centre shall execute the procedure for restart with the diagnostic
code indicating "timer expired for restart".
Note.- After unsuccessful retries, recovery decisions should be taken at higher layers.
4.1.9
Procedure When Link Layer is Out of Order
4.1.9.1
A centre, which determines that the link layer is out of order on a particular data link shall:
4.1.9.2
4.1.10
a)
discard all packets waiting to be transferred on any logical channel carried on the data
link;
b)
PVC termination centre, notify the CIDIN packet layer that all PVCs assigned to logical
channels carried on the data link are not usable.
A centre, which determines that the link layer is no longer out of order shall:
a)
execute the procedure for restart;
b)
PVC termination centre, notify the CIDIN packet layer that the PVC assigned to each
logical channel carried on the data link is usable.
Diagnostic Code Values
Diagnostic indication
No additional information
Invalid P(S)
Invalid P(R)
Packet type invalid when not in restart state
Packet type invalid when in flow control ready state
Packet type invalid on PVCs
Packet too short
Packet too long
Restart packet with non-zero logical channel identifier
Timer expired for reset
Timer expired for restart
Chapter 4
Sixth Edition
Page 10 of 20
Bits of diagnostic code

8 7 6 5 4 3 2
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 1
0 0 0 1 0 0 0
0 0 0 1 1 0 1
0 0 1 0 0 0 1
0 0 1 0 0 1 1
0 0 1 0 0 1 1
0 0 1 0 1 0 0
0 0 1 1 0 0 1
0 0 1 1 0 1 0
1
0
1
0
1
1
1
0
1
1
1
0
14/04/2011
EUR CIDIN MANUAL
Note.- Other bit combinations reserved.

4.1.10.1
When using a packet switched data network to provide a communication path between
CIDIN switching centre, these centres will act as DTEs. According to the CCITT
Recommendations X.25-1981, a DCE prevents values of the resetting cause field other
than 0 given in a RESET INDICATION packet to the DTE, when receiving a RESET
REQUEST from the other end of the PVC. The following diagnostic code values are
additionally recommended to indicate the reason for the reset procedure to an adjacent exit
centre (DTE).
Bits of diagnostic code
8 7 6 5 4 3 2 1
1 0 1 0 0 0 0 1
1 0 1 0 0 0 1 0
Diagnostic indication
DTE operational (Note 2)
DTE not operational (Note 1)
Note 1.- If a DTE receives a REQUEST INDICATION and the centre is a PVC termination
centre for the PVC assigned to the logical channel, notify the CIDIN packet layer that the
PVC assigned to the logical channel is not usable.
Note 2.- If a DTE receives a REQUEST INDICATION and the centre is a PVC termination
centre for the PVC assigned to the logical channel, notify the CIDIN packet layer that the
PVC assigned to the logical channel is usable.
4.1.11
Resetting Cause Field Values
4.1.11.1
CIDIN switching centres, the resetting cause field in reset packets transferred from a CIDIN
switching centre to the data network shall always be equal to 0. Resetting cause fields
received by a CIDIN switching centre from such a network shall be handled in accordance
with 4.1.7.
Bits of resetting cause field
8
7
6
5
4
3
0
0
0
0
0
0
1
x
x
x
x
x
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
1
1
0
0
0
1
0
0
0
0
0
1
1
1
Resetting cause indication

DTE originated
DTE originated (Note 1)
Out of order (Note 2)
Remote procedure error
Local procedure error
Network congestion
Remote DTE operational (Note 2)
Network operational (Note 2)
Incompatible destination
Network out of order (Note 2)
2
0
x
0
1
0
1
0
1
0
0
1
0
x
1
1
1
1
1
1
1
1
Note 1.- When bit 8 is set to 1, the bits represented by Xs are those indicated by the remote
DTE in the resetting cause field (virtual calls and permanent virtual circuits).
Note 2.- Applicable to permanent circuits only.
Note 3.- Other bit combinations reserved.
4.1.11.2
Chapter 4
CIDIN switching centre these centres will act as DTE. In this case the coding of the
resetting cause field in a reset packet is given as shown in the following table:
Sixth Edition
Page 11 of 20
14/04/2011
EUR CIDIN MANUAL
Resetting cause indication

DTE originated
DTE originated
Out of order
Remote procedure error
Network congestion
Remote DTE operational
Network DTE operational
Incompatible destination
Network out of order
4.1.12
Bits of resetting cause field

8
7
6
5
4
3
0
0
0
0
0
0
1
x
x
x
x
x
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
1
1
0
0
0
0
1
1
0
0
0
1
0
1
0
0
0
1
1
1
0
0
1
0
0
1
0
0
1
1
1
2
0
x
0
1
0
1
0
1
0
0
1
0
x
1
1
1
1
1
1
1
1
Restarting Cause Field Values
4.1.12.1
A centre shall always set the restarting cause field to equal 0.

Note.- Public data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may also transfer
restarting cause fields of the following values:
Restarting cause indication

Network congestion
Network operational
4.2
Guidance Material
4.2.1
X.25 Packet Layer Functions
Bits of restarting cause field

8
7
6
5
4
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
2
0
1
1
1
1
1
1
4.2.1.1
The X.25 packet layer in CIDIN is responsible for the establishment and maintenance of
logical connections which are multiplexed onto data links. The number of possible
connections (4095) is more than adequate for CIDIN. The user can send and receive strings
of octets on these connections at will. The X.25 packet layer provides this service by
transmitting and receiving the data in fixed units called "packets". This leads to a flexible
and efficient use of communication resources and the possibility of adaptation to various
load conditions.
4.2.1.2
The logical connections in X.25 ("virtual circuits") can be of two types: permanent virtual
circuits (PVCs) and switched virtual circuits (SVCs). Connections between CIDIN centres
via dedicated circuits should, by preference, be implemented with PVCs. Although SVCs
are also permitted, the choice of PVCs might lead to less processing overhead when the
circuit needs to be established. Connections between CIDIN centres via PSNs can be
implemented with PVCs or SVCs. The choice will depend on availability, service features
and their cost for the configuration in question.
4.2.1.3
Main and Alternate Connection Paths
4.2.1.3.1
Connection Paths connect a CIDIN centre to another CIDIN centre.
Chapter 4
Sixth Edition
Page 12 of 20
14/04/2011
EUR CIDIN MANUAL
4.2.1.3.2
The connection between CIDIN Centres is normally achieved through a preferred

connection path over a group of Virtual Circuits. This path is called the MAIN Connection
Path (MCP).
4.2.1.3.3
Should connection not be possible through the MCP then an attempt should be made to
connect via the ALTERNATE Connection Path (ACP) group of Virtual Circuits.
Exit Centre to Connection Path Mapping for each Ax
Main Connection Path
Alternate Connection Path
Virtual Circuit Group (1)
Virtual Circuit Group (2)
Note.VCG(1) and VCG(2) shall take different Virtual Circuit routes to different
adjacent CIDIN Centres.
4.2.1.4
Virtual Circuit Group
4.2.1.4.1
A Virtual Circuit Group (VCG) consists of a number of Virtual Circuits (VC) that connects
two, and only two, CIDIN centres. A Primary-type VC is always present and a Secondarytype VC is optional. Within this group, selection of the VC is a local matter. VC groups
form redundant connections between adjacent CIDIN centres. PVCs and SVCs may be
mixed within a VCG according to the table below:
Virtual Circuit Group (VCG)
Primary VC
Secondary VCs
PVC
additional PVCs (optional)
PVC
additional PVCs (optional)
SVC
Not recommended
Option 1
Option 2
Option 3
SVC
Not recommended
Notes. Where:
PVC = Permanent Virtual Circuit

SVC = Switched Virtual Circuit (established by a Virtual Call).
The number of PVCs forming a VCG is subject to bilateral agreement.

Secondary-type VCs are not allowed where the Primary-type VC is an SVC. The Packet
Switched Network (PSN) will provide redundancy in the case of SVCs. Note that it is
recognised that DTE addressing problems can lead to two SVCs being established
simultaneously. However two established SVCs are not permitted.
4.2.1.5
Virtual Circuits
4.2.1.5.1
Virtual Circuits (VC) within a group connect two, and only two, adjacent CIDIN centres.
In general, a VC is defined for Primary-type use (first selected or primary) with a
Secondary-type VC(s) (secondary) as backup. A CIDIN centre will use a Secondary-type
VC only when the Primary-type VC is not operational and vice versa. VCs of this type are
only used to increase the redundancy between adjacent CIDIN centres.
4.2.1.5.2
A VC can be of type PVC (Permanent Virtual Circuit) or SVC (Switched Virtual Circuit).
The PVC is a circuit connection in which a permanent association exists between two
DTEs. The SVC is a circuit connection in which a call set-up (Virtual Call) procedure and
call clearing procedure will determine a period of communication between two DTEs.
Chapter 4
Sixth Edition
Page 13 of 20
14/04/2011
EUR CIDIN MANUAL
4.2.1.6
Adjacent CIDIN Centre
4.2.1.6.1
Adjacent CIDIN centres are those that are connected via a one-hop VCG. In effect, all
centres that support SVC procedures to an interconnected PSN can be adjacent.
4.2.1.7
X.121 Addressing principles
4.2.1.7.1
When connected to a X.25 network a CIDIN Centre shall conform to the X.121 addressing
principles. This is particularly pertinent when connected to a PSN network. An X.121
address is a series of numbers from the 10-digit numeric character set 0-9, which
uniquely identifies a DTE/DCE interface on a given network. The X.121 address is
structured as follows:
DNIC
PNIC
PNTN
Sub Address
14 digits maximum
4.2.1.7.2
The Data Network Identification Code (DNIC) uniquely identifies a given network and
shall consist of four digits.
4.2.1.7.3
The Private Network Identification Code (PNIC) is utilised to identify a specific private
network connected to the public data network and shall consist of 1 to 6 digits. The Private
Network Terminal Number (PNTN) should consist of the full address that is used when
calling the data terminal from within its serving data network. Depending on the Private
Network, the PNTN may be followed by a sub-address. The sub-address is not processed
by the network for routing purposes.
4.2.1.7.4
For routing via Gateways, a 15th digit (namely 0) is used as an international prefix.
4.2.1.8
Characteristics of the PVC service provided by the CIDIN X.25 packet layer are:
PVC initialisation
All PVCs on a data link are initialised with the RESTART procedure.
Independence
The events occurring on one PVC are independent from those on other PVCs
Sequencing
Data is received in the same sequence in which it was sent
Error detection
4.2.1.9
Error detection in addition to that provided by the data link layer is performed. Errors are,
however, reported to the user without error recovery being performed: the RESET
procedure, which is initiated, can lead to packets being lost. Recovery procedures on a
higher layer prevent information loss.
4.2.1.10
Characteristics of the SVC service provided by the CIDIN X.25 packet layer are essentially
the same as those for PVCs (see above) except that the initialisation of virtual circuits by
means of the RESTART procedure does not apply to SVCs. In addition there are circuit
establishment and clearing procedures specifically for SVCs. Detailed guidance on the use
of SVCs can be found in Appendix F. The terminology used in conjunction with PVCs and
SVCs can be found in Appendix G.
Chapter 4
Sixth Edition
Page 14 of 20
14/04/2011
EUR CIDIN MANUAL
4.2.1.11
4.2.2
Layer 3a in CIDIN is composed of a subset of the corresponding CCITT X.25 layer.

Procedures associated with PVCs are mandatory while procedures associated with SVCs
may be implemented as an option. None of the extensions to X.25 (1980) introduced in the
1984 version are used. PVCs logically connect two adjacent CIDIN centres via one data
link. SVCs connect two adjacent CIDIN centres. Both types of virtual circuits appear
identical to their users i.e. to layer 3b.
X.25 Packet Formats
4.2.2.1
The X.25 packet layer provides for a set of logical connections multiplexed on the same
physical link (see Figure 4.8). The data units recognised by the protocol (PDUs) are called
packets. Unlike a frame of the data link layer, a packet is accompanied by a header but no
control information as a trailer. Each packet is transmitted as the user data of one I-frame
of the data link layer.
4.2.2.2
The packet formats associated with PVCs are:
4.2.2.3
4.2.2.4
Chapter 4
data packet
RR packet
RNR packet
RESET REQUEST packet
RESET CONFIRMATION packet
RESTART REQUEST packet
RESTART CONFIRMATION packet.
In addition, the packet formats associated with SVCs are:
CALL REQUEST / INCOMING CALL packet
CALL ACCEPTED / CALL CONNECTED packet.
Each packet format has, in the leading two octets:
a general format identifier and a logical channel group number and
a logical channel number.
Sixth Edition
Page 15 of 20
14/04/2011
EUR CIDIN MANUAL
CIDIN Packet Layer

Centre A
Centre B
PVC3
PV C2
PV C3
PVC2
Centre C
PV C4
X.25
Packet
Layer
PV C4
Data link
Data link
Data Link Layer
Figure 4.8 Relationship between PVCs and the Data Link Layer
4.2.2.5
The general format identifier has the constant value of '0001'. The logical channel number
(one octet) identifies the logical channel on which the packet is (logically) transmitted. The
logical channel group number effectively extends the logical channel number by four bits.
The twelve bits available to identify a logical channel therefore allow a multiplexing
capacity of 4095 logical channels on one data link. The logical channel with a logical
channel identifier of 0 is reserved for special uses. The logical channel in use between two
given CIDIN centres are a set of configuration parameters.
4.2.2.6
The format of the third octet depends on the packet type: a data packet, identified by bit 1
set to 0, contains send and receive sequence numbers and a "more data bit". The other
packet types contain a packet type identifier. In addition, the RR and RNR packets contain
a receive sequence number. Only the data packet carries a user data field. Its maximum
length is 256 octets although this can be restricted to 128 octets by some packet switched
data networks providing a communication path between CIDIN switching centres.
4.2.3
RESTART Procedure
4.2.3.1
4.2.4
The state of a logical channel in which data packets can be transmitted is called "flow
control ready state". The execution of the protocol procedures is, in general, specific to one
particular logical channel, i.e. to the logical channel whose logical channel identifier
appears in the packets. However in order to initialise all logical channels on a link, i.e. to
bring them into flow control ready state, a RESTART procedure is available. This is done
on the logical channel 0. The execution of the RESTART procedure is functionally
equivalent to the execution of the RESET procedure on each logical channel configured.
The RESTART procedure should be performed on each link when initialising a CIDIN
centre.
RESET Procedure
4.2.4.1
Chapter 4
The RESET procedure is used to initialise or re-initialise a particular logical channel. It

consists of the partner initiating the procedure sending a RESET REQUEST packet and
waiting for a RESET CONFIRMATION packet as a reply. The various cases in which
both partners initiate the procedure simultaneously (RESET collision) or in which a reply
is not received within a time-out period are described in the protocol specification. A
logical channel on which a RESET is being performed is temporarily not available for use
by the upper layer.
Sixth Edition
Page 16 of 20
14/04/2011
EUR CIDIN MANUAL
4.2.4.2
Additional information may be carried in RESET REQUEST packets as diagnostic data.

One such use is to allow a DTE to convey to remote a DTE the status of the VC between
them. A CIDIN PVC may be marked as unavailable for the transfer of CIDIN packets
(invalidated) by initiating a RESET REQUEST (cause code 00) with diagnostic code A2.
Conversely, a CIDIN PVC may be marked as available for the transfer of CIDIN packets
(validated) by initiating a RESET REQUEST (cause code 00) with diagnostic code A1.
4.2.4.3
The following tables and diagrams provide an analytical schematic presentation of the
CIDIN PVC Reset Handling procedures.
Event
PVCval
PVCinval
RESIval
RESI
Description
PVC validated by operator
PVC invalidated by operator
PVC validated by a remote DTE
Reset Indication for one of the following events:
reception of data from the remote DTE
reception of RESET Remote DTE Operational
reception of RESET Network Operational
reception of Restart Indication
RSTI
RESRval
RESRinval
Restart Indication
Reset request to validate the PVC
Reset request to invalidate the PVC
Figure 4.9 Table of events for PVC validation/invalidation
PVC Validated
RSTI
PVCval
PVCinval
RESIinval
(internal)
RESI
PVCval
RESIval
PVC Invalidated
PVC Invalidated
(external)
(internal)
PVCinval
(internal)
Figure 4.10 State transition diagram for PVC validation/invalidation
Chapter 4
Sixth Edition
Page 17 of 20
14/04/2011
EUR CIDIN MANUAL
External Events
RESI
RESIinval
RSTI
Initial State
PVC Validated
External Events
PVC Invalidated
(internal)
PVC Invalidated
(external)
RESRinval
RESIval
Internal Events
PVCinval
PVCval
RESRval
Final State
PVC Validated
PVC Invalidated
(internal)
PVC Invalidated
(external)
Implementation
Error
Figure 4.11 State transition table for PVC validation/invalidation
DTE
DCE
Example 1
Reset Request
Invalidate PVC (A2)
Data
Reset Request
Invalidate PVC (A2)
Reset Request Validate
PVC (A1)
Data
ACK
Example 2
Reset Indication
Invalidate PVC (A2)
Data
ACK
Data
Example 3
Reset Indication
Invalidate PVC
Reset Indication
DTE Operational
Data
ACK
Figure 4.12 Examples of the operation of PVC validation/invalidation
Chapter 4
Sixth Edition
Page 18 of 20
14/04/2011
EUR CIDIN MANUAL
4.2.5
Flow Control
4.2.5.1
4.2.6
The flow control mechanisms in the X.25 packet layer are analogous to those in the data
link layer. The flow control on one logical channel is independent from the flow control on
all other logical channels. The procedures involve the use of packet send and receive
sequence numbers and the window technique using modulo 8 arithmetic is equivalent. The
values of the packet send and receive sequence numbers are initialised by the RESET and
RESTART procedures.
Error Detection
4.2.6.1
The X.25 packet layer protocol detects a wide range of error conditions. The actions to be
performed in each case are described in the protocol specification. In the event of errors
associated with data packets, no recovery is performed and user data can be discarded.
Such errors are reported to the user (layer 3b).
4.2.6.2
In the case of procedural errors, RESET or RESTART procedures are initiated. If a

RESET or RESTART procedure cannot be successfully performed, the logical channel in
question is not available for use by the upper layer which must be informed of the
situation. This provides essential information for the routing algorithm of the CIDIN
packet layer.
4.2.7
SVC Set Up and Clearing Procedures
4.2.7.1
Contrary to PVCs, SVCs need only exist when they are required for data transmission.
This opens up the possibility of minimising charges, for example, when using PSNs. There
may be some differences in interpretation of the procedures between the cases DTE-DTE
and DTE-PSN-DTE. The configuration DTE-DTE may also require some additional
bilateral agreements concerning connection parameters. For setting up virtual circuits,
addressing formats according to CCITT X.121 are used.
4.2.7.2
The contents of the User Data field in CALL REQUEST packets may be used by higher
CIDIN layers (e.g. extensions for sub-addressing, security information, etc.) and must be
processed transparently by layer 3a. The length of the field is restricted to 16 octets.
4.2.7.3
For SVC set-up, the calling DTE sends a CALL REQUEST packet which (having been
processed by the network in the case of a PSN) arrives at the called DTE as an
INCOMING CALL packet. The called DTE responds with a CALL ACCEPTED packet,
which arrives at the calling DTE as a CALL CONNECTED packet. A similar procedure
applies for clearing a logical channel.
4.2.8
VC management and SVC implementation
4.2.8.1 A detailed analysis on VC management and SVC implementation is provided in section 5.3.
4.2.9
Parameters
The parameters of the X.25 packet layer are as follows.
Assignment of logical channel numbers to data links
The logical channel numbers are the identification of the X.25 packet layer connection
(VC) on a given link and are necessary because of the multiplexing function. These
must be agreed upon between the CIDIN centres on both ends of the link.
Chapter 4
Sixth Edition
Page 19 of 20
14/04/2011
EUR CIDIN MANUAL
Timers for restart and reset procedures

These timers are commonly known as T20 and T22 respectively and could typically be
of the order of 30 seconds
Packet length
The packet length is normally 256 octets. If a packet switched network is used, the
packet length can be restricted to 128 octets.
Chapter 4
Sixth Edition
Page 20 of 20
14/04/2011
EUR CIDIN MANUAL
5.
CIDIN Network Layer (3b)
5.1
5.1.1
The CIDIN Packet protocol Layer
5.1.1.1
A CIDIN packet header shall precede each transport header and the associated segment.
No further segmentation of the CIDIN message shall be used between transport protocol
layer and CIDIN packet protocol layer. Both headers, therefore, shall be used in
combination. Together they shall be referred to as the Communications Control Field
(CCF). Together with the message segment they form CIDIN packets that shall be
transmitted from entry centre to exit centre(s), when necessary through one or more relay
centres, as an entity.
5.1.1.2
CIDIN packets of one CIDIN message shall be relayed independently via predetermined
routes through the network thus allowing alternative routing on a CIDIN packet basis as
necessary.
5.1.1.3
The CIDIN packet header shall contain information to enable relay centres to handle
CIDIN packets in the order of priority, to transmit the CIDIN packets on the proper
outgoing circuit(s) and to duplicate or multiply CIDIN packets when required for multiple
dissemination purposes. The information shall be sufficient to apply address stripping on
the exit addresses as well as on the addressee indicators of messages in AFTN format.
Note.- Guidance material on address stripping in the CIDIN is contained in the Manual on
the Planning and Engineering of the Aeronautical Fixed Telecommunication Network
(Doc 8259).
5.1.2
The CIDIN Packet Header Format
5.1.2.1
Chapter 5
The CIDIN packet header shall contain the following components:

- Packet looping counter and
message priority indicator
(PLC and MP)
- Exit address(es)
(Ax)
- Destination address(es)
(Ad)
Sixth Edition
Page 1 of 17
14/04/2011
EUR CIDIN MANUAL
5.1.2.2
The CIDIN packet header shall be generated by the entry centre or station and shall be
interpreted by relay centre(s) and exit centre(s) receiving the CIDIN packets.
First bit transmitted

(low order bit)
0 1 1 0 0 0 1
PLC
MP
PACKET LOOPING COUNTER

AND MESSAGE PRIORITY ITEM
1
LENGTH
Ax1
EXIT ADDRESS
ITEM
0 Number of Ads
Ad1
Ad2
Ad3
.
.
Ad15
DESTINATION
ADDRESS
ITEM
0 Number of Ads
Ad16
Ad17
etc.
DESTINATION
ADDRESS
ITEM
Only in
the first
packet
of a
message
in AFTN
format
8 7 6 5 4
3 2 1
Last bit transmitted

Note.- Axs and Ads are specified as IA-5 in Annex 10, Vol. III, Part 1, 8.6.2.5
5.1.2.3
The components contained in the octets of the CIDIN packet header shall be the following.
5.1.2.4
The first item shall contain a five bit packet looping counter (PLC, bits 8, 7, 6, 5 and 4) and
a three bit message priority indicator (MP, bits 3, 2 and 1) which shall be interpreted as
follows:
000
001
010
011
100
101
110
111
Priority 1
Priority 2
Priority 3
Priority 4
Priority 5
Priority 6
Priority 7
Priority 8
5.1.2.5
The five bit packet looping counter (PLC) shall be set to 31 by the entry centre or station.
5.1.2.6
The highest CIDIN priority shall be reserved for CIDIN network management messages.
The remaining priorities shall be available for user messages.
5.1.2.7
The following item of the CIDIN packet header shall contain the exit address(es). The exit
address shall consist of the four-letter location indicator of the concerned exit centre,
followed immediately by one letter identifying a type of user in the CIDIN. If required,
one, two or three additional characters to further identify the application entity. In those
cases where a station is directly connected to CIDIN, the exit address shall consist of the
four-letter indicator of the concerned CIDIN station, followed immediately by one to four
letters identifying a user within that CIDIN station. The total number of letters in an exit
Chapter 5
Sixth Edition
Page 2 of 17
14/04/2011
EUR CIDIN MANUAL
address shall not exceed 8. Upper case letters shall be used only. The number of octets
used by each exit address shall be indicated in bits 1 to 4 of the first octet of each exit
address item. There shall be an exit address item for each exit address to which the CIDIN
packet is to be transmitted. The maximum number of exit addresses in a CIDIN message
shall be 16.
5.1.2.8
If destination addresses (Ads) are used they shall be inserted in the first packet only and
shall be inserted immediately following each associated exit centre address. (See 5.1.2.2
above).
5.1.2.9
The number of destination addresses associated with an exit address shall be indicated in
bits 1 to 4 of each destination address item. The length of each destination address shall be
8 octets.
5.1.2.10
When the number of destination addresses associated with an exit address exceeds 15 an
additional destination address item shall be added following the item containing the first 15
destination addresses. The maximum number of destination addresses associated with an
exit address in a CIDIN message shall be 21.
5.1.3
CIDIN Packet Procedures
5.1.3.1
The CIDIN packet procedures shall be defined for:
a)
entry centres;
b)
relay centres;
c)
exit centres and stations.
5.1.3.2
CIDIN packet header generation
5.1.3.2.1
For each information message submitted, the CIDIN packet layer shall accept the
following elements from the transport layer:
a)
message content, segmented such that the maximum packet length would not be
exceeded if the routing analysis were to require output on a single CIDIN circuit;
b)
exit centre address(es);
c)
CIDIN message priority;
d)
destination address(es), for inclusion in the first packet of messages in AFTN format
only.
5.1.3.2.2
The entry centre shall generate the packet header based on the information given in b), c)
and d), and based on the information derived in the routing analysis process.
5.1.3.3
Routing and relay of CIDIN packets
5.1.3.3.1
All packets shall be sent by the predetermined route available to effect delivery to the exit
address. Where the routing requires that a CIDIN packet be sent to the relay/entry centre
from which it was received, the next most expeditious route shall be used.
5.1.3.3.2
Centres shall be interconnected by one or more VCs. The route shall be defined as that
which requires the least number of traversals to reach the exit centre.
Chapter 5
Sixth Edition
Page 3 of 17
14/04/2011
EUR CIDIN MANUAL
5.1.3.3.3
It shall be permissible to choose between two or more equally expeditious predetermined

routes by any suitable method.
5.1.3.4
Selection of VC for transmission of a CIDIN packet
5.1.3.4.1
Each CIDIN switching centre shall maintain a routing table relating exit addresses with
primary, and if applicable, secondary outgoing VCs.
5.1.3.5
Transmission of CIDIN packets
5.1.3.5.1
Higher priority packets shall be transmitted before lower priority packets.
5.1.3.5.2
The relay of CIDIN packets shall not be delayed unnecessarily.
5.1.3.5.3
The relay of CIDIN packets shall not wait for complete CIDIN message receipt.
5.1.3.5.4
Packets having the same priority shall be transmitted in the order in which they are
received.
5.1.3.6
Action on packets with errors
5.1.3.6.1
When a centre or station receives a packet that does not contain a valid packet header, it
shall discard that packet.
5.1.3.7
Loss of communication
5.1.3.7.1
When a relay centre is notified that a VC is not usable it shall:

a)
discard all packets destined to exit centres for which both primary and secondary
outgoing VCs are not usable;
b)
transmit all packets destined for exit centres for which the primary outgoing VC is
not usable along the secondary outgoing VC to the exit centres;
c)
discard all packets which the routing requires to be sent to the relay/entry centre from
which they were received (see 5.1.3.3.1);
d)
for multi-addressed packets, transmit the packets to those exit addresses for which
communication is possible; and
e)
inform the operator of the action taken.
5.1.3.7.2
When a CIDIN switching centre ceases operation because of equipment failure, it shall,
when it resumes operations, discard all packets which are neither originated by, nor
addressed to it. The action on packets addressed to or originated by the failed centre will be
left for national determination.
5.1.3.8
Handling of multiple dissemination
5.1.3.8.1
A centre, which receives a CIDIN packet for multiple dissemination, shall determine the
outgoing VC on which the CIDIN packets of the CIDIN message shall be transmitted for
each exit address.
Chapter 5
Sixth Edition
Page 4 of 17
14/04/2011
EUR CIDIN MANUAL
5.1.3.8.2
The CIDIN packet header of packets transmitted on each outgoing VC shall contain only
the exit addresses and destination addresses (first packet of messages in AFTN format
only) to be reached via the particular VC. The relay of CIDIN packets shall not result in
unnecessary multiplication of packets. Address stripping shall be applied to Axs and Ads
(messages in AFTN format only) for destinations that cannot be reached via the particular
VC.
Note.- Guidance material on address stripping is contained in Annex 10, Volume II,
Attachment C.
5.1.3.8.3
Relay centres shall not alter the received CIDIN packet headers of CIDIN packets that are
transmitted on a single outgoing VC for all exit addresses specified.
5.1.3.8.4
Relay centres shall compose new CIDIN packet headers for CIDIN packets that are
transmitted on more than one outgoing VC and apply address stripping.
5.1.3.8.5
Centres detecting their own address among the exit addresses shall act as exit centre for
their own address, and as relay centre for the other exit addresses.
5.1.3.9
Action to be taken with packet looping counter
5.1.3.9.1
When a relay centre receives a packet with a PLC value of greater than zero it shall
decrement the PLC by 1 and transmit the packet. If, on receipt, the value of the PLC is zero
the packet shall be discarded.
5.2
Guidance Material
5.2.1
Functions of the CIDIN Network Layer
5.2.1.1
The CIDIN packet layer supplements the X.25 packet layer with the functions necessary to
bring the network up to the functionality required by the CIDIN user. It provides a
connectionless service in transmitting blocks of user data up to a maximum length of 256
octets ("CIDIN packets") through CIDIN. Its functions are:
Accepting message segments and control information from the transport layer
In an entry centre, information is accepted from the transport layer to be relayed
through the network.
Passing message segments and control information to the transport layer
On recognising that a CIDIN packet bears a local exit centre address, a CIDIN exit
centre passes the information on to its transport layer.
5.2.1.2
5.2.2
All packet switched networks require internal protocols to perform routing and relay
functions in addition to the network access functions of a protocol such as X.25. CIDIN is
no exception. The CIDIN packet layer protocol is designed to meet the special needs of
CIDIN.
CIDIN Packet Formats
5.2.2.1
Chapter 5
A CIDIN packet is the unit of data recognised by the CIDIN packet protocol with a
maximum length of 256 octets. It is transmitted as an X.25 user data field in layer 3a. In
the case where the maximum user data field length in layer 3a is 128 octets, the CIDIN
packet is transmitted in two X.25 user data fields. The M bit in the first of these two
Sixth Edition
Page 5 of 17
14/04/2011
EUR CIDIN MANUAL
packets is set to one to indicate that the following packet contains a continuation of the
user data.
5.2.2.2
A CIDIN packet consists of a CIDIN message (or segment of a message) preceded by a

CIDIN transport header and a CIDIN packet header:
CIDIN
packet header
CIDIN
transport header
CIDIN
message or
segment of
message
5.2.2.3
The CIDIN packet and transport headers together are called the "communications control
field". The communications control field may be at the most 256 octets long. Strictly
speaking, according to the principles of the OSI Reference Model, the CIDIN transport
header should be included only with the first segment of a CIDIN message rather than with
every message segment. Its inclusion is necessary because the re-assembly function is
located in the transport layer.
5.2.2.4
The CIDIN packet header consists of header items coded according to the principles
described in Appendix C. The first item is the packet looping and message priority
indicator. It is followed by a sequence of exit addresses or, in the case of the first segment
of messages in "AFTN format", by a sequence of exit addresses with their related
destination addresses. The coding of a message in AFTN format is characterised by the
presence of destination addresses and an indication in the MCF field (see transport
protocol). An exit address item may contain only one exit address while a destination
address item may contain up to 15 fixed length destination addresses.
5.2.2.5
The length of a CIDIN exit address, Ax, is variable up to a maximum of 8 characters. This
maximum length is designed for future requirements when CIDIN is expanded and for the
efficient addressing of applications.
5.2.2.6
The CIDIN packet layer generates the CIDIN packet header on the basis of information
supplied to it by the CIDIN transport layer. The messages are already divided into
segments of the appropriate size.
5.2.3
Routing and Relay
5.2.3.1
The relaying of CIDIN packets through CIDIN is done in layer 3b. Each CIDIN centre
contains a so-called routing table, which is distinct for each centre. In this table, each
possible Ax in CIDIN is associated with a primary and perhaps a secondary virtual circuit.
The discussion below is concerned initially with messages containing only one Ax, i.e.
with non-multiply disseminated messages. The procedure for routing and relay is as
follows:
A CIDIN centre recognising its own address, i.e. Ax = the address of the local CIDIN
centre, passes the CIDIN packet on to the CIDIN transport layer.
A CIDIN relay centre retransmits the CIDIN packet on the primary VC for the Ax
contained in the CIDIN packet if the primary VC is operational.
A CIDIN relay centre retransmits the CIDIN packet on the secondary VC for the Ax
contained in the CIDIN packet if the primary VC is not operational but the secondary
VC is operational.
In various error cases, the CIDIN packet is discarded
When the primary VC fails during the transmission of a message, care shall be taken to
ensure that the message is received in its entirety in the destination nodes. This can be
Chapter 5
Sixth Edition
Page 6 of 17
14/04/2011
EUR CIDIN MANUAL
achieved either by retransmitting the message on the standby VC or transmitting the

residue of the message over the standby VC. In this second case, the packet handling
procedures will ensure that no packets are lost.
5.2.3.2
The retransmission of CIDIN packets follows some priority rules. Each CIDIN packet
carries a priority indicator between 1 (highest) and 8 (lowest) in the CIDIN packet header
(the priority is assigned by an application program). CIDIN packets with the same priority
are retransmitted on a given VC in the same order in which they were received. CIDIN
packets with higher priority are transmitted on a given VC before CIDIN packets with
lower priority.
5.2.3.3
Since the routing is performed using a distributed algorithm, i.e. each CIDIN relay centre
is responsible for its own routing, it is important to guard against paths in the network
which contain infinite or very inefficient loops. These could, for example, come about by
incorrect editing of the routing table in a CIDIN relay centre. For this reason, the packet
looping counter is initially set to a maximum number of "hops" allowed between entry and
exit centre. The packet looping counter is decreased by 1 for each hop and the CIDIN
packet is discarded should the counter reach zero.
5.2.4
Multiple Dissemination
5.2.4.1
A message to be multiply disseminated contains more than one Ax in its CIDIN packet
header. The processing in a CIDIN relay centre at layer 3b of a CIDIN packet belonging to
such a message is logically equivalent to the processing of a set of messages, each of
which is not to be multiply disseminated (note that this is only a logical view of the
procedure and not a recommendation for the implementation). The outgoing CIDIN
packets on the same VC are grouped together into one CIDIN packet. They are identical
except for their address items.
5.2.4.2
The following example illustrates this procedure:

CIDIN packet received at CIDIN
centre E with Axs:
(A,B,C,D,E,F,G)
is first divided logically into a set of

CIDIN packets, each with one Ax:
(A) (B) (C) (D) (E) (F) (G)
and routing is performed logically

on each (see 5.2.3 above). Outgoing
VC:
VC1
(A)(C)(D)
VC2
(B)(G)
VC3
(F)
(A,C,D)
(B,G)
(F)
Before transmission, the CIDIN

packets on VC circuit are combined:
5.2.4.3
A CIDIN packet, which has been relayed, contains only those addresses which are relevant
to its onward path in the network. This procedure is called "address stripping" since it can
appear that addresses have been removed from the original CIDIN packet. Address
stripping in a relay centre is usually associated with the duplication of the CIDIN packet.
When an Ax is removed from the first CIDIN packet of a message in AFTN format, the set
of Ads associated with the Ax are removed as well. In order to demonstrate this feature, the
above example is shown in Figure 5.1 for the case in which the message is in AFTN
format.
5.2.4.4
Figure 5.2 shows an example of a routing table based on a fictitious routing plan. It
demonstrates the use of primary and secondary VCs as well as the way in which a
conventional AFTN switch, EK, is integrated into CIDIN.
Chapter 5
Sixth Edition
Page 7 of 17
14/04/2011
EUR CIDIN MANUAL
Transport
layer
E
CIDIN packet
To application
with address E
VC1
A
C
D
C
D
Incoming VC
E
F
G
VC2
G
exit address
destination addresses
transport header
message segment
VC3
Figure 5.1 Example of Multiple Dissemination
Chapter 5
Sixth Edition
Page 8 of 17
14/04/2011
EUR CIDIN MANUAL
AFTN
EK
EG
EB
LS
LI
KM
EG
CY
EB
See II
EB
EB
LI
KM
See III
KM
KM
LI
KM
KM
KM
EK
LI
KM
LI
III
EB
EB
EB
ED
EB
EB
ED
EG
ED
ED
EB
EB
EG
EG
ED
EG
EG
EG
ED
ED
EG
ED
EB
EB
EB
EB
EB
EB
ED
EB
EB
EB
EB
ED
EF
EG
EI
EK
EL
EN
EP
ES
ET
EB
ED
EB
ED
EK
EG
EG
EG
EG
EK
EB
EB
EK
EK
EK
EK
LB
LC
LE
LF
LG
LH
LI
LK
LL
LM
LO
LP
LR
LS
LT
LX
LY
LO
LI
EB
EB
LI
LO
LI
ED
LI
LI
LO
EB
LO
LS
LI
EB
LO
Primary
ED
ED
EB
EB
ED
ED
ED
ED
ED
ED
ED
EB
ED
ED
ED
EB
ED
Figure 5.2 Example of a Routing Table for EHAM (based on a fictitious routing plan)
5.3
Standards and Recommended Practices on SVC Implementation
5.3.1
Virtual Circuit Management

Virtual circuits are managed within layer 3b.
The operator has access to virtual circuit management functions. He may manually initiate a
RESTART on a link, RESET a virtual circuit, validate or invalidate a PVC and connect or
disconnect an SVC.
5.3.1.1
General specifications
5.3.1.1.1 The list of virtual circuits (PVCs and SVCs) maintained in association with the routing
table(s) in layer 3b is a static description of the configuration relative to all adjacent CIDIN
centres. For each SVC, this includes information on whether the centre can set up the SVC
Chapter 5
Sixth Edition
Page 9 of 17
14/04/2011
Secondary
CIDIN
Exit Centre
CIDIN
ED
EB
ED
EB
EB
ED
ED
ED
ED
ED
ED
Destination
Circuit
Secondary
AFTN
CIDIN
Primary
AFTN
Exit Centre
CIDIN
EG
EG
EG
EB
Destination
Circuit
Secondary
AFTN
CIDIN
Primary
AFTN
Exit Centre
Destination
LO
II
Circuit
A
B
C
D
E
F
G
H
K
L
M
N
O
P
R
S
U
V
W
Z
ED
AFTN
EH
CIDIN
CY
AFTN
KM
EB
EB
ED
ED
EB
EB
EB
EB
EB
EB
EB
ED
EB
EB
EB
ED
EB
EUR CIDIN MANUAL
automatically, by operator intervention, on demand or only when a primary PVC is out of

operation etc. An "idle time" and a "retry interval" are also associated with each SVC.
5.3.1.1.2 Two main timers shall be used:
The Idle timer and
The Retry timer.
Note 1. The Retry timer and the retry interval identify the same object.
The reference to a timer triggered at a Call request generation packet is made. This
timer is named the Call timer.
Note 2.-The way of implementing each timer is not specified; only the function and the
behaviour associated with them is described. The Retry timer and the Call timer may or
may not be the same.
5.3.1.1.3 Dynamic information shall be also maintained on the current status of each virtual circuit. The
information is used whenever a CIDIN packet is entered into an outgoing queue and it is also
used by the outgoing queue handling.
5.3.1.1.4 To facilitate identification:
Each PVC shall be assigned a five-character identifier; the first four characters
being the location indicator of the destination as defined in the relevant ICAO
documentation. The fifth character shall be a sequencing number, starting with 1, to
discriminate between PVCs (also to be used in the event of only one PVC being
used).
In case an SVC is used, it shall be assigned a five-character identifier. The first four
characters shall be the location indicator of the destination as defined in the
relevant ICAO documentation. The fifth character shall be a fixed number. (The
value 9 is being considered)
5.3.1.1.5 The capability shall exist for an established SVC to be cleared when no message has to be
transmitted after the expiration of a configurable timer.
5.3.1.1.6 In normal configurations only one SVC is to be set up between any two centres.
5.3.1.1.7 The X.121 address format shall be used (precision in APPENDIX F).
5.3.1.1.8 Minimum security aspects shall be considered consisting of the incoming call address checking
in the INCOMING CALL (Precision below in the paragraph: 5.3.3.3 and in APPENDIX F).
5.3.2
Virtual Circuit Initialisation
5.3.2.1 When a CIDIN centre (or a part of it) is initialised, all PVCs are initialised with the
RESTART procedure. All SVCs configured to be set up automatically are also connected.
5.3.2.2 If an internal error condition specific to a virtual circuit is detected, e.g. no packet throughput,
then the centre can initiate the RESET procedure on the virtual circuit for a limited number of
times within a given time period. When a RESET INDICATION packet is received, the
RESET procedure should be completed.
5.3.3
Call Establishment
5.3.3.1
Outgoing Call establishment
5.3.3.1.1
Normal Case
Chapter 5
Sixth Edition
Page 10 of 17
14/04/2011
EUR CIDIN MANUAL
5.3.3.1.1.1 For a given direction, as soon as data are to be transmitted and in case no established SVC
exists, an outgoing call shall be set up.
5.3.3.1.1.2 When the conditions for setting up an SVC are satisfied, it should be established with the
CALL REQUEST procedure. A centre which successfully initiates the setting up of an
SVC is considered to be its "owner", and this centre would normally be the one to initiate
the CLEAR REQUEST procedure (see below). An SVC can transmit CIDIN packets in
both directions, independent of which centre initiated the CALL REQUEST.
The figure below describes the principle:
LOCAL CENTRE
SUBNETWORK
REMOTE CENTRE
SVC is Idle
Start Call timer
CALL REQUEST
INCOMING CALL
CALL ACCEPTED
CALL CONNECTED
Stop Call timer

SVC becomes ESTABLISHED
data
data
Figure 5.3 Outgoing call establishment
5.3.3.1.2
5.3.3.1.2.1
5.3.3.1.2.1.1
Connection failure
Call timer elapses
When the Call timer elapses:
the CALL REQUEST shall be disconnected with the generation of a CLEAR

REQUEST with the clearing cause set to 00 (DTE originated),
periodic attempts shall be made to re-establish the SVC.
Chapter 5
Sixth Edition
Page 11 of 17
14/04/2011
EUR CIDIN MANUAL
LOCAL CENTRE
SUBNETWORK
REMOTE CENTRE
SVC is Idle
Start Call timer
CALL REQUEST
INCOMING CALL
Call timer elapses
CLEAR INDICATION
CLEAR REQUEST
CLEAR CONFIRMATION
CLEAR CONFIRMATION
SVC is trying to be
re-established periodically
Figure 5.4 Connection failure due to elapsed timer
5.3.3.1.2.2
Call Request Cleared
5.3.3.1.2.2.1 An SVC CALL REQUEST may be cleared by a DTE originated CLEAR REQUEST or
a network initiated CLEAR (CLEAR INDICATION). Periodic attempts shall be made to
re-establish the SVC.
LOCAL CENTRE
SUBNETWORK
REMOTE CENTRE
SVC is Idle
CALL REQUEST
CLEAR INDICATION
CLEAR CONFIRMATION
SVC is trying to be
re-established periodically
Figure 5.5 Connection failure due to CLEAR request
Chapter 5
Sixth Edition
Page 12 of 17
14/04/2011
EUR CIDIN MANUAL
5.3.3.2
CIDIN Crossing Call avoidance
5.3.3.2.1
When a Crossing Call is detected, a mechanism shall be set up to manage the situation such
as the call being re-established with an inferior probability for re-occurrence of Crossing
Call.
5.3.3.2.2
When an INCOMING CALL occurs, a CLEAR REQUEST packet shall be generated with
the clearing cause set to 00 (DTE originated).
Note.- The Call cleared may be the INCOMING CALL, the OUTGOING CALL or both of
them depending on the design intended.
5.3.3.2.3
To minimise the occurrence of multiple CIDIN Crossing Call, the specific timer Retry
timer shall be used.
5.3.3.2.4
To avoid multiple CIDIN Crossing Calls, the Retry timer pertaining to the two
communicating CIDIN Centres shall be given different values.
Recommendation.- The value of the Retry timer should be a random value.
Note. Different ways can be set up to implement the Retry timer management.
5.3.3.2.5
After the Retry timer elapses, an Outgoing SVC call shall be retried.
LOCAL CENTRE
SUBNETWORK
REMOTE CENTRE
CALL REQUEST
CALL REQUEST
INCOMING CALL
INCOMING CALL
CLEAR REQUEST
CLEAR REQUEST
CLEAR CONFIRMATION
CLEAR CONFIRMATION
SVC is trying to be
re-established
SVC is trying to be
re-established
Figure 5.6 Crossing Call avoidance
5.3.3.3
Incoming Call establishment
5.3.3.3.1
Normal Case
Chapter 5
Sixth Edition
Page 13 of 17
14/04/2011
EUR CIDIN MANUAL
LOCAL CENTRE
NETWORK
REMOTE CENTRE
SVC is Idle
CALL REQUEST
INCOMING CALL
CALL ACCEPTED
CALL CONNECTED
SVC is established
data
data
Figure 5.7 Incoming call establishment
5.3.3.3.2
Incoming call refusal
5.3.3.3.2.1 An SVC incoming call shall be refused for the following reasons:
5.3.3.3.2.2
the Calling address is unknown by the Local CIDIN Centre,

an SVC already exists with the Remote CIDIN Centre with the
received CALLING DTE address (only one SVC permitted between
two CIDIN Centres),
a CIDIN Crossing call is detected,
an SVC-type CIDIN exchange with the remote CIDIN Centre is not
possible as either Local or Remote DTE have been disabled.
An SVC Incoming call refused for the reasons listed above shall be cleared with the clear
reason code 00 (DTE originated).
LOCAL CENTRE
NETWORK
REMOTE CENTRE
CALL REQUEST
INCOMING CALL
CLEAR REQUEST
CLEAR INDICATION
CLEAR CONFIRMATION
CLEAR CONFIRMATION
Figure 5.8 Incoming call refusal
Chapter 5
Sixth Edition
Page 14 of 17
14/04/2011
EUR CIDIN MANUAL
5.3.4
Data Transfer
5.3.4.1
5.3.5
The transfer of data shall be made under the control of the X.25 flow mechanism which is
the same as for PVCs.
Disconnection
5.3.5.1 Normal case

5.3.5.1.1 The two following cases shall lead to SVC disconnection:
When the Idle timer elapses, meaning that no data have been
transferred before the timer elapses. The SVC is re-established as soon
as pending data exist.
When a CLEAR REQUEST is sent as a result of disabling the SVCtype CIDIN exchange with the remote CIDIN Centre by Operator
command. Outgoing SVC establishment to the remote CIDIN Centre
remains disabled and INCOMING CALLs are rejected (CLEAR
REQUEST) until the SVC-type exchange is enabled by an Operator
command.
LOCAL CENTRE
NETWORK
REMOTE CENTRE
SVC is established
data
data
Idle timer elapsed
CLEAR REQUEST
CLEAR INDICATION
CLEAR CONFIRMATION
CLEAR CONFIRMATION
SVC is Ilde
Figure 5.9 SVC disconnection
5.3.5.1.2
Chapter 5
After an idle period during which no CIDIN packets have been transmitted on an SVC in
either direction, the centre which had initiated the CALL REQUEST procedure for the
SVC should start the CLEAR REQUEST procedure. The length of the idle period is a
configurable parameter. The idle period can be set to the value "infinitely long" if the
SVC is not to be cleared automatically. Under exceptional conditions, e.g. a system reset,
either centre using an SVC can start the CLEAR REQUEST procedure.
Sixth Edition
Page 15 of 17
14/04/2011
EUR CIDIN MANUAL
5.3.5.1.3
When an established SVC is set Invalid by an operator command, the established SVC
shall be cleared with the clearing cause code set to 00 (DTE originated).
5.3.5.2 Network or CIDIN Remote Centre disconnection

5.3.5.2.1
5.3.6
After a Clear indication is received the Local CIDIN Centre shall attempt to re-establish
the SVC connection.
Reception of a RESET Indication Packet
5.3.6.1
A RESET Indication packet is received at the Local CIDIN Centre in case the remote
centre (remote DTE) or the network (DCE) request re-initialisation of an established SVC.
5.3.6.2
When a RESET Indication packet is received on an established SVC, the loss of data
packets may occur. As there are data recovery procedures implemented in the transport
layer, the SVC should be cleared in the case of reception of a RESET Indication packet by
a CIDIN centre.
5.3.6.3
A CLEAR REQUEST packet with cause code 00 (DTE originated) and an appropriate
diagnostic code (see Appendix F) is used for clearing the SVC.
Figure 5.10 and Figure 5.11 describe the above principles.
5.3.7
Reception of an INTERRUPT Indication Packet
5.3.7.1
The use of INTERRUPT Indication packets in CIDIN is not recommended. In case of

reception of an INTERRUPT Indication packet, the established SVC shall be cleared.
5.3.7.2
A CLEAR REQUEST packet with cause code 00 (DTE originated) and an appropriate
diagnostic code (see Appendix F) is used for clearing the SVC.
This procedure is similar to the one depicted in Figure 5.10 and Figure 5.11.
LOCAL CENTRE
NETWORK
REMOTE CENTRE
RESET REQUEST
RESET INDICATION
RESET CONFIRMATION
RESET CONFIRMATION
CLEAR REQUEST
CLEAR INDICATION
CLEAR CONFIRMATION
CLEAR CONFIRMATION
Figure 5.10 Reception of RESET Indication packet when re-initialisation is originated by

the DTE (remote centre)
Chapter 5
Sixth Edition
Page 16 of 17
14/04/2011
EUR CIDIN MANUAL
LOCAL CENTRE
RESET INDICATION
NETWORK
RESET REQUEST
RESET CONFIRMATION
REMOTE CENTRE
RESET INDICATION
RESET CONFIRMATION
CLEAR REQUEST
CLEAR REQUEST
CLEAR CONFIRMATION
CLEAR CONFIRMATION
Figure 5.11 Reception of RESET Indication packet when re-initialisation is originated by

the DCE (network)
5.3.8
Security and Reliability Aspects
5.3.8.1
It shall be possible to configure (and check) multiple X.25 addresses for a Remote CIDIN
Centre.
5.3.8.2
If the Calling address is not suitable, the CIDIN Centre receiving the Incoming call packet
shall clear the SVC with the clearing cause set to 00 (DTE originated).
5.3.8.3
In case of a connection to a network, a CIDIN Centre shall be connected physically to at

least one X.25 switch. In the event of DCE disconnection due to a network failure and in
case a second access1 to the network is available, call re-establishment should be made
available via this second access.
To increase reliability, it is recommended to connect CIDIN Centres via two physical links, preferably
belonging to different network switches (DCEs).
Chapter 5
Sixth Edition
Page 17 of 17
14/04/2011
EUR CIDIN MANUAL
6.
Transport Layer (4)
6.1
6.1.1
The Transport Protocol Layer
6.1.1.1
Information exchanged over the CIDIN shall be transmitted as CIDIN messages.
6.1.1.2
The length of a CIDIN message shall be defined by the CIDIN packet sequence number
(CPSN). The maximum permissible length is 215 packets, which in effect results in no
practical limitation.
6.1.1.3
Recommendation.- The maximum CIDIN message length should be restricted to 64 Kbytes.
6.1.1.4
If the length of a CIDIN message and its transport and packet headers (as defined below)
exceeds 256 octets the message shall be divided into segments and placed in the user data
field of CIDIN packets. Each segment shall be preceded by a transport header containing
information to enable the re-assembly of the CIDIN message at the exit centre(s) from
individually received segments and to determine further handling of the received complete
CIDIN message.
6.1.1.5
All segments of one CIDIN message shall be provided with the same message identification
information in the transport header. Only the CPSN and final CIDIN packet (FCP) indicator
shall be different.
6.1.1.6
Recovery of messages shall be performed at the transport layer.
6.1.1.7
Recommendation.- When an entry centre has to make separate transmissions of the same
message to more than one exit centre, the same message identification number (MIN) should
be used for each transmission.
6.1.1.8
The transport protocol shall be as described in 6.1.2 below.
6.1.2
The Transport Protocol
6.1.2.1
The Transport Header Format
6.1.2.1.1
The transport header shall contain the following components:
Chapter 6
Message identification number
(MIN)
Final CIDIN packet indicator
(FCP)
Message code and format or

network management field
(MCF/NMF)
Message type indicator
(MT)
Conversation protect indicator
(CP)
Network acknowledgement indicator
(NA)
Entry address
(Ae)
End of header
(EOH)
Sixth Edition
Page 1 of 17
14/04/2011
EUR CIDIN MANUAL
6.1.2.1.2
The transport header shall be generated by the entry centre and shall be interpreted by the exit
centre(s) receiving the CIDIN packet.
6.1.2.1.3
The transport header shall consist of:
First bit transmitted

(low order bit)
0
LENGTH
MIN
1
MIN ITEM
LENGTH
CPSN
CPSN ITEM
FCP
0
NA CP MT
MCF/NMF
0
LENGTH
ENTRY ADDRESS
ITEM
Ae
1
0 0
0 0
8
7 6
5 4
last bit transmitted

6.1.2.1.4
0
3
0
2
MESSAGE
CHARACTERISTICS
ITEM
0
1
END OF HEADER
ITEM
The components contained within the transport header shall be as follows:
6.1.2.1.4.1 The first item of the transport header shall contain the message identification number (MIN)
expressed in binary form. The low order bit of the MIN shall be bit 1 in the second octet of
the item. Any number of octets between one and four shall be employed to provide the MIN.
The number of octets used by the MIN shall be indicated in bits 1 to 4 of the first octet of this
item. The MIN shall identify the number of a CIDIN message transmitted by a specific entry
centre or station.
6.1.2.1.4.2 Recommendation.- Where the volume of traffic requiring acknowledgement so permits, the
number of MINs used should be limited.
6.1.2.1.4.2.1 At each entry centre or station only one pool of MINs shall be used for information and
network management messages.
6.1.2.1.4.2.2 Only when a CIDIN centre or station fails and the value of the last used MIN is
unrecoverable shall the MIN value be reset to zero. At all other times, the next available MIN
from the MIN pool shall be used.
6.1.2.1.4.3 The second item of the transport header shall contain the following two components:
1) A CIDIN packet sequence number (CPSN), beginning in the second octet of this item,
shall identify the sequence number of each CIDIN packet of a message. The CPSN shall
be assigned in sequence beginning with X0000000. The low order bit of the CPSN shall
be bit 1 of the second octet of this item.
Note.a) If the CPSN item consists of two octets including the header item then the X
(bit 8) in the second octet is the FCP component.
b) In the header item a length indication of 0000 is not used and one octet of
information is represented by a length indication of 0001.
Chapter 6
Sixth Edition
Page 2 of 17
14/04/2011
EUR CIDIN MANUAL
2) A final CIDIN packet (FCP) component (bit 8 of the last octet of this item) which shall be
set to:
1
to indicate the last CIDIN packet of a multi-packet message, or the only

packet of a single-packet message;
to indicate all other packets.
6.1.2.1.4.3.1 The number of octets used by the CPSN and FCP shall be indicated in bits 1 to 4 of the first
octet of this item.
6.1.2.1.4.4 The third item of the transport header shall contain the following four components:
1) A five bit component contained in bits 1 to 5, interpreted according to the setting of bit 6
as either:
a)
message code and format (MCF) component, designating which one of the
code and format types specified (see Table 6-1) is employed in the CUDF
for CIDIN information messages; or
b) a network management function (NMF) component, designating one of 32

network management message types and the means for interpreting the
CUDF (see Table 6-1).
2) A message type (MT) component (bit 6) which shall be set to:
0
to indicate an information message;
to indicate a network management message.
3) A one bit conversation protect (CP) component (bit 7) is reserved for future use.
4) A network acknowledgement (NA) component (bit 8) which shall be set to:
0
to indicate acknowledgement not required;
to indicate acknowledgement required.
6.1.2.1.4.5 The fourth item of the transport header shall contain the entry address (Ae) which identifies
the entry point of a CIDIN message into the CIDIN. The entry address shall consist of the
four-letter location indicator of the concerned entry centre followed immediately by one letter
identifying a type of user in the CIDIN. If required, one, two or three additional characters to
further identify the application entity may be used. In those cases where a user is connected
to the CIDIN via a CIDIN station, the entry address shall consist of the four letter location
indicator of the concerned station, followed immediately by four letters identifying a user
within that CIDIN station. The total number of letters in an entry address shall not exceed 8.
Upper case letters shall be used only. The number of octets used by the Ae shall be indicated
in bits 1 to 4 of the first octet of this item and a length of 0000 shall not be used.
Note.- Normally the entry address of a user is set identically to the exit address
6.1.2.1.4.6 The last item of the transport header shall be the end of header (EOH) item, as shown in
6.1.2.1.3 above.
Chapter 6
Sixth Edition
Page 3 of 17
14/04/2011
EUR CIDIN MANUAL
6.1.2.2
Transport Procedures
6.1.2.2.1
General: The transport procedures shall be defined for:

a)
entry centres;
b)
exit centres
6.1.2.2.1.1 Relay centres shall not perform processing functions at the transport layer.
6.1.2.2.2
Transport header generation
6.1.2.2.2.1 For each information message submitted, the entry centre shall accept the following
elements:
a)
message content (any approved code and format);
b)
exit centre address(es);
c)
destination addresses applicable to each exit centre address;
d)
message priority;
e)
message code/format;
f)
requirement for acknowledgement;
g)
requirement for uninterrupted conversation (future use);
h)
requirement for priority interruptible conversation (future use).
Item c) shall be provided for messages in AFTN format.

6.1.2.2.2.2 The entry centre shall generate the appropriate transport header based on the information
given in e), f), g) and h).
6.1.2.2.3
Message identification number assignment
6.1.2.2.3.1 The entry centre shall assign a MIN value to each message, from a pool of available
numbers. MIN values shall be assigned in continuous numerical sequence.
6.1.2.2.3.2 For CIDIN messages which require network acknowledgement, a given MIN value shall not
be reassigned to a new message until the corresponding network acknowledgement has been
received by the entry centre or station.
6.1.2.2.4
Information message handling
6.1.2.2.4.1 The information message content received from the applications software shall be placed in
one or more CUDF, with no addition or modification (see Figure 1.2). This shall be the
responsibility of the entry centre or station.
6.1.2.2.5
Network management message handling
6.1.2.2.5.1 The entry centre shall generate and respond to network management messages using the
standard format. Network management CUDF contents are generated by the entry centre or
station.
Note.- The format of the network management messages is contained in Table 6-2.
Chapter 6
Sixth Edition
Page 4 of 17
14/04/2011
EUR CIDIN MANUAL
6.1.2.2.6
Recovery procedure for messages on CIDIN
6.1.2.2.6.1 Handling of messages requiring acknowledgement on the transport layer

6.1.2.2.6.1.1 For messages requiring network acknowledgement the entry centre shall, before initiating
transmission, set the NA bit to "1" and temporarily store the message for possible
retransmission. After sending the last frame of the message a response time-out (TMR),
based on the transit time to the most remote exit centre, shall be initiated.
6.1.2.2.6.1.2 After complete and error free receipt of the first packet to arrive of any message requiring
network acknowledgement, the exit centre or station shall start a time-out (TNMA) for that
message; the time-out shall be restarted each time a further CIDIN packet of the same
message is received. The time-out shall be stopped when all packets of the message have
been completely received.
6.1.2.2.6.1.3 At the exit centre or station, once a message with the NA bit set to "1" has been completely
assembled and recorded, a network acknowledgement message shall be sent back to the entry
centre or station.
Note.- The format of the acknowledgement message is contained in Table 6-2.
6.1.2.2.6.1.4 Upon receiving a valid network acknowledgement response from all addressed exit
addresses for the complete message, the entry centre shall remove the corresponding message
from retransmission storage, and shall release the MIN value for future use.
6.1.2.2.6.2 Action on detection of message loss
6.1.2.2.6.2.1 If an entry centre or station does not receive a network acknowledgement message for a
message sent with the NA bit set to "1", within a period of time (TMR) it shall retransmit the
message with the same MIN value.
6.1.2.2.6.2.2 If a network acknowledgement message is still not obtained, the entry centre or station shall
send an enquiry message to that exit address, initiate a message response time-out (TEM) and
shall stop transmissions of information messages to that exit address.
6.1.2.2.6.2.3 When an entry centre or station fails to obtain an acknowledgement even after a retry to the
address, it shall inform the application layer and the operator of the unsuccessful attempt to
communicate. No information messages shall be sent to that exit address until one of the
ENQ messages periodically sent to that address is acknowledged for that address by an ENQ
response.
6.1.2.2.6.2.4 When a multiply disseminated message is not acknowledged for one or more exit addresses,
the entry centre or station, on expiry of time-out (TMR) shall retransmit the message only to
those addresses from which no acknowledgement was received. In this instance the exit
centres shall retain packets of a message for a period of time (TNMA) and discard these
packets if the message is not completed. This time TNMA shall be shorter than or equal to
TMR.
Note.- The format of the enquiry message is contained in Table 6-2.
6.1.2.2.6.2.5 On receipt of an enquiry message, the exit centre shall acknowledge the enquiry message by
transmitting an enquiry response message back to the entry centre or station.
Note.- The format of the enquiry response message is contained in Table 6-2.
6.1.2.2.6.2.6 Once the entry centre has received the enquiry response message, it shall resume sending
information messages to that exit address and inform the operator of this event.
Chapter 6
Sixth Edition
Page 5 of 17
14/04/2011
EUR CIDIN MANUAL
Note.- ENQ response messages received without a preceding ENQ message shall be logged
and reported to the operator, but the response message will not be taken as a valid data
exchange.
6.1.2.2.6.2.7 When a response to an enquiry message is not received within a period of time (TEM), the
entry centre or station shall retransmit the enquiry message.
6.1.2.2.6.2.8 When the exit centre or station time-out period expires before all packets of the message
have been completely received, the exit centre or station shall discard the incomplete
message.
6.1.2.2.7
Handling of messages not requiring acknowledgement on the transport layer
6.1.2.2.7.1 After complete and error-free receipt of the first packet to arrive of any message not requiring
network acknowledgement, the exit centre or station shall start a time-out (TNMA) for that
message. The time-out shall be restarted each time a further CIDIN packet of the same
message is received. The time-out shall be stopped when all packets of the message have
been completely received.
6.1.2.2.7.2 When the exit centre or station time-out period expires before all packets of the message have
been completely received, the exit centre shall discard the incomplete message.
6.1.2.2.8
Handling of messages with unacceptable code/format combinations
6.1.2.2.8.1 When an exit centre or station receives a message, requiring or not requiring an
acknowledgement which is in a code and format for which it has no applications software, it
shall discard the message, and send an MCF error message to the entry centre or station.
Note.- The format of the MCF error message is contained in Table 6-2.
6.1.2.2.8.2 On receipt of an MCF error message, the entry centre or station shall notify the application
layer.
6.1.2.2.9
Handling of multiple dissemination messages
6.1.2.2.9.1 For messages requiring multiple dissemination, the recovery procedures shall take place
between the entry centre and all exit centres concerned.
Table 6-1:
Significance of MCF and NMF indicators
MCF/NMF value
b5
b4
b3
b2
b1
Meaning
MCF (MT = 0)
NMF (MT = 1)
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
Reserved
Network management messages
AFTN
OPMET
ATN
Not yet allocated
Not yet allocated
Reserved
Network management messages
Enquiry
Acknowledgement
Enquiry response
Not yet allocated
MCF error
Not yet allocated
Not yet allocated
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
Chapter 6
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
Sixth Edition
Page 6 of 17
14/04/2011
EUR CIDIN MANUAL
MCF/NMF value
b5
b4
b3
1
0
0
1
0
0
1
0
0
1
0
0
1
0
1
1
0
1
1
0
1
1
0
1
1
1
0
1
1
0
1
1
0
1
1
0
1
1
1
1
1
1
1
1
1
1
1
1
b2
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
b1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
Meaning
MCF (MT = 0)
Not yet allocated
Not yet allocated
Reserved for regional use
Table 6-2:
Format for network management messages
NETWORK MANAGEMENT
MESSAGE
C
O
M
M
U
N
I
C
A
T
I
O
S
C
O
N
T
R
O
L
F
I
E
L
D
CIDIN
PACKET
HEADER
T
R
A
N
S
P
O
R
T
H
E
A
D
E
R
NMF (MT = 1)
Not yet allocated
Not yet allocated
Reserved
ACK
ENQ
MP
Enquiry
response
MCF error
Note c)
Note a)
000
Ax
Note a)
Note b)
MIN
next available
CPSN
all zero
FCP
MCF/NMF
see Table 6-1
MT
CP
NA
Ae
Note b)
Note a)
EOH
Note d)
1 000 0000
0100
CIDIN USER DATA FIELD
LENGTH
Note e)
0001
LENGTH
Note f)
0101
LENGTH
Note g)
NOTES:
a) Use the Ae of the original information message
b) Use the Ax of the original information message
c) Use the Ae of the original information message
d) Use the Ax identifier of own centre or station to
which the message refers
Chapter 6
Note b)
0100
NONE
NONE
LENGTH
Note e)
0001
LENGTH
Note f)
0101
LENGTH
Note g)
e) Use the MIN of the original information message

f) Use the Ax of the original information message
g) Use the CPSN of the last packet of the received
CIDIN message. Bit 8 shall be set to 0.
Sixth Edition
Page 7 of 17
14/04/2011
EUR CIDIN MANUAL
6.2
6.2.1
Functions of the CIDIN Transport Layer
6.2.1.1
The CIDIN transport protocol has been designed to perform efficiently those end-to-end
functions required of CIDIN not provided by the network layer. The network layer does
not, for example, consider the message as a whole and processes only individual segments
of it in the CIDIN packets. An end-to-end acknowledgement procedure is also not
contained in the network layer.
6.2.1.2
The CIDIN transport layer contains the end-to-end control functions of the message
transport service provided by CIDIN. The protocol is executed between entry and exit
centres and is handled transparently by other centres for a given message.
6.2.2
6.2.2.2.1
Guidance Material
Entry Centre (Ae)
6.2.2.1
Entry Centre Functions
6.2.2.1.1
Segmenting: Transport PDUs (messages) are divided into segments which will fit into 256
octet CIDIN packets at the entry centre.
6.2.2.1.2
Transmission of AFTN parameters: A special user of the transport layer is the AFTN
interface. Indicators specific to this user (AFTN destination addresses, and priority) are
transmitted.
6.2.2.1.3
Detection that an acknowledgement is missing: As a first recovery step, the message is

retransmitted. If an acknowledgement is still not obtained, the entry centre starts sending
ENQ messages to that Ax and does not send further information messages to that exit
centre until a reply has been received.
6.2.2.2
Entry Centre Finite State Machine
A simplified form of the state transition diagram for the transport entry centre module is shown in
Figure 6.1 and the corresponding state transition table in Table 6-3. A description of primitives, states
and events can be found in Appendix E.
Chapter 6
Sixth Edition
Page 8 of 17
14/04/2011
EUR CIDIN MANUAL
TIMconf
MCF error
TIMconf
ACK
IDLE
TPind
ACK
TIMconf
MCF error
TIMconf
ACK
TPind
MCF error
ATEM
SENQ
SME
ATMR
TPind
MCF error
TPind
ACK
SME
ATMR
WAIT2
TEM
timeout
TIMreq
TS user
TMR
timeout
WAIT1
SME
ATMR*
TPind
Resp ENQ
TMR
timeout
TIMconf
ATEM
SENQ
Legend: events
Action
* other actions possible
Figure 6.1 State Transition Diagram for the Entry Centre Module of a Transport Entity
(Simplified)
Table 6-3:
State Transition Table for the Entry Centre Module of a Transport

Entity
External Events
TIMreq
TS user
IDLE
Initial State
SME
Internal
Events
Chapter 6
TMR
TEM
TIMconf MCF
TIMconf Ax
out of service
SENQ
ATMR
TIMconf ACK
External
Events
TPind
resp
ENQ
WAIT2
TPind
MCF
error
TPind
ACK
WAIT1
Internal Events
ATEM
Sixth Edition
Page 9 of 17
14/04/2011
EUR CIDIN MANUAL
External Events
TIMreq
TS user
WAIT1
TPind
MCF
error
TPind
resp
ENQ
TMR
WAIT2
Implementation
error
6.2.3
TEM
IDLE
Final State
TPind
ACK
Internal Events
Exit Centre (Ax)
6.2.3.1
Exit centre Functions
6.2.3.1.1
Reassembling: Transport PDUs (messages) are reassembled from CIDIN packets at the
exit centre.
6.2.3.1.2
Network acknowledgement: Messages (e.g. AFTN messages) can be given to the

transport layer with the requirement that they be acknowledged within CIDIN. This
acknowledgement has end-to-end significance between entry and exit centres and gives a
high level of confidence in the message transport. For multiple disseminated messages, this
procedure applies to each entry/exit centre pair as though the messages were sent as a set
of non-multiple disseminated messages.
6.2.3.1.3
Detection of an incomplete message: An incomplete message is detected in an exit centre

when one or more CIDIN packets do not arrive in due time. The incomplete message is
discarded and no automatic recovery is performed.
6.2.3.1.4
Detection of unacceptable code/format combinations: An exit centre, which detects this

condition, discards the complete message and sends an error message to the entry centre.
On receiving an error message, an entry centre transport layer notifies its user.
6.2.3.2
Exit Centre Finite State Machine
6.2.3.2.1
A simplified form of the state transition diagram for the transport entry centre module is
shown in Figure 6.2 and the corresponding state transition table in Table 6-4. A description
of primitives, states and events can be found in Appendix E.
Chapter 6
Sixth Edition
Page 10 of 17
14/04/2011
EUR CIDIN MANUAL
TIMind:
TPreq*1
TPind
ENQ
TPreq
ENQ
UNASSIGNED
discard
message
TPind
FCP=1
TIMind:
TPreq*1
TPind
FCP=0
ATMA
ATNMA
TPind
FCP=0
TNMA
TPind
FCP=1
IN_PROCESS
Legend: events
action
Tpreq*1 = ACK or MCF as appropriate
Figure 6.2 State Transition Diagram for the Exit Centre Module of a Transport Entity
(Simplified)
Table 6-4:
State Transition Table for the Exit Centre Module of a Transport Entity
External Events
UNASSIGNED
Initial state
TPind
FCP=1
TPind
FCP=0
TPind
ENQ
IN_PROCESS
External events
Internal Events
TIMind
TPreq*1
TNMA
TPreq ENQ
ATNMA
Internal events
discard message
UNASSIGNED
Final state
IN_PROCESS
Implementation
error
Chapter 6
Sixth Edition
Page 11 of 17
14/04/2011
EUR CIDIN MANUAL
6.2.4
CIDIN Transport Protocol Formats
6.2.4.1
The structure of the CIDIN packet is shown in Figure 6.3. The transport header precedes
the segment of user data and, although it is present in every CIDIN packet, it is processed
only in the entry centre where it originates and in the addressed exit centre.
256 octets
CIDIN packet header
CIDIN transport header
Processed in
each CIDIN
centre
Processed in
each entry and exit
centre
Message segment
Transparent to CIDIN
Data communications field

Figure 6.3 Structure of a CIDIN Packet
6.2.4.2
The transport header consists of 5 header items coded according to the principles
described in Appendix C.
The MIN and Entry address items identify the message uniquely.
The CPSN item indicates the position of the message segment in the complete message
and whether the segment is the final one in the message.
The message characteristics item indicates the type of processing required for the
message.
The entry address item gives the address of the CIDIN centre at which the CIDIN
message was generated.
The end of header item delimits the header.
6.2.5
Message Identification and Addressing
6.2.5.1
When the user of the transport layer requests a message to be sent, the transport layer
generates a number (the MIN) to identify the message. Each entry centre generates MINs
independently so that the combination of entry centre address and MIN should identify
uniquely a message known to the whole of CIDIN at any one time. There will be only one
MIN pool per centre. The MINs will be allocated in numerical order, step size 1, starting
value 0, and will be re-used after reaching maximum value (wrap-around). The uniqueness
requirement implies that the entry centre, when generating MINs, should use as large a
pool as possible. However the size of the MIN represents a transmission overhead and
should therefore be restricted to a maximum size of four octets. The MIN and entry address
are used in the exit centre for reassembling the CIDIN packets into distinct messages and
for identifying the messages end-to-end in the acknowledgement or error procedures. As
such, the MIN should not be reset to zero other than when it roles over from its maximum
value or due to a failure of a centre which renders the last MIN unrecoverable.
Note 1.- Care should be taken that the MIN pool is sufficiently large to prevent MINs reused within a specific time period; 48 hours minimum, 31 days recommended.
Chapter 6
Sixth Edition
Page 12 of 17
14/04/2011
EUR CIDIN MANUAL
Note 2.- For the re-use of MIN no check on the acknowledgement of the message for which
it was previously is necessary.
6.2.5.2
In order to avoid any misunderstanding with regard to referencing of messages the MIN
should be presented to the operator as a decimal number.
= message parameters such as Ae of sender

= message parameters such as addressed remote Axs
= message parameters such as Ads
Application 1
Application 2
Ax1
Ax2
Application 3 e.g. AFTN Interface
Ax3
Common service
access point
Figure 6.4 Segmenting, Re-assembly and Addressing in the Transport Layer

6.2.5.3
Chapter 6
When passing messages up to the application programs, the exit addresses Ax are the
standard means of addressing the users of CIDIN (transport users) - see Figure 6.4. The
Axs are therefore the "transport service access point identifiers" in OSI terminology. There
should be a one-to-one correspondence between application processes and Axs. The
interactions between the users and the transport layer are a local matter and the way in
which they are implemented is not a subject for standardisation. This includes the way in
Sixth Edition
Page 13 of 17
14/04/2011
EUR CIDIN MANUAL
which a user registers with the transport layer when operational, the transfer of messages,
etc. An entry centre is not required to check the compatibility of the MCF with the Axs of
the message.
6.2.6
Acknowledgement Procedures
6.2.6.1
When sending a message, a user of the transport layer can indicate whether the message
should be acknowledged end-to-end within CIDIN. The acknowledgement procedure
functions in an entry centre as follows: a transport entity must first store a message
requiring acknowledgement for possible subsequent retransmissions. After segmenting the
message and passing it down to the CIDIN packet layer, it waits for an acknowledgement
to be received from the addressed exit centre. After receiving the acknowledgement, the
temporary storage can be deleted. If no acknowledgement is received, the transmission is
repeated and if an acknowledgement is still not received within a reasonable time, the
application is informed. The address in question is thereafter polled at regular intervals and
no further messages may be sent to it until a positive response has been obtained to this
polling.
6.2.6.2
The acknowledgement procedure for a message which is multiply disseminated is logically

equivalent to the case in which a simple message (not multiply disseminated) is sent to
each Ax addressed.
6.2.6.3
The acknowledgement procedure can lead, in some very rare cases, to a message being
received twice. For example, an acknowledgement can cross a retransmitted message in the
network, implying that the re-transmitter timer, TMR, has been set to too low a value. An
entry centre transport entity must therefore be able to cope with the reception of two
acknowledgements for the same message. The action performed by the exit centre
receiving the same message twice is a local matter: it could pass the duplicated message on
to the user or it could apply an ageing process to Ae/MIN combinations of messages
received. The possibility of duplicated messages must be considered when designing
higher-level protocols for users of CIDIN.
6.2.6.4
The acknowledgement procedure and the associated retransmission can also lead to
messages arriving at an exit centre in a different order from the one in which they were
transmitted. This must be taken into account by the higher level protocols.
6.2.6.5
The destination address item of the CIDIN protocol does not exclude the possibility to
code more than twenty one Ads to one Ax. However, since the source of a message
transmitted via the CIDIN AFTN application is an AFTN message with a maximum
number of twenty-one addressee indicators, all messages containing more than twenty-one
Ads per Ax should not be acknowledged.
6.2.7
Error Handling
6.2.7.1
Apart from the errors detected by the acknowledgement procedure, other errors can be
recognised by, and should be handled by the transport procedure. The general approach
taken is that the message in error should be handled if possible, but if that is not possible
then the event should be journalised. A warning message to the operator will alert him to
the event. More application specific information will be generated as other applications are
defined in the procedures.
a)
CIDIN packet of a message missing:

This situation can arise, for example, because timer TNMA has expired during the
assembly of a message at layer 4. A missing packet will prevent the exit function
from building a complete message from the received packets. The incomplete
message should be discarded, the event logged and a warning message sent to the
operator containing the Ae/MIN.
Chapter 6
Sixth Edition
Page 14 of 17
14/04/2011
EUR CIDIN MANUAL
b)
Receipt of ACK, ENQ response or MCF error packet:

The event is logged, reported to the operator and the packet is discarded.
c)
Receipt of packets with sequence numbers higher than the sequence number of a
packet with FCP=1:
Incoming packets containing the address of the CIDIN centre or station as an exit
address and belonging to the same message (as indicated by entry address and MIN)
are held until they form a complete message or until the packet reception timer
expires. A complete message consists of a continuous sequence of packets including
the packet sequence number zero and a packet with the Final CIDIN Packet Indicator
(FCP) set. As soon as a complete message is formed, it is passed up to the higher
layer of protocol handling for normal processing. If it contains packets with sequence
numbers higher than that of the lowest numbered packet with FCP set, those higher
numbered packets are discarded. The action is recorded in the log.
d)
Any other inconsistency in the CIDIN packet header data in related packets:
The header data is taken from the first received packet of the message (CPSN not
necessarily = 0) or from the packet (with CPSN = 0) of the message. The event is
logged and a warning message sent to the operator containing the Ae/MIN.
It is recommended that the maximum length of a message transmitted by CIDIN be
considerably less than the maximum allowed. This is in order to place a bound on the
retransmission time necessary in the case of an error in transmission. The
recommendation is analogous to the segmentation of long messages in the AFTN.
If, for a multiply disseminated message, some Axs are not available because, for
example, an enquiry/response exchange is in progress, the message should be sent to
the available Axs. The application should be informed that some Axs were not sent the
message. When they become available again, the application can send a new CIDIN
message with the original contents.
6.2.8
Form of the Service Interface to the Transport Layer
6.2.8.1
6.2.8.2
Chapter 6
The information required by the transport layer when accepting a message from a user for
transmission includes:
message priority
acknowledgement required or not
message characteristics (AFTN or other format, conversation protect, etc.)
exit centre address(es)
destination addresses (if AFTN message)
message content.
The way in which this information is mapped onto the various headers of the CIDIN
protocols is shown in Figure 6.5. The form of the interface between transport layer and
application is, however, a local matter.
Sixth Edition
Page 15 of 17
14/04/2011
EUR CIDIN MANUAL
AFTN Message
CIDIN Transport Layer
CIDIN message
segment
transport Header
X.25 Packet Layer
Message Priority
Message code/Format
conversation protection
AFTN destination Address
Exit Centre Address
CIDIN Packet Sequence Number
Final CIDIN Packet Indicator
Message Identification Number
Message type indicator
Entry centre address
general format identifier

logical channel (group) number
Application Layer
CIDIN Packet Layer
Network ACK
CIDIN Packet Header

X.25 Packet Header
Figure 6.5 Mapping of Message Parameters onto Headers

6.2.8.3
Messages are fully entered at entry centres before transmission begins and fully assembled
at exit centres before delivery to applications. An example of the way in which an AFTN
message can be segmented through the layers is shown in Figure 6.6.
Protocol Layer
Protocol Data Units and Control Information
AFTN Message
Application
Software
AFTN Header
Pri
Ad Ad Ad Ad Ad Ad Ad Ad Ad
Origin
Message text
(Axs derived from tables)

MCF, NA, CP
MP
Ax1(Ad) Ax2(Ad Ad Ad) Ax3(Ad Ad Ad Ad Ad)

Pri
Origin
Message text
transport header
Transport Layer
MP
Ax1(Ad) Ax2(Ad Ad Ad) Ax3(Ad Ad Ad Ad Ad)

first message segment (256 octets)
MP Ax1 Ax2 Ax3
second message segment (256 octets)
etc.
formation of CIDIN packets of maximum length 256 octets
CIDIN Packet Layer
CIDIN packets
sent to Ax1
CIDIN packets
sent to Ax2 Ax3
MP Ax1 Ad1
MP Ax2 Ad...Ad Ax3 Ad...Ad
MP Ax1
MP Ax2 Ax3
Figure 6.6 Example of the Way in which Messages can be segmented
Chapter 6
Sixth Edition
Page 16 of 17
14/04/2011
EUR CIDIN MANUAL
6.2.9
Enquiry (ENQ) procedures
6.2.9.1
6.2.10
If it is indicated in the message transport that acknowledge is required, then it is possible

for the sender to know that the responsibility for further treatment of the message has been
taken over by the addressed application entity. When the message has not been
acknowledged even after a retry, the sending centre starts an ENQ procedure, that is, it
sends ENQ messages to the particular Ax in a regular interval (TEM) until an ENQ
response is received from this particular Ax. Until that event has occurred no further
messages to that address are sent. It may be possible to reduce the ENQ message frequency
after a certain time period has elapsed, but it should be realised that this reduction causes
delay in restoring the traffic flow after restoration of service. The operator shall be
informed of the start of an enquiry procedure, and on the leaving the ENQ state. The
operator thus has the opportunity to initiate message delivery to an alternate Ax if required.
The operator shall have the means of initiating or stopping ENQ procedures. ENQ
responses received without a preceding ENQ message will be logged and reported, but will
not be taken as valid information.
Flow Control
Flow control at the transport layer is performed through the implementation of a windowing
mechanism. The range of the transport layer window sizes is 1 to 99, the recommended value
being 5.
6.2.11
Parameters
The parameters of the CIDIN transport layer are three timer values and the window size:
TMR:
time-out for expected network acknowledgement (Message Response). The

recommended value is 40 seconds.
Furthermore, the ability to configure the TMR per Ax or Ax could be
implemented.
TNMA:
time-out for reassembling of CIDIN packets to a message (Next Message

Arrival) The recommended value is 35 seconds. TNMA is less than or
equal to TMR.
TEM:
time-out for enquiry response (Enquiry Message). The recommended value

is 40 seconds.
w:
transport layer window size is the number of outstanding messages. The

range of w is 1 to 99. The recommended value is 5.
Chapter 6
Sixth Edition
Page 17 of 17
14/04/2011
EUR CIDIN MANUAL
7.
7.1
The AFTN Interface

Information mapping
7.1.1
In an entry centre, the AFTN interface maps the information contained in an AFTN
message onto the information required by CIDIN for transmitting the message. In the exit
centre, the AFTN interface performs the reverse operation. Information to be mapped is:
Network addresses
AFTN addressee indicators are mapped onto exit centre addresses.
Priority
The AFTN priority indicator is mapped onto CIDIN priorities in the entry
centre.
Parameters
Certain message parameters (acknowledgement required, message type =
AFTN) are set in the entry centre.
7.2
Logical View
7.2.1
7.3
The AFTN interface does not constitute a protocol as in the layers below since it does not
execute procedures between peer entities. The AFTN interface therefore only has local
functions to perform. However the rules executed by the AFTN interface for mapping
AFTN messages to and from the CIDIN layers is standardised. If this were not the case,
the transmission of a message by CIDIN would not be equivalent to its transmission by a
physical leased circuit (see Figure 1.3).
AFTN Header and Message Part
7.3.1
Chapter 7
The conventions for mapping an AFTN message onto a CIDIN user data field are shown in
Figure 7.1. Note that IA5 characters are used.
Sixth Edition
Page 1 of 3
14/04/2011
CIDIN user data field
Modified AFTN heading
EUR CIDIN MANUAL
Message part
MODIFIED
ADDRESS
(see 4.4.15.2)
Component of the message part

Start-of-Heading Character
Alignment Function
Priority Indicator
Alignment Function
ORIGIN
(see 4.4.15.2.2)
Filing Time
Originator Indicator
Priority Alarm
Optional Heading Information
Alignment Function
Start-of-Text Character
TEXT
(see 4.4.15.3)
Beginning of Text
Message text
Confirmation (if necessary)
Correction (if necessary)
ENDING
(see 4.4.15.3.12)
Alignment Function
Page-feed sequence
End-of-text Character
Figure 7.1 Structure of CIDIN User Data Field for Messages in AFTN format
(paragraph numbers refer to ICAO, Annex 10, Vol. II)
7.4
Address Mapping
7.4.1
For each AFTN address (Ad) in an AFTN message, the corresponding CIDIN exit address
(Ax) is determined from a table. The rules for generating Axs and Ads are described in
conjunction with the CIDIN packet protocol.
7.4.2
AFTN addresses are removed from AFTN messages in the mapping to CIDIN format since
this facilitates address stripping in CIDIN.
7.4.3.
The address mapping software should take advantage of the implicit limits placed on the
numbers of addresses: an AFTN message can have up to three lines of addresses. The
CIDIN packet protocol requires that all address items (Axs and associated Ads) for a
message must fit into one CIDIN packet. In the case where an AFTN message would
exceed this restriction, the AFTN interface must generate more than one CIDIN message
corresponding to the AFTN message.
7.4.4
The AFTN interface is allowed some flexibility in associating Ads with the Axs which are
responsible for the Ads. The choice of an alternate exit centre for an AFTN message is thus
the task of the AFTN interface. Alternative exit centres are not handled within CIDIN
itself. Where practicable, AFTN messages shall be re-routed to an alternative exit centre
for further delivery on the low speed AFTN in cases where delivery to the Ad via the
primary Ax is not possible.
7.5
Priority Mapping
7.5.1
Chapter 7
The AFTN priorities are mapped into the CIDIN priorities as indicated in the following
table:
Sixth Edition
Page 2 of 3
14/04/2011
EUR CIDIN MANUAL
Table 7-1:
7.5.2
7.6
CIDIN
Priority
bit-code
Description of
Characteristics
AFTN-Priority
Assignment
000
Vital to network operation
001
Messages relating to personal safety
010
Very urgent message
011
ATS co-ordination messages
AFTN DD
100
Flight safety message
AFTN FF
101
Routine message
AFTN GG
110
Low priority
AFTN KK
111
Non time critical message
AFTN SS
The original AFTN priority is left together with the date/time group and the origin address
in the AFTN message (CIDIN user data). This means that the AFTN priority does not have
to be derived from the CIDIN priority in the exit CIDIN centre.
Error handling
7.6.1
7.7
AFTN priority mapping
In the transmission of an AFTN message through the CIDIN network, the AFTN
transmission identifier (channel designator and sequence number) disappears from the
message headers. For this reason it is not practical to use the Annex 10 Vol. II procedures
(using the TI as a reference) as for low speed AFTN.
Errors requiring operator action
7.7.1
In the cases where errors which require active investigation are detected in the
AFTN/CIDIN interface, it is convenient to report such errors to the local AFTN operator
for further action. Each CIDIN Entry centre maintains a journal which cross refers the
Ae/MIN with the incoming (to the entry centre) AFTN TI, and each CIDIN Exit centre
maintains a similar journal which cross refers the Ae/MIN with the outgoing (from the
AFTN centre) AFTN TI. These two journals allow for end-to-end message tracing.
7.7.2
All cases of AFTN/CIDIN interface errors should give rise to an operator error message
with the following information:
a)
b)
c)
Error reason
Ae/MIN
ORIGIN LINE (from CIDIN information field).
7.7.3
Both b) and c) are included in the error message since either could be corrupted, and at
least one of these fields is required in order to be able to trace back to the originator of the
message.
7.7.4
The local AFTN operator (at the exit centre) receives an error message, and a service
message is sent to the entry centre AFTN operator with the following text:
CIDIN/AFTN
"ERROR REASON"
Ae/MIN
ORIGIN LINE (from CIDIN information field)
Chapter 7
Sixth Edition
Page 3 of 3
14/04/2011
EUR CIDIN MANUAL
8.
8.1
Statistics
Functional Areas
8.1.1
Four main functional areas may be identified when considering the application of CIDIN
statistics as follows:
System planning
for estimating future requirements.
Centre supervision
to assist in the immediate supervision of the CIDIN centre.
Network supervision
to assist in the evaluation of the need to rearrange the network configuration
and/or routing.
Facility performance
for use in isolating immediate operational and statistical problems in
automatic systems.
8.1.2
Statistics can be processed on-line, off-line or a mixture of both. In any case, the source
information must be collected on-line and archived on a suitable storage medium.
8.1.3
The statistics should be gathered and presented in a layered manner, corresponding to the
CIDIN protocol layers. The time span for each report can be fixed or variable by
command. It is suggested that one hour time divisions is convenient, with the facility to
present information at 10 minutes intervals when required for more definitive analysis.
8.2
Application layer statistics

Number of messages leaving application for transmission over CIDIN.
Number of messages arriving at application after transmission over CIDIN.
8.3
Layer 4 statistics
Chapter 8
Number of messages received
Number of messages transmitted
Average length of received messages
Average length of transmitted messages
Number of unacknowledged messages (requiring ACK)
Number of messages transmitted to each Ax
Number of messages received from each Ae.
Sixth Edition
Page 1 of 2
14/04/2011
EUR CIDIN MANUAL
8.4
Layer 3b statistics
Number of CIDIN packets received
Number of CIDIN packets transmitted
Number of CIDIN packets received per priority
Number of CIDIN packets transmitted per priority
Number of CIDIN packets discarded with PLC = 0
8.5
Layer 3a/2 statistics
8.5.1
These statistics are listed for consideration by Administrations when producing

specifications.
8.5.2
For each PVC defined on the route:
8.5.3
Number of packets received
Number of packets transmitted
Number of Reset requests sent
Number of Reset confirmations received
For each link from the centre:
8.5.4
Load in percentage of capacity (utilisation)
Number of link failures and recoveries
Percentage of time that line is out of service
Number of restart requests sent
Number of restart confirmations received.
The following statistic is considered to be useful but is not required for network
management purposes:
8.6
Number of centres found to be unreachable.
Additional statistics
8.6.1
The average and maximum elapsed time from the transmission of a message to the
reception of the corresponding ACK, are considered important statistics in the assessment
of network performance.
8.6.2
Additional statistics information may be required to support the CIDIN Network

Management function as detailed in the CIDIN Network Management Centre specification
e.g. PVC occupancy, average message length per Ax, number of messages per VC.
Chapter 8
Sixth Edition
Page 2 of 2
14/04/2011
EUR CIDIN MANUAL
9.
Testing
9.1
Introduction
9.1.1
9.2
In order that the various implementations of the CIDIN protocols are compatible, it is
important that they be tested according to the same set of principles. Experience has shown
that, although it is claimed that systems have been implemented according to the one set of
protocol specifications, they are often not capable of inter-working. This is due to errors in
implementation or to different interpretations of the specifications. The primary objective
of this chapter is to formulate recommendations for testing the ability of a given CIDIN
implementation to inter-work with an adjacent system and within a network environment.
Scope
9.2.1
9.3
This chapter provides general recommendations for the testing of CIDIN implementations.
The actual testing procedures are contained in Appendix D. Tests are described in
sufficient detail to give an appreciation of the variety of functions that are covered and the
facilities required.
General Principles
9.3.1
The creation of standards for testing is subject to consideration by a number of

standardisation bodies concerned with open systems (e.g. ISO, ITU-T).
9.3.2
CIDIN implementations consist of protocol layers according to the principles of the

Reference Model for Open Systems Interconnection. In this context, the OSI test concepts
distinguish between "multi-layer" and "embedded single-layer" testing.
9.3.3
In multi-layer testing, more than one protocol layer is subject to testing at the one time. An
extreme case of multi-layer testing is when the whole system containing the protocol
implementation, the "system under test" (SUT) is tested as a "black box" i.e. with no
regard for its internal structure. This strategy is likely to be more efficient when testing
implementations containing very few errors and has the advantage that layers are tested in
their real environment. However the multi-layer strategy is not suited to localising the
source of errors in individual protocol layers.
9.3.4
In embedded single-layer testing, an individual layer is the "implementation under test"

(IUT) and all test sequences are designed to test the behaviour of only this one layer. This
strategy, when repeated for each layer, requires more effort than the multi-layer strategy.
Single-layer testing is, however, more efficient in localising errors. It requires access to the
service interfaces of the protocol layer implementations.
9.3.5
A distinction is also made between "active" and "passive" testing. In active testing, the
SUT or IUT is tested against an implementation specifically designed for testing purposes.
For example, the reaction of the SUT to unexpected events, e.g. protocol errors, can be
tested explicitly. In passive testing, events at a given layer are merely monitored using a
suitable device in order to show that the SUT behaves correctly under normal operating
conditions.
9.4
CIDIN Test Strategy
9.4.1
Chapter 9
It is recommended that tests of CIDIN implementations be performed using active testing.

This does not preclude the additional use of passive testing. However active testing is
Sixth Edition
Page 1 of 18
14/04/2011
EUR CIDIN MANUAL
considered to be necessary in the CIDIN environment, in which equipment from different

suppliers must inter-work internationally.
9.4.2
Initially, it is recommended that a new CIDIN implementations be tested according to the

single-layer strategy. Testing begins with the layer suspected of being in error and works
upwards. Each set of tests concentrates on only one layer. Only after confidence has been
gained in an implementation of layer "N", does testing of layer "N+1" begin. If
subsequently an error is suspected in a layer that has already been accepted, tests must be
repeated on this layer. Additional tests may be required in this case. Depending upon the
changes made to this layer after the error has been found, the repetition of tests on
overlying layers could be necessary. For the purposes of this Manual, this approach is
called CIDIN Conformance Testing.
9.4.3
After successful completion of Conformance Testing, additional tests are performed,

involving the SUT and one or more "test partners". In the case of CIDIN, the test partners
are the SUT (a complete CIDIN centre, possibly together with an AFTN centre) and one or
more CIDIN centres or other complete implementations of the CIDIN protocols. For the
purposes of this Manual, this approach is called CIDIN Interoperability Testing.
9.4.4
The methods used in the various testing phases are different. They are described in the
appropriate sections.
9.4.5
In the case of CIDIN single-layer conformance tests, one of the test partners is an
implementation of a protocol layer (layer N) in a CIDIN centre. This implies that the
software modules representing CIDIN layers 2 to N should be separable from protocol
layers N+1 and higher. Stated in terms of the OSI Reference Model, this means that layer
N must offer a "service interface" to the higher layers. It can be assumed that this is true of
CIDIN implementations since this requirement conforms to modern software design
principles concerning modularity. The service interface should be accessible for testing
purposes: if this is not the case then only a restricted set of tests can be performed. The
other test partner is special-purpose test equipment.
9.4.6
The other test partner in CIDIN single-layer conformance tests is one or more intelligent
protocol monitor/analysers. Depending upon the layer being tested, this equipment will
simulate certain CIDIN layers and have special test software on top of it.
9.4.7
It can be expected that, as experience with CIDIN implementations accumulates, the set of
test procedures will grow and the procedure definitions themselves will evolve. For
example, if a problem occurs during operation of the network due to incompatibility of
implementations, additional tests should be included in the test suite so that this problem
can in future be excluded during the testing of new implementations.
9.4.8
A principal difficulty in performing protocol testing is the co-ordination of the test

partners: actions performed by one partner must be in correct sequence with the actions
performed by the other. This difficulty is often overcome by embedding the
implementation under test in an environment which makes it behave passively ("test
responder" or "ferry"). The responsibility for the test sequences and the co-ordination is
then taken over by the test equipment, which consequently must be more sophisticated.
The use of such test equipment is not always possible within the scope of CIDIN testing so
that a different strategy has to be adopted.
9.5
Description Technique
9.5.1
Chapter 9
The strategy requires the exact specification of steps in the test procedures and their
sequencing for all partners involved. The format used in Appendix D for this purpose is
called "Procedures" and forms the bulk of the test descriptions. The test procedures are
divided up into sets, each of which is summarised in an "Overview" format.
Sixth Edition
Page 2 of 18
14/04/2011
EUR CIDIN MANUAL
9.5.2
Each test is performed using a particular configuration defined in the "Configuration"

format. A configuration is used to test only one layer of the protocol stack. More than one
test configuration may be required.
9.5.3
The formats "Configuration", "Overview" and "Procedures" are described briefly below:
9.5.3.1
Configurations
Implementation under test (IUT)
Which layer in which function (e.g. entry centre)?
Parameter settings
Values of parameters in the IUT and constant when using this configuration.
Underlying layer
Which layer in which function underlies the IUT?
Initialisation state
How is this layer initialised before using this configuration?
Parameters
Values of parameters in this layer constant when using this configuration.
Number of test connections involved

How many logical connections are accessed by the IUT when using this configuration?
Connections in underlying layer

Logical connections accessed by the layer under the IUT.
Logical connections accessed by the layer under the IUT.
How many?
(a)to (c)
Association of these connections with the test partners (X) to (Y).
Test partners
Physical entities involved in this configuration.
(X) to (Z)
Association of the identifiers (X) to (Z) with the test partners in this configuration.
Additional conditions
Other requirements placed on this configuration.
Figure
Chapter 9
Sixth Edition
Page 3 of 18
14/04/2011
EUR CIDIN MANUAL
Graphical representation of the configuration.

9.5.3.2 Overview
9.5.3.2.1
Testing can in principle never be exhaustive. For this reason, the complete set of tests is
divided into functional sets, called "test group" which can be extended as required. A test
group concentrates on one aspect of the protocol being tested e.g. the connection
establishment phase. The tests for any one layer are contained in a number of test groups.
A test group is associated with the testing of only one layer in single-layer testing.
9.5.3.2.2
All common features of the tests in a test group are described in the format "Overview".
The parameters in such a description are as follows:
Purpose
Which functions are to be tested by this test group?
References to CIDIN SARPs
Which paragraphs of the CIDIN SARPs describe the protocol functions being tested?
Configuration used
A test group is associated with only one previously defined configuration.
To be preceded by test groups
It could be advisable for reasons of test efficiency to complete other test groups
before beginning on this one.
Coding
The coding of all protocol data units (PDUs) used in the test group is defined here.
Initialisation
Initialisation conditions common to all the procedures in this test group. All test
procedures start in this state with all partners waiting.
Special considerations
Miscellaneous information.
Test procedures
List of all procedures in this test group and their purposes
9.5.3.3 Procedures
9.5.3.3.1
The test sequences in a test group are called "procedures". A procedure specification must
detail the actions to be performed by each test partner and the sequence of these relative to
those of other partners. The procedure specification describes this situation of test partners
active in parallel.
9.5.3.3.2
There are two basic types of operations to be performed by test partners: either the partner
sends a PDU or it waits for an external event to occur. Each procedure begins with all
partners in a wait state except for the partner which performs the initial send.
Chapter 9
Sixth Edition
Page 4 of 18
14/04/2011
EUR CIDIN MANUAL
9.5.3.3.3
The parameters associated with each step in a procedure are as follows:

Step number
Sequential number
Alternate step
If after execution of this step an additional test partner must become active, the
appropriate step number is given here. This can lead to a "forking", i.e. an increasing
number of test partners can become active simultaneously.
Test partner
Which test partner performs the step - (X), (Y) or (Z) - see the configuration
description?
Connection
On which connection does the event occur - (a), (b) or (c) - see the configuration
description?
Wait event / Send?
Does the test partner wait for an event or send a PDU?
PDU, Time
Which PDU is sent or which time-out occurs?
Parameters/Comments
Additional information
9.6
Performance of the Tests
9.6.1
In general, two or more test operators, who determine when and what PDUs are sent at the
layer under test by their respective implementations, execute each test procedure. It is
important that an operator has voice contact with other operators.
9.6.2
Each test procedure begins with all test partners in a stable wait state. The appropriate
operator then causes the partner active in procedure step 1 to send its specified PDU. The
ensuing sequence of events and their synchronisation is then as detailed in the procedure
description.
9.6.3
The method with which the operator causes the appropriate PDU to be sent depends upon
whether he is operating the IUT or test equipment side of the configuration:
at the IUT, the PDU is sent (a) as an automatic reaction of the protocol machine with
no interaction at the service interface or is sent (b) as a result of an interaction at the
service interface with the operator possibly via special test software;
at the test equipment, the required PDU is sent explicitly by the operator either via predefined test sequences or manually.
Note that the IUT itself is not modified since this would defeat the purpose of testing.
Chapter 9
Sixth Edition
Page 5 of 18
14/04/2011
EUR CIDIN MANUAL
9.6.4
In specifying the test procedures, care has been taken to test the reactions of the IUT only
as required by CIDIN SARPs. Where CIDIN SARPs allow some freedom (e.g. in layer 3a:
when to send RR when receiving information packets), the test procedures should allow for
various possible implementation design decisions.
9.6.5
The interactions required at the service interface of the IUT in the single-layer testing are
those which would normally be caused by an ordinary layer on top of the IUT. No
abnormal behaviour of the IUT is required by the test procedures. This simplifies the
performance of the tests at the IUT.
9.7
Conformance Testing
9.7.1
General
9.7.1.1
9.7.2
Conformance testing is performed per CIDIN protocol layer in order to localise and
diagnose errors in an IUT and to increase confidence in a new CIDIN centre.
Physical Layer
9.7.2.1
The layer 1 tests are not described in this manual because they concern only the physical
interface of each CIDIN centre (DTE) with the authority (e.g. PTT) supplying the
communication lines (DCE). However there is a need for co-ordination between the
respective centres to ensure agreement on the details involved, in addition to provision of
the lines themselves.
9.7.2.2
In the case where CIDIN centres are connected to each other locally or to test equipment
during a testing phase, special physical interfaces can be agreed upon bilaterally with or
without modems.
9.7.2.3
Equipment to be used will vary from case to case but will normally consist of special
physical line monitors/analysers displaying bit patterns sent and received together with
indicators for the status of the interface lines.
9.7.2.4
When performing single-layer tests, the physical layer must be working reliably before
tests with layer 2 are commenced. However, extensive testing of the physical layer is only
feasible in conjunction with tests of the higher layers when timing or synchronisation
problems become apparent.
9.7.2.5
It is important that higher layer tests (in particular, layer 2 tests) be performed using
different data rates in the physical layer. This is necessary in order to detect possible timing
errors. The data rates to be tested should include, as a minimum, all those at which the
CIDIN centre under test will use in operations. Although protocol testing in discrete steps
as recommended here can never detect all timing problems of real-time operations,
experience has shown that the use of different data rates in the physical layer can be a help
in this matter.
9.7.3
Data Link Layer
9.7.3.1
The layer 2 tests consist of the following four test groups:

1. Test the transfer between non-operational (ADM) and operational (ABM) modes under
various conditions including error situations.
2. Test the transfer of data in I-frames for the normal error-free cases.
3. Test flow control procedures during data transfer.
Chapter 9
Sixth Edition
Page 6 of 18
14/04/2011
EUR CIDIN MANUAL
4. Test flow control procedures during data transfer.

9.7.3.2
One test configuration is used - see Figure 9.1. The CIDIN centre under test is connected
directly to a protocol monitor/analyser. This is the traditional and most effective way of
testing link layer protocols. In the monitor/analyser, the Test sequences are programmed
manually since no direct use can be made of its HDLC (LAP-B) implementation. However
advantage can be taken of the tools available for generating the test sequences.
9.7.3.3
No changes are to be made to the layer 2 implementation in the CIDIN centre under test.
The reactions expected from it in the test procedures are those required by the protocol
definition. This is appropriate because it can be expected that the HDLC implementations
in CIDIN centres will at least partly be in intelligent line controllers or in firmware.
9.7.3.4
The test operator at the CIDIN centre needs indications of the status of the HDLC
implementation, e.g. whether it is in ADM or ABM state. It must be possible to set the
implementation in a number of different initialisation states.
(X)
CIDIN operator
with access to
service interface
(Y)
Test operator
terminal
Layer 3a or test
software
Protocol
analyser/
monitor
Layer 2 (IUT)
One physical circuit

Figure 9.1 Test Configuration: Layer 2
9.7.3.5
The interactions necessary between the test operator and the layer 2 implementation under
test are those normally offered to a layer 3a implementation. Not all of the actions of the
implementation under test need to be visible to the operator e.g. the spontaneous sending
of an RR.
9.7.3.6
For effective testing, the test operator may need access to the layer 2 service interface, e.g.
for:
manipulating the data being passed to layer 2
simulating congestion.
It appears important that the interactions at this service interface can be traced if necessary.
9.7.4
X.25 Network Layer
9.7.4.1
The layer 3a tests consist of the following three test groups:

initialisation procedures: transition to and from flow control ready state
non-error procedures in flow control ready state
recovery procedures
Chapter 9
Sixth Edition
Page 7 of 18
14/04/2011
EUR CIDIN MANUAL
9.7.4.2
A functioning layer 2 in the test equipment and in the CIDIN implementation under test is
a pre-condition for the layer 3a tests. The test equipment will normally consist of a
protocol monitor/analyser in which the layer 3a test sequences are generated and executed
by hand. The generation of the test sequences can be supported by a set of tools designed
especially for X.25 layer 3.
9.7.4.3
Two distinct configurations are used - see Figure 9.2. A test operator at the CIDIN centre
under test participates in the three test groups. In general, a flexible method of generating
and changing routing tables, in the CIDIN centre under test, is necessary.
9.7.4.4
The required test operator interactions are those, which would normally be expected from
the layer 3b software. This means that a layer 3b implementation, properly configured,
could be used to drive the tests. Test operator access to a layer 3a service interface
(corresponding to the interface with layer 3b) is not necessary.
9.7.4.5
No changes should be necessary to the layer 3a implementation under test. All reactions to
the test procedures are those prescribed by the protocol definition.
Configuration 1
(X)
(Y)
Protocol
analyser/monitor
Test operator
Layer 3b
CIDIN operator with
access to layer 3b
Layer 3a (IUT)
Test sequences
Layer 2
Layer 2
Configuration 2
(Z)
(X)
(Y)
Operator access for
monitoring (tracing)
Protocol
analyser/monitor
Test sequences
Layer 3a (IUT)
Layer 2
Test sequences
Layer 2
(b)
Protocol
analyser/monitor
Layer 2
(a)
Figure 9.2 Test Configurations: layer 3a
Chapter 9
Sixth Edition
Page 8 of 18
14/04/2011
EUR CIDIN MANUAL
9.7.5
CIDIN Network Layer
9.7.5.1
The layer 3b tests consist of the following test groups:
9.7.5.2
entry centre layer 3b functions

relay functions for messages without multiple dissemination
multiple dissemination and address stripping in a relay centre
error processing
The exit centre layer 3b functions, consisting mainly of recognising of the local Axs, are
included with the relay functions. This grouping is determined by the following properties
of layer 3b:
Entry centre layer 3b functions can conveniently be isolated from relay centre
functions.
Exit centre layer 3b functions (except for the recognition of its own Ax in a packet) are
local matters and not a subject for conformance testing.
All other functions of layer 3b can be tested in the context of a relay centre.
9.7.5.3
The test configurations are shown in Figure 9.3. The partner against which the CIDIN
centre under test is tested is an intelligent protocol monitor/analyser containing the full
X.25 implementation required by CIDIN, together with the test sequences, as specified in
the procedure descriptions. The latter is a user of layer 3a, simulating the layer 4
implementation. No routing or passing on of CIDIN packets is necessary in the test
equipment.
9.7.5.4
The logical connections between the IUT and the corresponding test partner are generally
considered to be VCs. However, the test groups may contain tests applicable exclusively to
PVC or SVC type connections.
9.7.5.5
The software required in the SUT consists of an operator interface for controlling the test
runs together with diagnostic tools (e.g. traces). Operator access must be possible at the
CIDIN packet service interface layer (as well as at the transport layer) since the test
procedures involve individual CIDIN packets. These components are similar to software
which would normally be written during the software development for self test purposes.
9.7.5.6
In the CIDIN centre under test, the test procedures are driven by a standard layer 4
implementation. In test group 1, some operator intervention is necessary at the layer 3b
service interface.
Chapter 9
Sixth Edition
Page 9 of 18
14/04/2011
EUR CIDIN MANUAL
Configuration 1
(X)
(Y)
Layer 4
Layer 3b(IUT)
Test sequences
Layer 3a
Layer 3a
Layer 2
Layer 2
(a)
(b)
Two VCs on the same or different circuits
Configuration 2
(X)
(Y)
Layer 4
Layer 3b(IUT)
Test sequences
Layer 3a
Layer 3a
Layer 2
Layer 2
(a)
(b)
(c)
Three VCs on at least two different circuits
Figure 9.3 Test Configurations: Layer 3b
9.7.6
CIDIN Transport Layer
9.7.6.1
The layer 4 tests are divided into two basic functional sets:
entry centre functions and
exit centre functions.
9.7.6.2
Chapter 9
This division is convenient since the sets of functions are clearly distinct. A separate test
configuration is necessary for each of the two sets. For each set we distinguish between
normal and exceptional sequences of events and tests applicable to both types of VCs or
only one type (SVC or PVC). This leads to six test groups.
Sixth Edition
Page 10 of 18
14/04/2011
EUR CIDIN MANUAL
9.7.6.3
The configuration (see Figure 9.4) in the CIDIN centre under test is very similar to an
operational configuration since we are dealing with the uppermost standardised CIDIN
layer. The test procedures are driven in the SUT by an operator (via an operator terminal)
and appropriate application software. In the case of AFTN messages, the operator interface
could be via an AFTN software interface or an AFTN centre.
However more efficient testing is to be expected from using an operator interface directly
on top of the transport layer.
9.7.6.4
The operator sends and receives messages. In addition, he must be able to:
reset layer 4 and
trace the service interface between layer 4 and the application software.
9.7.6.5
The ability to trace the interface between layers 4 and 3b is also useful.
Configuration 1
(Y)
Test equipment
simulating two exit
centres
(X)
Application
Test sequences
Layer 4 (IUT)
EXIT1
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Layer 2
EXIT2
(a)
(b)
Two VCs possibly on the same circuit
Configuration 2
(X)
(Y)
Test equipment
simulating one entry
centre
Application
EXIT 1
Test sequences
Layer (IUT)
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Layer 2
(a)
One VC
Figure 9.4 Test Configurations: Layer 4
Chapter 9
Sixth Edition
Page 11 of 18
14/04/2011
EUR CIDIN MANUAL
9.7.6.6
The test equipment consists of a system with complete implementations of CIDIN layers 2
to 3b and special layer 4 test software. Since no particular demands are placed upon
throughput in the single-layer tests, this equipment could consist of an intelligent protocol
monitor/analyser. It could also consist of a CIDIN centre modified for testing the layer 4
implementation. The lower layers 2, 3a and 3b are normal operational implementations.
Layer 4 is replaced by test software specially written to test layer 4 and to exercise the
lower layers. Depending upon the design of the test equipment, it is likely that this test
software would have the same structure as and many components common with the layer
3b test software.
9.7.6.7
Basic requirements placed upon the test software in the test equipment are the ability to:
send and receive CIDIN messages which have been edited before the test is started,
manipulate the sequence in which CIDIN packets are sent,
send network management messages and to
analyse and record CIDIN packets received.
9.7.7
Application Interface
9.7.7.1
CIDIN provides a reliable connectionless transport service for any application which can
use this service conveniently. The specification of CIDIN protocols extends up to layer 4
and the application protocols of a CIDIN user are, in general, of no interest to CIDIN since
the application protocol data units are transmitted transparently by it. Therefore,
application protocols need not be tested within the scope of testing CIDIN protocol
implementations.
9.7.7.2
This is however not true when the user is the AFTN - see Chapter 7. Parts of the AFTN
"protocol" (e.g. addressing conventions) are mapped onto the headers of layer 3b and 4
protocol data units at an entry centre and mapped out of the headers at an exit centre. The
implementation of this mapping (the "AFTN interface") is therefore relevant when testing
a CIDIN centre. The AFTN interface is used by all applications which communicate via
AFTN messages.
9.7.7.3
By comparison with the single-layer test configurations for all other CIDIN layers, the
configurations necessary for testing the AFTN interface are not "peer-to-peer" - see Figure
9.5. This means that the implementation under test (AFTN Interface: application layer) is
not located logically on the same protocol layer as the test software (layer 4 or user of layer
3b). The possible configuration in which the AFTN application is tested peer-to-peer
(AFTN station to AFTN station) is not suitable for detecting all possible errors.
9.7.7.4
The AFTN interface tests are divided into two basic sets:
entry centre mapping, and
exit centre mapping.
9.7.7.5
Within each set, the normal and error cases are tested, thus giving four test groups.
9.7.7.6
The test configurations include a CIDIN centre to which AFTN stations are connected
either directly or via an AFTN centre. No assumptions are made on how or where the
AFTN interface is implemented since this is a local matter. The test configurations also
include protocol test equipment. Alternatively a modified CIDIN centre could be used.
9.7.7.7
Sets of testing procedures concerning the AFTN and the CIDIN network management
application interfaces are included in Appendix D.
Chapter 9
Sixth Edition
Page 12 of 18
14/04/2011
EUR CIDIN MANUAL
Configuration 1
(X)
(Y)
AFTN
station
Test equipment
simulating two exit
centres
AFTN interface
(IUT)
AFTN centre
ENTRY
Layer 4
Test sequences
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Layer 2
EXIT1
EXIT2
(a)
(b)
Two VCs possibly on the same circuit
Configuration 2
AFTN
stations
AFTN centre
(X)
(Y)
Test equipment
simulating one entry
centre
AFTN interface
(IUT)
Test sequences
EXIT
Layer 4
ENTRY
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Layer 2
(a)
One VC
Figure 9.5 Test Configurations: AFTN Interface
9.8
Interoperability Testing
9.8.1
Chapter 9
In interoperability testing, the CIDIN centre under test is treated as a whole without any
regard to its internal structure and without concentrating on any one particular protocol
layer. However, such an approach must allow access to configuration tables and other
parameters in the CIDIN system.
Sixth Edition
Page 13 of 18
14/04/2011
EUR CIDIN MANUAL
9.8.2
The tests performed are equivalent to the interactions, which may take place during normal
operations. Interoperability tests are highly dependent upon the test configuration available
(test equipment, other CIDIN centres, connectivity, physical interface to the AFTN). The
functions investigated during interoperability testing are a subset of those investigated
during single-layer testing.
9.8.3
It may be useful, when diagnosing the results of a test session, to look at traces which have
been made at various points in the SUT. It is recommended that tracing be performed at the
service interfaces of the protocol layers. It is helpful for trouble-shooting purposes if a
tracing capability is present in all CIDIN implementations and this can be switched on or
off with a software switch according to need. It is also advisable to monitor the
communication line(s) between the SUT and the test equipment at various protocol layers
with a suitable device during testing.
9.8.4
The CIDIN centre under test is tested in its functions as an entry/exit and as a relay centre
as shown in Figure 9.6. The status of the AFTN centre is only schematic and can, in fact,
be connected to or integrated into the CIDIN centre in different ways. We distinguish
between the operation of the entry/exit centre when handling AFTN and non-AFTN traffic.
Tests involving the latter via an operator interface at the SUT are necessary in order to
investigate the handling of non-AFTN formats. They are also necessary to investigate
functions, which would not be accessible via an AFTN centre.
9.8.5
Interoperability tests are normally restricted to bilateral and quadrilateral tests.
9.8.5.1
In the case of bilateral tests, the minimal set of interoperability tests to be performed is:
Group 1: AFTN and non-AFTN messages: Sending and receiving of various types of
messages by the SUT under different conditions (flow control blockages, line
disturbances).
Group 2: Mechanisms for re-transmission of messages: acknowledgement loss and
consequent procedures.
Group 3: Traffic exchange using SVCs: Verification of functionalities CIDIN SVCs.
9.8.5.2
In the case of quadrilateral tests, the minimal set of interoperability tests to be performed
is:
Group 1: Transmission/reception of multi-destination messages in normal cases and
in cases of network failure.
Group 2: Alternative routing selection procedures
Chapter 9
Sixth Edition
Page 14 of 18
14/04/2011
EUR CIDIN MANUAL
Configuration 1
AFTN Station
AFTN Station
SUT
Other implementation or
test equipment simulating
an AFTN+CIDIN
entry/exit centre.
AFTN + CIDIN
Entry/Exit Centre
1 physical circuit with 1 VC
Configuration 2
CIDIN operator
terminal
Test operator
terminal
SUT
an AFTN+CIDIN
entry/exit centre
AFTN + CIDIN
Entry/Exit Centre
One or more physical circuits with several VCs
Configuration 3
Test operator
terminal
SUT
a CIDIN entry/exit centre
CIDIN Relay
Centre
Several physical circuits

Figure 9.6 Test Configurations: Interoperability Testing
Chapter 9
Sixth Edition
Page 15 of 18
14/04/2011
EUR CIDIN MANUAL
9.9
Testing phases in CIDIN
9.9.1
Conformance testing (single layer - local)
9.9.1.1
Purpose
9.9.1.1.1
This type of testing is called conformance testing by the relevant ISO groups. Its purpose is
to test the logic of the protocol implementation in the system under test, without
necessarily considering dynamic (performance) aspects. The rationale behind the layer-forlayer approach is discussed extensively in the CIDIN manual.
9.9.1.2
Configurations
9.9.1.2.1
The configurations involve one CIDIN centre, the system under test, and the test
equipment with local connections (see CIDIN Manual Figure 9.1 to Figure 9.5). Note that,
in general, access to the service interfaces of the implementation of individual layers under
test is necessary.
9.9.1.3
Tools
9.9.1.3.1
Common to all test groups in this phase is the use of dedicated test equipment, either
special purpose analyser/monitors, or
CIDIN centres extended with features to drive conformance tests.
9.9.1.4
Test cases
9.9.1.4.1
In particular, the test cases include the generation of protocol errors by the test equipment
in order to test the reaction to these in the system under test. The specification of
conformance test cases in Appendix D cannot be considered to be complete. Almost
certainly, additional cases will have to be specified reflecting the experience in this and
other phases during the testing.
9.9.2
Conformance testing (Single layer - remote)
9.9.2.1
Purpose
9.9.2.1.1
Although desirable, the performance of this test phase is not mandatory in the CIDIN
context. It is a variation of the first conformance testing phase: the test tools are used
remotely from the system under test. This allows the CIDIN implementation in one State,
to be tested via communication lines against test equipment in another State with the
possibility of discovering additional errors in the implementations.
9.9.2.2
Configurations
9.9.2.2.1
As for previous phase (remotely).
9.9.2.3
Tools
9.9.2.3.1
As for previous phase.
Chapter 9
Sixth Edition
Page 16 of 18
14/04/2011
EUR CIDIN MANUAL
9.9.2.4
Test cases
9.9.2.4.1
As for previous phase
9.9.3
Interoperability testing (bilateral)
9.9.3.1
Purpose
9.9.3.1.1
This and the following test phases are called interoperability testing by the relevant ISO
working groups. By comparison with conformance testing, the system under test is
considered as one unit with no regard for the individual layers. This test phase is described
under "interoperability testing" in paragraph 9.8. Dynamic aspects are not handled in this
phase.
9.9.3.2
Configurations
9.9.3.2.1
The configurations involve one CIDIN centre (the system under test) and the test partner
(see Appendix D - Interoperability Tests and CIDIN Manual Figure 9.6).
9.9.3.3
Tools
9.9.3.3.1
The test partner could be another CIDIN centre taking part in the interoperability tests or
equipment simulating a complete CIDIN centre. In addition, tracing and monitoring
facilities are necessary.
9.9.3.4
Test cases
9.9.3.4.1
See Appendix D, Interoperability Tests. Because the test partner is a complete CIDIN
centre, it is recommended that no protocol errors be intentionally generated to test the
reaction of the system under test; this is more the task of conformance testing.
9.9.4
Interoperability testing (quadrilateral)
9.9.4.1
Purpose
9.9.4.1.1
Quadrilateral interoperability testing is a natural extension of bilateral interoperability

testing in that more than two centres are tested together. It includes dynamic (performance
and load) testing.
9.9.4.2
Configurations
9.9.4.2.1
The configurations involve one CIDIN centre (the system under test) and three or more
test partners (see Appendix D - Interoperability Tests).
9.9.4.3
Tools
9.9.4.3.1
The test partners could be other CIDIN centres taking part in the network tests or
equipment simulating complete CIDIN centres. In addition, tracing and monitoring
facilities are necessary.
Chapter 9
Sixth Edition
Page 17 of 18
14/04/2011
EUR CIDIN MANUAL
9.9.4.4
Test cases
9.9.4.4.1
See Appendix D Interoperability Tests. It is probable that the performance of such tests
will lead to the specification of additional single-layer tests.
9.9.5
Network extension
9.9.5.1
Purposes
9.9.5.1.1
Network extension refers to the procedures for extending a functioning CIDIN network
either by the addition of further centres or by additional functions. Because of the
introduction of new features into an existing operational environment, it is likely that test
procedures different from those used in the previous phases will be necessary.
9.9.5.2
Configuration
9.9.5.2.1
These will depend on the type of extension being tested.
9.9.5.3
Tools
9.9.5.3.1
These are likely to be the same as those used for network testing.
9.9.5.4
Test cases
(to be defined)
Chapter 9
Sixth Edition
Page 18 of 18
14/04/2011
EUR CIDIN MANUAL
10.
Operational Procedures
10.1
Introduction of new CIDIN COM Centres in the International Network
10.1.1
Preconditions
Before a new CIDIN COM Centre becomes operational, a set of pre-defined steps must be
completed in accordance with the principles and procedures provided in the EUR
CIDIN Manual and the ATS Messaging Management Manual. Full compliance is
necessary, in order to avoid disturbances in the daily operation of the CIDIN Centres during
this phase. For example, if the operational tables were loaded into the new system without
any international co-ordination, all operational CIDIN COM Centres would receive ENQ
from an unknown Entry Centre.
10.1.2
Stepwise approach
The following preparatory steps must be carried out successfully before any action for
introduction into the CIDIN network is initiated (also see Chapter 9):
1.
successful technical and operational acceptance of any new system, including CIDIN
Protocol Conformance Tests,
2.
bilateral Interoperability Tests with each adjacent COM Centre,

In this phase, the routing tables of the new system contain only the Ax of the COM
Centres which are involved in test activities. The tests are agreed on a bilateral or basis.
3.
quadrilateral Interoperability tests with adjacent COM Centre(s) and the first centre(s)
behind.
In this phase, only the Ax of the additional COM Centres are included in the routing
tables of the new system. The tests are agreed on a quadrilateral basis.
10.1.3
Routeing arrangements for the Ax of the new COM Centre
10.1.3.1 In accordance with the Routeing Update Procedure, which is described further in 10.3, a
COM Centre requesting to be integrated into the international CIDIN network sends a
Change Request to the AMC Operator.
10.1.3.2 As a result of the successful execution of the above procedure, the Ax and the routeing
arrangements for the new CIDIN Centre are known and the CIDIN routeing tables in all
CIDIN Centres are updated at the same time i.e. the agreed AIRAC date.
10.1.4
Introduction of the operational AFTN Routeing Tables
10.1.4.1 The introduction of the fully established AFTN Routeing Table, as agreed during the AMC
procedure, must be performed step by step. The new CIDIN COM Centre carries out the
following procedure with every CIDIN node of the network:
1) the next COM Centre is contacted and an agreement on the date for testing and starting
operation is reached i.e. AFTN message exchange using the respective exit addresses,
2) a simulation of message exchange is performed (testing),
3) actual traffic is exchanged (operation)
10.1.4.2 If one or more COM Centres are affected by transit traffic (CIDIN Relay), then the new
CIDIN Centre should inform these centre(s) in advance about the tests and the operational
date.
10.1.4.3 The introduction of the fully established AFTN Routeing Tables throughout the network
should be completed by the AIRAC date following the AIRAC referred to in 10.1.3.2. In
case this introduction procedure is not completed by this time, the new Centre informs the
AMC accordingly and provides a list of the centres already introduced.
Chapter 12
Sixth Edition
Page 1 of 4
14/04/2011
EUR CIDIN MANUAL

10.1.4.4 When the introduction of the AFTN Routing Tables is completed, the integrated COM
Centre informs the AMC of its successful introduction into the international network.
10.1.4.5 It is the responsibility of the new CIDIN Centre or the respective Authority to co-ordinate the
above actions.
Chapter 12
Sixth Edition
Page 2 of 4
14/04/2011
EUR CIDIN MANUAL
10.2
QSP procedure in CIDIN operations
10.2.1
Introduction
10.2.1.1 When requesting agreement on the re-routeing of traffic in the CIDIN environment, unlike
the conventional AFTN, a clear distinction must be made between re-routeing in terms of
VCG to reach the original exit address Ax (conventional QSP), and re-routeing that implies
re-mapping of AFTN addressee indicators (Ad) to a new exit address (alternate Ax).
10.2.1.2 The QSP procedure used in the conventional AFTN (Ref. Annex 10, Volume II, Chapter 4)
was adapted to produce a CIDIN QSP procedure, according to which, formal and
unambiguous messages are used for the co-ordination of CIDIN traffic re-routeing.
10.2.2
Message Types
10.2.2.1
The analysis of the workflow led to the establishment of the following message types:
Name of message Direction of co-ordination
Subject
Request
from the initiating body
to initiate a re-routeing/re-mapping request
Agreement
response to the initiating body
to confirm the request
Partial Agreement response to the initiating body
to confirm the request in part
Disagreement
to disagree to the request
Cancellation
from the initiating body
to stop the re-routeing/re-mapping measure
Confirmation
to confirm stopping
10.2.2.2
As there are two different possibilities for change requests, each kind of change uses a
dedicated message set (re-routeing messages, re-mapping messages).
Note.- To facilitate migration to AMHS, CIDIN Network Management Messages (operator messages),
are being replaced by corresponding AFTN service messages. The content and format of these
messages is described in detail in the EUR/NAT Routing Directory.
Chapter 12
Sixth Edition
Page 3 of 4
14/04/2011
EUR CIDIN MANUAL
10.3
Routing Update Procedure in the CIDIN network
10.3.1
Purpose of the procedure
10.3.1.1 The aim of the routeing update procedure is to ensure that the routeing tables implemented
by all CIDIN/AFTN COM Centres correspond to those contained in the ATS Messaging
Management Centre (AMC) database and that no inconsistency or other operational
problems arise as a result of a routeing modification not previously analysed and agreed
formally.
10.3.2
Procedure and Documentation
10.3.2.1 The procedure is detailed in EUR Doc 021 ATS Messaging Management Manual.
Chapter 12
Sixth Edition
Page 4 of 4
14/04/2011
EUR CIDIN MANUAL
11.
11.1
Quality of Service
Introduction
11.1.1
Quality of Service (QoS) provided by a network is the ability of the network to satisfy user
requirements. In this context, a user may be a network application, a human end user or a
network administrator.
11.1.2
Aeronautical applications impose particular safety critical and time critical performance
requirements on the AFS.
11.1.3
By defining appropriate Quality of Service (QoS) performance requirements for the AFS
and identifying criteria by which performance can be measured, it is possible to ensure that
current applications are served in an optimal manner, network resources are efficiently
deployed and network developments are in line with the evolution of applications.
11.1.4
Within the scope of the AFS, QoS performance requirements are most effectively expressed
in terms of the following parameters:
message loss probability
transit times
integrity
availability
11.2
Requirements
11.2.1
The AFS accommodates various applications that may have different requirements. A
formal analysis to determine QoS parameter values that should be met by the AFS is a very
complex task, so over-dimensioning of the network is usually adopted, resulting in sufficient
capacity and service assurance but also significantly higher costs.
11.2.2
In a pragmatic approach, the following sources of information are considered:
available regulatory documentation,
characteristics of present and projected traffic,
user and network operator expertise.
11.2.3
Furthermore, to arrive at concrete values for performance parameters, a number of

assumptions and restrictions are made:
as it is virtually impossible to adapt the network to the specific requirements of each

application, the most demanding QoS requirements are considered,
the QoS values defined represent worst-case performance,
the QoS values defined are those the transport layer should provide to the application,
only the international segment of the network is considered. Local arrangements

should ensure provision of appropriate QoS at the national level (SLAs between users
and national AFS providers).
11.2.4
Based on the above analysis the following numerical values are assigned to performance
parameters for the EUR AFS:
QoS performance requirements
Message loss probability (ACK is not received within 2 min)
Maximum transit time (for 95% of the traffic)
Integrity (probability of undetected message corruption)
Availability on a yearly basis
11.3
Numerical values
< 10-4
< 10 sec
< 10-6
99.99%
Enablers
11.3.1
Chapter 11
Network performance is highly dependent on features, facilities and services such as:
switching capacity of a communications centre,

Sixth Edition
Page 1 of 2
14/04/2011
EUR CIDIN MANUAL
11.3.2
11.4
bandwidth/line capacity,
reliability of network components,
appropriate staffing,
efficient management of network resources at the operational and administrative
levels.
Furthermore, in the frame of AFS performance, particular application requirements such as

retention of traffic archives for investigation purposes, provision of back-up media etc.
should also be noted, even though they are not formally considered as factors contributing to
QoS.
Standard performance measurement method
11.4.1
The specification of numerical values for performance requirements is meaningless unless

provision is foreseen for measurement of network performance. In practical terms,
measurements are performed on the two major components of the network, which are the
switching systems (nodes) and the links used.
11.4.2
Technically, such measurements involve, among other things:

generation of large message/data volumes,
automation of measurement,
time stamping of messages,
use of statistical analysis.
11.4.1
Capacity assessment of a switch
11.4.3.1
An estimation of the traffic volumes a switching system should be able to handle in its
lifetime could be made through the following calculations:
Current traffic figures under normal operation are increased by:
30% spare capacity for rerouting purposes
100% for anticipated general traffic growth (5% yearly growth over 12 years)
50% for new applications, and their expected decreased efficiency in data handling and
the additional amount of details to be transported.
11.4.3.2
The required capacity (for the lifetime of a system) is thus four times the current traffic.
11.4.3.3
Knowledge of the actual switching capacity of a communication centre is considered very

important for the operation, management and development of the AFS network and the
assessment of network performance. To measure this switching capacity specially designed
test equipment should be deployed using specific test principles and performance values
commonly agreed in the EUR AFS community.
11.4.3.4
A high level description of such equipment, called test harness and of the testing
methodology to be applied is provided in Appendix H of this Manual.
11.4.2
Transit time assessment
11.4.4.1
Statistical analysis of transit time measurements may be used for the evaluation of the
efficiency of main and alternate routes deployed within the network so that the network
performance is optimized to meet the corresponding QoS performance requirements.
11.4.4.2
Dedicated or integrated tools allow, among other things, for the measurement of actual
transit time between Ae/Ax pairs, based on the time stamping of the original message and
the corresponding ACK. These tools may also be used for monitoring and analysis of CIDIN
traffic and investigation of error situations and other protocol-related events.
Chapter 11
Sixth Edition
Page 2 of 2
14/04/2011
EUR CIDIN MANUAL
Attachment A:
Change Control Mechanism of the EUR CIDIN Manual
Proposals to introduce changes to the existing CIDIN procedures/documentation may arise

from CIDIN users or manufacturers. The procedure for submission and processing of a
Defect Report (DR) or a Change Proposal (CP) involves the following steps:
A.1
Procedure for DR
a.
A problem is detected concerning the operation of the CIDIN network, which may be
attributed to the CIDIN protocol, implemented CIDIN procedures and/or
inconsistencies in CIDIN documentation.
b.
The problem is reported to the Rapporteur of the AFSG Operations Group, by

submission a defect report (DR). A standard reporting format is used (see attached
template).
c.
The Rapporteur assigns a number and priority to the defect report and introduces it to
the agenda of an upcoming meeting of the AFSG Operations Group.
d.
The AFSG Operations Group evaluates the report and either adopts it as a working
item or rejects it. The party, which submitted the defect report, is notified accordingly.
e.
Experts of the AFSG Operations Group are assigned to the problem and milestone
dates are set. Outside expertise may be invited to participate, as appropriate.
f.
The AFSG Operations Group develops proposals for resolving the problem and
submits them to the AFSG for approval.
g.
The AFSG approves or rejects the presented proposals. In case of the latter, the subject
is referred back to the AFSG Operations Group (step e) or discarded.
h.
The AFSG Operations Group drafts appropriate text for amendment of the EUR
CIDIN Manual and submits it to the AFSG for approval.
i.
The AFSG approves or rejects the proposed material. In case of the latter, the subject
is referred back to the AFSG Operations Group (step h).
j.
The proposed amendments to the CIDIN Manual are presented to the EANPG for
approval.
k.
Solutions are implemented.
Steps (f) and (h) may run in parallel.
A.2
Procedure for CP
The same structured procedure, with the exception of steps (f) and (g) applies in case of
proposed enhancements to the CIDIN Manual or inconsistencies in existing CIDIN
documentation.
In this case, a change proposal (CP) should be submitted to the AFSG Operations Group.
The format of the CP is similar to that of the DR.
Attachment A
Sixth Edition
Page 1 of 3
14/04/2011
EUR CIDIN MANUAL
A.3
Template for Defect Reports / Change Proposals
TEMPLATE FOR DEFECT REPORTS / CHANGE PROPOSALS
DR_____
CP_____
Title:
Short, indicative textual name
Reference:
Number assigned by the OG Rapporteur
Originator reference:
Provided by the originator
Submission date:
Submitting State/Organization:
Author:
Contact Information:
e-mail, fax, telephone and postal address
Experts involved:
Status:
Assigned by the OG Rapporteur
Priority:
Assigned by the OG Rapporteur
Document reference:
Affected section(s) of the EUR AMHS Manual

or its Appendices
Description of defect:
Nature of the problem in detail

Reason(s) for requesting changes
Assigned expert(s):
Task history:
Working Papers and Information Papers

Produced on the subject
Proposed solution:
Including amendments to the text, if feasible
Attachment A
Sixth Edition
Page 2 of 3
14/04/2011
EUR CIDIN MANUAL
DR/CP STATUS control sheet

Event
Date
DR or CP received
submission date
discussion at
OG/ ...
Date for development of
proposals/ solutions
discussion at
OG/ ...
presentation to
AFSG/ ...
Date for development of
amendment to the Manual
discussion at
OG/
presentation to
AFSG/ ...
Status
Remark
Set to submitted
Set to accepted
Set to rejected
Responsible:
Set to resolved
Set to adopted
Set to rejected
Responsible:
Set to approved
Set to approved
for application
Additional DATES and comments
END of document
Attachment A
Sixth Edition
Page 3 of 3
14/04/2011
ICAO EUR DOC 005
INTERNATIONAL CIVIL AVIATION ORGANIZATION
APPENDICES
of the
EUR CIDIN MANUAL

Sixth Edition
Published by the European and North Atlantic Office of ICAO
April 2011
EUR CIDIN MANUAL APPENDICES
Table of Contents
A
Appendix A - Abbreviations and Terms .............................................................................................. 1
A.1 ABBREVIATIONS.................................................................................................................................. 1
A.2 DEFINITION OF TERMS ....................................................................................................................... 6
B
Appendix B CIDIN Conformance Proforma .................................................................................... 1
B.1 INTRODUCTION ......................................................................................................................................... 1
B.2 DOCUMENT STRUCTURE ........................................................................................................................... 1
B.3 REFERENCES AND STANDARDS ................................................................................................................. 2
B.4 CONFORMANCE PROFORMAE .................................................................................................................... 2
B.4.1
Physical Layer Layer 1 ................................................................................................................. 2
B.4.2
Link Layer Layer 2 ....................................................................................................................... 3
B.4.3
Network Layer Layer 3a (X.25 Packet Layer) ............................................................................. 3
B.4.4
Network Layer Layer 3b (CIDIN Packet Layer) .......................................................................... 4
B.4.5
CIDIN Transport Layer Level 4 ................................................................................................... 5
B.4.6
Application Layer CIDIN Network Management Application .................................................... 6
B.4.7
Application Layer AFTN Application.......................................................................................... 6
B.4.8
Application Layer OPMET Operator Message Application ........................................................ 7
B.4.9
Application Layer OPMET Application ...................................................................................... 7
B.4.10 Application Layer ATN Subnetwork Application........................................................................ 7
B.5 ABBREVIATIONS AND SYMBOLS ............................................................................................................... 8
B.6 CONFIGURABLE PARAMETERS PROFORMA FOR NEW CIDIN CONNECTIONS ............................................ 9
C
Appendix C General Coding Principles ............................................................................................ 1
C.1 CODING PRINCIPLES.................................................................................................................................. 1
C.1.1
General ............................................................................................................................................ 1
C.2 FORMATS .................................................................................................................................................. 1
C.2.1
Header Items ................................................................................................................................... 1
C.2.2
Header Item Code ........................................................................................................................... 1
C.2.3
Allocation of Header Item Codes .................................................................................................... 2
D
Appendix D CIDIN TESTING PROCEDURES............................................................................... 1
D.1 CONFORMANCE TESTS (SINGLE LAYER) ....................................................................................... 1
D.1.1
CONFORMANCE TESTING PROCEDURES .............................................................................. 2
D.1.2
Purpose of conformance tests .......................................................................................................... 2
D.1.3
Testing prerequisites ....................................................................................................................... 2
D.1.4
CONFORMANCE TESTS (SINGLE LAYER) Layer 3b .............................................................. 3
D.1.5
CONFORMANCE TESTS (SINGLE LAYER) Layer 4 .............................................................. 23
D.1.6
CONFORMANCE TESTS (SINGLE LAYER) AFTN interface ................................................. 49
D.1.7
CONFORMANCE TESTS (SINGLE LAYER) CIDIN Network Management Application
Interface . . . . ................................................................................................................................................ 64
D.2 INTEROPERABILITY TESTS (BILATERAL) ........................................................................................ 72
D.2.1
INTEROPERABILITY TESTING PROCEDURES (Bilateral) ................................................... 73
D.2.2
Purpose of bilateral interoperability tests ...................................................................................... 73
D.2.3
Testing prerequisites ..................................................................................................................... 73
D.3 INTEROPERABILITY TESTS (QUADRILATERAL)............................................................................... 81
D.3.1
INTEROPERABILITY TESTING PROCEDURES (Quadrilateral) ............................................ 82
D.3.2
Purpose of quadrilateral interoperability tests ............................................................................... 82
D.3.3
Testing prerequisites ..................................................................................................................... 82
E
Appendix E Interface Primitives........................................................................................................ 1
E.1 PRIMITIVES ............................................................................................................................................... 1
E.2 ENTRY CENTRE STATES ............................................................................................................................ 2
E.3 ENTRY CENTRE EXTERNAL EVENTS ......................................................................................................... 2
E.4 ENTRY CENTRE INTERNAL EVENTS .......................................................................................................... 2
E.5 ENTRY CENTRE ACTIONS .......................................................................................................................... 2
E.6 EXIT CENTRE STATES ............................................................................................................................... 2
E.7 EXIT CENTRE EXTERNAL EVENTS ............................................................................................................. 3
E.8 EXIT CENTRE INTERNAL EVENTS .............................................................................................................. 3
E.9 EXIT CENTRE EXTERNAL ACTIONS ........................................................................................................... 3
Sixth Edition
Page i of ii
14/04/2011
E.10 EXIT CENTRE INTERNAL ACTIONS ............................................................................................................ 3

F
Appendix F - Guidance on the Implementation of SVCs.................................................................... 1
F.1 INTRODUCTION ......................................................................................................................................... 1
F.2 PURPOSE AND SCOPE ................................................................................................................................ 1
F.3 NETWORK IMPLEMENTATION .................................................................................................................... 1
F.3.1
Availability ...................................................................................................................................... 1
F.3.2
Security ........................................................................................................................................... 3
F.4 NETWORK CONFIGURATION ...................................................................................................................... 3
F.4.1
Description ...................................................................................................................................... 3
F.4.2
Advantages of the use of SVCs ....................................................................................................... 6
F.4.3
Implementation phases .................................................................................................................. 11
F.5 SVC SET-UP AND CLEARING .................................................................................................................. 11
F.5.1
Timers ........................................................................................................................................... 11
F.5.2
Particularities of alarms ................................................................................................................. 12
F.5.3
Call re-establishment periodicity................................................................................................... 13
G
Appendix G X.25 PICS/PRL .............................................................................................................. 1
G.1 DEFINITIONS ............................................................................................................................................. 1
G.1.1
ITU-T and OSI X.25 Standards ....................................................................................................... 1
G.1.2
Usage and explanation .................................................................................................................... 2
G.1.3
Notation ........................................................................................................................................... 2
G.1.4
References ....................................................................................................................................... 2
G.2 CONFORMANCE STATEMENT..................................................................................................................... 3
G.3 NETWORK LAYER REQUIREMENTS ........................................................................................................... 3
G.4 GENERAL DTE CHARACTERISTICS ........................................................................................................... 4
G.5 PROCEDURES, PACKET TYPES AND PACKET FORMATS. ............................................................................ 5
G.6 MISCELLANEOUS FEATURES AND OPTIONS ............................................................................................. 10
G.7 FACILITIES .............................................................................................................................................. 11
G.8 PARAMETER VALUES AND RANGES ........................................................................................................ 15
H
Appendix H Centre Switching Capacity ........................................................................................... 1
H.1 INTRODUCTION ......................................................................................................................................... 1
H.2 SWITCHING CAPACITY MEASUREMENT .................................................................................................... 1
H.2.1
Test Harness .................................................................................................................................... 1
H.2.2
Test Principles and Performance Values ......................................................................................... 2
H.2.3
Method of Capacity Measurement .................................................................................................. 3
H.3 REALISATION ............................................................................................................................................ 4
Sixth Edition
Page ii of ii
14/04/2011
Appendix A - Abbreviations and Terms
A.1
ABBREVIATIONS
(as used in the EUR CIDIN Manual)
ABM
Asynchronous Balanced Mode
ACK
Acknowledgement message
ACP
Alternate Connection Path
ADISP
Automated Data Interchange Systems Panel
Ad
Destination address
ADM
Asynchronous Disconnected Mode
Ae
Entry address
AFS
Aeronautical Fixed Services
AFSG
European Aeronautical Fixed Services Group
AFTN
Aeronautical Fixed Telecommunication Network
AIS
Aeronautical Information Service
ANC
Air Navigation Commission
ASCII
American Standard Code for Information Interchange
ATC
Air Traffic Control
ATFM
Air Traffic Flow Management
ATN
Aeronautical Telecommunication Network
ATS
Air Traffic Service(s)
ATSO
Air Traffic Services Organization
Ax
Exit address
BCC
Block Check Character
BER
Bit Error Rate
bps
Bits per second
CCC
Co-operating CIDIN Centre
CCITT
Comit Consultatif International Tlgraphique et Tlphonique

International Telegraph and Telephone Consultative Committee
CCS
Appendix A
Calculus of Communicating Systems
Sixth Edition
Page 1 of 14
14/04/2011
CIDIN
Common ICAO Data Interchange Network
CMC
CIDIN Management Centre
CP
Conversation Protect
CPU
Central Processor Unit
CPSN
CR
Call Redirection
CRC
Cyclic Redundancy Check
CSN
Channel Sequence Number
DBE
Data Bank EUROCONTROL
DCE
Data Circuit-Terminating Equipment
DEP
Departure Message
DLE
Data Link Escape
DTE
Data Terminal Equipment
DIS
Draft International Standard
DISC
Disconnect
DLCF
Data Link Control Field
DM
Disconnected Mode
DNIC
Data Network Identification Code
EAN
European ATSO Network
EANPG
European Air Navigation Planning Group
ENQ
Enquiry
EOT
End of transmission
ETB
End of transmission block
ETX
End of text
EUR
European
Flag
FCP
Final CIDIN Packet
FCS
Frame Check Sequence
FEC
Forward Error Correction
Appendix A
Sixth Edition
Page 2 of 14
14/04/2011
FPL
Filed Flight plan
FFPL
Formatted Flight plan
FMP
Flow Management Position
FRMR
Frame Reject
FSM
Finite State Machines
HDLC
High Level Data Link Control Procedures
HG
Header Generation
HG
Hunt Group
HIC
Header Item Code
HR
Header Removal
ICAO
International Civil Aviation Organisation
IDB
Integrated Data Base
ISO
International Organisation for Standardisation
ISO/DP
ISO Draft Proposal
ISO/IS
ISO International Standard
ITA-2
International Telegraph Alphabet Number 2
IA-5
International Alphabet Number 5
ITU
International Telecommunication Union
IUT
Implementation Under Test
Length Indicator
LAP-B
Link Access Procedure, Balanced mode
LDF
Link Data Field
M-bit
More data bit
MCF
Message Code and Format
MCP
Main Connection Path
MIN
MP
Message Priority
MT
Message Type
NA
Network Acknowledgement
Appendix A
Sixth Edition
Page 3 of 14
14/04/2011
NACK
Negative Acknowledge
NAM
North American
NASC
National AIS Service Centre
NAT
North Atlantic
NOTAM
Notice to Airmen
OPMET
Operational Meteorological (information)
OSI
Open Systems Interconnection
PDN
Public Data Network
PDU
Protocol Data Unit
PICS
Protocol Implementation Conformance Statement
PLC
Packet Looping Counter
PNIC
Private Network Identification Code
PNTN
Private Network Terminal Number
PRL
Profile Requirements List
PSN
Packet Switched (data) Network
PTT
Postal Telephone and Telegraph Administration
PVC
Permanent Virtual Circuit
REV
Revision (message)
REJ
Reject
RNR
Receive Not Ready
RR
Receive Ready
SABM
Set Asynchronous Balanced Mode
SARPS
Standards and Recommended Practices (ICAO)
SITA
Socite Internationale de Tlcommunications Aronautiques
SNDCF
Subnetwork Dependent Convergence Function
SREJ
Selective Reject
SOH
Start of header
STX
Start of text
SUT
System Under Test
Appendix A
Sixth Edition
Page 4 of 14
14/04/2011
SVC
Switched Virtual Circuit
T20
X.25-timer
T22
X.25-timer
TAF
Aerodrome forecast
TEM
Time-out for Enquiry response
TMR
Time-out for Message Response (ACK).
TNMA
Time-out for reassembling of CIDIN packets to a message (Next

packet to the current arrival message)
TSG
Technical Sub-group
UTC
Universal Coordinated Time
VC
Virtual Circuit
VCG
Virtual Circuit Group
VP
Variable Length Parameter
V.nn
CCITT Recommendation belonging to the V Series
Window size
WMO
World Meteorological Organisation
X.nn
CCITT Recommendation belonging to the X series
Appendix A
Sixth Edition
Page 5 of 14
14/04/2011
A.2
DEFINITION OF TERMS
(as used in the EUR CIDIN Manual)
Note.- The indications in brackets (thus) give the source of the term or the context in which the term is used.
acknowledgement:
element of a procedure used for confirming to a message sender that a

message has reached its destination; term used at different protocol layers;
active testing:
the activity of investigating the properties of an implementation by means

of special purpose test equipment and procedures; not performed during
normal operations;
address mapping:
the finding of correspondences between an address in one address space

and address(es) in another; normally performed by means of tables of
correspondences;
address space:
a set of addresses which have some common features, e.g. same format,
reachable on the same network;
address stripping:
(ICAO/Annex 10) in connection with multiple addressing procedures, the

procedure for removing addresses from messages when the addresses are
not required for onward transmission by another centre;
addressing:
the association of identifiers to protocol entities for the purpose of directing

protocol data units to the entities;
Aeronautical Fixed Service:
(ICAO/Annex 10) voice and data telecommunications service operated by

ICAO States; users are at fixed locations;
Aeronautical Fixed
Telecommunication Network:
(ICAO/Annex 10) the world-wide network providing the data part of the
AFS
AFTN interface:
(CIDIN) a CIDIN application which uses the CIDIN transport service with
the corresponding mapping for the purpose of forwarding AFTN messages
within the AFTN;
alternate routing:
the procedure of forwarding data by a route which is different from the

normal one; normally due to the normal route being out of service or
overloaded;
application:
a specific group of users of the CIDIN network, that share the same global
task type and use compatible procedures and protocols; these users can be
persons or automated processes;
application entity:
a specific user within this application is identified with the words

"application entity"; the application entities are the units which are to be
addressed, and who are assigned the Axs/Aes (Ax and Ae are identical for
the same entity).
ASCII:
a 7-bit coded character set; includes alpha-numeric, control and graphic

characters;
audit trail:
the recording of a sequence of events which belong to one context, e.g. the
transmission of one message; used for the investigation of error situations;
bearer network:
network equipment which plays the server role in a client-server

relationship between network components or layers;
Appendix A
Sixth Edition
Page 6 of 14
14/04/2011
bit error rate:
average fraction of bits which are received in error; an acceptable rate might
be, e.g. 10-6
bit stuffing:
procedure for avoiding the presence of a delimiter (e.g. flag) while allowing
complete transparency of user data;
boundary:
(CIDIN) a virtual closed line enclosing a set of CIDIN centres;
bulk data transfer:
a type of application of communication services in which large volumes

(e.g. megabytes) of data are transferred;
bulletin:
a set of data with common characteristics, e.g. meteorological data for a

specified area at a given time;
centre:
(CIDIN) switching centre in the CIDIN network which handles the CIDIN
protocols;
CIDIN Management Centre
a centralised entity which stores the CIDIN network management database

and performs the centralised management functions;
Co-operating CIDIN Centre:
a COM Centre which participates in the centralised CIDIN network

management activities;
code and byte independence:
(ICAO) procedures allowing the transmission of any bit combinations in

complete octets of data;
code/format:
(CIDIN) indication of the way in which user data is structured and

expressed in bit combinations in a message; refers to a type of application;
common network:
a network providing service not only to one particular application or user;
Common ICAO Data

Interchange Network:
(CIDIN) data network within the AFS;
confirmation:
(ISO) a type of service primitive; information returned to a service user

concerning the execution of a service requested by the user;
conformance test:
(OSI) a test of a protocol implementation with respect to its specification;
conformance test procedure:
part of a conformance test; usually relates to a specific aspect of the

protocol and is performed according to a well-defined script;
connection oriented:
(ISO) a class of protocols/service providing a connection context;

necessitate connection establishment and disconnection phases;
connectionless:
(ISO) a class of protocols/service providing no connection context; data is

transmitted without a previous connection establishment phase;
conventional AFTN:
(ICAO/Annex 10) data part of the AFS without CIDIN; based on teletype
procedures;
conversational mode:
(CIDIN) type of communication between two users in which a sequence of

interactions together form a dialogue;
cutover:
transition of a system from testing to operations;
cyclic redundancy check:
a set of redundant data in a protocol data unit which allow the detection and
correction of a class of transmission errors;
Appendix A
Sixth Edition
Page 7 of 14
14/04/2011
data circuit terminating

equipment (DCE):
(CCITT) network equipment providing user access to the network;
data integrity:
measure of the quality of transmission;
data link frame:
protocol data unit in the link layer;
data link layer:
layer providing service to the network layer; concerned with the reliable
transfer of data across the data link;
data terminal equipment (DTE):
(CCITT) user system accessing a network;
deadlock:
situation in which each of two or more related parties waits for enabling
conditions to be signalled from the other party(ies); no useful work is
performed in this state;
dedicated circuit:
transmission resource used for one particular service or application or

between one pair of locations;
dedicated procedures:
procedures which are useful only to one particular type of application;
delimiter:
indication of the end of a field;
destination address:
(ICAO/Annex 10) AFTN addressee indicator when contained in a CIDIN

packet header;
digital facsimile:
presentation protocol for the transmission of images;
diversion:
an exceptional route for a message to a destination;
duplex:
allowing two way simultaneous traffic;
dynamic routing:
a routing strategy which varies with time depending on the current state of
the network;
encapsulate:
enclose a block of data between header and trailer without changing the
data;
end-to-end:
range of a function extends right up to the corresponding points at the users;
enquiry:
(CIDIN) the request to a remote CIDIN exit centre for information on its
status; the procedure is performed when an entry centre has reasons to
believe that the remote centre is out of order or cannot be reached;
entry address:
CIDIN address of an application entity submitting a message to CIDIN;
entry centre:
(CIDIN) CIDIN centre at which a given message is submitted for transport

by CIDIN;
error processing:
the treatment of non-normal situations with the aim of recovery;
evolutionary upgrade:
enhancement of the functionality of a system in small steps without placing

great change requirements on the systems environment;
exit address:
(CIDIN) unique identification of a CIDIN user for the purpose of delivering

messages;
Appendix A
Sixth Edition
Page 8 of 14
14/04/2011
exit address:
(CIDIN) CIDIN address of an application entity to which a message is

being sent;
exit centre:
(CIDIN) CIDIN centre at which a message leaves CIDIN;
facsimile data:
binary representation of images;
ferry:
(ISO) technique for conformance testing; a ferry channel provides the

means for co-ordinating local and remote implementations under test;
file transfer:
- see bulk data transfer
finite state machine:
technique for representing the behaviour of an automation; at any time it

exists in one of a finite number of States; State changes dependent on
external events are defined;
formal description technique:
method of defining a protocol using formal syntax and semantics; a goal is

the proof of correctness and consistency of the definition;
frame:
protocol data unit transferred across a data link;
functional requirement:
requirement placed on a system referring to qualitative features rather than

quantitative features such as capacity, throughput, etc.;
general coding principles:
common methods for coding information as binary values;
general format identifier:
method of indicating the type of contents in a set of data fields; applicable

to a wide range of field types;
glossary:
(CIDIN) explanation of terms and abbreviations from the CIDIN Manual;

may contain a reference to itself;
High Level Data Link Control

Procedures (HDLC):
(CCITT) a set of bit-oriented link layer procedures;
IA-5, International Alphabet

Number 5:
a 7 bit alpha-numeric character set coding system;
implementation under test:
(ISO) implementation of one or more protocols which are to be studied by

testing;
improved AFTN:
(ICAO) data part of the AFS based on CIDIN;
incomplete message:
(CIDIN) message at an exit centre of which parts are missing;
indication:
(ISO) type of service primitive; information provided to a user who did not
initiate the interaction;
information frame:
(CCITT) frame containing user information;
interoperability testing:
(CIDIN) testing phase in which two (bilateral) or four (quadrilateral)

CIDIN centres are tested together.
interactive:
a mode of working in which two or more systems or people co-operate

under strict time constraints;
inter-working:
the co-operation of systems (networks) to deliver a common service;
Appendix A
Sixth Edition
Page 9 of 14
14/04/2011
ITA-2, International Telegraph

Alphabet Number 2:
a 5 bit alpha-numeric character set coding system;
line monitor/analyser:
test equipment which records and analyses transmitted data;
Link Access Procedure,

Balanced Class (LAP-B):
(CCITT) a variant of HDLC; component of X.25;
logical channel:
(CCITT) possible connection-oriented relationship provided by X.25;
looping counter:
(CIDIN) a counter which contains the number of relay centres which a

CIDIN packet has traversed;
looping of messages:
(CIDIN) an error situation in which a message repeatedly travels the same

path through the network without coming closer to its destination; can be
caused by inconsistencies in routing tables;
main connection path
the preferred connection path between two CIDIN centres established over
a group of virtual circuits;
M-bit:
a bit in X.25 coding used in CIDIN for chaining segments of CIDIN

packets in public packet switching networks;
management centre:
(CIDIN) network management system with global knowledge of network

configuration and status;
medium speed:
transmission at speeds of the order of 2,400 bps;
meshed network:
interconnection of network nodes (switching enters) in such a way that

many alternative routes through the network are possible;
message:
(CIDIN) block of data which together represents a set of information;

handled as one whole by the network (as seen by the user);
message handling:
the transfer and processing of messages (documents)
message identification number:
(CIDIN) unique identification of a message generated by an entry centre;
modulo arithmetic:
arithmetic with a small finite number of digits;
multi layer testing:
the testing of more than one protocol layer implementation simultaneously:
multiple dissemination:
the transmission of a message to more than one destination; replication is

done in the network layer;
multiplexing:
a method to combine many different channels of information on to one

physical link;
natural language description:
specification by means of a spoken language such as English;
nesting:
containment of one object within another;
network access protocol:
protocol between a network users system and the network;
network acknowledgement:
(CIDIN) confirmation by the exit centre of successful message reception to

the entry centre
network carrier:
provider of network services (e.g. PTT)
Appendix A
Sixth Edition
Page 10 of 14
14/04/2011
network extension:
(CIDIN) testing phase in which new features or an extended configuration

are tested;
network management:
the task of organising, controlling and administering the resources in a

network;
octet:
an eight bit byte;
Open Systems Interconnection

(OSI):
(ISO) a distributed computer system interconnection architecture

standardised by the ISO;
operator:
(CIDIN) person operating a CIDIN centre performing system monitoring

and control;
OSI reference model:
(ISO) the basic model for the open system interconnection as defined by the
ISO;
packet:
(CIDIN) block of data which is handled as an integral unit;
packet header:
(CIDIN) protocol control information in a packet;
packet layer:
(CIDIN) provider of service to the transport layer;
packet looping indicator:
see looping counter;
packet switching:
a technique used in data communication for transmitting information in

blocks (packets) utilising store-and-forward technique;
peer-to-peer:
(ISO) a relationship between entities in the same layer of the OSI Reference
Model;
permanent virtual circuit:
(CCITT) an X.25 virtual circuit that is permanently set up. No connection

or disconnection phases are needed;
permanent virtual circuit

termination centre:
(CIDIN) a centre in which a user of a permanent virtual centre is located;
permanent virtual transit centre:
(CIDIN) a centre which provides a concatenation of a pair of virtual circuits

in a predefined manner;
physical layer:
(ISO) the lowest layer of the OSI Reference Model;
point-to-point:
a communication relationship between two (and only two) partners;
poll:
request for information or reply from a remote communication partner;
primary route:
a route which is selected for data flow from source to destination unless
circumstances indicate that this is undesirable;
primitive:
(ISO) a single interaction between service user and service provider in the
OSI Reference Model;
priority handling:
the processing, e.g. scheduling of events depending on their relative

importance;
priority indicator:
(ICAO/ANNEX10) indication of the relative importance of a data unit (or

message) with respect to other data units (or messages);
Appendix A
Sixth Edition
Page 11 of 14
14/04/2011
profile:
(ISO) a set of one or more standards and/or the identification of chosen

classes, subsets, options or parameters of those standards;
protocol:
a set of rules formulated to control the exchange of data between two

communicating parties;
protocol architecture:
relationships between protocols in a communication context;
protocol control information

(ISO):
that part in a protocol data unit which is used between entities to co-ordinate
their operation;
protocol data unit:
(ISO) a set of data exchanged between two protocol entities at a particular

layer;
protocol layer:
(ISO) a constituent part of the OSI Reference Model which defines a well
defined function in the communication context; (the OSI Reference Model
consists of 7 protocol layers)
protocol implementation
conformance statement
a statement denoting which capabilities have been implemented for a

protocol;
profile requirements list
profile requirements expressed in the form of conformance requirements

and arranged in a tabular list format;
public data network (PDN):
a network providing a transmission service which can be subscribed to;
PVC Validate
an operator action to enable the reception of CIDIN packets on a PVC;
PVC Invalidate
An operator action to prevent the reception of CIDIN packets on a PVC;
queue:
an ordered collection on objects waiting for service;
re-assembly:
the process of putting a set of parts, e.g. of a message, together in the

original sequence;
recording:
storing information on the sequence of events;
regional subnetwork:
part of a network located in one geographical area;
relay centre:
(CIDIN) CIDIN centre, at which passes the CIDIN packets are forwarded
from one centre to another centre;
request (ISO):
type of service primitive issued by the user of a service to invoke a specific

service;
reset:
a function which sets the correspondent entities to a predefined state (reinitialisation);
reset collision:
the simultaneous and uncoordinated issuing of reset requests of two or more

communication parties;
response:
(ISO) a type of service primitive issued by the user of the service to

acknowledge or complete some procedure previously invoked by an
indication to that user;
restart:
bringing a resource, e.g. a set of PVCs, into its original state to resume
operation;
Appendix A
Sixth Edition
Page 12 of 14
14/04/2011
routing:
procedures for passing messages or other data units through a network to

specified destination;
routing table:
a table of correspondences between message destinations and next centre;
routing exchange:
(CIDIN) network management procedure for exchanging information

related to routing;
segmenting:
the process of dividing a block of data (message) into a concatenated

sequence of smaller parts;
service access point (ISO):
conceptual point at which a service user accesses the service provider in a

layered communication system associated with an address;
service provider:
(OSI) concept of the Reference Model referring to the lower layer of a pair
of layers;
session:
a relationship between two users of communication services which

normally lasts for an extended time interval, e.g. minutes;
single layer testing:
the testing of protocol layers individually;
static routing:
routing procedures which are not dynamically dependent on the current

state of the network;
station:
(CIDIN) a centre providing only entry/exit functions;
statistics gathering:
the recording of statistical information;
store-and-forward:
a technique in which blocks of data are stored in a node before being passed
on to the next node;
sublayer:
(OSI) subdivision of a layer;
switched virtual circuit:
an X.25 virtual circuit which requires a connection and disconnection

phase;
system under test (SUT):
a system which is the object of testing;
systems management:
(ISO) functions in the application layer related to the management of

various OSI resources across all layers of the architecture;
test group:
(CIDIN) group of test procedures;
test partner:
(CIDIN) another installation involved in a test;
test phase:
(CIDIN) one of the five parts of testing a CIDIN implementation or part of

the network;
test procedure:
a set of activities to be performed when testing;
test responder:
user of a protocol layer under test; not the initiator of test procedures;
time out:
monitoring in time for no activity;
topology:
a set of spatial relationships; the physical and logical relationship of nodes

in a network (schematic arrangement of links and nodes);
Appendix A
Sixth Edition
Page 13 of 14
14/04/2011
trailer:
last part of a PDU;
transit time:
time taken to traverse a (sub-)network;
transparent:
not visible to and not affected by a process;
transport header:
(CIDIN) protocol control information in a transport protocol data unit;
transport layer:
(CIDIN) provider of the CIDIN service to the CIDIN users and

applications;
transport layer:
the lowest layer of the Reference Model with end-to-end significance;
transport service:
service provided by the transport layer;
trials:
(CIDIN) the testing of CIDIN protocols and centre implementations before

operations commence;
tributary:
a subordinate part of a network;
user:
the client in a client-server relationship;
user data:
data which are only understood and processed by the user;
virtual circuit:
(CCITT, X.25) logical relationship between two users of the X.25 service;
virtual circuit group
a number of VCs that connect two and only two CIDIN centres;
END of Appendix A
Appendix A
Sixth Edition
Page 14 of 14
14/04/2011
Appendix B CIDIN Conformance Proforma
B.1
Introduction
B.1.1
The CIDIN standard contains a large number of configurable options, for which there is no simplified
material to aid either future procurement of CIDIN equipment or the setting up of new CIDIN links.
B.1.2
Over/under specification of new equipment and complications in establishment of new links could be
avoided if the details of essential operational parameters and mandatory/optional functions were
clarified.
B.1.3
EUR AFS 1995 proposed the development of a guidance document that contained a summary of
essential detail from the CIDIN Manual and other relevant references.
B.1.4
It should be pointed out that in cases of interconnected networks, the values specified in Layers 1, 2
and 3a may not apply. In such cases, the relevant functional equivalents should be use
B.1.5
The CIDIN Conformance Proforma is a dynamic document, which should be regularly updated to
reflect relevant amendments to Annex 10 and the CIDIN Manual, as well as AFSG recommendations.
B.2
Document Structure
B.2.1
This document is structured in a manner corresponding to the CIDIN layered model, i.e. Physical,
Link, Network, CIDIN and Application Layers.
B.2.2
The Proforma syntax is as follows:
Item
Value/Configuration
Status
References
Where:
B.2.3
Item
= parameter to be defined/specified
Value
= value, specification or configuration of the item
Status
= shows Mandatory or Optional status
Reference
= shows references into ICAO and other documentation
The following symbols are used in the proforma:

(Item number)
B
M
NA
O
O(n)
(P)
R
R(n)
S
B.2.4
Conditional item symbol dependent upon the support marked for (item)
Dependant on bilateral agreement with connecting Centre
Mandatory
Not applicable
Optional
Optional, but at least one of reference (n) must be supported
Parameter
Recommended
Recommended where options supported by reference (n) are not supported
Superseded by later recommendation
It is recommended that the following information, as a minimum, be requested as part of any CIDIN
supply enquiry:
Appendix B
Supplier Details
Sixth Edition
Page 1 of 9
14/04/2011
Date of statement
Implementation name/version
Hardware name/version
Operating system name/version
Other Operating systems/version claimed compatible
Statement of compliance with relevant provisions of standard documents
B.2.5
Section 6 shows a breakdown of parameters that have "optional" or "non-defined" value. These must
be compatible between connecting CIDIN centres to achieve successful operation and they should
be agreed on initial link establishment.
B.3
References and Standards
B.3.1
ICAO Annex 10, Vol. II and III (up to and including Amendment 76)
B.3.2
ICAO EUR CIDIN Manual, Second Edition, Issue 1
B.3.3
CCITT/ITU-T Recommendations X, V, M
B.3.4
Recommendations of EUR AFS/AFSG Meetings
B.4
Conformance Proformae
B.4.1
Physical Layer Layer 1
Item
B.4.1.1Physical Interface
B.4.1.1.1
B.4.1.1.2
B.4.1.1.3
B.4.1.2 Signaling Rate
B.4.1.2.1
B.4.1.2.2
B.4.1.2.3
B.4.1.2.4
B.4.1.3 Modulation
B.4.1.3.1
B.4.1.3.2
B.4.1.3.3
B.4.1.3.4
B.4.1.4 Circuit Type
B.4.1.4.1
B.4.1.4.2
B.4.1.5 Character Set
B.4.1.6 User Notification
B.4.1.6.1
Appendix B
Value/Configuration
Status
V.24/V.28
X.21 bis
X.21
(P) bits per second
600, 1200
2400, 4800
9600
64 kbps or greater
(P)
V.23
V.26, V.27
V.29
V.32
O 4.1.1
O 4.1.1
O 4.1.1
M.1020
Digital
IA-5
R 4.1.4, B
O 4.1.4, B
M
Physical Errors
References
CM 2, CM 2.2.3
CM 2.1, A10 8.6.2

O 4.1.2, B
O 4.1.2, B
O 4.1.2, B
O 4.1.2, B
CM 2.1, A10 8.6.2.3
O 4.1.3, B
O 4.1.3, B
O 4.1.3, B
O 4.1.3, B, R for 4.1.2.3
CM 2.1.1
Sixth Edition
Page 2 of 9
CM 2.1.2
A10 8.6.1, A10 8.6.2.4
CM 2.2.2
14/04/2011
B.4.2
Link Layer Layer 2
Item
B.4.2.1 Link Procedure
B.4.2.2 Data Field Length

B.4.2.3 Repetition Counter
B.4.2.3.1 N2
B.4.2.3.2 N2
B.4.2.4 Window Size
K
B.4.2.5 Timer Values
B.4.2.5.1.1 T1
B.4.2.5.1.2 T1
B.4.2.6 Address
B.4.2.6.1 A/B
B.4.2.6.2 B/A
B.4.2.7 Statistics
B.4.2.8.1
B.4.3
Value/Configuration
HDLC LAP-B
Frame format, Transmission
Sequences, Modes of Operation,
Functions
and
Parameters,
Commands and Responses, Busy
Condition, Time Out Functions
N1 = 259 Octets Maximum
(P)
10
5
K = 1 to 7
7
(P) seconds
5
3
(P)
01/03
03/01
As listed in References
Link Failure and
Re-establishment
Status
M
References
CM 3.1, CM 3.2
A10 8.6.4
CM 3.2.2.3
CM 3.2.7.3
S
R
R
S
R
O
O 4.2.6, B
O 4.2.6, B
M
M
CM 3.2.5.1
CM 3.2.7.1
CM 3.2.7.2
CM 3.2.2.5
CM 8.5
CM 3.2.1.3
Network Layer Layer 3a (X.25 Packet Layer)
Item
B.4.3.1 Procedure
Status
M
R
References
CM 4, A10 8.6.5.3.2
CM 4.1.1
(P) 0 to FFF
(P)
M
R
B, R
R
CM 4.1.1, 4.2
CM 4.1.7, CM 4.2.4
CM 4.1.3.2
CM 5.3.1.1.4
By Bilateral Agreement
B, O
CM 4.2.1, CM 4.2.2,
CM 4.2.7,CM 5.3,CM ApF
B.4.3.2.1.6 SVC Range

SVC Identifier
Format
B.4.3.3 User Data Field
400 to 4FF
(P)
B,R, 4.3.2.1.3
R
256 Octets Maximum
B.4.3.4 Window Size

W
B.4.3.5 Timer Values
B.4.3.5.1.1 T20
B.4.3.5.1.2 T20
B.4.3.5.3.1 T22
(P) K = 2 to 7
7
(P) seconds
180
30
180
O, B
R
CM 4.1.1.4,
A10 8.6.5.1.3.4
CM 4.2.5, CM 4.1.6.5,
CM 4.1.1.4
S
R
S
CM 4.1.8.2
CM 4.2.9
CM 4.1.7.3
B.4.3.2 Virtual Circuits and

Procedures
B.4.3.2.1.1 PVC Implementation
B.4.3.2.1.2 PVC Reset Handling
B.4.3.2.1.3 PVC LCI
B.4.3.2.1.4 PVC Identifier
Format
B.4.3.2.1.5 SVC Implementation
Appendix B
Value/Configuration
X.25 1980
X.25 1984
Packet Format,
Logical Channels,
Reaction to Invalid Packets,
Initialization Procedures,
Data Transfer Procedures
By Bilateral Agreement
Sixth Edition
Page 3 of 9
CM 5.3.1.1.4
14/04/2011

Item
B.4.3.5.3.2 T22
B.4.3.6 Statistics
Value/Configuration
30
Status
R
M
B.4.3.7.1
B.4.3.7.2
B.4.3.7.3
B.4.3.7.4
Reset/Restart Initiation and

Termination
Format Errors
Message Queue per PVC
B.4.4
M
R
Network Layer Layer 3b (CIDIN Packet Layer)
Item
B.4.4.1 Procedure
B.4.4.2 Routing
B.4.4.3 CIDIN Packet Length

B.4.4.4 Message Priority
B.4.4.5 Ax Length
B.4.4.6 Number of Ax per
CIDIN Message
B.4.4.7 Number of Ad per
Destination Address Item
B.4.4.8 Number of Ad per Ax
B.4.4.9 Statistics
B.4.4.10.1
B.4.4.10.2
Appendix B
References
CM 4.2.9
CM 8.5, CM 8.6
CM 4.2.1.3, CM 4.2.6,
CM 4.1.7.5.6, CM 5.3.1
Value/Configuration
CIDIN Packet Protocol
Packet Format, Packet
Procedures, Packet
Transmission, Loss of
Communication Procedure,
VC Management
(P)
Routing, Relay,
Multiple Dissemination,
Alternative Routing
(P) 256 Octets Maximum
(P) 1 to 8
Status
M
M
M
CM 5.2.2.1
CM 5.1.2.4,
(P) 5 to 8 Octets
16 Maximum
M
M
CM5.1.2.7, CM5.2.2.5
CM 5.1.2.7
15 Maximum
CM 5.2.2.4
21 Maximum
M
M
CM 6.2.6.5
CM 8.4, CM 8.6
CM 5.2
Incorrect Format
Message Queue per Ax
M
R
Sixth Edition
Page 4 of 9
References
CM 5, A10 8.6.5.3.3
M
CM 5.1.3, CM 5.2.3
CM 5.2.4
14/04/2011
B.4.5
CIDIN Transport Layer Level 4

Value/Configuration
CIDIN Transport Protocol
Transport Header Format,
Transport Procedures,
MIN Assignment,
Message Handling,
Invalid Message Handling
Status
M
References
CM 6, A10 8.6.5.3.4
CM 6.1.2.1.4.1
CM 6.1.2.1.4.3,
B.4.5.3.2.1 Message Length

B.4.5.3.2.2 Message Length
B.4.5.4 Ae Length
B.4.5.5 Window Size
w
B.4.5.6 Timers
B.4.5.6.1 TMR
B.4.5.6.2 TNMA
B.4.5.6.3 TEM
B.4.5.7 Network Management
215 CIDIN Packets Maximum

64 Kb
(P) 5 to 8 Octets
(P) = 1 to 99
5
(P) seconds
40
35
40
S
R
M
O
R
O
R
R
R
CM 6.1.1.2, A10 8.6.5.4.2

CM 6.1.1.3
CM 6.1.2.1.4.5
CM 6.2.10
CM 6.2.10
CM 6.1.2.2.6
CM 6.2.10
CM 6.2.10
CM 6.2.10
CM Table 6.1
CM Table 6.2
B.4.5.7.1 NA
B.4.5.7.2 CP
B.4.5.7.3 MT
B.4.5.7.4 ENQ NMF
B.4.5.7.5 ENQ Response NMF
B.4.5.7.6 ACK NMF
B.4.5.7.7 MCF Error NMF
B.4.5.8 Network Management
Procedures
B.4.5.8.1
B.4.5.8.2
B.4.5.8.3
B.4.5.8.4
B.4.5.9 Handling of CIDIN
Message Repetition
B.4.5.9.1
B.4.5.9.2
0
0
1
2
4
3
8
M
M
M
M
M
M
M
M
Item
B.4.5.1 Procedure
B.4.5.2 MIN Length

B.4.5.3
B.4.5.3.1 CPSN Length
B.4.5.10 Statistics
B.4.5.11.1
B.4.5.11.2
B.4.5.11.3
B.4.5.11.4
B.4.5.11.5
Appendix B
ACK
ENQ
MCF Error
Flow Control
CM 6.2.6, CM 6.1.2.2.6
CM 6.2.6
CM 6.2.9
CM 6.1.2.2.8
CM 6.2.11
MIN Handling
TMR Configurable per Ax
Group
Ax Accessibility
Missing ACK
Incomplete Message
Incorrect Format
Timer Expiration
Sixth Edition
Page 5 of 9
R
R
CM 6.2.5.2, 6.2.5.2
C.M. 6.2.10
M
M
CM 8.3
CM 6.1.2.2.6.2.6,
CM 6.1.2.2.6.2.3, CM 6.2.2.1.3
CM 6.2.3.1.3
CM 6.2.3.1.4, CM 6.2.7.1
CM 6.2.7.1, CM 6.2.6
CM 6.2.9.1, 6.1.2.2.6
14/04/2011
B.4.6
Application Layer CIDIN Network Management Application
Item
B.4.6.1 Procedure
B.4.6.1.1
B.4.6.1.2
B.4.6.2 Parameters
B.4.6.2.1 NA
B.4.6.2.2 CP
B.4.6.2.3 MT
B.4.6.2.4 MCF
B.4.6.3 Ae/Ax Fifth Character
B.4.6.4.1 Operator
B.4.6.4.2 Routing
B.4.6.4.3 Statistics
B.4.6.5 Message Format
B.4.6.5.1
B.4.6.5.2
B.4.6.5.3
B.4.6.6 Statistics
B.4.7
Status
References
CM 1.2.2.3.9
M
O
CM Table 6.1
M
M
M
M
M
MP = 1 to 8/Codes 000 to 111

MP = 1/Code 000
MP = 7/Code 110
M
M
M
Operator Messages
Routing Messages
Statistics Messages
M
M
M
M
CM 1.2.2.4.5
CM 7.5
CM 7.7
CM 10.2
CM 11
CM 8.2
Application Layer AFTN Application
Item
B.4.7.1 Procedure
B.4.7.2 Parameters
B.4.7.2.1 NA
B.4.7.2.2 CP
B.4.7.2.3 MT
B.4.7.2.4 MCF
B.4.7.4.1 SS
B.4.7.4.2 DD
B.4.7.4.3 FF
B.4.7.4.4 GG
B.4.7.4.5 KK
B.4.7.6 Audit Trail
B.4.7.7 Statistics
B.4.7.8.1
Appendix B
Value/Configuration
Network Management and
Administration,
Operator Message Exchange,
Network Message
Management Exchange
(P)
1
0
0
1
M
Value/Configuration
Aeronautical Fixed
Telecommunication Network
(P)
1
0
0
2
A
Status
M
MP = 2/Code 001
MP = 4/Code 011
MP = 5/Code 100
MP = 6/Code 101
MP = 7/Code 110
A10, Vol. II, Ch. 4
Ae/MIN-TI/CSN Correlation
M
M
M
M
M
M
M
R
Errors
Sixth Edition
Page 6 of 9
References
CM 7, A10-Vol.II-Ch.4
CM Table 6.1
M
M
M
M
M
CM 1.2.2.4.4
CM 7.5
CM 7.3, A10-Vol.II-Ch.4
CM 7.7.1
CM 8.2
CM 7.7.2
14/04/2011
B.4.8
Application Layer OPMET Operator Message Application
Item
B.4.8.1 Procedure
B.4.8.2 Parameters
B.4.8.2.1 NA
B.4.8.2.2 CP
B.4.8.2.3 MT
B.4.8.2.4 MCF
B.4.8.3 Ae/Ax Fifth and Sixth
Character
B.4.8.6 Statistics
B.4.9
References
(P)
1
0
0
1
MM
R
M
M
R
R
CM Table 6.1
MP = 1 to 8
As Described in References
TBD
R
R
R
CM 1.2.2.5.2
WMO 386
Status
R
References
WMO 386
CM Table 6.1
CM 1.2.2.5.3
Value/Configuration
(P)
1
0
0
3
O
MP = 6/Code 101
TBD
M
M
M
R
M
R
M
R
CM 1.2.2.5.2
CM 1.2.2.5.3
WMO 386
Application Layer ATN Subnetwork Application
Item
B.4.10.1 Procedure
B.4.10.2 Parameters
B.4.10.2.1 NA
B.4.10.2.2 CP
B.4.10.2.3 MT
B.4.10.2.4 MCF
B.4.10.3 Ae/Ax Fifth
Character
B.4.10.6 Statistics
Appendix B
Status
R
Application Layer OPMET Application
Item
B.4.9.1 Procedure
B.4.9.2 Parameters
B.4.9.2.1 NA
B.4.9.2.2 CP
B.4.9.2.3 MT
B.4.9.2.4 MCF
B.4.9.6 Statistics
B.4.10
Value/Configuration
Value/Configuration
Status
R
(P)
0
0
0
4
TBD
M
M
M
R
R
MP = 2,5,7/Codes 001,100,110
TBD
R
M
R
Sixth Edition
Page 7 of 9
References
ICAO Doc 9705-AN/956
CM Table 6.1

14/04/2011
B.5
Abbreviations and Symbols
ACK
Ad
Ae
AFSG
AFTN
AN
Ap
Ax
A10
A10, Vol. II
Acknowledgement Message
CIDIN Destination Address
CIDIN Entry Address
Aeronautical Fixed Service Group
Aeronautical Fixed Telecommunication Network
Air Navigation
Appendix B to the CIDIN Manual
CIDIN Exit Address
Annex 10, Volume III, July 1995 up to and including Amendment 76
Annex 10, Volume II, July 1995 up to and including Amendment 76
bps
CID
CM
CP
CPSN
CSN
bits per second

Common ICAO Data Interchange Network
CIDIN Manual/ICAO EUR DOC 005
Conversation Protect Indicator
Channel Sequence Number
ENQ
HDLC LAP-B
IA
LCI
Enquiry Message
High Level Data Link Control - Link Access Protocol-B
International Alphabet
Logical Channel Identifier
M
MCF
MIN
MP
MT
ITU-T Recommendation M-Series

Message Code and Format Indicator
Message Priority Indicator
Message Type Indicator
NA
NMF
Network Acknowledgement Indicator

Network Management Field Indicator
PVC
R
SVC
Permanent Virtual Circuit

CCITT/ITU-T Recommendation R-Series
Switched Virtual Circuit
TEM
TI
TMR
TNMA
TBD
V
WMO
X
Appendix B
Time-out for Enquiry Response

Transmission Identification
Time-out for Expected Network Acknowledgment
Time-out for Re-assembling of CIDIN Packets to a Message
To be Determined
CCITT/ITU-T Recommendation V-Series
World Meteorological Organization
CCITT/ITU-T Recommendation X-Series
Sixth Edition
Page 8 of 9
14/04/2011
B.6
Configurable Parameters Proforma for New CIDIN Connections
Reference
P.4.1.2
P.4.1.3
P.4.1.4
Item
Signaling Rate
Modulation
Circuit Type
Value
B
B
M.1020/64k
L.4.2.2
Data Field Length N1
259 Octets Max.
L.4.2.3
L.4.2.4
L.4.2.5.1.2
L.4.2.6.1
L.4.2.6.2
Repetition Counter N2
Window Size K
Timer Value T1
Address A/B
Address B/A
5/10
7
3
01/03
03/01
N.4.3.2.1.3
N.4.3.2.1.6
N.4.3.3
N.4.3.4
N.4.3.5.1.2
N.4.3.5.3.2
PVC LCI or
or SVC Range
Packet Size
Window Size W
Timer T20
Timer T22
CP.4.4.3
CIDIN Packet Length
CT.4.5.5
CT.4.5.6.1
CT.4.5.6.2
CT.4.5.6.3
Window Size W
Timer TMR
Timer TNMA
Timer TEM
Actual Value
B
B
B
0 to FFF
400 to 4FF
256 Octets
7
30
30
Comment
Bilateral agreement
Varies by P.4.1.2
Bilateral agreement
May vary by higher level
requirements
R
R
Bilateral agreement
B
R
R
R
R
R
Bilateral agreement
Bilateral agreement
Bilateral agreement
Bilateral agreement
R
R
R
R
May be modified dynamically
256 Octets Max.

5
40
35
40
Where:
P
= Physical Layer Parameters
= Link Layer Parameters
= Network X.25 Layer (3a) Parameters
CP
= CIDIN Packet Layer (3b) Parameters
CT
= CIDIN Transport Layer (4) Parameters
Note.- The table shows only parameters that are not specified as of Mandatory value and are required for the
setting up of new CIDIN connections between centres.
END of Appendix B
Appendix B
Sixth Edition
Page 9 of 9
14/04/2011
Appendix C General Coding Principles
C.1
Coding Principles
C.1.1
General
C.1.1.1
The formats in which the protocol control information (headers, trailers) is coded for the level 2 and
3a protocols are taken from the international standard X.25 and are not specific to CIDIN. The
CIDIN protocols for levels 3b and 4, on the other hand, are designed specifically for CIDIN. In
order to establish common principles for the coding of these layers, to simplify implementations and
to provide rules for the extension of headers if necessary at some later date, general coding
principles have been drawn up by the ADIS Panel.
C.2
Formats
C.2.1
Header Items
C.2.1.1
A self-contained unit within a header is called a "header item" or "item" for short. Two types of
formats are used for header items: a fixed length item (one octet) and a variable length item. The
fixed length item consists of a header item code (HIC) and a fixed length parameter (P). The
variable length item consists of a HIC, a parameter of variable length parameter (VP) and a length
indicator (L) which gives the length of VP in octets or as the number of its sub-parameters.
C.2.2
Header Item Code
C.2.2.1
The HIC is an identifier which uniquely specifies a particular item. It is coded as a binary number
which occupies bits 5 to 8 of the first octet of the item. (The bits of an octet are numbered 1 to 8, bit
1 being transmitted first).
C.2.2.2
In the HIC of a fixed length item, bits 7 and 8 are set to 0 and 1 respectively. The HIC can therefore
identify 4 distinct fixed length header items. In the HIC of a variable length item, bit 8 is set to 0.
The HIC can therefore identify 8 distinct variable length header items.
C.2.2.3
Parameters
C.2.2.3.1
The fixed length parameter (P) in the fixed length item occupies bits 1 to 4 of the first (and only)
octet of this item and is represented as a binary number.
C.2.2.3.2
The variable length parameter (VP) in the variable length item may be represented as a binary
number or as a string of IA5 characters, one character per octet. It occupies the second and
subsequent octets of the item. The length indicator (L) is the number of octets in VP. It is
represented as a binary number and occupies bits 1 to 4 of the first octet.
C.2.2.3.3
Since the type and length of header items are self defining, they can be skipped by the software
processing them without having to be processed in detail.
C.2.2.3.4
The two types of header items are illustrated below.
Appendix C
Sixth Edition
Page 1 of 3
14/04/2011

C.2.2.3.4.1 Fixed length item
<----------HIC---------->
1
0
X
X
<------P------>
P
P
8
Last bit
transmitted
1
First bit
transmitted
C.2.2.3.4.2 Variable Length Items

<------HIC------>
O
X
X
X
p
p
p
p
<---------L----------->
y
y
y
y
p
p
p
p
=
p
p
=
p
p
p
p
p
p
p
p
p
p
8
Last bit
transmitted
p
p
Parameter VP
p
p
1
First bit
transmitted
C.2.3
Allocation of Header Item Codes
C.2.3.1
Some of the possible codes have already been allocated to the headers of the level 3b and 4 protocol
data units.
C.2.3.1.1
Fixed Length Items

HIC
1000
CP/T
T*
1001
1010
1011
Header Item
End of header
(P is set to 0000)
not allocated
not allocated
not allocated
CP/T = Item belongs to CIDIN packet or transport header

* = The end of header item terminates the CIDIN transport header.
C.2.3.1.2
Variable Length Items

HIC
0000
0001
0010
0011
0100
0101
0110
CP/T
T
CP +
CP #+
CP
T
CP
T
Header Item, length of VP

entry address (Ae), L octets, 1<L<9.
exit address (Ax), L octets, 1<L<9.
destination address (Ad), 8L octets, 0<L<16
packet looping counter and priority, 1 octet
message identification number (MIN), L octets, 0<L<16
packet sequence number/final packet, L octets, 0<L<3
message characteristics, 1 octet
CP/T = Item belongs to CIDIN packet or transport header
Appendix C
Sixth Edition
Page 2 of 3
14/04/2011
#=
This item is only valid in the first CIDIN packet of message.
+=
These items can be present as pairs more than once in a CIDIN packet header.
END of Appendix C
Appendix C
Sixth Edition
Page 3 of 3
14/04/2011

Date of issue : 2003
Appendix D CIDIN TESTING PROCEDURES
CIDIN TESTING PROCEDURES
Appendix D
Sixth Edition
Page 1 of 1
14/04/2011

CIDIN Conformance Testing
D.1
Appendix D
Date of issue:
2003
CONFORMANCE TESTS (SINGLE LAYER)
Sixth Edition
Page 1 of 101
14/04/2011
D.1.1
CONFORMANCE TESTING PROCEDURES
D.1.2
Purpose of conformance tests
The purpose of conformance testing is to demonstrate conformity of an implementation to the CIDIN protocol SARPs,
to diagnose and localize errors in individual protocol layers and, generally, to increase confidence in a new CIDIN
centre, by using a layer-for layer testing approach.
In the frame of such single layer conformance testing, each individual layer of the CIDIN protocol suite is considered as
an IUT and test sequences are designed to test the behaviour of only this one layer.
However, as the data link and network layer of CIDIN are based on well proven industrial standards (HDLC
LAPB/X.25), testing of these lower layers is not considered necessary. A certificate of conformance to X.25 provided
by the manufacturer involved should suffice.
The testing configurations proposed involve the system under test, CIDIN testing equipment or another CIDIN centre
and local connections. Depending on the type of connection used (PVC, SVC), CIDIN network layer test sequences are
distinguished in three categories:
Tests that apply to both types of VCs (VC)

Tests that apply to both types of VCs with minor adjustments (PVC/SVC)
Tests specific to PVCs
Tests specific to SVCs
For the CIDIN transport and application layer test sequences, the connection between the two centres is considered to
be one sole VC without distinction (PVC or SVC).
In case of SVCs, the SUT shall use an already established SVC to send user data and CIDIN ENQ, ENQr, ACK or
MCF Error messages. If no SVC has been established, the SUT shall send an X.25 call request.
D.1.3
Testing prerequisites
Prior to the actual testing phase, the appropriate general and specific parameters per layer must be set.
Appendix D
Sixth Edition
Page 2 of 101
14/04/2011

D.1.4
Appendix D
Date of issue: 2003
CONFORMANCE TESTS (SINGLE LAYER) Layer 3b
Sixth Edition
Page 3 of 101
14/04/2011
CIDIN Conformance Tests

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue: 2003
3b
A
Page: 1/2
System Under Test (SUT)

Parameter settings
Underlying layer
Installation state
CIDIN Centre, entry/exit centre, layer 3b
Exit Addresses Axs

(routing tables drawn up according to the needs of the procedures)
layer 3a
PVCs in flow control ready state

SVCs: In this configuration SVCs may also be used (where possible this is
indicated per test case) At any moment in time only one SVC shall exist
between two exit centres.
Parameter settings
Timers
window size = 7
T20 (reply to RESTART): 60 sec

T22 (reply to RESET): 60 sec
Maximum number of repetitions after timeout: 10

Test Parameters
N.A.
:
SUT
System Under Test
CIDIN Testing Equipment or anther CIDIN Centre
Number of connections in underlying layer :

Connections
a: VCa
b: VCb
(SUT) - (Y), VC
(SUT) (Y), VC
The configuration should be varied with links a and b on the same and/or different physical circuits.
When using SVCs: At any moment in time only one SVC shall exist between two exit centres.
SUT
Layer 4
Layer 3b
Test
Sequences
Layer 3a
Layer 3a
Layer 2
a: VCa
Layer 2
b: VCb
Appendix D
Sixth Edition
Page 4 of 101
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue: 2003
3b
B
Page: 2/2
System Under Tests (SUT)
CIDIN Centre, replay centre, layer 3b
Parameter settings
Exit Addresses Axs (routing tables drawn up according to the needs of the
procedures).
Underlying layer
layer 3a
all PVCs in flow control ready state
Installation state
SVCs: In this configuration SVCs may also be used (where possible this is
indicated per test case). At any moment in time only one SVC shall exist
between two exit centres.
Parameter settings
Timers
window size = 7
T20 (reply to RESTART): 60 sec

T22 (reply to RESET): 60 sec
Maximum number of repetitions after timeout: 10
N.A.
Test Parameters
SUT
System Under Test

Connections
a: VCa
b: VCb
c: VCc
(SUT) - (Y), VC
(SUT) (Y), VC
(SUT) (Y), VC
Tests should be performed using various different correspondences of PVCs to circuits. More than one link is necessary.
For example a possible correspondence is VCa in link 1 and VCb and VCc in link 2.
SUT
Layer 4
Layer 3b
Test
Sequences
Layer 3a
Layer 3a
Layer 2
a: VCa
Layer 2
b: VCb
c: VCc
Appendix D
Sixth Edition
Page 5 of 101
14/04/2011

Overview
Layer :
Test Group
:

Single Layer Tests
Date of issue: 2003
3b
1
Page: 1/1
Purpose :
Test entry centre functions for normal and error cases
List of procedures:
1.1
Entry centre functions (normal cases)
1.2
Entry centre functions (error cases)
1.3
Flow control on outgoing PVCs and independence of PVCs
Configuration used:
3b.A
To be preceded by test groups:
Coding:
CID 1 to CID 7:
layer 4 messages (AFTN and non-AFTN) with various sets and different
addresses (see procedure descriptions)
MP:
message priority 8
INV 1 to INV 6:
as CIDi but with various invalid features (see procedure descriptions)
M 1 to M2:
as CIDi but different message lengths (see procedure descriptions)
Installation:
The SUT is configured to initialise VCs (a) and (b) as appropriate.
The driving layer 4 has a batch of messages to send.
Special considerations:
The contents of the messages should be varied so that the CIDIN packets can be identifiable.
The non-AFTN messages could originate in the service message application.
Appendix D
Sixth Edition
Page 6 of 101
14/04/2011

Procedures
Layer :
Test Group
:
Procedure
:

Single Layer Tests
3b
1
1 (PVC/SVC)
Date of issue: 2003
Purpose: Entry centre functions (normal cases)
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
Results - Additional
Comments during test
period
Prepare test messages CID 1 CID 5

Centre SUT (System Under Test) is initialised and
acting as a CIDIN entry centre
1
SUT
wait
SUT
a: VCa
send
CID 1
- 1 CIDIN packet, free text

- Addresses to 1 exit centre via VCa
SUT
a: VCa
b: VCb
send
CID 2

- Addressed to several exit centres via VCs a & b
SUT
a: VCa
send
CID 3
- 1 CIDIN pocket, in AFTN format, addressed to

10 Ad's related to 1 Ax.
SUT
a: VCa
send
CID 4
- 2 CIDIN packets, in AFTN format, addresses to

10 Ad's related to 1 Ax
SUT
a: VCa
send
CID 5
- 1 CIDIN packets, in AFTN format addressed to

20 Ad's related to 1 Ax
a: VCa
wait
b: VCb
waits for operator indications

- layer 3b initialised
- VCs a & b initialised
[In case an SVC connection is used the SUT
issues an X.25 call request and Y accepts the
Call] At any moment in time only one SVC shall
exist between SUT and Y.
- Y is in the RECEIVE READY state
CID 1 to 5 Wait for CID 1 to 5 and check on correct reception

in particular check:
- CID 1 correctly coded (e.g. looping counter is set
to 31)
- CID 2 message duplicated on b
- in CID 3 addresses correctly coded
- in CID 4 addresses Ads only present within first
packet
- in CID 5 , correct coding of addresses
END OF PROCEDURE
Appendix D
Sixth Edition
Page 7 of 101
14/04/2011

Procedures
Layer :
Test Group
:
Procedure
:
Step
No.
Alt.
Step
No.
Centre

Single Layer Tests
3b
1
2 (PVC/SVC)
Connection
Action
Date of issue: 2003
Purpose: Entry centre functions (error cases)

Page: 1/1
Event
Parameters/Comments
period
Prepare test messages CID 1 CID 5

Centre X (System Under Test) is initialised and
acting as a CIDIN entry centre
1
SUT
wait
SUT
a: VCa
send
CID 1

- Addressed to 1 exit centre (Y) via VCa
SUT
a: VCa
send
INV 1

(exit address unknown in SUT)
SUT
a: VCa
send
INV 2
- 1 CIDIN pocket, free text

(maximum allowed length exceeded)
SUT
a: VCa
send
INV 3

(exit address is address of SUT)
SUT
a: VCa
send
INV 4a
as INV 1 except invalid HIC (i.e. not 0011)
SUT
a: VCa
send
INV 4b
as INV 1 except exit address item code non-valid

(i.e. not 0001)
SUT
a: VCa
send
INV 4
- 1 CIDIN packet, in AFTN format address to

several Axs
(With transport header not fit in one CIDIN packet)
INV 5
Message in AFTN format with more than 16 exit

addresses
b : VCb
9
SUT
a: VCa
b: VCb
send
10
a: VCa
wait
b: VCb
wait for operator indications

- layer 3b initialised
- VCs a & b initialised
[In case an SVC connection is used the SUT
issues an X.25 call request and Y accepts the
Call] At any moment in time only one SVC shall
exist between SUT and Y.
- Y is in the RECEIVE READY state
INV 1 TO Receive valid messages derived from CID 1

INV 5
& INV 1 to 5
& CID 1
Check for valid formats, in particular CHECK:
- INV 1 leads to no transmission
- INV 2 is truncated or not sent
- INV 3 is not sent
- for INV 4 and INV 5, more than one
messages generated
END OF PROCEDURE
Appendix D
Sixth Edition
Page 8 of 101
14/04/2011

Procedures
Layer :
Test Group
:
Procedure
:

Single Layer Tests
3b
1
3 (PVC)
Purpose:
Date of issue: 2003
Flow control of outgoing PVC and

independence of PVCs
Page: 1/1
Step
No.
Alt. Centre Connection

Step
No.
Action
Event
Parameters/Comments
period
Prepare test messages CID 6 and CID 7

Centre SUT (System Under Test) is initialised
1
SUT
a: VCa
send
CID 6
Non AFTN message consisting of 64 CIDIN packets
SUT
b: VCb
send
CID 7
Message consisting of 1 CIDIN packet send on PVC

distinct from that of CID 6
CHECK:
- CID 6 and CID 7 can be sent simultaneously
(i.e. PVCs are independent)
a: VCa
wait
CID 6/1
b: VCb
wait
CID 7
a: VCa
wait
CID 6/2
Second CIDIN packet of CID 6

(Y now reduces rate of reception of CIDIN packets (e.g.
< one per sec.)
a: VCa
wait
CID 6/20
Twentieth CIDIN packet of CID 6
SUT
b: VCb
send
CID 7
b : VCb
wait
CID 7
a: VCa
wait
CID 6/64
First CIDIN packet of CID 6
Reception of remaining CIDIN packets
END OF PROCEDURE
Appendix D
Sixth Edition
Page 9 of 101
14/04/2011

Overview
Layer
Test Group
:
:

Single Layer Tests
Date of issue: 2003
3b
2
Page: 1/1
Purpose: Test relay functions

List of procedures:
2.1
Relay functions in a relay centre
2.2
Alternate routing in case of link failure
2.3
Priority handling and looping prevention
Configuration used:
3b.B
To be preceded by test groups:
Coding:
PDU 1 to PDU 6 :
CID 8
PDU11, PDU 12 :
PDU 7 :
CIDIN packets with different routing requirements

a long message consisting of 64 CIDIN packets
CIDIN packets with priorities 4 and 5 respectively
CIDIN packet with PLC set to 31
Installation:
The SUT is configured to initialise VCs a, b and c as PVCs or as SVCs.
(Initialisation by the test partner (Y) should also be demonstrated).
Appendix D
Sixth Edition
Page 10 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
Step
No.
:
:
:

Single Layer Tests
3b
2
1 (PVC)
Alt. Centre Connection

Step
No.
Purpose:
Date of issue: 2003
Relay functions in a relay centre

Page: 1/1
Action
Event
Parameters/Comments
a: VCa
send
PDU 1
First CIDIN packet of a message to be routed

from SUT to Y via b
a: VCc
send
PDU 2
Second CIDIN packet of a message to be routed

from SUT to Y via b
a: VCa
send
PDU 3
First CIDIN packet of a message to be routed from

SUT to Y via a
b: VCb
send
PDU 4
Second CIDIN packet of a message to be routed

from SUT to Y via a
b: VCb
wait
PDU 1
b: VCb
wait
PDU 2
a: VCc
wait
PDU 3
a: VCc
wait
PDU 4
a: VCa
send
PDU 5
CIDIN packet 5 which SUT would normally route

via a
CHECK: PDU is not relayed via a
10
a: VCa
send
PDU 6
CIDIN packet which should be routed from SUT to Y

via b
CHECK: If a and b on the same circuit, the packet is
returned to Y
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 11 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
Step
No.
:
:
:
Alt. Centre
Step
No.

Single Layer Tests
3b
2
2 (PVC)
Purpose:
Date of issue: 2003
Alternate routing in case of link failure

Page: 1/1
Connection
Action
Event
CID 8
Parameters/Comments
a: VCa
send
b: VCb
wait
CID 8/20 Receive the first 20 packets

Reduce rate of reception in Y on VCb
Execute RESET or RESTART on VCb
b: VCb
wait
CID 8/64 Receive remaining packets of CID 8

CHECK: at most 7 packets have been lost
because of the disturbance
a: VCa
send
c: VCb
wait

Cause a link failure on the line carrying VCb
c: VCc
wait
CID 8/64 Receive remaining packets of CID 8 on c

CHECK: At most 7 packets have been lost
because of the disturbance
a: VCa
send
b: VCb
wait
b: VCb
c: VCc
wait
Comments during test period
Non-AFTN message consisting of 64 packets

to be routed via b (primary) or a (alternate)
CID 8
CID 8
Cause a link failure on the line carrying VCc
Cause a link failure on the line carrying VCb
Remove the failures on both links
Wait for SUT to initialise VCs b and c
CHECK: the message P is not retransmitted
and has been discarded
END OF PROCEDURE
Appendix D
Sixth Edition
Page 12 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
Step
No.
Alt.
Step
No.
:
:
:
Centre

Single Layer Tests
3b
2
3 (PVC/SVC)
Connection
Action
Purpose:
Date of issue: 2003
Priority handling and looping prevention

Page: 1/1
Event
Parameters/Comments
Cause blockage on line carrying b
At any moment in time only one SVC

shall exist between SUT and Y
1
a: VCa
send
PDU 8 CIDIN packet with priority 4 to be routed in SUT

via b
a: VCa
send
PDU 9 CIDIN packet with priority 5 to be routed in SUT

via b
Repeat steps 1 and 2 several times
b: VCb
wait
PDU 8
b: VCb
wait
PDU 9 CHECK: in analysing the sequence in which PDU 8

and PDU 9 have been received, show that, in
general, PDU 8 overtakes PDU 9 and that the
received sequence within the one priority group is
the same as the sending sequence
a: VCb
send
In the following steps SUT and Y simulate a loop.

PDU 7 CIDIN packet with looping counter set to 31
b: VCb
wait
PDU 7 CHECK: Looping counter decremented
a: VCb
send
PDU 7 Looping counter not manipulated

CHECK: This looping sequence is terminated by a
looping counter of 1
END OF PROCEDURE
Appendix D
Sixth Edition
Page 13 of 101
14/04/2011

Overview

Single Layer Tests
Date of issue:
Layer
Test Group
:
:
3b
3
Purpose
Test multiple dissemination and address stripping in relay centre
List of procedures
2003
Page: 1/1
:
3.1
Multiple dissemination and address stripping (normal cases) (PVC)
3.2
Multiple dissemination and address stripping (error cases)
Configuration used
3b.B
(PVC)
Coding:
PDU 10 to PDU18:
PDU 17(b), PDU 17(c), etc:
Installation
single CIDIN packets with various sets of different addresses

(see procedure descriptions)
packets derived from PDU 17 and modified according to stripping rules
:
The SUT is configured to initialise VCs a, b and c as PVCs.
(Initialisation by the test partner (Y) should also be demonstrated)
Special attention should be directed to the coding of the address stripped packets
Appendix D
Sixth Edition
Page 14 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
3b
3
1 (PVC)
Purpose:
Step
No.
Alt.
Step
No.
Centre
Connection
Action
10
a: VCa
send
Event
Date of issue: 2003
Multiple dissemination and address

stripping (normal cases)
Page: 1/1
Parameters/Comments
period
PDU 10 First CIDIN packet of non-AFTN message with

Axs:
Ax1 to be routed via b
a: VCa
send
PDU 11 As for PDU 10 but AFTN format

(5 Ads for Ax1 and 3 Ads for Ax2)
a: VCa
send
PDU 12 As for PDU 10 but not first packet
a: VCa
send
PDU 13 As for PDU 10 but

Ax2 to be routed via c
a: VCa
send
PDU 14 As for PDU 13 but AFTN format as PDU 11
a: VCa
send
PDU 15 First CIDIN packet in message with AFTN format

with Axs:
Ax1 to be routed via b (5 Ads)
Ax2 to be routed via c (3 Ads)
Ax3 to be routed via b (5Ads)
a: VCa
send
PDU 16 As for PDU 13 but not first packet
a: VCa
send
PDU 17 Not first packet in message with Axs:

Ax1 to Ax8 to be routed via b
Ax9 to Ax11 to be routed via a
Ax13 to Ax15 to be routed via b
a: VCa
send
PDU 18 First CIDIN packet in message with AFTN format

with Axs:
Ax1 to be routed via b (5Ads)
Ax2 is the exit address of SUT (1 Ads)
Ax3 to be routed via c (no Ads)
10
a: VCa
b :VCb
c: VCc
wait
PDU 10 Receive the packets derived from steps 1 to 9

to
PDU 18
CHECK: Coding and address stripping is correct. In
particular:
No packets received on VCa
PDU 10, PDU 11 and PDU 12 received as sent
PDU 13 to PDU 17 correctly routed and stripped
PDU 18 not routed further to Ax2
END OF PROCEDURE
Appendix D
Sixth Edition
Page 15 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
3b
3
2 (PVC)
Purpose:
Date of issue: 2003
Multiple dissemination and address

stripping (error cases)
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
a: VCa
send
PDU 17
b: VCb
wait
PDU 17(b) Packets derived from PDU 17

(Ax1 to Ax8 and Ax13 to Ax15)
c: VCc
wait
PDU 17 (c) Packet derived from PDU 17 (Ax12)

(the packet to be routed via c could also,
depending on routing tables in SUT, be
transmitted via b and c)
Non-first packet in message with Axs:

Ax1-Ax8 to be routed via b
Ax9-Ax11 to be routed via a
Ax13-Ax15 to be routed via b
Cause of failure of the link carrying VCc

4
a: VCa
send
b: VCb
wait
PDU 17
Repeat step 1
PDU 17 (bb) Packet equivalent to PDU 17 (b) supplemented

by those Axs for which b is the secondary route.
Re-establish the failed link
a: VCa
send
PDU 17
b: VCb
wait
PDU 17 (b) As in step 2
c: VCc
wait
PDU 17 (c) As in step 3

Cause the failure of the link carrying VCc
a: VCb
send
10
c: VCc
wait
PDU 17
As in step 1
Repeat step 1
PDU 17 (cc) Packet equivalent to PDU 13 (b) supplemented

by those Axs for which b is the secondary route
Re-establish the failed link
11
a: VCa
send
PDU 17
As in step 1
12
b: VCb
wait
PDU 17 (b) As in step 2
13
c: VCc
wait
PDU 17 (c) As in step 3

END OF PROCEDURE
Appendix D
Sixth Edition
Page 16 of 101
14/04/2011

Overview

Single Layer Tests
Layer
Test Group
:
:
3b
4
Purpose
Test reaction to errors and transmission failure
List of procedures
Date of issue: 2003
Page: 1/1
:
4.1
Processing of erroneous packets received
4.2
Discarding of packets when loss of communications occurs
4.3
Operator initiated resets
4.4
Network initiated resets
4.5
Switching between PVC (primary VC) and SVC (secondary VC)
Configuration used
3b. B
To be proceeded by test groups
3b.3.1
Coding :
PDU 7
INV 7 to INV 17 :
valid first CIDIN packet of message in AFTN format

invalid variations of PDU 7
Sequence of CIDIN packets contained in procedure 3b.3.1

Installation
:
The relay centre (SUT) is configured to initialise all VCs as PVCs in flow control ready state
SVCs can be used in some procedures, others are dedicated to PVCs
SVC necessary in test procedure 3b.4.5
At any moment in time only one SVC shall exist between two exit centres
No congestion
:
In the test equipment (Y) the rate of receiving CIDIN packets must be adjustable
Facilities are required for causing link failures
Appendix D
Sixth Edition
Page 17 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
Step
No.
Alt.
Step
No.
:
:
:
Centre

Single Layer Tests
3b
4
1 (PVC/SVC)
Connection
Action
Date of issue: 2003
Purpose: Processing of erroneous packets received

Page: 1/1
Event
Parameters/Comments
Results Additional
At any moment in time only one SVC shall exist

between SUT and Y
1
a : VCa
send
PDU 7
b : VCb
wait
PDU 7
a: VCa
send
INV 7
As PDU 17 but invalid header item code 1011
a : VCa
send
INV 8
As PDU 17 but number of characters in an

Ax >8
a : VCa
send
INV 9
As PDU 17 but Axs are unknown in SUT
a : VCa
send
INV 10 As PDU 17 but an Ax consists of zero characters
a : VCa
send
INV 11 As PDU 17 but CP3N (transport header) non-zero
a: VCa
send
INV 12 As PDU 17 but exit and address items repeated

with the last item not completely contained in
the packet
a: VCa
send
INV 13 As PDU 17 but address item Ax2 repeated (without

Ads) an additional 15 times
10
a : VCa
send
INV 14 As PDU 17 but no message priority item present
11
a : VCa
send
INV 15 As PDU 17 but no Ax item present
12
a : VCa
send
INV 16 As PDU 17 but packet header not terminated

by MIN item (transport header)
13
a : VCa
send
INV 17 As PDU 17 but CP3N indicates second

CIDIN packet and Ads are present
14
b : VCb
c: VCc
wait
Valid first packet of message in AFTN format

with addresses:
CHECK: No CIDIN packet should be received

from SUT. Operator messages and error
logs can be generated in centre SUT
END OF PROCEDURE
Appendix D
Sixth Edition
Page 18 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
Step
No.
Alt.
Step
No.
:
:
:
Centre

Single Layer Tests
3b
4
2 (PVC/SVC)
Connection
Action
Purpose:
Date of issue: 2003
Discarding of packets when loss

of communication occurs
Page: 1/1
Event
Parameters/Comments
Results Additional
At any moment in time only one SVC

shall exist between SUT and Y
Cause failure of links carrying VCs b and c
1
2
3
4
5
6
7
8
9
)
) Carry out steps 1 to 9 of procedure 3b.3.1
)
) Repeat until the congestion situation in SUT
) causes transmission to be halted by means
) of flow control in layer 3a
)
)
)
Reinitialise the links carrying VCs b and c
10
11
12
13
14
15
16
17
18
19
)
)
) Repeat the same 9 steps
)
)
)
)
)
)
-
b : VCb
c : VCc
wait
PDU 8 to Receive the routed packets from steps 10 to 18 as in

PDU 16 procedure 3b.3.1
CHECK: The failure and recovery of the links
has not affected the packets received in step 19
END OF PROCEDURE
Appendix D
Sixth Edition
Page 19 of 101
14/04/2011

Procedures
Single Layer Tests
Layer
Test Group
Procedure
Purpose:
:
:
:
3b
4
3 (PVC)
Date of issue: 2003
Operator initiated resets

-Reaction to resets with diagnostic code A1/A2
-Generation of resets with diagnostic code A1/A2
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection Action
Event
Parameters/Comments
Results Additional
PDU 7: Valid first and last packet of message in

AFTN format with Ax1 to be routed via:
VCa (primary PVC) / VCb (secondary PVC)
1
SUT
a: VCa
send
PDU 7
PDU 7 via primary VC
a :VCa
wait
PDU 7
Reception of PDU 7
a :VCa
send
SUT
b: VCb
send
PDU 7
PDU 7 via secondary VC

SUT demonstrates switching to secondary VC
because the CIDIN packet layer was notified that
the primary logical channel is not usable
b :VCb
wait
PDU 7
Reception of PDU 7
a :VCa
send
SUT
a: VCa
send
PDU 7

SUT demonstrates switching back to primary VC
the logical channel is usable
a :VCa
wait
PDU 7
Reception of PDU 7
SUT
a: VCa
send
10
SUT
b: VCb
send
X.25 reset
request
00/A2
PDU 7
11
SUT
a: VCa
send
12
SUT
a: VCa
send
X.25 reset Operator (on Y) initiates X.25 reset with cause

request code 00, diagnostic code A2 (DTE not operational)
00/A2
X.25 reset Operator (on Y) initiates X.25 reset with cause

request code 00, diagnostic code A1 (DTE operational)
00/A1
PVC invalidated by operator

SUT sends X.25 reset with cause code 00,
diagnostic code A2 (DTE not operational)
SUT demonstrates that it does not use the logical
channel which was set to not usable by the operator
X.25 reset PVC validated by operator

request SUT sends X.25 reset with cause code 00,
00/A1
diagnostic code A1 (DTE operational)
PDU 7

SUT to demonstrate that it does use the logical
channel which has was set to usable by operator
END OF PROCEDURE
Appendix D
Sixth Edition
Page 20 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
3b
4
4 (PVC)
Purpose:
Date of issue: 2003
Network initiated resets

-Cause: Out of order, network out of order
-Remote DTE operational, network operational
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
Results Additional

VCa (primary PVC) / VCb (secondary PVC)
Note: in order to execute this test Y has to be
configured as DCE (logical level)
1
SUT
a: VCa
send
PDU 7
a: VCa
wait
PDU 7
Reception of PDU 7
a :VCa
send
SUT
b: VCb
send
PDU 7

b :VCb
wait
PDU 7
Reception of PDU 7
a :VCa
send
SUT
a: VCa
send
PDU 7

10
a :VCa
wait
PDU 7
Reception of PDU 7
11
a :VCa
send
10
13
SUT
b: VCb
send
11
b :VCb
wait
12
14
a :VCa
send
13
SUT
a: VCa
send
PDU 7

14
a :VCa
wait
PDU 7
Reception of PDU 7
X.25 reset Operator (on Y) initiates an X.25 reset with cause

request code 01 (out of order), diagnostic code nn (any
01/nn diagnostic code can be selected)

request 09 (remote DTE operational)
09/nn

request 1D (network out of order)
1D/nn
PDU 7 PDU 7 via secondary VC
PDU 7
Reception of PDU 7

request 0F (network operational)
0F/nn
END OF PROCEDURE
Appendix D
Sixth Edition
Page 21 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
3b
4
5 (PVC/SVC)
Purpose:
Date of issue: 2003
Check switchover between PVC and SVC
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
Results Additional

VCa (primary VC, type PVC) / VCb (secondary
VC, type SVC)
1
SUT
a: VCa
send
PDU 7 PDU 7 via primary VC (PVC)
a: VCa
wait
PDU 7 Reception of PDU 7 (PVC)
a:
disconnect
link a
Disconnect link a
SUT
b: VCb
send
a:
reconnect
link a
SUT
a: VCa
send
PDU 7 PDU 7 via secondary VC

SUT demonstrates:
1
issue of an X.25 call request to establish
an SVC
-switch to secondary VC because the CIDIN packet
layer was notified that the primary logical channel
is not usable
Re-connect link a
PDU 7 PDU 7 via primary VC (PVC)

SUT demonstrates:
-switch back to primary VC because the CIDIN
packet layer was notified that the primary logical
channel is usable
Note: The goal of the test is to switch back whilst
the SVC still exists (not cleared due to expiration of
the idle timer). This can be achieved by:
-performing this step quickly after steps 4 and 5, or
-sending CIDIN packets from Y to SUT via VCb to
prevent expiration of the idle timer.
END OF PROCEDURE
Appendix D
Sixth Edition
Page 22 of 101
14/04/2011
D.1.5
Appendix D
Date of issue:
2003
CONFORMANCE TESTS (SINGLE LAYER) Layer 4
Sixth Edition
Page 23 of 101
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue: 2003
4
A
Page: 1/1
CIDIN Centre, entry centre, layer 4
Timers:
TNMA = 35 sec, TMR = 40 sec, TEM = 40 sec
MIN range:
1 to 100
Max message length: 64.000 octets
layer 3b
Installation state
operational state
Parameter settings
routing tables set up for the individual procedures
Parameter settings
Underlying layer
Number of test connections involved :
N.A.
Test Parameters :
SUT
System Under Test
CIDIN Testing Equipment or another CIDIN Centre

Connections
a: VCa
b: VCb
(SUT) (Y), route to EXIT 1

(SUT) (Y), route to EXIT 2
Additional conditions :
The test partner Y simulates two separate exit centres
The VC type used is PVC
SUT
Application
Layer 4
Test Sequences
EXIT1 EXIT2
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
a: VCa
Layer 2
b: VCb
Appendix D
Sixth Edition
Page 24 of 101
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue:
2003
4
B
Page: 1/1
CIDIN Centre, exit centre, layer 4
Timers
:
Min range
:
Max message length:
layer 3b
Installation state
operational state
Parameter settings
exit address of SUT is EXIT 1
Parameter settings
Underlying layer
TNMA = 35 sec, TMR = 40 sec, TEM = 40 sec.

1 to 100
64.000 octets
N.A.
Test Parameters
SUT
System Under Test

Connections
a: VCa
(SUT) - (Y), route to EXIT 1
The VC type used is either PVC or SVC

Link a may carry more than one VCs
It should also be demonstrated that the events on route a are independent from those (e.g. route failures) on
other routes
SUT
Application
(EXIT 1)
Layer 4
Test
Sequences
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Appendix D
a: VCa
Sixth Edition
Page 25 of 101
Layer 2
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue:
2003
4
C
Page: 1/1
CIDIN Centre, entry/exit centre, layer 4
Purpose
Verification of centre behaviour upon reception of messages with errors

and in exceptional cases
Timers :
layer 3b
Parameter settings
Underlying layer
Installation state :
Parameter settings
PVCs in flow control ready state. In case SVCs are used they are
established dynamically.

Test Parameters
TNMA = 35 sec, TMR = 40 sec, TEM = 40 sec.
N.A.
:
SUT
System Under Test
Test CIDIN Centre or Testing Equipment

Connections
b: VCb
(SUT) - (Y), only one VC is defined (either PVC or SVC)
The configuration should be varied with connections a and b on the same and or different circuits
SUT
AFTN/CIDIN
Application
Layer 4
Test
Sequences
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Layer 2
b: VCb
Appendix D
Sixth Edition
Page 26 of 101
14/04/2011

Overview
Layer :
Configuration :

Single Layer Tests
Date of issue: 2003
4
1
Page: 1/1
Purpose
List of procedures
Test entry centre functions for normal cases

:
1.1
Acknowledgement of single address messages, check the processing of

ACKs received
1.2
Acknowledgement of multiple address messages, check the processing of

ACKs received
Configuration used
4.A
Coding:
MACK1 to MACK2:
messages consist of 3 CIDIN packets and requiring acknowledgement
MACK3 to MACK4:
messages consist of 3 CIDIN packets with multiple Axs requiring

acknowledgement
ACK, ENQ, ENQr :
network management messages
TMR
Timeout
Initialisation:
Normal operation state
Initialisation of entry centre started by application software and operator should be demonstrated
Operators access for resetting the MIN generator is necessary.
For reasons of efficiency in the testing, facilities for repetition of messages are desirable.
Appendix D
Sixth Edition
Page 27 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
1
1 (PVC)
Purpose:
Date of issue: 2003
Acknowledgement of single address messages,

check the processing of ACKs received
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
SUT
a: VCa
send
MACK1 Message requiring acknowledgement
a : VCa
wait
MACK1
12
a: VCa
send
ACK
SUT
a: VCa
wait
ACK
SUT
a: VCa
send
SUT
a: VCa
wait
SUT
a: VCa
send
SUT
a: VCa
wait
TMR
SUT
a: VCa
send
ENQ
Results Additional
period
Acknowledgement
MACK2 Message requiring acknowledgement

TMR
Timeout
MACK2 Repetition of step 5

Second timeout
CHECK : SUT refuses the transmission of

further messages to Y
10
SUT
a: VCa
wait
TEM
ENQ timeout
11
17
SUT
a: VCa
send
ENQ
12
a : VCa
wait
MACK2 Receive but do not acknowledge
13
a : VCa
wait
14
a : VCa
wait
ENQ
15
a : VCa
wait
ENQ
16
a: VCa
send
ENQr
Enquiry response
17
SUT
a: VCa
wait
ENQr
CHECK: SUT now accepts messages for

transmission to Y
Receive but do not acknowledge
END OF PROCEDURE
Appendix D
Sixth Edition
Page 28 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
1
2 (PVC)
Purpose:
Date of issue:
2003
Acknowledgement of multiple address messages

check the processing of ACKs received
Page: 1/1
Step
No.
Centre
Connection
Action
Alt.
Step
No.
2
Event
Parameters/Comments
SUT
a: VCa
send
MACK 3 Message requiring acknowledgement sent to two Axs
MACK3 Receive at both Axs
Results Additional
period
b : VCb
2
a: VCa
b : VCb
wait
a: VCa
b: VCb
send
ACK
Acknowledgement
SUT
a: VCa
b: VCb
wait
ACK
Acknowledgement
SUT
a: VCa
b : VCb
send
MACK4 Message requiring acknowledgement sent to two Axs
a: VCa
b : VCb
wait
MACK4 Receive at both Axs
15
a: VCa
send
ACK
SUT
a: VCa
wait
ACK
SUT
wait
TMR
10
SUT
11
SUT
12
SUT
13
SUT
14
19
SUT
15
16
b: VCb
send
Only one exit centre acknowledges
Timeout on acknowledgement expected on b
MACK4 Retransmit on b
wait
TMR
Second timeout
send
ENQ
CHECK: SUT refuses the transmission of

further messages to Ax(b) in Y
wait
TEM
ENQ timeout
b: VCb
send
ENQ
b: VCb
wait
b : VCb
wait
ENQ
17
b : VCb
wait
ENQ
18
b: VCb
send
ENQr
Enquire response
19
SUT
b: VCb
wait
ENQr
CHECK: SUT now accepts messages for

transmission Ax(b) in Y
b: VCb

Receive but do not acknowledge
END OF PROCEDURE
Appendix D
Sixth Edition
Page 29 of 101
14/04/2011

Overview
Layer
Test Group
:
:

Single Layer Tests
Date of issue:
2003
4
2
Page: 1/1
Purpose: Test entry centre functions for error cases
List of procedures:
2.1
Reaction of transport layer in case of link failures (show route independence of ACK,
handling of temporary and permanent link errors)
2.2
Check the centre reaction on reception of MCF error messages
Configuration used
4.B
4.1
Coding:
MACK1 to MACK2:
as for procedure 4.1.1
ACK, ENQ, ENQr:
MCF:
MCF error message
Initialisation:
Initialisation of entry started by application software and operator should be demonstrated
Procedures are based upon disturbances of procedure 4.1.1
Means for simulation of link failures are required
Appendix D
Sixth Edition
Page 30 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
2
1 (PVC/SVC)
Purpose:
Date of issue: 2003
Reaction of transport layer in

transmission failures
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
SUT
a: VCa
send
MACK1
Message requiring acknowledgement
a : VCa
wait
MACK1
Message is acknowledged
Results Additional
period
3
4
Cut the connection

SUT
SUT
a: VCa
SUT
SUT
SUT
SUT
send
MACK1
wait
a: VCa
send
TNMA expires
MACK 1
wait
a: VCa
Message is repeated
TNMA expires
send
ENQ
Enquiry message is sent
wait
ENQ
ENQ timeout
CHECK: operator/application/error log is informed
END OF PROCEDURE
Appendix D
Sixth Edition
Page 31 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
2
2 (PVC/SVC)
Purpose:
Date of issue: 2003
Check the centre reaction on reception of MCF

error Messages
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
SUT
a: VCa
send
MACK1
a : VCa
wait
MACK1
a: VCa
send
MCFe
SUT
a: VCa
wait
MCFe
Parameters/Comments
Results Additional
period
0
MCF error message indicating an error in the

CIDIN packet of MACK1

5
SUT
a: VCa
send
M1
a : VCa
wait
M1
a: VCa
send
MCFe
Message not requiring acknowledgement
MCF error message indicating an error in a CIDIN

packet of M1
END OF PROCEDURE
Appendix D
Sixth Edition
Page 32 of 101
14/04/2011

Overview
Layer
Test Group
:
:

Single Layer Tests
Date of issue: 2003
4
3
Page: 1/1
Purpose:
Test exit centre functions for normal cases
List of procedures:
3.1
Reassembling of CIDIN packets in exit centre (show that packets are correctly assembled
into messages in spite of irregularities in sending)
Configuration used
4.B
Coding:
CID 9
CID 10 :
Layer 4 message with 20 CIDIN packets not requiring ACK

Layer 4 message with 20 CIDIN packets requiring ACK
(sub-messages CID 10+CID 10)
Initialisation:
Initialisation of exit centre started by application software and operator should be demonstrated.
This test group requires extensive manipulation of the sequence of CIDIN packets sent by the
simulated entry centre.
Appendix D
Sixth Edition
Page 33 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
3
1 (VC)
Purpose:
Date of issue: 2003
Reassembling of CIDIN packets in exit centre

(show that packets are correctly assembled into
messages in spite of irregularities in sending)
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
a : VCa
send
CID 9
Message not requiring acknowledgement and

consisting of 20 CIDIN packets
SUT
a: VCa
wait
CID 9
CHECK: message correctly assembled
a : VCa
send
CID 9
Last 10 packets sent before the first 10 packets
SUT
a: VCa
wait
CID 9
a : VCa
send
CID 9
CIDIN packet number 10 not sent
SUT
a: VCa
wait
CID 9
Receive first CIDIN packets
SUT
a: VCa
wait
TNMA
Timeout on packet number 10

CHECK: message is discarded in SUT
10
a : VCa
send
CID 9
CIDIN packet number 10 is sent twice before

last packet is sent
11
SUT
a: VCa
wait
CID 9
10
12
a : VCa
send
CID 9
Message is sent except for packet number 10

Packet number 10 is then sent with FCP=1
11
13
SUT
a: VCa
wait
CID 9
CHECK: 10 packets correctly assembled
12
14
a : VCa
send
CID 9
Message is sent in packets of random length

<=256 octets
13
15
SUT
a: VCa
wait
CID 9
14
a : VCa
send
CID 10
As for CID 1 but requiring acknowledgement.

All packets are sent except CIDIN packet number
10
15
SUT
wait
TNMA
CHECK: incomplete message retained only until

timeout TMNA
Results Additional
END OF PROCEDURE
Appendix D
Sixth Edition
Page 34 of 101
14/04/2011

Overview
Layer
Test Group
:
:

Single Layer Tests
Date of issue: 2003
4
4
Page: 1/1
Purpose
List of procedures
Test exit centre functions for error cases
4.1
Reaction of transport layer in transmission failures (temporary link failure, discarding of incomplete
messages)
4.2
Reaction of exit centre to invalid messages (show that the MCF error messages are sent under the
correct condition)
Configuration used
4.B
4.3
Coding :
CID 10
as in test group 3 (sub-messages CID 10+CID10)
ACK
INV 18 to INV 24
MCF
Initialisation
:
:
messages whose CIDIN packets contain invalid coding

(see procedure descriptions)
MCF error messages

Initialisation of exit centre started by application software and operator should be demonstrated
Means for simulation of link and centre failures are required
Appendix D
Sixth Edition
Page 35 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
4
1 (VC)
Purpose:
Date of issue: 2003
Reaction of transport layer to transmission

failures (temporary link failure, discarding of
incomplete messages)
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
a : VCa
send
CID 10
a: VCa
wait
CID 10
a: VCa
send
ACK
a: VCa
wait
ACK
Parameters/Comments
Results Additional
period
Acknowledgement
Cause temporary failure on link a

Remove failure and re-initialise/re-establish link a
5
a : VCa
send
CID 10
CID 2 without first CIDIN packet
a : VCa
wait
TMR
11
a : VCa
send
CID 10
a: VCa
wait
CID 10
a: VCa
wait
CID 10
10
13
a: VCa
send
ACK
Acknowledgement
11
a : VCa
wait
ACK
CHECK: Operation is not affected by above failure

of link a
12
a : VCa
send
CD 10
Simulate waiting for ACK

Complete message
Cause permanent failure on the link a

13
wait
TMNA
Timeout on arrival of missing packet

CHECK: CID 10 is discarded in SUT
END OF PROCEDURE
Appendix D
Sixth Edition
Page 36 of 101
14/04/2011

Procedures
Single Layer Tests
Layer
Test Group
Procedure
Purpose:
:
:
:
4
4
2 (VC)
Date of issue: 2003
Reaction of exit centre to invalid messages

(show that the MCF error messages are sent
under the correct conditions)
Page: 1/1
Step
No.
Alt.
Step
No.
7
-
Centre Connection Action
a : VCa
send
Event
INV 18
Parameters/Comments
Results Additional
period
Network management message
1
which requires response (ENQ) without ECH
2
a : VCa
send
INV 19
ENQ with non-zero CP3N
a : VCa
send
INV 20
ENQ with FCP=0
a : VCa
send
INV 21
ENQ response
a: VCa
send
INV 22
Message with MT=1 and invalid NMF
a : VCa
send
INV 23
Message consisting of valid first CIDIN packet

(CP3N) followed by CIDIN packet with
CP3N2=CP3N-1
SUT
a: VCa
wait
INV 18 to
INV 23
Receive invalid messages

CHECK: SUT does not send responses to invalid
messages
11
a : VCa
send
INV 24
Information message with invalid MCF (MT=0)
SUT
a: VCa
wait
INV 24
10
SUT
a: VCa
send
MCFe
11
a : VCa
wait
MCFe
Send appropriate MCF error message
END OF PROCEDURE
Appendix D
Sixth Edition
Page 37 of 101
14/04/2011

Overview
Layer
Test Group
:
:

Single Layer Tests
Date of issue: 2003
4
5
Page: 1/1
Purpose
List of procedures
Verification of centre behaviour upon reception of packets containing errors
:
5.1
Reaction on reception of enquiry response messages without an enquiry message

having been previously sent
5.2
Reception of acknowledgement and MCF error for messages not sent by the centre
5.3
Centre reaction upon reception of packets of one message with different Axs in their
headers
5.4
Reaction upon reception of packets of one message, several of which contain the
final CIDIN packet indicator
5.5
Verification of centre behaviour upon reception of a message with Ax whose

location code is correct although the application does not exist at the centre
5.6
Loop prevention mechanism: no retransmission of packets via the receiving VC
Configuration used
4.C
To be preceded by the groups
Coding :
PDU 19 to PDU 22
(see procedure description)
ENQ and ACK
As for procedure 4.1.1
MCF
MCF error message
Initialisation
Appendix D
Sixth Edition
Page 38 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
5
1 (VC)
Purpose:
Date of issue: 2003
Reaction to reception of enquiry response

messages without an enquiry message having
previously been sent
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
b : VCb
wait
INIT
Upgrading of link b. [VC initialisation]
SUT
b: VCb
send
ENQr
ENQr message correct

Ax: CBAFTN, Ae: CAAFTN
Text field empty
b : VCb
receive
ENQ r
Reception of ENQr
Results Additional
Verify if Y discards the received packet without

additional action
END OF PROCEDURE
Appendix D
Sixth Edition
Page 39 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
5
2 (VC)
Purpose:
Date of issue: 2003
Reception of ACK and MCF error for messages

not sent by the centre
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
b : VCb
wait
INIT
Upgrading of link b, [VC initialisation]
SUT
b: VCb
sent
ACK
ACK message correct

text field: MIN=25/CP3N=7/Ax=CAAFTN
b : VCb
receive
ACK
Reception of ACK of message not sent by Y
SUT
b: VCb
send
MCF e
MCFe message correct

Text field: MIN=27/CP3N=3/Ax=CAAFTN
b : VCb
receive
MCF e
Reception of MCFe for a message not sent by Y

Verify if Y discards the packets received in steps 2
and 4 without additional action
Results Additional
END OF PROCEDURE
Appendix D
Sixth Edition
Page 40 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
5
3 (VC)
Purpose:
Date of issue: 2003
Centre reaction upon reception of packets

of one message with different Axs in their
headers
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
b : VCb
wait
INIT
Upgrading of link c, [VC initialisation]

PDU 8 and PDU 9 are packets with identical
Aes and MINs
SUT
b: VCb
send
PDU 19
Correct packet with:

Ax: CBOPCID, Ae: CAOPCID
CP3N=0/FCP=0/NA=1/MT=0/MCF=00001
SUT
b: VCb
send
PDU 20
Correct packet with:

CP3N=0/FCP=0/NA=1/MT=0/MCF=00001
b : VCb
receive
Results Additional
period
PDU 19 & Reception of message

PDU 20 CHECK: Reaction of Y to reception of the message
END OF PROCEDURE
Appendix D
Sixth Edition
Page 41 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
5
4 (VC)
Purpose:
Date of issue: 2003
Reaction upon reception of packets of one

message, several of which contain the Final
CIDIN Packet Indicator
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
b : VCb
wait
INIT

P1, P2 and P3 are packets of one message with
NA=1/MT=0/MCF=0001
1 packet CP3N=1-1
SUT
b: VCb
send
P19
FCP=0
SUT
b: VCb
send
P20
FCP=1
SUT
b: VCb
send
P21
FCP=0
b: VCb
receive
P19
Y completes message PDU 19
b : VCb
receive
P20
Y completes messages PDU 20
b: VCb
receive
P21
Y discards PDU 21 upon expiry of TNMA
b : VCb
send
ACK
ACK (CPSN=1)
SUT
b: VCb
receive
ACK
Reception of ACK
10
SUT
b: VCb
send
P19
FCP=0
10
11
SUT
b: VCb
send
P21
FCP=1
11
SUT
b: VCb
send
P20
FCP=1
CHECK: reaction of Y
possible reception of ACK at SUT
Results Additional
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 42 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
5
5 (VC)
Purpose:
Date of issue: 2003
Verification of centre behaviour upon

reception of a message with Ax whose location
code is correct although the application
does not exist at the centre
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
b : VCb
wait
INIT
SUT
b: VCb
send
PDU 22
Message PDU 22 packets sent

(Ax without application at Y)
b: VCb
receive
PDU 22
Reception of PDU 22
Results Additional
period
CHECK: reaction of Y upon reception of the

message
END OF PROCEDURE
Appendix D
Sixth Edition
Page 43 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
5
6 (VC)
Purpose:
Date of issue: 2003
Loop prevention mechanisms

(no retransmission of packets via the receiving
VC)
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
b : VCb
wait
INIT
SUT
b: VCb
send
PDU 19
CIDIN packet correct:

Ax : CAAFTN
b: VCb
receive
PDU 19
Reception of PDU 19
CHECK: Y does not retransmit PDU 19
Results Additional
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 44 of 101
14/04/2011

Overview
Layer :
Test Group :

Single Layer Tests
Date of issue: 2003
4
6
Page: 1/1
Purpose
List of procedures
Test functionalities exclusive to SVCs

:
6.1
Verification of the calling DTE address against a list of configured DTEs,

check rejection of call in case the DTE address is not recognised.
6.2
Repetition of a call request after expiration of the call retry timer. Check
that no ENQ is sent during the retry phase.
6.3
Crossing call avoidance.
Configuration used
4.B
Coding :
MACK1 to MACK2:
messages consist of 3 CIDIN packets and requiring acknowledgement
ACK, ENQ, ENQr:
network management messages
Initialisation
Y is initially configured with DTE Address DTE-Y1

SUT is configured with DTE Address DTE-SUT
SUT has a DTE-Y1, DTE-Y2, DTE-Y3 and DTE-Y4 configured as DTE addresses for Y
SUT and Y are initialised, no SVCs are established.
Y must be able to change its own X.25 DTE address.
Appendix D
Sixth Edition
Page 45 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
6
1 (SVC)
Purpose:
Date of issue: 2003
Verification of the calling DTE address against

a list of configured DTEs by the NSU
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
period
Prepare configuration of Y and SUT

1
a: VCa
send
SUT
a: VCa
wait
SUT
a: VCa
send
X.25 call
accepted
Call accepted
a: VCa
wait
X.25 call
connected
Call connected
a: VCa
send
MACK1
SUT
a: VCa
wait
MACK1
Receive MACK1
SUT
a: VCa
Send
ACK
SUT
a: VCa
Send
X.25 clear
request
SUT/Y
a: VCa
repeat 1-8
X.25 call
request
Trigger X.25 call request with calling address

DTE-Y1 and called address DTE-SUT
X.25
Incoming call with calling address DTE-Y1 and
incoming call called address DTE-SUT, checking of the calling
address
Acknowledgement for MACK1

SVC is cleared by Y after expiration of the idle timer
Repeat steps 1-7 with Y configured with DTE-Y2,

DTE-Y3 and DTE-Y4.
10
12
SUT
11
14
a: VCa
Send
SUT
a: VCa
Wait
SUT
a: VCa
Send
X.25 clear
request
Clear Request
14
a: VCa
Wait
X.25 clear
indication
Clear Indication, clearing cause/diagnostic 00/F2
15
a: VCa
send
X.25 clear Clear confirmation

confirmation
16
SUT
a: VCa
Wait

confirmation
12
13
16
Remove DTE-Y4 from the SUT configuration

X.25 call
request
Trigger X.25 call request with calling address DTEY4 and called address DTE-SUT
X.25
address
END OF PROCEDURE
Appendix D
Sixth Edition
Page 46 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
6
2 (SVC)
Purpose:
Date of issue: 2003
To verify call retry timer operation
Page: 1/1
Step
No.
Alt.
Step
No.
Centre Connection
Action
Event
Parameters/Comments
SUT
SUT
a: VCa
send
MACK1
SUT
a: VCa
send
X.25 call
request
a: VCa
wait
a: VCa
send
X.25 clear
request
Clear Request, clearing cause/diagnostic 00/F2
SUT
a: VCa
wait
X.25 clear
indication
Remove DTE-SUT from the Y configuration.

Y shall be configured with address DTE-Y1
Attempt to send MACK1
Send of a X.25 call request with calling address DTESUT and called address DTE-Y1 (initially triggered by
step 2)
X.25 incoming Incoming call with calling address DTE-SUT (unknown)
call
and called address DTE-Y1
SUT
a: VCa
send

confirmation
11
a: VCa
wait

confirmation
SUT
a: VCa
wait
repeat 3-8
call retry timer Expiration of the call retry timer shall trigger the sending
expiration of the call request again (step 3)
10
12
SUT
a: VCa
11
15
a: VCa
12
SUT
a: VCa
send
X.25 call
request
X.25 call request with calling address DTE-SUT and

called address DTE-Y1
13
SUT
a: VCa
wait
X.25 call
connected
Call connected (Y receives incoming call, sends call

accept)
SUT
a: VCa
send
ENQ
Enquiry
a: VCa
wait
ENQ
Enquiry. Check that the SUT does not send multiple

enquiries.
a: VCa
send
ENQr
Enquiry response
SUT
a: VCa
wait
ENQr
Enquiry response
SUT
a: VCa
send
MACK1
MACK1
19
a: VCa
wait
MACK1
MACK1
20
a: VCa
send
ACK
21
SUT
a: VCa
wait
ACK
22
SUT
a: VCa
send
X.25 clear
request
14
17
15
16
19
17
18
21
period
Observe the repetition of step 3-8 for 5 minutes (at least

> 2 x TMR + 2 x TEM to check queuing of ENQs)
Add DTE-SUT as remote DTE in the configuration of Y
SVC is cleared by SUT after expiration of the idle timer
END OF PROCEDURE
Appendix D
Sixth Edition
Page 47 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
4
6
3 (SVC)
Purpose:
Date of issue: 2003
Crossing call avoidance
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
SUT
a: VCa
send
MACK1
Attempt to send MACK1
SUT
a: VCa
send
X.25 call
request
Send of a X.25 call request with calling address

DTE-SUT and called address DTE-Y1 (initially
triggered by step 1)
a: VCa
wait
a: VCa
send
SUT
a: VCa
wait
SUT
a: VCa
send
X.25 clear
indication
SUT detects the crossing call and shall send a Clear

Indication, clearing cause/diagnostic 00/F5
a: VCa
wait
X.25 clear
indication
a: VCa
send

confirmation
SUT
a: VCa
wait

confirmation
1
2
Parameters/Comments
period
X.25
Incoming call with calling address DTE-SUT and
incoming call called address DTE-Y1. Y shall ignore this call.
X.25 call
request
Trigger a X.25 call request with calling address DTEY1 and called address DTE-SUT
X.25
address
Note: After expiration on the X.25 timer T21, the

SUT shall also send a clear request for its original
call (step 2). Then the next call (retry) shall be
accepted and data can be exchanged
Appendix D
Sixth Edition
Page 48 of 101
14/04/2011
D.1.6
Appendix D
Date of issue:
2003
CONFORMANCE TESTS (SINGLE LAYER) AFTN interface
Sixth Edition
Page 49 of 101
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue:
2003
AFTN
A
Page: 1/1
AFTN interface software in a CIDIN entry centre
Purpose
Verification of AFTN interface behaviour in normal and exceptional cases
Address of AFTN origin station EAFTNTST
layer 4
Installation state
operational state
Parameter settings
Ae of centre ENTRY
Parameter settings
Underlying layer

Test Parameters
N.A.
:
SUT
CIDIN entry centre
Test CIDIN Centre or Testing Equipment simulating 2 exit centres

Connections
a: VCa
b: VCb
(SUT) - (Y) (EXIT1)

(SUT) (Y) (EXIT2)
The protocol analyser requires complete X.25 software with test software superimposed
SUT
AFTN station
EAFTNTST
AFTN
centre
Protocol analyzer/
Test equipment
AFTN
interface
Layer 4
Test Sequences
Layer 3b
EXIT1 EXIT2
Layer 3a
Layer 3a
Layer 2
a: VCa
Layer 2
b: VCb
Appendix D
Sixth Edition
Page 50 of 101
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue:
2003
AFTN
B
Page: 1/1
AFTN interface software in a CIDIN exit centre
Purpose
Verification of AFTN interface behaviour in normal and exceptional cases
Address of AFTN destination stations EAFTNTS1, EAFTNTS2
layer 4
Installation state
operational state
Parameter settings
Ax of centre EXITA
Parameter settings
Underlying layer

Test Parameters
N.A.
:
SUT
CIDIN exit centre
Test CIDIN Centre or Testing Equipment simulating an entry centre

Connections
a: VCa
(SUT) - (Y), route between ENTRY and EXITA
SUT
Y
AFTN stations
EAFTNTS1, EAFTNTS2
AFTN
centre
AFTN
interface
Test Sequences
EXTIA
Layer 3b
ENTRY
Layer 3a
Layer 3a
Layer 2
Appendix D
Protocol analyzer/
Test equipment
a: VCa
Sixth Edition
Page 51 of 101
Layer 2
14/04/2011

Overview
Layer :
Test Group :

Single Layer Tests
Date of issue: 2003
AFTN
1
Page: 1/1
Purpose
List of procedures
Test entry centre functions (normal cases)

:
1.1
1.2
Messages with addresses mapped onto one Ax

Messages with addresses mapped onto more than one Ax
Configuration used
A.A
Coding :
Text
repetitions*
Priority
Addresses (DESTINxx, xx=)
MES1
FF
AA
MES2
FF
BB
MES3
SS
AA to CC
MES4
GG
AA to PP
MES5
10
FF
AA to BB
MES6
10
DD
AA to DD
MES7
10
FF
AA to QQ
Text*
CIDIN/AFTN tests The quick brown fox jumped over the lazy dog 123456789
NA: 1
MT:0
CP:0
MCF:2
P: 2 for SS 3 for DD, FF 3 for GG, KK
Initialisation
Normal operational state; in routing tables: all messages sent via EXIT1 or EXIT2.
Initialisation of entry centre started by application software and operator should be demonstrated.
Test procedure should be repeated using input messages in ITA-2 or IA-5 characters.
The internal link between the AFTN interface software and the AFTN centre is implicitly tested.
Appendix D
Sixth Edition
Page 52 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
1
1
Purpose:
Date of issue: 2003
Messages with addresses mapped onto one Ax:

demonstrate correct mapping of AFTN message
onto CIDIN packets.
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
SUT
VCa
send
MES1
AFTN message with one Ad (Ax = EXIT1)
VCa
wait
MES1
CHECK: correct coding of CIDIN packet
SUT
VCb
send
MES2
As MES1 but with different Ad (Ax = EXIT2)
VCb
wait
MES2
SUT
VCa
send
MES3
AFTN message with several Ads (Ax = EXIT1)
VCa
wait
MES3
VCa
send
MES4
AFTN message with 16 Ads (Ax = EXIT1)
VCa
wait
MES4
CHECK: correct coding of two CIDIN packets

(two CIDIN messages)
comments during test
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 53 of 101
14/04/2011

Single Layer Tests

Procedures
Layer
Test Group
Procedure
Step
No.
:
:
:
AFTN
1
2
Centre Connection
Purpose:
Date of issue: 2003
Messages with addresses mapped onto more than one

Ax: demonstrate correct mapping of AFTN messages
onto CIDIN packets.
Page: 1/1
Alt.
Step
No.
2
Action
Event
Parameters/Comments
SUT
Vca, VCb
send
MES5
AFTN message with 2 Ads, mapped to EXIT1 and

EXIT2 respectively
Vca, VCb
wait
MES5
CHECK: correct coding of CIDIN packets
SUT
Vca, VCb
send
MES6
AFTN message with 4 Ads, one mapped onto EXIT1

and three onto EXIT2
Vca, VCb
wait
MES6
SUT
VCa
send
MES7
AFTN message with 17 Ads, each mapped onto a

different Ax. (The 17 Axs are logically distinct but are
routed via EXIT1.)
VCa
wait
MES7
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 54 of 101
14/04/2011

Overview
Layer :
Test Group :

Single Layer Tests
Date of issue: 2003
AFTN
2
Page: 1/1
Purpose
List of procedures
Test entry centre functions (exceptional cases)

:
2.1
2.2
Reaction to AFTN messages with format errors

Reaction to transmission errors
Configuration used
A.A
A.1
Coding :
INV1 to INV5: variations of MES6 (see test group A.1)

MES1:
(see test group A.1)
ACK, ENQ, ENQr: level 4 management messages
Initialisation
:
As for test group A.1
Appendix D
Sixth Edition
Page 55 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
2
1
Purpose:
Date of issue: 2003
Reaction to AFTN messages with format errors: show

that incorrect messages input at an AFTN station lead
to no incorrect CIDIN messages (possibly a function of
the AFTN centre).
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
SUT
VCa
send
INV1
AFTN message with addresses unknown at the

entry centre (*)
SUT
VCa
send
INV2
AFTN message with unknown priority (*)
SUT
VCa
send
INV3
AFTN message with no carriage returns

between heading and addresses (*)
SUT
VCa
send
INV4
AFTN message with incorrectly formatted

origin line (*)
SUT
VCa
send
INV5
AFTN message with no carriage returns before

text (*)
SUT
VCa
send
INV6
AFTN message with no end of text signal (*)
SUT
VCa
send
INV7
AFTN message
characters (*)
with
text
length
comments during test period
>1800
END OF PROCEDURE
Note: After expiration on the X.25 timer T21,

the SUT shall also send a clear request for its
original call (step 2). Then the next call (retry)
shall be accepted and data can be exchanged
(*) The action required from the AFTN centre
and AFTN interface software is a local matter.
The minimum requirements are:
- creation of an AFTN message conforming to
the standard, if possible, before transmission
over CIDIN and
- operator message or entry in error log
END OF PROCEDURE
Appendix D
Sixth Edition
Page 56 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
2
2
Purpose:
Date of issue: 2003
Reaction to transmission errors: show that

transmission errors in CIDIN lead to the correct
reaction in the sending AFTN/CIDIN centres.
Page: 1/1
Step
No.
Centre
Connection
Action
Event
Alt.
Step
No.
2
Parameters/Comments
SUT
VCa
send
MES1
VCa
wait
MES1
VCa
send
ACK
ACK for MES1
SUT
VCa
send
MES1
Repetition of step 1
VCa
wait
MES1
VCa
wait
T(TMR)
VCa
wait
MES1
Receive again
CHECK: MIN unchanged
10
VCa
send
ACK
ACK for MES1
SUT
VCa
send
MES1
10
VCa
wait
MES1
11
VCa
wait
T(TMR)
No ACK sent
12
VCa
wait
MES1
Receive again
13
15
VCa
wait
T(TMR)
14
SUT
VCa
send
MES1
15
VCa
wait
ENQ
No ACK sent
CHECK: AFTN and/or CIDIN centre operator
is informed
CHECK: The entry centre does not transmit the
message
Wait for next ENQ
16
VCa
send
ENQr
Positive ENQ response
17
VCa
wait
MES1
CHECK: MES sent by the entry centre without

further operator action
18
20
VCa
send
ACK
ACK for MES1
19
22
SUT
VCa
send
MES1
20
VCa
wait
MES1
21
VCa
send
MCFe
MCF error message
22
SUT
VCa
wait
MCFe
CHECK: the application level is informed and

appropriate action is taken
comments during test period
Simple AFTN message
No ACK sent
END OF PROCEDURE
Appendix D
Sixth Edition
Page 57 of 101
14/04/2011

Overview
Layer :
Test Group :

Single Layer Tests
Date of issue: 2003
AFTN
3
Page: 1/1
Purpose
List of procedures
Test exit centre functions (normal cases)

:
3.1
3.2
Normal reception of AFTN messages

Flow control in exit centres
Configuration used
A.B
Coding :
Text
repetitions*
Priority
Addresses (Ad1, Ad2, Ad3)
MES11
FF
EAFTNTS1
MES12
FF
EAFTNTS1, EAFTNTS2
MES13
SS
EAFTNTS1, DUMMY1, DUMMY2
Text*: sample_test; ITA-2_characters 29, 1 to 26, 30 to 32, 1to 28 (69 characters)
ACK: level 4 acknowledgement
Initialisation
:
Normal operational state
Initialisation of the exit centre started by the application software and the operator should be
demonstrated
Appendix D
Sixth Edition
Page 58 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
3
1
Purpose:
Date of issue: 2003
Normal reception of AFTN messages: show that AFTN

messages sent via CIDIN reach the addressed AFTN
station in the correct format.
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
VCa
send
MES11
Message addressed to Ad1 (EAFTNTS1)
VCa
send
MES12
Message addressed to Ad1 and Ad2 (EAFTNTS1,

EAFTNTS2)
VCb
send
MES13
Message addressed to Ad as well as Ads connected

to other exit centres (EAFTNTS1, DUMMY1,
DUMMY2)
SUT
VCb
wait
MES11
MES12
MES13
Message output to AFTN stations

Ad1 and Ad2
period
CHECK: AFTN messages are correctly converted

from CIDIN to AFTN format
5
VCa
wait
ACK
Reception of ACKs corresponding to MES11,

MES12 and MES13
END OF PROCEDURE
Appendix D
Sixth Edition
Page 59 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
3
2
Purpose:
Date of issue: 2003
Flow control in the exit centre: show that the

AFTN/CIDIN centre reacts correctly to a high
volume of messages to be output.
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
VCa
send
MES11
Send MES11 repeatedly in rapid succession

simulating a sequence of distinct messages
SUT
VCa
wait
MES11
Receive MES11 repeatedly to demonstrate correct

implementation of rate adaptation and flow control
period
CHECK: Messages are output to the AFTN station

in correct order
No messages are lost
The flow control mechanism eventually restricts
the transmission from Y
3
VCa
wait
ACKs
Receive ACKs corresponding to each message sent
END OF PROCEDURE
Appendix D
Sixth Edition
Page 60 of 101
14/04/2011

Overview
Layer :
Test Group :

Single Layer Tests
Date of issue: 2003
AFTN
4
Page: 1/1
Purpose
List of procedures
Test exit centre functions (exceptional cases)

:
4.1
4.2
Reaction to AFTN messages with format errors

Reaction to failure of the AFTN station
Configuration used
A.B
Coding :
Initialisation
INV1 to INV7
variations of MES12
MCFe, ACK
level 4 management messages
MES11
(see test group 3)
:
As for test group 3
Appendix D
Sixth Edition
Page 61 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
4
1
Purpose:
Date of issue: 2003
Reaction to received AFTN messages with format

errors: show that the appropriate action is taken
in the CIDIN exit centre/AFTN station.
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
VCa
send
INV1
AFTN message with unknown Ads
VCa
wait
INV2
AFTN message with unknown priority
VCa
send
INV3
AFTN message with no carriage returns between

heading and addresses
VCa
wait
INV4
AFTN message with incorrectly formatted origin

line
VCa
send
INV5
AFTN message with no carriage returns before text
VCa
wait
INV6
AFTN message with no end-of-text signal
VCa
send
INV7
AFTN message with text length > 1800 characters
SUT
VCa
wait
INV1 to
INV7
period
CHECK: Appropriate action in AFTN interface

software and AFTN centre
The minimum requirements are:
- creation of an AFTN message conforming to the
standard, if possible
- operator message or entry in error log
END OF PROCEDURE
Appendix D
Sixth Edition
Page 62 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
:
:
:

Single Layer Tests
AFTN
4
2
Purpose:
Date of issue: 2003
Reaction to failure of the AFTN station: show that

no messages sent via CIDIN are lost.
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
VCa
send
MES11
VCa
wait
ACK
SUT
VCa
wait
MES11
Parameters/Comments
period
Send simple AFTN message

Repeat this sending sequence as fast as the ACK
procedure allows simulating the sending of distinct
messages
Output first instance of MES11
Cause a failure of the connection to the AFTN
station addressed in MES11
Restore the connection to the AFTN station
SUT
VCa
wait
MES11
Output further instances of MES11

CHECK: No instances of MES11 have been lost
END OF PROCEDURE
Appendix D
Sixth Edition
Page 63 of 101
14/04/2011
D.1.7
Appendix D
Date of issue:
2004
CONFORMANCE TESTS (SINGLE LAYER)

CIDIN Network Management Application Interface . . . .
Sixth Edition
Page 64 of 101
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue:
2004
CIDIN Network Management Application Interface

A
Page: 1/1
CIDIN Network Management interface software in a CIDIN entry centre
Purpose
Verification of the interface behaviour in normal cases
layer 4
Installation state
operational state
Parameter settings
Ae of centre ENTRM
Underlying layer

Test Parameters
N.A.
:
SUT
CIDIN entry centre
Test CIDIN Centre or Testing Equipment simulating an exit centre

Connections
a: VCa
(SUT) - (Y) (EXITM)
SUT
Network Management working position

Protocol analyzer/
Test equipment
Local
matter
NM interface
Test Sequences
EXITM
Layer 4
Layer 3b
Layer 3a
Layer 2
Appendix D
Layer 3a
a: VCa
Sixth Edition
Page 65 of 101
Layer 2
14/04/2011

Configurations
Layer :
Configuration :

Single Layer Tests
Date of issue:
2004

B
Page: 1/1
CIDIN Network Management interface software in a CIDIN exit centre
Purpose
Verification of NM interface behaviour in normal cases
layer 4
Installation state
operational state
Parameter settings
Ax of centre EXITM
Underlying layer

Test Parameters
N.A.
:
SUT
CIDIN exit centre
Test CIDIN Centre or Testing Equipment simulating an entry centre

Connections
a: VCa
(SUT) - (Y), route between ENTRM and EXITM
SUT
Network Management working position

Protocol analyzer/
Test equipment
Local
matter
NM interface
Test Sequences
ENTRM
EXITM
Layer 3b
Layer 3a
Layer 2
Appendix D
Layer 3a
a: VCa
Sixth Edition
Page 66 of 101
Layer 2
14/04/2011

Overview
Layer :
Test Group :

Single Layer Tests
Date of issue: 2004

1
Page: 1/1
Purpose
Test entry centre functions (normal cases)
List of procedures
:
1.1
1.2
Messages with all possible priorities (B.4.6)

Messages up to the maximum length (1.2.2.5.2)
Configuration used
Coding :
Message
Priority
Text
NA-bit
MES1
NA=1
MES2
NA=1
MES3
NA=1
MES4
NA=1
MES5
NA=1
MES6
NA=1
Text A:
(NM)OP
CCCC DE BBBB 18:10:25
AFTN MAPPING AGREEMENT REQUEST (AD-AX)
BBBB TO MAP AFTN INDICATORS LP TO AX CCCCA
DUE TO OUTAGE EEEEA
PLEASE CONFIRM AGREEMENT OR DISAGREEMENT
NA: see procedure
MT:0
CP:0
MCF:1
Text B:
(NM)OP
123456....line 1lines are 80 characters long plus cr/lf) ..7890
123456line 2 .7890
123456line 3 .7890
|
| total CUDF = 24 x 82 = 1968 + 8 for (NM)OP cr lf
|
123456line 23.7890
123456line 24.7890
NA: 1
Appendix D
MT:0
CP:0
MCF:1
Sixth Edition
Page 67 of 101
14/04/2011

Text C:
(NM)OP
123456....line 1lines are 80 characters long plus cr/lf) ..7890
123456line 2 .7890
123456line 3 .7890
|
| total CUDF = 24 x 82 = 1968 + 8 for (NM)OP cr lf
|
123456line 23.7890
123456line 24.7890
...text exceeding the max CUDF length for NM
NA: 1
Initialisation
MT:0
CP:0
MCF:1
Normal operational state; in routing tables: all messages sent via EXITM
Initialisation of entry centre started by application software and operator should be demonstrated.
The selection of the priority is a local matter.
The internal link between the Network Management working position and the IUT is implicitly tested.
Appendix D
Sixth Edition
Page 68 of 101
14/04/2011

Procedures
Layer
Test Group
Procedure
Step
No.
Alt.
Step
No.
:
:
:

Single Layer Tests
Network Management
1 (entry centre)
1
Date of issue: 2004
Purpose: Ability to generate messages with different

priorities (B.4.6) and Network Acknowledgment bit
(NA=1)
Page: 1/1
Centre
Connection
Action
Event
Parameters/Comments
SUT
VCa
send
MES1
NM message with priority 1 (000), NA=1
VCa
wait
MES1
CHECK: correct coding of CIDIN message
SUT
VCa
send
MES2
VCa
wait
MES2
SUT
VCa
send
MES3
VCa
wait
MES3
SUT
VCa
send
MES4
VCa
wait
MES4
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 69 of 101
14/04/2011

Procedures
Layer
Group
Procedure
Step
No.
:
:
:

Single Layer Tests
Network Management
1 (entry centre)
2
Centre Connection
Action
Event
Date of issue: 2004
Purpose: Ability to transmit Messages up to maximum

text length.
Checking of the text length
Page: 1/1
Alt.
Step
No.
2
Parameters/Comments
SUT
VCa
send
MES5
VCa
wait
MES5
SUT
VCa
send
MES6
Overlong NM message with priority 1 (001), NA=1
VCa
wait
period
CHECK: no message produced.

END OF PROCEDURE
Note: Step No. 3 The way to prevent transmitting

overlong messages is a local matter.
Appendix D
Sixth Edition
Page 70 of 101
14/04/2011

Overview
Layer :
Test Group :
Single Layer Tests
Date of issue: 2004
Network Management
2
Page: 1/1
Purpose
List of procedures
Test exit centre functions (normal cases)

:
2.1
Normal reception of Network Management messages with

different priorities
Reception of a message with maximum message length and
reception of an overlong message
2.2
Configuration used
Coding :
Appendix D
See configuration A
Sixth Edition
Page 71 of 101
14/04/2011

CIDIN Interoperability Testing
D.2
Appendix D
Date of issue: April 2003
INTEROPERABILITY TESTS (Bilateral)
Sixth Edition
Page 72 of 101
14/04/2011
D.2.1
INTEROPERABILITY TESTING PROCEDURES (Bilateral)
D.2.2
Purpose of bilateral interoperability tests
The purpose of bilateral interoperability tests is to test the joint operation of two CIDIN centres in normal operating
conditions, including all defined CIDIN layers. They are also intended to test the complete operation of more than one
application, verifying their interfaces with Layer 4.
These are performed between two CIDIN centres at the system level. The centres subject to testing (Centre A and
Centre B) are treated as a whole, without taking into account their internal structure or the particular implementation of
each of the CIDIN protocol layers.
The testing of the specific functions of each layer (single-layer testing) shall have been previously performed at each
centre, in local or remote mode and their correct operation layer by layer shall have been demonstrated.
For the purpose of such tests, the connection between the two centres is considered to be one sole VC without
distinction (PVC or SVC). However, some dedicated integration tests are included in this section concerning particular
operational features of SVC communications, PVC/SVC switchover procedures and others.
Bilateral interoperability tests will test the behaviour of the centres in entry and exit functions. More complete tests will
be performed during the quadrilateral interoperability testing phase, including the relay functions. These latter tests will
be performed once bilateral tests have been carried out successfully between each two centres participating in the
quadrilateral tests.
The centres subject to testing will be equipped with real operation software, which will not have been modified for
testing purposes. This software will consist of CIDIN Layers 1-4, as well as sources for providing AFTN and nonAFTN messages, both requiring and not requiring end-to-end acknowledgements. Thus, the centres must be able to
respond to at least two different Axs one for AFTN messages, and the other for non-AFTN messages.
The tracing functions available at each centre will be used to analyse the results of the testing sessions, as well as
protocol analysers monitoring the lines at both ends. In the event that the anticipated results are not obtained in any of
the tests, this will permit a subsequent analysis of the situation in order to determine the cause of variance in the
behaviour of the centres or the type of error detected. As a result of this analysis, it may be necessary to repeat some of
the tests at a single layer (in the case of error detection), or to expand the testing sequence or include new tests in
subsequent versions (in the case of variance in interpretation of the specification).
D.2.3
Prior to the actual testing phase, the following items must be discussed and agreed as a minimum between the two test
partners:
General and specific parameters

Connections to be used (Characteristics and association)
Initial state (Steps completed before the starting point)
Test messages to be used
Test addresses to be used
Mapping of Ads to Axs
Sets of routing tables for each centre
Appendix D
Sixth Edition
Page 73 of 101
14/04/2011

Bilateral Tests
Configurations/Overview
Type:
Test Group:
Date of issue:
2003
I
1
Page 1/1
Purpose: Verification of centre behaviour in normal AFTN and non-AFTN traffic.

List of procedures:
1.1
Normal transmission/reception of AFTN messages.
1.2
Normal transmission/reception of non-AFTN messages.
1.3
Simultaneous transmission of AFTN and non-AFTN messages in normal conditions.
Type:
Test Group:
I
2
Purpose: Mechanisms for retransmission of messages

List of procedures:
2.1
Verification of retransmission mechanisms based on ACK loss
Type:
Test Group:
I
3
Purpose: Verification of centre behaviour in normal traffic exchange situations (incoming call reception, traffic
exchange, clearing due to elapse of the idle timer, operator initiated clearing etc. when using SVCs
List of procedures:
3.1
AFTN message exchange using SVCs

General parameters:
As in Single Layer Tests (layers 3b & 4)
Specific parameters:
Connections:
(SUT) (Y)
One link a between Centres SUT and Y

One VC is defined
In Test Group 3 the VC type is SVC.
Configuration:
SUT
AFTN/CIDIN
Application
AFTN/CIDIN
Application
Layer 4
Layer 4
Layer 3b
Layer 3b
Layer 3a
Layer 3a
Layer 2
Appendix D
a: VCa
Sixth Edition
Page 74 of 101
Layer 2
14/04/2011

Bilateral Tests
Procedures
Type:
Test Group:
Procedure:
I
1
1 (VC)
Date of issue:
2003
Purpose: Normal transmission/reception of AFTN messages
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
1,2
SUT, Y
a: VCa
wait
INIT
Upgrading of link a [VCa initialisation]
SUT
a: VCa
send
M11
Message M11 sent
a: VCa
receive
M11
Reception of M11
SUT
a: VCa
send
M21
Message M21 sent
a: VCa
receive
M21
Reception of M21
CHECK: correct reception at Y
a: VCa
send
ACK
Acknowledgement of M11
SUT
a: VCa
receive
ACK
a: VCa
send
ACK
SUT
a: VCa
receive
ACK
END OF PROCEDURE
Appendix D
Sixth Edition
Page 75 of 101
14/04/2011

Procedures
Type:
Test Group:
Procedure:
Bilateral Tests
I
1
2 (VC)
Date of issue:
2003
Purpose: Normal transmission/reception of non-AFTN messages
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
1,2
SUT, Y
a: VCa
wait
INIT
SUT
a: VCa
send
M31
Message M31 sent
a: VCa
receive
M31
Reception of M31
a: VCa
send
ACK 1
SUT
a: VCa
receive
ACK1
Reception of M31 acknowledgement
SUT
a: VCa
send
M42
Message M42 sent
a: VCa
receive
M42
Reception of M42
a: VCa
send
ACK 2
SUT
a: VCa
receive
ACK 2
Reception of M42 acknowledgement
END OF PROCEDURE
Appendix D
Sixth Edition
Page 76 of 101
14/04/2011

Bilateral Tests
Procedures
Type:
Test Group:
Procedure:
I
1
3 (VC)
Date of issue:
2003
Purpose: Simultaneous transmission of AFTN and

non-AFTN messages in normal conditions
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
1,5
SUT, Y
a: VCa
wait
INIT
SUT
a: VCa
send
M11
SUT
a: VCa
send
M21
SUT
a: VCa
send
M31
11
SUT
a: VCa
send
M42
)
)
) Steps 1 to 4 should be repeated ten times
)
)
)
)
a: VCa
send
M11
a: VCa
send
M21
a: VCa
send
M31
a: VCa
send
M42
)
)
) Steps 5 to 8 should be repeated ten times
)
)
)
)
10
a: VCa
receive
MIJ
Y receives MIJ (messages deriving from steps 1 to 4)
10
14
a: VCa
send
ACK
Acknowledgement of MIJ
11
12
SUT
a: VCa
receive
ACK
12
13
SUT
a: VCa
receive
MIJ
Y receives MIJ (messages derived from steps 5 to 8)
13
SUT
a: VCa
send
ACK
Acknowledgement of MIJ
14
a: VCa
receive
ACK
CHECK: no message has been lost at either centre
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 77 of 101
14/04/2011

Bilateral Tests
Procedures
Type:
Test Group:
Procedure:
I
2
1 (VC)
Date of issue:
2003
Purpose: Verification of retransmission mechanisms based on ACK loss
Page: 1/1
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
period
TMR = 0 at SUT
0
1,5
SUT, Y
a: VCa
wait
INIT
SUT
a: VCa
send
M11
Message M11 sent (AFTN with NA=1)
SUT
wait
TMR
TMR expires at SUT
SUT
send
M11
Retransmission of M11
SUT
wait
TMR
TMR expires at SUT again
a: VCa
receive
M11
Reception of M11
a: VCa
send
ACK
a: VCa
receive
M11
Reception of M11
10
a: VCa
send
ACK
12
SUT
a: VCa
send
ENQ
SUT enquires Y
10
11
a: VCa
receive
ENQ
Reception of ENQ at Y
11
a: VCa
send
ENQr
Y responds to enquiry
12
SUT
a: VCa
receive
ACK
Reception of acknowledgement
13
SUT
a: VCa
receive
ACK
(The ACKs received in steps 12 and 13 should be
ignored and the operator informed)
14
SUT
a: VCa
receive
ENQr
Reception of ENQr at SUT
15
a: VCa
send
M11
Message M11 sent
a: VCa
END OF PROCEDURE
Appendix D
Sixth Edition
Page 78 of 101
14/04/2011

Procedures
Type:
Test Group:
Procedure:
Step
No.
Alt.
Step
No.

Integration Tests
I
3
1 (SVC)
Centre Connection
A,B
Date of issue: 2002
Purpose: AFTN message exchange (SVC, normal case)

Page: 1/2
Action
Event
Parameters/Comments
wait
INIT
Configuration
[initialisation]
VCa
send
CALL REQUEST
CALL REQUEST sent
VCa
receive
INCOMING CALL
Reception of INCOMING CALL
VCa
send
CALL ACCEPTED
CALL ACCEPTED sent
VCa
receive
CALL CONNECTED
CALL CONNECTED received
VCa
send
M11
Message M11 sent
VCa
receive
M11
Message M11 received
VCa
send
ACK
VCa
receive
ACK
VCa
send
M12
Message M12 sent
10
VCa
receive
M12
Message M12 received
11
VCa
send
ACK
12
VCa
receive
ACK
wait
Idle timer elapsed

Initiation of clearing procedure (by
the Centre that requested the call)
13
14
VCa
send
CLEAR REQUEST
15
VCa
receive
CLEAR INDICATION
16
VCa
send
CLEAR CONFIRMATION
17
VCa
receive
CLEAR CONFIRMATION
of
VCa
as
period
SVC
SVC becomes idle

18-25
Repetition of steps 1-8
(B acts as the Local Centre and A as

the Remote Centre)
Operator initiated CLEAR (Cause
code 00)
26
VCa
send
CLEAR REQUEST
27
VCa
receive
CLEAR INDICATION
28
VCa
send
CLEAR CONFIRMATION
29
VCa
receive
CLEAR CONFIRMATION
SVC cleared
Appendix D
Sixth Edition
Page 79 of 101
14/04/2011

Page: 2/2
Step
No.
Alt.
Step
No.
Centre
Connection
Action
Event
Parameters/Comments
30
VCa
send
CALL REQUEST
CALL REQUEST sent
31
VCa
receive
INCOMING CALL
Reception of INCOMING CALL
Repetition of steps 26-29
Incoming call refusal
32-35
period
CHECK: After repetition of 30-35

several times the SVC becomes
not operational. DTE remains
disabled until enabled by the operator
END OF PROCEDURE
Appendix D
Sixth Edition
Page 80 of 101
14/04/2011

D.3
Appendix D
Date of issue: April 2003
INTEROPERABILITY TESTS (Quadrilateral)
Sixth Edition
Page 81 of 101
14/04/2011
D.3.1
INTEROPERABILITY TESTING PROCEDURES (Quadrilateral)
D.3.2
Purpose of quadrilateral interoperability tests
The purpose of quadrilateral interoperability tests is to test the validity of implementation of relay centres, routeing
principles in normal cases and using secondary routes, and simultaneous traffic situations from various centres. Also to
be tested will be CIDIN protection mechanisms against loops, packet loss, message loss, etc., within a real operation
configuration, providing initial conclusions concerning window values, timers, MIN ranges, etc., to be used in the
future.
These tests will usually be performed among four CIDIN centres in real operation, although only three centres are
required in some cases. A prerequisite for the performance of the tests will be that each of the centres participating in
this phase shall have successfully completed bilateral interoperability testing with at least one other CIDIN centre,
preferably of a different manufacturer.
Tests at this level are not concerned with the type of connection (PVC, SVC) established between any two participating
centres.
The centre subject to testing will be equipped with complete CIDIN software (up to and including Layer 4), and will be
able to generate and receive both AFTN and non-AFTN messages, consequently responding to more than one Ax/Ae.
Centres must have facilities available for varying timers, particularly TMR and TEM, to permit message loss
simulation. Also, as in the case of bilateral interoperability testing, it is felt to be advisable for centres to be equipped
with protocol analysers for monitoring their lines in various tests, also permitting errors analysis if the results of any
particular test are not expected.
Since tests do not require equivalent behaviour in all centres, most of them will have to be performed from the
beginning at each of the participating centres.
D.3.3
Due to the number of participating centres, such tests should be scheduled and co-ordinated in detail.
Prior to the actual testing phase, the following items must be discussed and agreed as a minimum:
General and specific parameters

Connections to be used (Characteristics and association)
Initial state (Steps completed before the starting point)
Test messages to be used
Test addresses to be used
Mapping of Ads to Axs
Sets of routing tables for each centre
Appendix D
Sixth Edition
Page 82 of 101
14/04/2011

Quadrilateral Tests
Overview
Type:
Test Group:
Date of issue: 2003
N
1
Page: 1/1
Purpose: Verification of correct transmission/reception of multi-destination

messages in normal cases and in the event of network out of service
List of procedures:
1.1
Transmission of an AFTN message from one centre to more than 2 other centres.
1.2
Transmission of AFTN multi-destination messages with remote link out of order.
1.3
Transmission of AFTN multi-destination messages with adjacent primary link out of

service.
1.4
Transmission of messages to an isolated centre and its progressive recovery process.
1.5
Transmission of a message not requiring acknowledgement to three other centres when the adjacent link of the
primary route to one of the destination centres is out of service.
1.6
Transmission of a message not requiring acknowledgement from one centre to several other centres when a
remote link is out of service.
Type:
Test Group:
N
2
Purpose: Verification of alternative routing selection procedures at message entry/relay centres

List of procedures:
2.1
Verification whether a relay centre selects alternate route
Appendix D
Sixth Edition
Page 83 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
1
1
Date of issue: 2003
Purpose: Transmission of an AFTN message from one centre

to more than 2 other centres
Page: 1/1
CONFIGURATION DIAGRAM
a: VCa
B
b: VCb
d: VCd
c: VCc
Primary routes:
Centres:
Links:
A, B, C, D
a, b, c, d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)
Activities:
This test is intended to verify if the centres involved react in accordance with the provisions of the protocol. For this
purpose, one single centre (A) sends messages addressed to all other centres involved in the test (B, C and D). The
correct return of ACK messages from the destination centres is verified.
Appendix D
Sixth Edition
Page 84 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
1
Date of issue: 2003
Purpose: Transmission of an AFTN message from one

centre to more than two other centres
Page: 1/1
Step
No.
Ref.
Step
No.
CENTRE A
Ref.
Centre
Connection
Action
a: VCa, d:VCd send
Event
M11
Parameters/Comments
period
AFTN message M11 sent to centres B,C and D

Reception of acknowledgements
(not necessarily in the indicated order)
a: VCa
receive
ACK
ACK sent from Centre B to Centre A
d:VCd
receive
ACK
ACK sent from Centre D to Centre A
a: VCa
receive
ACK
ACK sent from Centre C to Centre A
CENTRE B
1
a: VCa
receive
PM1I
Reception of M11 message packets from centre A
b: VCb
send
M1I
Centre B relays packets to Centre C

CHECK: correct address suppression
wait
M11
Wait for complete M11
a: VCa
send
ACK
b: VCb
receive
PACK
) Centre B relays ACK sent from Centre C to Centre A
a: VCa
send
PACK
)
)
receive
PM1I
Reception of M11 messages packets from Centre A
CENTRE C
1
b: VCb
wait
M11
b: VCb
send
ACK
receive
PM1I
Reception of M11 message packets from Centre A
CENTRE D
1
d:VCd
wait
M11
d:VCd
send
ACK
END OF PROCEDURE
Appendix D
Sixth Edition
Page 85 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
1
2
Date of issue: 2003
Purpose: Transmission of AFTN multi-destination

messages with remote link out of service
Page: 1/1
a: VCa
X b: VCb
d: VCd
c: VCc
Primary routes:
Centres:
Links:
A, B, C, D
Activities:
With link b out of service, A sends a message addressed to centres B, C and D. The test is intended to verify that centres
B and D correctly return ACK messages to A, that Centre A initiates and carries out the process provided in the
protocol with respect to C (resends the message to C, ENQUIRY process, etc.). Finally, it will be verified that after the
recovery of link b, A resends the message and C receives and returns the appropriate ACK message.
Appendix D
Sixth Edition
Page 86 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
2
Date of issue: 2003

Page: 1 / 2
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection
Action
Event
Parameters/Comments
CENTRE A
1
a: VCa
d:VCd
wait
SYNC
Wait for performance of step 1 at Centre B
M11
AFTN message M11 sent to centres B,C and D

Reception of acknowledgements
(not necessarily in the indicated order)
receive
ACK
receive
ACK
wait
TMR
TMR expires
a: VCa
send
M11
M11 sent only to Centre C
wait
TMR
TMR expires
a: VCa
send
ENQ
ENQ sent from Centre A to Centre C
wait
TEM
TEM expires
Steps 8 to 9 are repeated several times
10
a: VCa
receive
ENQr
Centre C response to Centre A enquiry
11
a: VCa
send
M11
12
a: VCa
receive
ACK
DISCONNECT LINK b
receive
PM11
M11 packets addresses to Centre B and C

CHECK: Centre B discards packets addresses
to Centre C
a: VCa, d:VCd send
CENTRE B
1
a: VCa
wait
M11
a: VCa
send
ACK
a: VCa
receive
M1I
M11 packets addresses to C
a: VCa
receive
PENQ
RECONNECT LINK b
a: VCa
receive
PENQ
b: VCb
send
PENQ
Centre B relays ENQ sent from Centre A to

Centre C
Appendix D
Sixth Edition
Page 87 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
2
Date of issue: 2003

Page: 2/2
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection
Action
Event
Parameters/Comments
10
b: VCb
receive
PENQr
Centre C response to Centre A ENQ
11
10
a: VCa
send
PENQr
Centre B relays Centre C ENQr to Centre A
12
11
a: VCa
receive
PM11
M11 packets addresses to Centre C
13
12
b: VCb
send
PM11
14
b: VCb
receive
ACK
15
14
a: VCa
send
ACK
B relays ACK sent from Centre C to Centre A
CENTRE C
1
b: VCb
receive
ENQ
b: VCb
send
ENQr
Centre C response to A enquiry
13
b: VCb
receive
PM11
11
wait
M11
b: VCb
send
ACK
receive
PM11
CENTRE D
1
d:VCd
wait
M11
d:VCd
send
ACK
END OF PROCEDURE
Appendix D
Sixth Edition
Page 88 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
1
3
Date of issue: 2003

messages with adjacent primary link out of service
Page: 1/1
a: VCa
B
b: VCb
d: VCd
c: VCc
Primary routes:
Centres:
Links:
A, B, C, D
Activities:
With link a out of service, a message requiring ACK is sent from A to all the other centres (B, C and D). All of the
centres receive the message and send ACK. The ACK sent by centre C cannot progress beyond B, such that A considers
it out of service and sends ENQ messages. At a given time, link a is restored and the reply to the ENQ and the correct
reception of the ACK will be checked.
Appendix D
Sixth Edition
Page 89 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
3
Date of issue: 2003

Page: 1/3
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection
Action
Event
Parameters/Comments
period
CENTRE A
1
DISCONNECT LINK a
d:VCd
send
M11
AFTN message M11 sent to Centres B, C and D
d:VCd
receive
ACK
d:VCd
receive
ACK
wait
TMR
TMR expires
d:VCd
send
M11
wait
TMR
TMR expires again
d:VCd
send
ENQ
wait
TEM
TEM expires
10
RECONNECT LINK a
11
a: VCa
send
ENQ
12
13
a: VCa
receive
ENQr
Centre C response to Centre A enquiry
13
a: VCa
send
M11
14
16
a: VCa
receive
ACK
receive
PM11
M11 packets addressed to Centre B
CENTRE B
1
b: VCb
wait
M11
b: VCb
send
ACK
b: VCb
receive
PACK
b: VCb
receive
PACK
11
b: VCb
receive
PENQr

Step 6 is repeated several times
11
a: VCa
receive
PENQ
b: VCb
send
PENQ
Centre B relays ENQ sent from Centre A to Centre C
Appendix D
Sixth Edition
Page 90 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
3
Date of issue: 2003

Page: 2/3
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection
Action
Event
Parameters/Comments
13
b: VCb
receive
PENQr
10
a: VCa
send
PENQr
Centre B relays Centre C ENQr to Centre A
11
13
a: VCa
receive
PM11
M11 packets addressed to Centre C
12
11
a: VCa
send
PM11
13
16
b: VCb
receive
PACK
14
13
a: VCa
send
PACK
Centre B relays ACK sent from Centre C to Centre A
period
CENTRE C
1
c: VCc
receive
PM11
M11 packets addressed to Centres B and C
b: VCb
send
PM11
Centre C relays packets addresses to Centre B
wait
M11
b: VCb
send
ACK
b: VCb
receive
PACK
c: VCc
send
PACK
Centre C relays ACK sent from Centre B to Centre A
c: VCc
receive
PM11
wait
M11
b: VCb
send
ACK
10
d:VCd
receive
ENQ
11
b: VCb
send
ENQr

Steps 10 and 11 are repeated several times
12
11
b: VCb
receive
ENQ
13
b: VCb
send
ENQr
14
12
b: VCb
receive
PM11
15
13
wait
M11
16
b: VCb
send
ACK
Appendix D
Sixth Edition
Page 91 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
3
Date of issue: 2003

Page : 3/3
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection Action
Event
Parameters/Comments
CENTRE D
1
d:VCd
receive
PM11
M11 packets addressed to Centres B, C and D
c: VCc
send
PM11
Centre D relays packets to Centres B and C
wait
M11
d:VCd
send
ACK
c: VCc
receive
PACK
d:VCd
send
PACK
D relays ACK sent from Centre B to Centre A
d:VCd
receive
PM11
c: VCc
send
PM11
D relays packets to Centre C
d:VCd
receive
PENQ
10
c: VCc
send
PENQ
D relays ENQ sent from Centre A to Centre C

Steps 9 and 10 are repeated several times
END OF PROCEDURE
Appendix D
Sixth Edition
Page 92 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
1
4
Date of issue: 2003
Purpose: Transmission of messages to an isolated centre and

its progressive recovery process
Page: 1/1
a: VCa
B
b: VCb
d: VCd
c: VCc
Primary routes:
Secondary routes
Centres:
Links:
A, B, C, D
a,b,c,d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)
Activities:
Centre A sends a multi-destination message addressed to Centres B, C and D with links b and c out of service. Centre A
receives ACK from Centres B and D. Centre B discards packets addressed to C. When TMR expires, Centre A resends
the message only to Centre C with B again discarding the packets. When TMR expires a second time, A sends ENQ
packets to C, with B also discarding these packets.
Link c is now restored. Centre A continues making enquiries to C through B. Finally, link b is restored. Centre C
receives Centre A ENQ and responds through B. When A receives Centre C ENQr, it sends the message through B. C
sends the appropriate ACK also through B.
Appendix D
Sixth Edition
Page 93 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
4
Date of issue: 2003

Page 1 /2
Step
No.
Ref.
Step
No.
CENTRE A
1
1
Ref.
Centre
Connection
Action
wait
a: VCa, d:VCd send
Event
Parameters/Comments
SYNC
Wait for performance of step 1 at Centre C
M11
AFTN message M11 sent to Centres B, C and D
period
Reception of ACKs not necessary in the indicated

order
3
a: VCa
receive
ACK
d:VCd
receive
ACK
wait
TMR
TMR expires
a: VCa
send
M11
wait
TMR
TMR expires again
a: VCa
send
ENQ
wait
TEM
TEM expires
10
a: VCa
receive
ENQr
11
a: VCa
send
M11
12
a: VCa
receive
ACK
wait
SYNC
receive
PM11
Reception of M11 packets

(Ax for Centres B and C)
CENTRE B
1
a: VCa
wait
M11
a: VCa
send
ACK
a: VCa
receive
PM11
Reception of M11 packets (Ax only for Centre C)
a: VCa
receive
PENQ

Step 6 is repeated several times
wait
SYNC
a: VCa
receive
PENQ
Appendix D
Sixth Edition
Page 94 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
4
Date of issue: 2003

Page 2/2
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection
Action
Event
Parameters/Comments
b: VCb
send
PENQ
10
b: VCb
receive
PENQr
11
10
a: VCa
send
PENQr
12
11
a: VCa
receive
PM11

(Ax only for Centre C)
13
12
b: VCb
send
PM11
14
b: VCb
receive
PACK
15
14
a: VCa
send
PACK
period
CENTRE C
1
DISCONNECT LINKS b AND c
wait
SYNC
Wait for performance of steps 9 of Centre A

and 6 of Centre B
CONNECT LINK c
CONNECT LINK d
b: VCb
receive
ENQ
b: VCb
send
ENQr
13
b: VCb
receive
PM11
M11 packets addresses to Centre C

(Ax only for Centre C)
11
wait
M11
b: VCb
send
ACK
CENTRE D
1
1
wait
SYNC
Wait for the performance of step 1 at Centre C
d:VCd
receive
PM11
Reception of M11 packets

(Ax only for Centre D)
wait
M11
d:VCd
send
ACK
wait
SYNC
Wait for step 3 at Centre C

END OF PROCEDURE
Appendix D
Sixth Edition
Page 95 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
1
5
Date of issue: 2003
Purpose: Transmission of a message, not requiring an ACK, to three

other Centres, when the adjacent primary link of the route
to one of the destination centres is out of order.
Page: 1/1
a: VCa
B
b: VCb
d: VCd
c: VCc
Primary routes:
Centres:
Links:
A, B, C, D
Activities:
With link a out of service, a message not requiring an ACK is sent from A to all other centres. All the centres receive
the message. A line monitor connected between C and D shows the message passing from D to C.
Acknowledgements are not received at centre A.
Appendix D
Sixth Edition
Page 96 of 101
14/04/2011

Quadrilateral Tests
Procedure
Type:
Test Group:
Procedure:
N
1
5
Date of issue: 2003
Purpose: Transmission of a message, not requiring an ACK, to three

other Centres, when the adjacent primary link of the route
to one of the destination centres is out of order.
Page 1/1
Step
No.
Ref.
Step
No.
Ref.
Centre
Connection
CENTRE A
1
-
CENTRE B
1
2
2
Action
Event
Parameters/Comments
DISCONNECT LINK a
d:VCd
send
M62
Non-AFTN message M62 sent to Centres B, C and D
b: VCb
receive
PM62
M62 packets addressed to Centre B
wait
M62

(Ax for Centres B and C)
CENTRE C
1
2
c: VCc
receive
PM62
b: VCb
send
PM62
Centre C relays packets addressed to Centre B
wait
PM62
CENTRE D
1
2
d:VCd
receive
PM62
M62 packets addressed to Centres B,C and D
b: VCb
send
PM62
Centre D relays packets addressed to Centres B and C
wait
PM62
period
END OF PROCEDURE
Appendix D
Sixth Edition
Page 97 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
1
6
Date of issue: 2003
Purpose: Transmission of a message, not requiring an ACK, from one

Centre to several other Centres when a remote link is out of order.
Page: 1/1
a: VCa
X b: VCb
d: VCd
c: VCc
Primary routes:
Centres:
Links:
A, B, C, D
Activities:
When link b out of service, a message not requiring an ACK is sent from A to all the other centres. The message is
received at B and D, but B discards the packets for centre C.
Then link b is restored and it is verified that when Centre A re-sends the message it will be delivered at all centres.
Acknowledgements are not received at Centre A.
Appendix D
Sixth Edition
Page 98 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
1
6
Date of issue: 2003
Purpose: Transmission of a message, not requiring an ACK, from one Centre

to several other Centres when a remote link is out of order.
Page 1/1
Step
No.
Ref.
Step
No.
CENTRE A
1
-
Ref.
Centre
Connection
Action
Event
Parameters/Comments
SYNC
Wait for performance of step1 at Centre B
M62
Non-AFTN message sent to Centres B,C and D
wait
M62
Wait for performance of step 4 at Centre B
a: VCa, d:VCd send
M62
Non-AFTN message sent to Centres B,C and D
DISCONNECT LINK b
receive
PM62

CHECK: that Centre B discards the packets
addressed to Centre C
a: VCa, d:VCd send

-
CENTRE B
1
-
a: VCa
wait
M62
RECONNECT LINK b
a: VCa
receive
P62I
send
PM62
wait
M62
CENTRE C
1
2
SYNC
Check that no message is received at C
SYNC
Wait for completion of step 4 at Centre B
wait
PM62
Reception of M62 packets from Centre A
wait
M62
CENTRE D
1
2
d:VCd
receive
PM62
Reception of M62 from Centre A
wait
M62
d:VCd
receive
PM62
Reception of M62 from Centre C
wait
M62
END OF PROCEDURE
Appendix D
Sixth Edition
Page 99 of 101
14/04/2011

Quadrilateral Tests
Procedure Abstract
Type:
Test Group:
Procedure:
N
2
1
Purpose:
Date of issue: 2003
Verify whether a relay centre selects alternate route
Page: 1/1
a: VCa
B
VCe
d: VCd
X b: VCb
C
c: VCc
Primary routes:
Secondary routes
Centres:
A, B, C, D
Links:
a, b, c, d, e (carrying VCa, VCb, VCc, VCd and VCe respectively and possibly other VCs)
Activities:
Centre A sends a message requiring ACK to C in normal conditions. Routing for the message and the corresponding
ACK is checked.
Link b is disconnected, and a new message is sent from A to C. Routing for the message (ABDC) and the
corresponding ACK (CDA) is checked.
Appendix D
Sixth Edition
Page 100 of 101
14/04/2011

Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:
N
2
1
Purpose:
Date of issue: 2003
Verify whether a relay centre selects alternate route
Page 1/1
Step
No.
Ref.
Step
No.
CENTRE A
1
-
Ref.
Centre
Connection
Action
Event
Parameters/Comments
a: VCa
send
M41
AFTN message is sent to Centre C
a: VCa
receive
ACK
wait
SYNC
Ensure that link b is out of service
a: VCa
send
M41
Message M41 sent to Centre C
d:VCd
receive
ACK
CENTRE B
1
1
a: VCa
receive
PM41
Reception of M41 packets addressed to Centre C
b: VCb
send
PM41
b: VCb
receive
PACK
a: VCa
send
PACK
a: VCa
receive
PM41
e:VCe
send
PM41
Centre B relays packets to Centre C using link e
CENTRE C
1
2
b: VCb
receive
PM41
Reception of message M41 packets
wait
M41
b: VCb
send
ACK
DISCONNECT LINK b
c: VCc
receive
PM41
Reception of message M41 packets
wait
M41
:VCc
send
ACK
ACK sent from Centre C to Centre A using link c

instead of link b
CENTRE D
1
6
e:VCe
receive
PM41
c: VCc
send
PM41
Centre D relays packets to Centre C
c: VCc
receive
PACK
d:VCd
send
PACK
Centre D relays ACK sent from Centre C to Centre A
period
END OF PROCEDURE
END of Appendix D
Appendix D
Sixth Edition
Page 101 of 101
14/04/2011
Appendix E Interface Primitives
E.1
Primitives
Primitive
TIMreq
Description
Request for transmission of an
information message
TIM conf
Confirmation of transmission of
an information message
TIMind
Indication of a received
information message
TIMresp
Transmission information
message response
Request for transmission of a
CIDIN packet
Tpreq
TPconf
Tpind
Appendix E
Confirmation of transmission of a
CIDIN packet
Indication of a received packet
Associated Parameters
Interface control information: (a) Exit address vector
Ax whose elements Ax(I), I=1,..n,n<=16, denote the set
of exit centre addresses for the message. (b) For
messages in AFTN format destination address matrix
Ad whose row vectors Ad(I,j), j=1,..m, m<=15, denote
the set of destination addresses reached via the exit
centre Ax(i). (c) Message priority MP. (d) Message
code and format MCF. (e) Network acknowledgement
flag NA.
Interface data: (a) Message content, including. In the
case of a message in AFTN format, the priority
indicator, origin and ending parts. TIMconf (in the case
of messages requiring acknowledgement).
Interface control information: Response vector R
from which a response (ACK or MCF error) has been
received. The boolean element R(i) is true if and only if
a response has been received from the exit centre Ax(i)
Response type vector RT.RT(i)=1,2 means ACK and
MCF error respectively for the exit centre Ax(i),
I=1,n<=16.
Interface control information: (a) Destination address
vector Ad. For messages in AFTN format, Ad denotes
the set of destination addresses reached via the exit
centre address. (b) Message priority MP. (c) Message
code and format MCF.
Interface data: Message content including, in the case
of a message in AFTN format, the priority indicator,
origin and ending parts.
_____
Interface control information: (a) Exit address vector
Ax. (b) Destination address matrix Ad (only in the first
CIDIN packet of messages in AFTN format). (c)
Message priority MP.
Interface data: (a) CIDIN transport header. (b)
segment of information message or ACK, ENQ, ENQ
response or MCF error.
The implementation of a TPconf is a local matter and
not considered further here.
Interface control information: () Destination address
vector Ad of maximum dimension 15 (for messages in
AFTN format). In the case where more than one Ax is
present in an exit centre, the address Ax(s) can be
passed as a parameter as well. (b) Message priority MP.
Interface data: (a) CIDIN transport header. (b)
Sixth Edition
Page 1 of 3
14/04/2011
TPresp
E.2
Transmission of packet response
Entry Centre States

State
IDLE
WAIT1
WAIT2
E.3
Description
Inactive but available for transport of an information
message
Waiting for responses after the first transmission of
the message
Waiting for responses after the second transmission of
a message
Entry Centre External Events

Event
TIMreq from TS user
TPind (parameter ACK)
TPind (parameter MCF error
TPind (response to enquiry)
E.4
Description
time-out repeat message
time-out repeat enquiry
Entry Centre Actions

Action
SME
ATMR
TIMconf ACK
TIMconf Ax out of service
ATEM
SENQ
E.6
Description
send a message via the corresponding
Tpreq
activate the timer TMR
activate the ENQ timer

send ENQ via TPreq
Exit Centre States

State
UNASSIGNED
IN_PROCESS
Appendix E
Description
Entry Centre Internal Events

Event
TMR time-out
TEM time-out
E.5
Segment of information message or ACK, ENQ, ENQ

response or MCF error.
_____
Description
inactive but available for receiving an information
message
waiting for a non-first segment of a message
Sixth Edition
Page 2 of 3
14/04/2011
E.7
Exit Centre External Events

Event
TPind (FCP = 1)
TPind (FCP = 0)
TPind (ENQ)
E.8
Description
Exit Centre Internal Events

Event
TNMA
E.9
Description
time-out, message assembly
Exit Centre External Actions

Action
TIMind to the TS user
TPreq*1 send ACK or MCF
error
TPreq ENQ send message
response to the ENQ
E.10
Description
Exit Centre Internal Actions

Action
ATNMA
DISCARD the message
Description
activate the timer TNMA
END of Appendix E
Appendix E
Sixth Edition
Page 3 of 3
14/04/2011
Appendix F - Guidance on the Implementation of SVCs
F.1
Introduction
F.1.1
As more and more CIDIN Centres migrate in order to use PSN facilities, X.25 SVC usage is being
considered. SVCs offer a more flexible way to connect systems (including these systems that were
previously exchanging data via CIDIN relay); however, in using SVCs, addressing aspects that do
not exist for PVCs need to be addressed. Furthermore, some concern arises regarding security
aspects and a minimum guidance about call management is deemed necessary.
F.2
Purpose and Scope
F.2.1
The purpose of this Appendix is to give initial guidance on issues relating to availability, reliability,
addressing, security and call management, in relation with SVCs in an interconnected X.25 network
environment.
F.3
Network Implementation
F.3.1
Availability
F.3.1.1
To increase service reliability, CIDIN Centres should be connected to the network via two physical
links, preferably belonging to different network switches. In the event of a DCE (PSN end)
disconnection due to a network failure, call re-establishment should be made via the second access.
F.3.1.2
To make this configuration transparent to adjacent CIDIN Centres and thereby optimise network
routing and limit unsuccessful calls, it is recommended that the knowledge of X.25 DTE addresses
be minimised by using the PSN Call Redirection facility or the Hunt Group facility (preferred
operation)1.
F.3.1.3
This should be done in a transparent way that fully utilises SVCs without the need to implement
additional logic. This transparency can be achieved by many PSNs, by performing internal address
translation and stripping of facility fields. The PSN (DCE) at the called DTE side should suppress
the notifications related to the Hunt Group facility or the Call Redirection facility (CLAMN and
CRN) and should perform address translation (in both directions) to an agreed single X.121 address.
F.3.1.4
CIDIN Centres can then be connected with redundancy (multiple links, on-line/stand-by systems)
without the need for adjacent Centres to be aware of these multiple connections, i.e., the remote
CIDIN Centre is known by one X.121 address.
F.3.1.5
The following points provide some information on the way most networks implement address
management.
In some cases even both facilities could be used. In Centres with on-line and stand-by systems the addresses for
the first system could belong to a hunt group and this one could be re-directed to a second hunt
group with the addresses of the second system.
Appendix F
Sixth Edition
Page 1 of 13
14/04/2011

-
F.3.1.5.1 Address handling

The network, at port level, performs verification of called and calling addresses, and address insertion
or modification. According to the setting of the option to ignore the local address, the insertion or
modification of a called or calling address is done (in case of CIDIN Centres connected to networks this
option should not be set due to security reasons).
Call Request: A calling address is optional, however, any calling address provided by a DTE must
match that configured in the network (if the option to ignore local address is not subscribed; if set,
the network does not perform any checking of the DTE-provided calling address against that
configured in the network). If the DTE does not provide a calling address, the address configured in
the network is used as the calling address.
Call Accept: It is optional for the called DTE to provide calling and called addresses in a call accept
packet. If the calling address is provided by the called DTE, the address must match that specified
in the corresponding incoming call request packet. If the called DTE does not provide a calling
address, the DCE inserts the calling address from the corresponding incoming call request packet.
The called address from the corresponding incoming call request packet is inserted as the called
address if the called DTE does not provide a called address or if the DTE provides a called address
and the option to ignore the local address is set. If this option is not subscribed and the called DTE
provides a changed called address, a CLAMN is inserted by the DCE if not present. The called
DTE must provide a changed called address if it provides a CLAMN or else the call is cleared.
Call Connect: The DCE passes to the calling DTE the called and calling addresses returned from
the remote DCE.
Clear Request: Called and calling addresses are not allowed in clear packets sent by the calling
DTE. When providing a called address, the called DTE must always specify a CLAMN (if either a
called address or CLAMN is provided by a called DTE, both must be provided). If the called DTE
does not specify a called address and the corresponding incoming call was redirected, the redirected
address and CLAMN are inserted in the clear packet.
Clear Indication generated by the network: Clear packets received by a called and calling DTE
normally contain called and calling addresses of length zero.
F.3.1.5.2 Address suppression

Usually networks are able to remove the called address in all call accept/call connect and clear request
packets and the calling address in all call accept/call connect and call request/incoming call packets (in
case of CIDIN Centres connected to networks this option should not be set due to security reasons).
F.3.1.5.3 Hunt groups
When a DTE calls a Hunt Group, the call is established with a Hunt Group member address. A common
option offered by network is to notify the calling DTE of the successful connection to the Hunt Group
address instead of to the member address. Also, calls from a Hunt Group member can be configured to
signal the Hunt Group address instead of the member address. This option forces the Hunt Group
address over the member address for calls from the network to the Hunt Group, and for calls from the
Hunt Group member towards the network. Calls from the network directly to the Hunt Group member
are unaffected.
F.3.1.5.4 ADDRESS TRANSLATION
Networks allow, as an option at port level, translation of calling and/or called addresses in packets from
and to remote DTEs. If this option is enabled, a call originating on the network will have the calling
and/or called addresses translated and these calling and/or called addresses will be translated back to the
original addresses when the call accept is received from the DTE). A similar mechanism applies to call
originating on the remote DTE.
Appendix F
Sixth Edition
Page 2 of 13
14/04/2011
F.3.2
Security
F.3.2.1 Address checking

The X.121 addresses of remote DTEs should be configured. These addresses are needed for:
verification of the Calling DTE Address field in the INCOMING CALL packet. A
non-configured INCOMING CALL should be rejected (CLEAR REQUEST).
the Called DTE Address in the CALL REQUEST packet.
For a given Ax, the above two addresses will normally be the same (by using the facilities described in
point 3.1 above), however systems should be prepared for different addresses. In case of a duplicate
connection using the Hunt Group principle, it may happen that the INCOMING CALL address is either
a port address or the hunt group address.
F.3.2.3 Closed User Group
The International Closed User Group (ICUG) facility can be used by the PSN for security reasons
(bilateral agreement on its usage is required because the facility is excluded in the X.25 PRL as shown
in Appendix G).
F.4
Network Configuration
F.4.1
Description
In this section, a VCG configuration in the context of CIDIN centres connected among them using
PSNs and leased lines is going to be considered, providing finally some advantages in the use of SVCs
as a component of a VCG.
As it has been introduced in the CIDIN Manual, a Virtual Circuit Group (VCG) consists of a number of
Virtual Circuits (VC) that connect two, and only two, CIDIN centres. Also it states that a Primary-type
VC is always present and a Secondary-type VC is optional.
In the case of having CIDIN centres connected to PSNs, it is recommended in a first step that any VCG
consist of the use of a PVC as a Primary-type VC and a single SVC as a Secondary-type VC (in section
4.3 an implementation plan is presented).
Virtual Circuit group (VCG)
Primary VC
PVC
Secondary VC
SVC
In this way, in a normal situation only the PVC of each VCG is established.
If this PVC is detected to be out of order, then a Call establishment procedure is initialised in order to
set up a single SVC (secondary VC) between the CIDIN centres involved.
The SVC is disconnected when one of the following occurs:
Appendix F
The Idle timer elapses. In this case, it is attempted to switch back from the secondary VC
(SVC) to the primary VC (PVC).
The SVC-type CIDIN exchange is disabled by an operator command.
The PVC is re-established (reception of a positive RESET code).
Sixth Edition
Page 3 of 13
14/04/2011

As an example Figure F.1 shows different network configurations:
Ax2
Ax3a
Line 4
Line 5
Line 3
Line 6
CR
HG
GW4
GW5
PSN2
PSN3
PVC1
PVC2
GW2
GW1
GW3
PSN1
Line 1
Line 2
Line 8
Line 7
Leased line
Ax4
Ax3b
Ax1
Leased line
PVC4
PVC3
Ax5
Figure F.1 Example of VCG Network Configuration
Appendix F
Sixth Edition
Page 4 of 13
14/04/2011

Five CIDIN centres have been considered in the example:
-
CIDIN centre 1 is connected to PSN1 by using two different lines (Line 1 and Line 2). Line 1
supports the PVC1 and a potential SVC and Line 2 supports the PVC2 and a potential SVC.
Besides, there exist one leased line with CIDIN Centre 4 and another leased line with CIDIN Centre
5. CIDIN level 3b has been configured in CIDIN Centre 1 as follows:
> Ax2:
Main Virtual Circuit group VCG(1)
Primary VC
PVC1
Secondary VC
SVC1
Alternate Virtual Circuit group VCG(2)

Primary VC
PVC2
Secondary VC
SVC2
> Ax3:
Main Virtual Circuit group VCG(1)
Primary VC
PVC2
Secondary VC
SVC2
Alternate Virtual Circuit group VCG(2)

Primary VC
PVC1
Secondary VC
SVC1
> Ax4:
Virtual Circuit group VCG(1)
Primary VC
Secondary VC
PVC3
> Ax5:
Virtual Circuit group VCG(1)
Primary VC
Secondary VC
PVC4
Appendix F
Sixth Edition
Page 5 of 13
14/04/2011

-
CIDIN centre 2 is connected to PSN2 by using two different lines (Line 3 and Line 4). Line 3
supports the PVC1 and a potential SVC and Line 2 supports a potential SVC.
CIDIN centre 3 is composed of two different systems for redundancy purposes. The first one is
connected to PSN3 by using Line 5 supporting the PVC2 and a potential SVC. The second one is
connected to PSN3 by using Line 6 supporting a potential SVC.
CIDIN centre 4 is connected with CIDIN Centre 1 by using the leased line Line 7.
CIDIN centre 5 is connected with CIDIN Centre 1 by using the leased line Line 8.
F.4.2
Advantages of the use of SVCs

The VCG network configuration proposed above has the following advantages:
F.4.2.1 Network economy.

In the case of CIDIN centres connected to PSN, the use of a SVC per VCG, provides a more efficient
use of the mentioned PSN since network resources are only used when they are required.
That means that SVCs are established only when there exists a real need for interchanging information
between two CIDIN centres. The Idle Timer mechanism has been envisaged for disconnecting the
SVC when there are no messages to be transmitted.
On the other hand, only one PVC per VCG is going to be established between two CIDIN Centres in
normal conditions instead of two or more that there exist in real interconnections.
F.4.2.2 Redundancy
The use of SVCs in CIDIN centres interconnected by PSNs allows the possibility of taking advantage of
network facilities such as the PSN Hunt Group and Call Redirection facilities.
If the PVC becomes out of order, then a Call establishment procedure would be initialised in order to set
up a SVC between the corresponding CIDIN centres. At this step, it is possible to take advantage of the
following:
-
Hunt Groups (HGs).
Call Redirection (CR).
Potential redundancy at the PSN accesses.
Use of different Gateways among PSNs.
Appendix F
Sixth Edition
Page 6 of 13
14/04/2011

F.4.2.2.1 Hunt Group
Having a look on Figure F.2, a Hunt Group has been configured on the CIDIN Centre 2 side.
Ax2
Ax3a
Line 4
Ax3b
Line 5
Line 3
Line 6
CR
HG
GW4
GW5
PSN2
PSN3
SVC1d
PVC1
PVC2
SVC1
GW2
GW1
GW3
PSN1
Line 1
Line 2
Line 8
Line 7
Leased line
Ax4
Ax1
Leased line
PVC4
PVC3
Ax5
Figure F.2 Example of redundancy by using Hunt Group facilities

It is possible that any of the PSN ports to which CIDIN Centre 2 is connected is down (for example,
port associated to Line 3). That means that the PVC1 and/or SVC1 becomes out of order (PVC) or
cleared (SVC) and CIDIN Centre 1 initiates a call establishment procedure in order to set up a new SVC
with CIDIN Centre 2, following the CIDIN layer 3B configuration drawn up in the previous section.
In this way, SVC1d will be set up by using another physical connection between CIDIN Centre 2 and
PSN2 (Line 4), in a manner completely transparent to the calling CIDIN Centre.
Appendix F
Sixth Edition
Page 7 of 13
14/04/2011

F.4.2.2.2 Call Redirection
Having a look on Figure F.3, a Call Redirection has been configured on the CIDIN Centre 3 side.
Ax2
Ax3a
Line 4
Ax3b
Line 5
Line 3
Line 6
CR
HG
GW4
GW5
PSN2
PSN3
SVC2
SVC2b
PVC1
PVC2
GW2
GW1
GW3
PSN1
Line 1
Line 2
Line 8
Line 7
Leased line
Ax4
Ax1
Leased line
PVC4
PVC3
Ax5
Figure F.3 Example of redundancy by using Call Redirection facilities

It is possible that one of the systems goes down (for example CIDIN Centre 3, on-line system). That
means that the PVC2 and/or SVC2 becomes out of order (PVC) or cleared (SVC) and CIDIN Centre 1
initiates a call establishment procedure in order to configure a new SVC with CIDIN Centre 3,
following the CIDIN layer 3b configuration drawn up in the previous section.
In this way, SVC2b can be set up by using a Call Redirection facility in order to get the other system
(CIDIN Centre 3, stand-by system), in a manner completely transparent to the calling CIDIN Centre.
Appendix F
Sixth Edition
Page 8 of 13
14/04/2011

F.4.2.2.3 Potential redundancy at the PSN accesses
Having a look on Figure F.4, at CIDIN Centre 1, in order to access the PSN configuration, it is possible:
-
To force that the SVC uses a specific line.
To have a configuration table where two or more potential PSN access are collected in order to be
used dynamically by the DTE.
Ax2
Ax3a
Line 4
Ax3b
Line 5
Line 3
Line 6
CR
HG
GW4
GW5
PSN2
PSN3
PVC1
PVC2
SVC1
GW2
GW1
GW3
PSN1
SVC1c
Line 1
Line 7
Leased line
Ax4
Line 2
Line 8
Leased line
Ax1
PVC4
PVC3
Ax5
Figure F.4 Example of redundancy by using redundancy at the PSN accesses

In order to improve reliability, the second approach is recommended.
In this way, if Line 1 is going down, then the PVC1 and/or SVC1 becomes out of order and CIDIN
Centre 1 initiates a call establishment procedure in order to set up a new SVC with CIDIN Centre 2,
following the layer 3B configuration drawn up in the previous section.
In this way, SVC1c will be set up by using another physical connection between CIDIN Centre 1 and
PSN1 (Line 2).
Appendix F
Sixth Edition
Page 9 of 13
14/04/2011

F.4.2.2.4 Use of different gateways between PSNs
Having a look on Figure F.5, two different gateways have been configured for interconnecting PSN1
and PSN2.
Ax2
Ax3a
Line 4
Line 5
Line 3
Line 6
CR
HG
GW4
GW5
PSN2
PSN3
PVC1
PVC2
SVC1
GW2
GW1
SVC1b
GW3
PSN1
Line 1
Line 2
Line 8
Line 7
Leased line
Ax4
Ax3b
Ax1
Leased line
PVC4
PVC3
Ax5
Figure F.5 Example of redundancy by using different gateways between PSNs

It is possible that any of the above-mentioned gateways is out of service (for example, GW1). That
means that the PVC1 and/or SVC1 are (is) out of service and CIDIN Centre 1 initiates a call
establishment procedure in order to set up a new SVC with CIDIN centre 2, following the L3B
configuration drawn up in the previous section.
In this way, SVC1b will be set up by using another gateway between PSN1 and PSN2 completely
transparent to the calling and called DTE.
F.4.2.3 On-line manipulations
The use of SVC through PSNs allows, as it was described above, the use of X.25 network facilities
(Hunt Group (HG), Call Redirection (CR)) as well as potential redundancy at the PSN accesses and the
use of different Gateways among PSNs.
That means that, in a remote CIDIN centre different activities can be performed without any operational
implication in the adjacent CIDIN centres:
-
Configuration/maintenance activities of X.25 PVCs and/or SVCs.
Configuration/maintenance activities on systems that could conform the remote CIDIN centre.
Appendix F
Sixth Edition
Page 10 of 13
14/04/2011
F.4.3
Implementation phases
In the case of having CIDIN centres connected to PSNs, it is recommended to follow the next approach:
1st PHASE: Any VCG consists of a PVC as a Primary-type VC and a single SVC as a
Secondary-type VC.
This has been the Network Configuration recommended previously. The VCG would be as follows:
Primary VC
Secondary VC
PVC
SVC
2nd PHASE: Use of a single SVC as a Primary-type VC.
Once SVCs are widely configured and used by CIDIN centres and the Operational staff is confident
about their use, it is proposed to go into this second phase, that consists of:
Primary VC
Secondary VC
SVC
In this way, in a normal situation only one SVC per VCG would be established between two adjacent
CIDIN centres, taking the maximum advantage of the features of X.25 SVCs.
F.5
SVC Set-up and Clearing
F.5.1
Timers
F.5.1.1 The Idle Timer

The Idle timer must be configured to be:
-
triggered when the transmission of all the data have been achieved,
stopped when the data transmission is resumed.
When the Idle timer elapses, the SVC shall be disconnected by sending a Clear request to the network
with the Clearing cause set to 00 (DTE originated).
A specific value must be configured to indicate that the timer is set to an infinite value, which leads to
not clearing the SVC.
Note.-: This value is called infinite long in the paragraph 4.1.13.1.6.
The Idle timer must be configurable per SVC, taking into account traffic requirements.
The length of the idle period is a configurable parameter. The minimum value should be 2*TMR +
TEM + T21 (X.25 DTE Call Request Response Timer) seconds. The value should be chosen so that an
optimum is achieved in minimising overhead caused by CLEAR/CALL REQUEST procedures and
avoiding unnecessary allocation of PSN resources.
F.5.1.2 The Call retry timer
The Call retry timer must be:
Appendix F
Triggered when a Call request is sent,
stopped when a Call connected is received originated by the Remote CIDIN Centre.
Sixth Edition
Page 11 of 13
14/04/2011

Note 1.- The Call retry timer plays its role particularly in the case of CIDIN Crossing call avoidance.
Note 2.- Though the Call retry timer is triggered by the same event as the T21 timer and the action
entailed is similar (generation of a Clear request), they are not managed by the same level.
The T21 timer value should be higher than the Call retry timer value.
F.5.2
Particularities of alarms
F.5.2.1 Two types of alarms can be distinguished:

-
The technical alarms with a detail information intended to specialist operators for investigation
purpose. These alarms should be streamed and saved in log files,
The operator alarms with a synthetic information such as: CIDIN SVC <svc name> connected or
CIDIN SVC <svc name> disconnected. These alarms should be real-time displayed or printed on
administration devices.
F.5.2.2 When a SVC is established:

-
an explicit information message should be generated indicating the context (e.g.: SVC
established),
an explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> connected.
F.5.2.3 In case of a Clear SVC due to a Call retry timer expiration, an explicit and an appropriate information
message should be generated indicating precisely the context (e.g.: Call retry timer elapsed). Because
of possible multiple and numerous attempts to re-establish a SVC, the number of times this information
is generated should be configurable to prevent the information support from being overloaded.
F.5.2.4 When a Call is Cleared by the network, an explicit and appropriate information message should be
generated indicating precisely the default (e.g.: Outgoing call cleared).
F.5.2.5 When it appends a CIDIN crossing call an explicit and appropriate information message should be
generated indicating precisely the context (e.g.: Incoming call refused: collision on CIDIN SVC <svc
name>).
F.5.2.6 When an incoming call is accepted:
-
An explicit and appropriate information message should be generated indicating precisely the
context (e.g.:
Incoming call accepted).
An explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> connected.
F.5.2.7 For three cases concerning an incoming call refused an explicit and appropriate information message
should be generated indicating precisely the context, which could be respectively:
-
Incoming call refused: unknown calling remote centre <name>,
Incoming call refused: <svc name> already connected,
Incoming call refused: collision on CIDIN SVC <svc name>
F.5.2.8 When the Idle timer elapses:

-
context (e.g.: Idle timer elapses for CIDIN SVC <svc name>).
An explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> disconnected.
F.5.2.9 When a SVC-type CIDIN exchange is disabled by an operator command:

-
Appendix F
context (e.g.: Invalidation of CIDIN SVC <svc name>).
Sixth Edition
Page 12 of 13
14/04/2011

-
F.5.2.10 When a closed SVC is validated by an operator command an explicit and appropriate information
message should be generated indicating precisely the context (e.g.: Validation of CIDIN SVC <svc
name>).
F.5.2.11 When a Clear indication is received:
-
An appropriate information message should be generated indicating precisely the default (e.g.:
Incoming clear indication for CIDIN svc <svc name>).
F.5.2.12 If the Calling address is not suitable, an explicit and appropriate information message should be
generated indicating precisely the default (e.g.: Incoming call address not allowed the svc <svc
name>).
F.5.3
Call re-establishment periodicity

The periodicity to attempt to re-establish the call should depend on a configurable timer and a
configurable number.
F.5.4
Specific diagnostic values for Clear packets

Different errors may lead to the generation of a CLEAR REQUEST packet by the Local CIDIN Centre
ports with the clearing cause code equal to 00and an appropriate clearing diagnostic code.
The recommended values for clearing diagnostic codes to be used in the CIDIN environment are
derived from the ISO 8208 standards
The clearing diagnostic codes that should be generated for a CLEAR REQUEST packet with clearing
cause code 00, are described in the following table:
Corresponding ISO 8208
origin reason
Decimal
value
Higher Level Initiated:

disconnection normal
Hex-decimal
value
CIDIN origin reason
F1
241
Operator disconnection
Higher level Initiated

Disconnection abnormal
Higher level Initiated:

Connection
rejection,
reason
unspecified
(permanent condition)
242
F2
242
245
F2
F5
Table F-1:
Note:
idle timer elapses (no message to

transmit)
Unknown Calling Address
Reception of an Interrupt packet.
Retry Timer elapses.
Already connected.
CLEAR Diagnostic Codes
The values listed in the table above are used to inform the operators.
No automatic action depending on CLEAR DIAGNOSTIC CODES are foreseen.
END of Appendix F
Appendix F
Sixth Edition
Page 13 of 13
14/04/2011
Appendix G X.25 PICS/PRL

This Appendix provides the PICS/PRL for the X.25 level 3 (CIDIN Network Layer 3a) profile for PVCs
and SVCs.
The requirements for the lower layers (Data Link Layer and Physical Layer) are laid down in the Annex
10.
G.1
Definitions
Profile:
A set of one or more base standards, and, where applicable, the

identification of chosen classes, subsets, options and parameters of those
base standards, necessary for accomplishing a particular function.
Profile Requirements
List (PRL):
The profile requirements are expressed in the form of conformance

requirements and are arranged in a tabular list format.
Protocol Implementation
Conformance
Statement
(PICS):
A statement denoting which capabilities have been implemented for a

protocol.
G.1.1
ITU-T and OSI X.25 Standards

In 1976 the International Consultative Committee recommended X.25 as the desired protocol for
Telegraphy and Telephony (CCITT). X.25 is a packet switched data network protocol which defines an
international recommendation for the exchange of data as well as control information between a user
device (host), called Data Terminal Equipment (DTE) and a network node, called Data Circuit
Terminating Equipment (DCE). X.25 utilises a Connection-Oriented service, which insures that packets
are transmitted in order.
The following standards were produced:

CCITT X.25 1976 (Orange Book)

CCITT X.25 1980 (Yellow Book)
CCITT X.25 1984 (Red Book)
CCITT X.25 1988 (Blue Book)
Since 1993 the CCITT is renamed into ITU-T (International Telecommunication Union). The most
recent ITU-T Recommendation X.25 (10/96) was revised by the ITU-T Study Group 7 and was
approved by the WTSC2 (05.10.96).
The matching OSI X.25 standard, which is the base standard for the CIDIN X.25 PRL, is:
ISO/IEC 8208:1993, Information Technology Data communications X.25 Packet Layer

Protocol for Data Terminal Equipment (3rd edition).
The initial ISO/IEC International Standard was based on the CCITT Red Book. Subsequent editions
also followed CCITT/ITU-T standards. The ISO/IEC 8208 and ITU X.25 are different in scope. The
CCITT/ITU-T specification specifies the behaviour of the DCE and a minimum set of requirements is
specified for the DTE. The OSI specification focus is on the DTE and interworking between DTEs
(including direct DTE-to-DTE) and contains additional guidance for DTEs.
World Telecommunication Standardization Conference.
Appendix G
Sixth Edition
Page 1 of 15
14/04/2011
G.1.2
Usage and explanation

By mandating a X.25 profile for CIDIN using a PRL the interoperability on X.25 level with X.25
networks and between CIDIN Centres using different X.25 versions as well can be guaranteed.
To evaluate conformance of a particular implementation, it is necessary to have a statement of which
capabilities and options have been implemented. Such a statement is called a PICS. This statement is
normally made by the supplier of the system.
New implementations in a Centre shall be validated against the PRL and a PICS shall be completed.
Deviations from the PRL shall be agreed on a bilateral basis only3.
G.1.3
Notation
The following notations from ISO/IEC TR 10000-1 are used in the PRL to indicate the status of
features:
m:
mandatory
o:
optional
O.<n>
optional, but support of at least one of the group of options labelled by the
same numeral <n> is required
not applicable (i.e. logically impossible in the scope of the profile)
x:
excluded
Notes.1) Two-character combinations may be used, in which case the first character refers to the static
(implementation) status, and the second to the dynamic (use); thus 'mo' means 'mandatory to
be implemented, optional to be used'.
2) The 'o.<n>' notation is used to show a set of selectable options (i.e. at least one of the set must
be implemented) with the same identifier n.
3) A feature marked 'x' may nonetheless be part of an implementation so long as it is not used
when the implementation is operating in conformance with the profile.
4) Use of features marked 'x' would require bilateral agreement. In this event, the status of the
features should be revised as they may be of interest to other implementations.
The following predicate notation is used:
<predicate>:
<predicate>:
introduces a group of items, all of which are conditional on <predicate> (the extent of
the group is shown by the layout).
introduces a single item which is conditional on <predicate>.
Note. - In each case, the predicate may be the identifier of a profile feature, or a Boolean combination
of predicates ('' is the symbol for logical negation).
Base standard requirements are shown using the equivalent notations in upper case (i.e. M, O, O.<n>,
X).
G.1.4
References
This profile references the following protocol specifications:
It shall be assured that such deviations do not have influence on the communication with other partners
(especially in the area of SVCs certain parameters are system wide).
Appendix G
Sixth Edition
Page 2 of 15
14/04/2011
G.2
EUR CIDIN Manual Second Edition (August 2002)

Connection-mode Network Protocol using ISO/IEC 8208.
Conformance Statement
Table G-1:
Conformance Overview
Supplier
Contact point for queries about the PICS
Implementation name/version
Machine name/version
Operating system name/version
Other hardware and operating systems claimed
System name (if applicable)
Date of statement
Have the features of the base standards been
implemented in accordance with requirements
of this PRL?
Yes o
NOTE. - Failure to respond 'Yes' to all of these questions indicates a failure of conformance to this
profile
G.3
Network Layer Requirements

The PRLs given in this section are based on the PICS proforma for ISO/IEC 8208:1993 (Annex B). The
entries in the 'References' column under 'Base standard features' of the following tables are references to
clauses in that standard.
Appendix G
Sixth Edition
Page 3 of 15
14/04/2011
G.4
General DTE Characteristics

Table G-2:
ISO/IEC 8208:1993
Base Standard Features
Item
Service supported
Vs
virtual call
Vp
permanent virtual circuit
References
Status
EUR CIDIN Manual

Profile Features
References
Status
O.1
O.1
4.1
4.1
m
m
O.2
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
o.2
Ec/3
Environments supported
DTE/DCE(1993)
Ec/8
DTE/DCE(1988)
O.2
Ec/4
DTE/DCE(1984)
O.2
Ec/0
DTE/DCE(1980)
O.2
Et/t
DTE/DTE in fixed role as DTE
O.2
Et/c
DTE/DTE in fixed role as DCE
Vs: O.2
Et/d
DTE/DTE with dynamic role selection
M8
Packet sequence numbering supported

Modulo 8
M128
Rna
Reference Number optional user facility

supported, for alternative Logical Channel
Identifier assignment
- without reversion to use of logical
channel ranges
-with possible reversion to use logical
channel ranges
RNb
Appendix G
3, 3.2
Modulo 128
o.2
o.2
o.2
o.2
o.2
4.5
Vs: O.2
13.2,
12.1.1,
Table 3
13.2,
12.1.1,
Table 3
13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
13.29.2.1
O.3
O.3
Et: O
Et: X
Et: O
Et: X
13.29.2.1
Sixth Edition
Page 4 of 15
14/04/2011
G.5
Procedures, Packet Types and Packet Formats.

Table G-3:
Packet Layer Functions Independent of Logical Channels
ISO/IEC 8208:1993
Item
Packet Layer Functions Independent of Logical
Channels
Z2s
Are the following packet layer functions

supported:
Sending diagnostic packet
Z4i
Initiating On-line Facility Registration:

-
Z4r
send REGISTRATION REQUEST

receive REGISTRATION
CONFIRMATION
Responding to On-line Facility Registration:
receive REGISTRATION REQUEST
send REGISTRATION
CONFIRMATION
Appendix G
EUR CIDIN Manual

Profile Features
References
Status
References
Status
12.7, Table 24
Et: O
Et: X
O
ox
Et: O
13.1,
13.1.1.1,
13.1.1.3, 13.1.1.4
12.9.1
12.9.2, Table 10
13.1,
13.1.1.1,
13.1.1.4
12.9.1
12.9.2, Table 10
Sixth Edition
Page 5 of 15
14/04/2011

Table G-4:
ISO/IEC 8208:1993
Item
Call Setup
Are outgoing Virtual Calls supported:
S1a
S1b
S1c
SP1b
- Fast Select, no restriction on response?

- Fast Select with restricted response?
- non-Fast Select?
CALL REQUEST, basic format
SP1e
send CALL REQUEST, extended format
SP2b
SP2e
receive CALL CONNECTED, basic format

receive CALL CONNECTED, extended
format
Is alternative addressing supported for
outgoing Virtual Calls:
- using A = 1 and expanded Address
Block format?
- using the Called Address Extension
Facility?
Are incoming Virtual Calls supported:
S2a
S2b
S2c
SP4b
- Fast Select with acceptance possible?

- Fast Select, always cleared?
- non-Fast Select with acceptance
possible?
- non-Fast Select, always cleared?
receive INCOMING CALL, basic format
receive INCOMING CALL, extended
format
send CALL ACCEPTED, basic format
SP4e
send CALL ACCEPTED, extended format
DN1
DN2
Is D-bit negotiation supported:

- for outgoing Virtual Calls
- for incoming Virtual Calls
S2d
SP3b
SP3e
Call Setup
References
5.2.1,
5.2.5,
Table 33
5.2.4, 13.16
13.16
5.2.4
12.2.3.1
12.2.3.1,
12.2.3.2
12.2.4.1
12.2.4.1,
12.2.4.2
13.28
13.28.2.1,
12.2.1.2
13.28.2.2.
Status
O
O
O
S1c: M
S1ab: O.4
S1ab: O.4
S1ac: M
S1a: M
EUR CIDIN Manual

Profile Features
References Status
4.2.7
x
4.2.7
Ec/3: O
Ec/3: X
Ec/3: O
Ec/3: X
O
O
O
m
m
x
m
12.2.4.1,
12.2.4.2
O
S2: M
S2ab: M
S2axc: O.5
S2c: M
S2axc: O.5
S2axc: O.5
S2anc: O
6.3
6.3
S1ac: O
S1ac: O
5.2.2, 5.2.5,
Table 33
5.2.3, 13.17
13.17
5.2.3
5.2.3
12.2.3.1
12.2.3.1,
12.2.3.2
12.2.4.1
4.2.7
Sixth Edition
Page 6 of 15
x
x
Note. - The D-bit shall always be negotiated to 0.
Appendix G
x
x
m
m
14/04/2011

Table G-5:
ISO/IEC 8208:1993
Item
Call Clearing
Call Clearing
References
Status
EUR CIDIN Manual

Profile Features
References
Status
Is call clearing supported, for:

- response to indication of clearing
- aborting an outgoing Virtual Call attempt?
- rejecting an incoming Virtual Call?
5.5.4, Table 33
5.5.2
5.4, 5.5.1, 5.5.3
5.3, 5.5.1, 5.5.3
5.5.1, 5.5.3
12.2.5.1
12.2.5.1, 12.2.5.2
Cany: M
Cany: M
4.2.2.3
12.2.6.1
12.2.6.1, 12.2.6.2
C1: M
C1rn: M
4.2.2.3
m
x
CP3b
- originating clearing of an established

Virtual Call?
receive CLEAR INDICATION, basic format
receive CLEAR INDICATION, extended
format
send CLEAR CONFIRMATION, basic format
send CLEAR CONFIRMATION, extended
format
send CLEAR REQUEST, basic format
O
S1: O
S2bd: M
S2acxbd:
O
O
12.2.5.1
4.2.2.3
CP3e
send CLEAR REQUEST, extended format
12.2.5.1 12.2.5.2
CP4b
receive CLEAR CONFIRMATION, basic

format
receive CLEAR CONFIRMATION, extended
format
12.2.6.1
C2a: M
C2bcxa:
O.6
C2bcxa:
O.6
C2axbc: X
C2: M
12.2.6.1, 12.2.6.2
C2rnci: M
C1
C2a
C2b
C2c
CP1b
CP1e
CP2b
CP2e
CP4e
Table G-6:
ISO/IEC 8208:1993
Item
Resetting of Logical Channels
RSi
RSr
Is resetting supported:
as initiator?
send RESET REQUEST
receive RESET CONFIRMATION/
INDICATION
as responder?
receive RESET INDICATION
send RESET CONFIRMATION
Appendix G
m
o
m
4.2.2.3
Resetting of Logical Channels
References
8, 8.4, Table 34
8.1, 8.3
12.5.1
12.5.2, 12.5.1
8.2
12.5.1
12.5.2
Sixth Edition
Page 7 of 15
Status
EUR CIDIN Manual

Profile Features
References
Status
4.1.2, 4.1.7
mm
4.1.2, 4.1.7
mm
14/04/2011

Table G-7:
ISO/IEC 8208:1993
Item
Error Procedures (Virtual Call Service)
References
5.2.1, 5.4, 8.1,
Table 33
Is ERROR-C procedure:
W1a
W1b
clear the Virtual Call?

restart the packet layer?
Is ERROR-R procedure for virtual calls:
W2sc
restart the packet layer?
ISO/IEC 8208:1993
Item
Interrupt Transfer
Is
Is sending interrupts supported?
send INTERRUPT REQUEST
receive INTERRUPT CONFIRMATION
Is receiving interrupts supported?
receive INTERRUPT INDICATION
send INTERRUPT CONFIRMATION
Table G-9:
ISO/IEC 8208:1993
Item
Sending Data
DS1
Is sending of DATA packets supported?
DS2
DS4a
DS4b
DS5a
DS5b
DS6
DS7a
DS7b
DS8
Are the following supported:

- send-window rotation on receiving updated
P(R) values?
- sending M = 0 in DATA packets?
- sending M = 1 in DATA packets?
- sending Q = 0 in DATA packets?
- sending Q = 1 in DATA packets?
- responding to packet retransmission requests
(received
REJECT packets)?
- Window Rotation Timer procedure?
- ERROR-R action on expiry
- packet retransmission on expiry
- discard of over-length flow control packets
(instead of ERROR-R)?
Appendix G
Status
EUR CIDIN Manual

Profile Features
References
Status
O.7
O.7
m
x
O.8
6.3, 6.4, 6.6,

6.8.1,
6.8.2,
7.1.3, 7.1.4, 8.2,
11.2.1,
13.4.1,
Tables 34-36
Table G-8:
Ir
Error Procedures
Interrupt Transfer
References
6.8, 6.8.1, 6.8.3,
Table 35
12.3.2
12.3.3
6.8, 6.8.2, 6.8.3
Table 35
12.3.2
12.3.3
Status
O
EUR CIDIN Manual

Profile Features
References
Status
ox
Sending Data
References
6, 6.1, 7.1.1,
7.1.2,
7.1.3,
12.3.1
Status
O
7.1, 7.1.2, 7.1.3
6.4, 6.5, 6.7

6.4, 6.5, 6.7
6.6
6.6
13.4.2 12.8
M
O
O.10
O.10
Et: O
11.2.1(a)
11.2.1(b)
O
Et: O
Et: X
O
Table 36 Note 2
Sixth Edition
Page 8 of 15
EUR CIDIN Manual

Profile Features
References
Status
mm
mm
4.1.2.3 c
4.1.2.3 c
mm
x
mm
ox
ox
ox
ox
14/04/2011

Table G-10: Receiving Data
ISO/IEC 8208:1993
Item
Receiving Data
DR1
Is receiving of DATA packets supported?
DR2
DR3
DR4b
DR5a
DR5b
DR6
DR7a
DR7b
DR7c
DR8a
DR8b
DR8c
DR9
Are the following supported:

- receive-window rotation by sending
updated P(R)
values?
- flow control by sending RECEIVE NOT
READY
and RECEIVE READY?
- receiving M = 1 in DATA packets?
- receiving Q = 0 in DATA packets?
- receiving Q = 1 in DATA packets?
- requesting packet retransmission by sending
REJECT packets?
- recovery from receipt of DATA packets
containing invalid P(S), by:
- ERROR-R action?
- requesting packet retransmission ?
- ignoring the packet and waiting for a correct
retransmitted packet?
- recovery from receipt of DATA packets
with
invalid User Data field, by:
- ERROR-R action?
- requesting packet retransmission?
- ignoring the packet and waiting for a correct
retransmitted packet?
- Window Status Transmission Timer
procedure?
EUR CIDIN Manual

Profile Features
References
Status
mm
References
6, 6.1, 6.2, 7.1.1,
7.1.2,
7.1.3,
12.3.1
Status
O
7.1.2, 7.1.3
mm
7.1.5,
7.1.6,
12.4.1, 12.4.2
mm
6.4, 6.5, 6.7

6.6
6.6
13.4.1, 12.8
O
O.11
O.11
O
11.3(a)
11.3(b)
11.3(c)
O.12
O.12
O.12
mm
ox
ox
11.3(a)
11.3(b)
11.3(c)
O.13
O.13
O.13
mm
ox
ox
11.2.2
ox
4.1.2.3 c
ox
mm
ox
Table G-11: Delivery Confirmation

ISO/IEC 8208:1993
Item
Delivery Confirmation
DC
Is Delivery Confirmation supported?
Appendix G
References
6.3, 6.5,
7.1.4
Sixth Edition
Page 9 of 15
6.7,
Status
O
EUR CIDIN Manual

Profile Features
References
Status
x
14/04/2011
G.6
Miscellaneous Features and Options

Table G-12: Values of Cause and Diagnostic Codes
ISO/IEC 8208:1993
Item
Values of Cause and Diagnostic Codes
In RESTART REQUEST packets sent:
Y1d
Y2b
Y3d
Y4b
Y5d
Y6b
References
12.6.1.1,
12.6.1.2,
Tables 24-25
- Cause = 128, private diagnostic codes

In RESTART INDICATION packets received:
- Cause not 0 or 128, any diagnostic code
value
In CLEAR REQUEST packets sent:

In CLEAR INDICATION packets received:
value
In RESET REQUEST packets sent:

In RESET INDICATION packets received:
O.14
ox
EC: M
EC: O
O.15
ox
EC: M
EC: O
O.16
ox
EC: M
EC: O
12.6.1.1, Table 9,
12.6.1.2
12.2.3.1.1,
12.2.3.1.2,
Tables 24-25
12.2.3.1.1, Table
7 12.2.3.1.2,
12.5.1.1,
12.5.1.2,
Tables 24-25
12.5.1.1, Table 8,
12.5.1.2

value
Appendix G
Status
EUR CIDIN Manual

Profile Features
References
Status
Sixth Edition
Page 10 of 15
14/04/2011
G.7
Facilities
Table G-13: Facilities Sent in CALL REQUEST Packets
ISO/IEC 8208:1993
Item
Facilities Sent in CALL REQUEST Packets
FS1pi
Flow Control Parameter Negotiation, packet
size
FS1wi
Flow Control Parameter Negotiation, window
size
FS2ib
Basic Throughput Class Negotiation
FS2ie
Extended Throughput Class Negotiation
FS3b
Closed User Group Selection, basic format
FS3e
FS5
FS6a
FS6b
FS6c
Closed User Group Selection, extended

format
Closed User Group With Outgoing Access
Selection, basic format
Selection, extended format
Bilateral Closed User Group Selection
Fast Select
Reverse Charging
ICRD Status Selection
FS7i
Network User Identification
FS8i
FS9b
Charging Information, requesting service

RPOA selection, basic format
FS9e
RPOA selection, extended format
FS12
FS99i
Transit Delay Selection and Indication

Local non-X.25 facilities, following Facility
Marker
Remote non-X.25 facilities, following
Facility Marker
Facility Marker, CCITT-specified DTE
facilities
Calling Address Extension
Called Address Extension
Minimum Throughput Class Negotiation,
basic format
extended format
End-to-end Transit Delay Negotiation
Expedited Data Negotiation
Priority
Protection
FS4b
FS4e
FS98i
FS20i
FS21i
FS22i
FS23ib
FS23ie
FS24i
FS25i
FS26i
FS27i
Appendix G
EUR CIDIN Manual

Profile Features
References
Status
x
References
13.12, 15.2.2.1.1
Status
O
13.12, 15.2.2.1.2
13.13, 15.2.2.2.1,
Table 20a
13.13, 15.2.2.2.2,
Table 20b
13.14.6,
15.2.2.3.1
13.14.6,
15.2.2.3.2
13.14.7,
15.2.2.4.1
13.14.7,
15.2.2.4.2
13.15, 15.2.2.5
13.16, 15.2.2.6
13.18, 15.2.2.6
13.25.4.2,
15.2.2.6
13.21, 13.21.3,
15.2.2.7
13.22, 15.2.2.8.1
13.23, 13.23.2,
15.2.2.9.1
13.23, 13.23.2,
15.2.2.9.2
13.27, 15.2.2.13
15.1, Table 18
O
O
O
O
x
x
x
x
O
O
x
x
O
O
x
x
15.1, Table 18
15.1
x
x
x
O
O
O
O
x
x
x
x
14.1, 15.3.2.1
14.2, 15.3.2.2
14.3, 15.3.2.3.1,
Table 20a
14.3, 15.3.2.3.2,
Table 20b
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6
Sixth Edition
Page 11 of 15
14/04/2011

Table G-14: Facilities Sent in CALL ACCEPT Packets
ISO/IEC 8208:1993
Item
Facilities Sent in CALL ACCEPT Packets
FS1pr
size
FS1wr Flow Control Parameter Negotiation, window
size
FS2rb
FS2re
FS7r
Network User Identification
FS8r
FS10r
FS99r
Charging Information, requesting service

Called Line Address Modified Notification
Marker
Facility Marker
facilities
Priority
Protection
FS98r
FS20r
FS22r
FS24r
FS25r
FS26r
FS27r
References
13.12, 15.2.2.1.1,
Table 13
13.12, 15.2.2.1.2,
Table 13
13.13, 15.2.2.2.1,
Table 20a
13.13, 15.2.2.2.2,
Table 20b
13.21,
13.21.3
15.2.2.7
13.22, 15.2.2.8.1
13.26, 15.2.2.12
15.1 Table 18
Status
O
EUR CIDIN Manual

Profile Features
References
Status
x
O
O
O
x
x
x
15.1, Table 18
15.1
14.2, 15.3.2.2
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6
O
O
O
O
O
x
x
x
x
x
Table G-15: Facilities Sent in CALL REQUEST Packets

ISO/IEC 8208:1993
Item
Facilities Sent in CALL REQUEST Packets
FS10d
FS13
Call Deflection Selection
FS99d
FS98d
FS20d
FS22d
Appendix G

Marker
Facility Marker
facilities
EUR CIDIN Manual

Profile Features
References
Status
x
x
References
13.26, 15.2.2.12
13.25.2.2,
15.2.2.10
15.1, Table 18
Status
O
O
O
15.1, Table 18
15.1
14.2, 15.3.2.2
Sixth Edition
Page 12 of 15
14/04/2011

Table G-16: Facilities Received in INCOMING CALL Packets
ISO/IEC 8208:1993
Item
Facilities Received in INCOMING CALL
Packets
FR1pi
size
FR1wi
Flow Control Parameter Negotiation, window
size
FR2ib
FR2ie
FR3b
Closed User Group Selection, basic format
FR3e
FR5
FR6a
Closed User Group Selection, extended

format
Selection, basic format
Selection, extended format
Bilateral Closed User Group Selection
Fast Select
FR6b
Reverse Charging
FR11
Call Redirection or Call Deflection

Notification
Marker
facilities
Calling Address Extension
basic format
extended format
Priority
Protection
FR4b
FR4e
FR12i
FR99i
FR20i
FR21
FR22i
FR23b
FR23e
FR24i
FR25i
FR26i
FR27i
Appendix G
EUR CIDIN Manual

Profile Features
References
Status
References
Status
13.12, 15.2.2.1.1
13.12, 15.2.2.1.2
13.13, 15.2.2.2.1
Table 20a
13.13, 15.2.2.2.2
Table 20b
13.14.6,
15.2.2.3.1
13.14.6,
15.2.2.3.2
13.4.7, 15.2.2.4.1
13.4.7, 15.2.2.4.2
13.15, 15.2.2.5
13.16,
13.17,
15.2.2.6
13.18,
13.19,
15.2.2.6
13.25.3,
15.2.2.11
13.27, 15.2.2.13
15.1, Table 18
O
O
x
x
O
O
x
x
15.1
x
x
x
O
O
O
O
x
x
x
x
14.1, 15.3.2.1
14.2, 15.3.2.2
14.3, 15.3.2.3.1,
Table 20a
14.3, 15.3.2.3.2,
Table 20b
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6
Sixth Edition
Page 13 of 15
14/04/2011

Table G-17: Facilities Received in CALL CONNECT Packets
ISO/IEC 8208:1993
Item
Facilities Received in CALL CONNECT
Packets
FR1pr
size
FR1wr Flow Control Parameter Negotiation, window
size
FR2rb
FR2re
FR10r
FR12r
FR99r

Marker
facilities
Priority
Protection
FR20r
FR22r
FR24r
FR25r
FR26r
FR27r
EUR CIDIN Manual

Profile Features
References
Status
References
Status
13.12, 15.2.2.1.1,
Table 14
13.12, 15.2.2.1.2,
Table 14
13.13, 15.2.2.2.1,
Table 20a
13.13, 15.2.2.2.2,
Table 20b
13.26, 15.2.2.12
13.27, 15.2.2.13
15.1, Table 18
O
O
O
x
x
x
15.1
14.2, 15.3.2.2
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6
O
O
O
O
O
x
x
x
x
x
Table G-18: Facilities Received in CLEAR INDICATION Packets

ISO/IEC 8208:1993
Item
Facilities Received in CLEAR INDICATION
Packets
FR8ad
Charging information, monetary unit
FR8bd
Charging information, segment count
FR8bc
Charging information, call duration
FR10d
FR99d
Marker
FR20d
facilities
FR22d
EUR CIDIN Manual

Profile Features
References
Status
References
Status
13.22, 15.2.2.8.2
13.22, 15.2.2.8.3
13.22, 15.2.2.8.4
13.26, 15.2.2.12
15.1, Table 18
O
O
O
O
O
x
x
x
x
x
15.1
14.2, 15.3.2.2
Table G-19: Facilities Received in CLEAR CONFIRMATION Packets

ISO/IEC 8208:1993
Item
Facilities
Received
in
CLEAR
CONFIRMATION Packets
FR8af
Charging information, monetary unit
FR8bf
Charging information, segment count
FR8cf
Charging information, call duration
Appendix G
References
Status
13.22, 15.2.2.8.2
13.22, 15.2.2.8.3
13.22, 15.2.2.8.4
O
O
O
Sixth Edition
Page 14 of 15
EUR CIDIN Manual

Profile Features
References
Status
x
x
x
14/04/2011
G.8
Parameter Values and Ranges

Table G-20: Parameter Values and Ranges
ISO/IEC 8208:1993
Item
Parameter Values and Ranges
What values are supported:
V1s
- Default packet sizes (sending)?
References
Status
16.2.2.5
V1r
Default packet sizes (receiving)?
16.2.2.5
V2s
Default window sizes, sending?
16.2.2.6
V2r
Default window sizes, receiving?
16.2.2.6
16, 32, 64,

128, 256, 512,
1024, 2048,
4096 octets
16, 32, 64,
128, 256, 512,
1024, 2048,
4096 octets
(M8: in the
range 1-7)
(M8: in the
range 1-7)
EUR CIDIN Manual

Profile Features
References
Status
4.1.1.4 a
256
4.1.1.4 a
256
4.1.1.4 b
4.1.1.4 b
END of Appendix G
Appendix G
Sixth Edition
Page 15 of 15
14/04/2011
Appendix H Centre Switching Capacity
H.1
Introduction
H.1.1.1
To know the switching capacity of COM Centres in the EUR Region is regarded as extremely
important as this, apart from the identification of potential COM Centre problems, helps to
continuously improve the long-term operation of the EUR AFS.
H.1.1.2
A test equipment (test harness) provided for this purpose, shall be able to measure the switching
capacity of a COM Centre in accordance with specified test principles and performance values.
H.1.1.3
The purpose of this Appendix is to define the high-level requirements such test equipment shall
fulfil.
H.2
Switching Capacity Measurement
H.2.1
Test Harness
H.2.1.1
Figure H.1 shows the test harness of a COM centre, which may consist of multiple systems.
COM centre under test

(SUT)
(Fast)
Ethernet
serial lines
V.24/V.11
CIDIN
X.25
ASYNC
TCP/IP
Test System 1
serial lines
V.24/V.11
CIDIN
X.25
ASYNC
(Fast)
Ethernet
TCP/IP
Test System n
serial lines
V.24/V.11
CIDIN
X.25
ASYNC
(Fast)
Ethernet
TCP/IP
Test System n+1
Figure H.1 Test Harness

H.2.1.2
The test harness shall emulate real life conditions to the maximum extent possible:
Appendix H
The test equipment shall provide standard serial interfaces (V.24/V.11) and, if applicable, (Fast)
Ethernet LAN interfaces.
CIDIN, X.25 and the character-oriented asynchronous protocol (ASYNC) shall be supported on
serial connections, TCP/IP on LAN connections.
Sixth Edition
Page 1 of 4
14/04/2011
H.2.2
Test Principles and Performance Values
H.2.2.1
Table H-1 gives an overview of the test principles and performance values considered along with the
resulting requirements the system under test and the test equipment have to fulfil.
Table H-1:
No.
Requirements to be fulfilled by COM Centre and Test Equipment
Test Principles /
Performance Values
Requirements
COM Centre
Under Test
Requirements
Test Equipment
1.
Tests to be performed on a system

that behaves correctly
Approved message
Approved test equipment shall be used.
handling system shall be Interfaces should be of real-life type
tested.
2.
The system is not used for other

purposes during capacity tests
COM Centre shall not be Test equipment shall be linked with the
charged with any other
COM Centre interfaces. Therefore the test
than test traffic
equipment shall provide
COM Centre shall be
exclusively connected to
test equipment
a flexible number of V24 (RS232)

and/or V11 (X.21) interfaces,
a flexible number of (Fast) Ethernet

interfaces
CIDIN/X.25/HDLC protocol stack

(serial V.24/V.11 interfaces)
Asynchronous Byte protocol stack

(serial V.24 interfaces)
TCP/IP protocol stack

(Ethernet Interfaces)
The quantity and kind of the interfaces

used shall provide the same overall
bandwidth as the operational COM Centre
connections.
3.
Only the stable equilibrium

situation is taken into account (e.g.
one hour duration of traffic load)
4.
CPU load indication and transit

times are not taken into account
5.
Input/output ratio 1:3 (1 incoming

message generates 3 outgoing
messages)
6.
COM Centre shall not

show exceptional or
overload conditions.
Test equipment shall not show any

exceptional or overload conditions (lack of
resources in terms of memory, disk space,
increasing message queues, etc.)
COM Centre shall be

configured accordingly
Test equipment shall provide the following

possibilities to configure test messages:
-
up to 21 AFTN addresses,
AFTN
AFTN Priority,
CIDIN
AFTN Originator,
CIDIN Relay Packet (only if

applicable)
some message text,
message length up to 64 kbytes,
test messages shall be storable as

templates.
2 out of 3 CIDIN packets are relay

packets
Appendix H
COM Centre shall be

configured accordingly
Sixth Edition
Page 2 of 4
14/04/2011
No.
7.
Test Principles /
Performance Values
Different, standardized message
lengths (text length without AFTN
header) shall be used:
Requirements
COM Centre
Under Test
COM Centre shall be
able to handle AFTN
messages longer than
2.100 bytes
200 bytes (share: 20%)

Requirements
Test Equipment
Test equipment shall be able to
-
generate and transmit AFTN messages

via AFTN circuits and via CIDIN
connections;
receive AFTN messages on AFTN

circuits and CIDIN connections
(message sink);
generate the required mix of messages

and transmit them to COM Centre;
exactly specify the amount of

messages to be generated and
transmitted:
frequency (e.g. messages/minute),
overall number of messages to be
transmitted,
continuous message transmission;
provide statistics about the amount of

messages transmitted/received.
H.2.3
Method of Capacity Measurement
H.2.3.1
The switching capacity of a COM Centre is defined as the maximum number of messages that can
be permanently switched, i.e. the COM Centre remains fully operable and shows no overload or
exceptional behaviour under this switching load.
H.2.3.2
COM Centres have different architectures and work in distinct environments; hence no standardised
test scenario can be applied. This means that the test harness has to be configured individually for
each COM Centre in accordance with the requirements defined in Table H-1.
H.2.3.3
In order to quantify the actual amount of switched messages, the test equipment shall record and
provide statistics about the messages transmitted to/received from the COM Centre under test.
H.2.3.4
Measurement method:
H.2.3.5
The COM Centre under test is charged with a certain number of messages that were generated
following the profile as defined in Table H-1/points 5-9. The message load is generated by applying
a defined transmission frequency.
H.2.3.6
After one hour of testing, the statistical values recorded by the test equipment shall be checked
against the expected values. The expected values can be calculated from the message profile
and the transmission frequency used. If measured values and calculated values do not correspond
and there are no problems with the lines, the COM Centre under test is not able to cope with the
message load.
Appendix H
Sixth Edition
Page 3 of 4
14/04/2011
H.3
Realisation
H.3.1
The system shall be based on state-of-the-art PC-AT-compatible hardware and a standard operating
system (e.g. MS Windows, Unix etc.).
END of Appendix H
Appendix H
Sixth Edition
Page 4 of 4
14/04/2011

Eur Cidin Manual v6 - 0

Uploaded by

Document Information

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

Eur Cidin Manual v6 - 0

Uploaded by

Copyright:

Available Formats

ICAO EUR DOC 005

INTERNATIONAL CIVIL AVIATION ORGANIZATION

EUR CIDIN MANUAL

Published by the European and North Atlantic Office of ICAO

EUR CIDIN MANUAL

Record of Amendments and Corrigenda

EUR CIDIN MANUAL

Amendments to CIDIN Manual

Introduction of guidance material for CIDIN Implementation

Major review, including update of the Manual to take account

Review of testing terminology as well as test cases in

Introduction of Network management application interface

New edition to consolidate 1st and 2nd Amendments.

New edition to introduce Chapters 12 and 13 and Appendix H.

New edition to introduce Chapter 6 Transport Layer,

EUR CIDIN MANUAL

EUR CIDIN MANUAL

EUR CIDIN MANUAL

EUR CIDIN MANUAL

The objectives of the CIDIN manual are to:

Provide guidance to implementers and users,

Define uniquely the requirements placed on an implementation of the CIDIN

Review the rationale of the protocols,

Define tests to be performed on protocol implementations, and

Describe the interfaces of applications to CIDIN.

The manual is organised into the following format:

Chapter 2 describes the physical layer.

Chapter 3 describes the link layer

Chapter 4 describes the network layer. Appendix F contains guidance

Chapter 5 describes the CIDIN network layer. Appendix G contains detailed

Chapter 6 describes the transport layer. Appendix E contains information on

Chapter 7 describes the AFTN interface.

Chapter 8 describes the statistical requirements for CIDIN.

Chapter 9 describes the test strategy for routing implementations. Appendix D

Chapter 10 provides information relating to the operation of the CIDIN network.

Chapter 11 provides information relating to Quality of Service.

EUR CIDIN MANUAL

A Common Network for Various Applications

The conventional AFTN represents a large investment in equipment and operations.

interactive computer applications (response times in seconds),

conversational mode between terminals (session relationship between users),

transmission of facsimile data (binary data, not characters), and

file transfer applications (large messages and data volumes)

The installation and maintenance of networks dedicated to one special application is an

Air Traffic Services,

Aeronautical Information Service,

Operational Meteorological Service and

Search and Rescue Service.

Although ICAO is concerned with international data interchange standards, individual

EUR CIDIN MANUAL

The Reference Model for Protocol Layers

Current international communications protocol standardisation work is based on the

A system, which can communicate with other systems, is an implementation of a collection

The separation of communication functions into layers with reduced

EUR CIDIN MANUAL

The Functions of the Layers

EUR CIDIN MANUAL

The CIDIN Protocols

EUR CIDIN MANUAL

routing and relay

Relay centre performing PVC termination functions in level 3a and

Figure 1.2 The Functions of CIDIN Centres Related to Protocol Layers

EUR CIDIN MANUAL