ISO/IEC 9314-25:1998

Information technology - Fibre Distributed Data Interface (FDDI) - Part 25: Abstract test suite for FDDI - Station Management Conformance Testing (SMT-ATS)

This part of ISO/IEC 9314 contains the Abstract Test Suites for the Fiber Distributed Data Interface (FDDI) token ring Station Management (SMT) layer protocol. The SMT Protocol is extensive and very complex. In the development process, the protocol was broken into six separate areas. Those areas dealt with Physical Connection Management (PCM), Entity Coordination Management (ECM) Ring Management (RMT), Configuration Management (CMT), Frame Based Management (FBM) and Management Information Base (MIB). This SMT ATS is divided along the same boundaries, with the exception that PCM and ECM are combined. Those two concepts are tested together. The formal description language used for Abstract Test Suite (ATS) development is Tree and Tabular Combined Notational (TTCN) and is defined in ISO 9646Framework. TTCN is intended for higher layer protocol testing and requires the use of discreet Protocol Data Units (PDUs). The TTCN notation is used in the test cases for RMT, FBM and MIB. It cannot be used for PCM, ECM and CFM. These three protocols use line states as the method of conveying information. The TTCN (P) is similar in structure to TTCN but changes the paradigm from PDUs to line states. A description of the concept of TTCN (P) can be found in the beginning of section 6, PCM.

Technologies de l'information — Interface de données distribuées sur fibre (FDDI) — Partie 25: Suite de test abstraite pour FDDI — Contrôle de conformité de gestion de station (SMT-ATS)

General Information

• Status: Published
• Publication Date: 30-Sep-1998
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1/SC 25 - Interconnection of information technology equipment
• Drafting Committee: ISO/IEC JTC 1/SC 25 - Interconnection of information technology equipment
• Current Stage: 9093 - International Standard confirmed
• Start Date: 13-Jul-2018
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO/TR 25107:2006 - Non-destructive testing - Guidelines for NDT training syllabuses
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 9314-25:1998 - "Information technology - Fibre Distributed Data Interface (FDDI) - Part 25: Abstract test suite for FDDI - Station Management Conformance Testing (SMT‑ATS)" defines the Abstract Test Suites (ATS) used to verify conformance of the FDDI Station Management (SMT) layer. The standard breaks SMT testing into functional areas - Physical Connection Management (PCM), Entity Coordination Management (ECM), Configuration Management (CFM), Ring Management (RMT), Frame Based Management (FBM) and Management Information Base (MIB) - and provides formal test descriptions, timing definitions and PIXIT proformas for test implementation.

Key topics and requirements

• Scope of testing: Comprehensive ATS for SMT functionality including PCM+ECM (combined), CFM, RMT, FBM and MIB, addressing station initialization, configuration, ring recovery, connection control and management information.
• Test languages: Uses TTCN (Tree and Tabular Combined Notation) for higher‑layer protocol tests (RMT, FBM, MIB) that depend on discrete Protocol Data Units (PDUs). For PCM, ECM and CFM - which rely on line states rather than PDUs - the document uses TTCN(P), a line‑state adaptation of TTCN.
• Timers and parameters: Defines a set of critical timers (T_REQ/TTRT, T_Max, D_Max, T_Non_Op, RM_React, T_Jam, etc.) and PCM‑specific timing constraints (TB_Min, TB_Max, MI_Max, C_Min, etc.) that must be initialized prior to testing.
• Test artifacts and annexes: Includes detailed test cases, tester configurations, tables of configuration summaries and normative PIXIT proformas for RMT and MIB to capture implementation specifics required by test houses.
• Conformance methodology: Aligned with ISO/IEC 9646 framework for conformance testing; the ATS is the authoritative suite for SMT conformance claims.

Practical applications and users

• Who uses it: Protocol implementers, network equipment vendors, independent test laboratories, quality assurance teams and certification bodies performing FDDI SMT conformance and interoperability testing.
• Why it matters: Ensures consistent, repeatable verification of station management behaviors - essential for interoperable FDDI rings used in legacy high‑performance networks, industrial systems, and telecommunications infrastructure.
• How it’s applied: Test labs implement the ATS using TTCN or TTCN(P) harnesses, populate PIXIT/PICS information, execute timing‑sensitive test cases and report verdicts (Pass/Fail/Inconclusive) to validate SMT implementations.

Related standards

• ISO/IEC 9314 family (FDDI PHY, MAC, PMD)
• ISO/IEC 9314-6 (Station Management standard referenced)
• ISO/IEC 9646 (Conformance testing methodology and TTCN)

Keywords: ISO/IEC 9314-25:1998, FDDI SMT-ATS, FDDI conformance testing, TTCN, TTCN(P), station management protocol, PIXIT, PICS, ring management, MIB.

Standards Content (Sample)

INTERNATIONAL
ISO/IEC
STANDARD
9314-25
First edition
1998-10
Information technology –
Fibre Distributed Data Interface (FDDI) −
Part 25:
Abstract Test Suite for FDDI −
Station Management Conformance
Testing (SMT-ATS)
 ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office Case postale 56 CH-1211 Genève 20 Switzerland
• • •
Reference number
PRICE CODE XP
For price, see current catalogue

9314-25  ISO/IEC:1998(E)
Contents
Page
1 Scope . 1
2 Normative references . 1
3 Definitions . 1
4 Convention and abbreviations . 2
5 Timer definition . 2
6 Physical Connection Management (PCM) & Entity Coordination
Management (ECM) - Abstract Test Suites . 5
7 CFM conformance tests . 74
8 Ring Management (RMT) - Abstract Test Suite . 127
9 Frame Base Management (FBM) - Abstract Test Suite . 180
10 Management Information Base (MIB) - Abstract Test Suite . 522
ANNEX A (normative) PIXIT Proforma for Fiber Distributed Data Interface
(FDDI) - Station Management (SMT) - Ring Management (RMT) . 893
ANNEX B (normative) PIXIT Proforma for Fiber Distributed Data Interface
(FDDI) - Station Management (SMT) - Management Information
Base (MIB) . 897
Tables
Table 1 - DAS Configuration Test Case Summary . 109
Table 2 - DAC Configuration Test Case Summary . 110
Table 3 - SAS Configuration Test Summary . 110
Table 4 - SAC Configuration Test Case Summary . 110
ii
9314-25 © ISO/IEC:1998(E)
Figures
Figure 1 - Tester Configuration for Indicated Cases . 9
Figure 2 - Tester Configuration for Indicated Cases . 15
Figure 3 - Tester Configuration for Indicated Cases . 16
Figure 4 - Tester Configuration for Indicated Cases . 17
Figure 5 - Tester Configuration for Indicated Cases . 18
Figure 6 - Tester Configuration for Indicated Cases . 65
Figure 7 - Tester Configuration for Indicated Cases . 67
Figure 8 - Tester Configuration for Indicated Cases . 67
Figure 9 - Tester Configuration for Indicated Cases . 69
Figure 10 - Tester Configuration for Indicated Cases . 70
Figure 11 - Tester Configuration for Indicated Cases . 72
Figure 12 - Single MAC DAS Test Configurations (1 of 3) . 111
Figure 13 - Single MAC DAS Test Configurations (2 of 3) . 112
Figure 14 - Single MAC DAS Test Configurations (3of 3) . 113
Figure 15 - Dual MAC DAS Test Configurations (1 of 3) . 114
Figure 16 - Dual MAC DAS Test Configurations (2 of 3) . 115
Figure 17 - Dual MAC DAS Test Configurations (3 of 3) . 116
Figure 18 - Single MAC DAC Test Configurations (1 of 2) . 117
Figure 19 - Single MAC DAC Test Configurations (2 of 2) . 118
Figure 20 - Dual MAC DAC Test Configurations (1 of 2) . 119
Figure 21 - Dual MAC DAC Test Configurations (2 of 2) . 120
Figure 22 - SAS Test Configurations . 121
Figure 23 - No MAC SAC Test Configurations . 122
Figure 24 - Single MAC SAC Test Configurations . 123
Figure 25 - Optional Master Port Permitted Path Single MAC DAC Test
Configurations . 124
Figure 26 - Optional Master Port Permitted Path Dual MAC DAC Test
Configurations . 125
Figure 27 - Ring Hold Option DAS Test Configurations . 126
iii
9314-25  ISO/IEC:1998(E)
FOREWORD
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in
the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 9314-25 was prepared by Joint Technical Committee ISO/IEC JTC 1 Information
technology, Subcommittee SC 25, Interconnection of information technology equipment.
ISO/IEC 9314 consists of the following parts, under the general title Information technology – Fibre Distributed Data
Interface (FDDI):
– 2CTV����6QMGP�4KPI�2J[UKECN�.C[GT�2TQVQEQN��2*;�
– 2CTV����6QMGP�4KPI�/GFKC�#EEGUU�%QPVTQN��/#%�
– 2CTV����2J[UKECN�.C[GT�/GFKWO�&GRGPFGPV��2/&�
– 2CTV����5KPING�/QFG�(KDTG�2J[UKECN�.C[GT�/GFKWO�&GRGPFGPV��5/(�2/&�
– 2CTV����*[DTKF�4KPI�%QPVTQN��*4%�
– 2CTV����5VCVKQP�/CPCIGOGPV��5/6�
– 2CTV����2J[UKECN�.C[GT�2TQVQEQN��2*;���
– 2CTV����/GFKC�#EEGUU�%QPVTQN����/#%���
– 2CTV����.QY�%QUV�(KDTG�– 2J[UKECN�/GFKWO�&GRGPFGPV��.%(�2/&�
– 2CTV�����6QMGP�4KPI�6YKUVGF�2CKT�2J[UKECN�NC[GT�/GFKWO�&GRGPFGPV���62�2/&�
– 2CTV�����%QPHQTOCPEG�6GUV�2TQVQEQN�+ORNGOGPVCVKQP�%QPHQTOCPEG�5VCVGOGPV
RTQHQTOC��%6�2+%5�
– 2CTV�����2J[UKECN�/GFKWO�&GRGPFGPV�%QPHQTOCPEG�6GUVKPI��2/&�#65�
– 2CTV�����2J[UKECN�.C[GT�2TQVQEQN�%QPHQTOCPEG�6GUVKPI��2*;�#65�
– 2CTV�����#DUVTCEV�6GUV�5WKVG�HQT�FDDI K�5VCVKQP�/CPCIGOGPV�%QPHQTOCPEG�6GUVKPI
�5/6�#65�
– 2CTV�����/GFKC�#EEGUU�%QPVTQN�%QPHQTOCPEG�6GUVKPI��/#%�#65�
iv
9314-25 © ISO/IEC:1998(E)
INTRODUCTION
The International Organization for Standardization (ISO) has developed a standard to
define the procedures required for Conformance Testing. These procedures are set
forth in ISO 9646, Parts 1-7. Part 3 defines the language syntax to be used for writing
Abstract Test Suites (ATS), that language is Tree and Tabular, Combined Notation
(TTCN).
The Station Management (SMT) Abstract Test Suite (ATS) directly supports the FDDI
Protocol Implementation Conformance Statement (PICS) Proforma and works in
correlation with three other FDDI ATS standards.
This ATS for FDDI SMT provides the test procedures and test cases required to test
the station management protocol described in the SMT standards. SMT specified the
local portion of the system management application process for FDDI, including the
control required for proper operation of an FDDI station in an FDDI ring. SMT
provided services such as connection management, station insertion and removal,
station initialization, configuration management, fault recovery, communication
protocol for external authority, scheduling policies and the collection of statistics. SMT
interact with PMD, PHY, and MAC for testing.
The three ATS standards when combined with SMT, that make up the complete
Conformance Test for the FDDI Protocol are:
a) An ATS for FDDI Physical Medium Dependent (PMD) that provides a
conformance test for FDDI PMD. PMD specifies the optical interface of FDDI
stations. PMD is not a protocol standard and this ATS requires the
measurement of physical quantities such as optical power, wavelength and
signal jitter. The PMD ATS differs from the methodology of higher level
protocol conformance tests written using the Tree and Tabular Combined
Notation as specified by ISO 9643-3, because the TTCN notation does not
provide a suitable vehicle for Physical Layer testing, where there is no
concept of a protocol data unit and where physical quantities must be
measured.
b) An ATS for the FDDI Physical Layer Protocol (PHY) that provides a
conformance test for FDDI PHY. PHY specifies the upper sublayer of the
Physical Layer for the FDDI, including the data encode/decode, framing and
clocking, as well as the elasticity buffer, smoothing and repeat filter functions.
FDDI PHY, however, does contain several state machines and implements a
protocol at the level of FDDI code symbols. The only physical quantity that
must be measured in this conformance test is frequency. The PHY ATS
cannot use the TTCN notation. A unique notation is developed in the PHY
ATS for specifying test patterns and expected results in terms of FDDI code
symbol strings.
c) An ATS for FDDI Media Access Control (MAC) that provides a Conformance
test for FDDI MAC. MAC specifies the lower sublayer of the Data Link Layer
for FDDI. It specifies access to the medium, including addressing, data
checking and data framing. MAC also specifies the receiver and transmitter
state machines. Since MAC is a protocol that deals primarily with complete
PDUs, the Tree and Tabular Combined Notation language specified in ISO
9643-3 is used to specify MAC protocol tests.
International Standard ISO/IEC 9314-25:1998, Information technology - Fibre
Distributed Data Interface (FDDI) - Station Management Conformance Testing (SMT-
ATS) was developed by ISO/IEC JTC 1/SC 25.
v
9314-25  ISO/IEC:1998(E)
INFORMATION TECHNOLOGY –
FIBRE DISTRIBUTED DATA INTERFACE (FDDI) –
Part 25: Abstract Test Suite for FDDI – Station Management Conformance
Testing (SMT ATS)
1  Scope
This part of ISO/IEC 9314 contains the Abstract Test Suites for the Fiber Distributed Data Interface
(FDDI) token ring Station Management (SMT) layer protocol. The SMT Protocol is extensive and very
complex. In the development process, the protocol was broken into six separate areas. Those areas
dealt with Physical Connection Management (PCM), Entity Coordination Management (ECM) Ring
Management (RMT), Configuration Management (CMT), Frame Based Management (FBM) and
Management Information Base (MIB).
This SMT ATS is divided along the same boundaries, with the exception that PCM and ECM are
combined. Those two concepts are tested together. The formal description language used for
Abstract Test Suite (ATS) development is Tree and Tabular Combined Notational (TTCN) and is
defined in ISO 9646Framework. TTCN is intended for higher layer protocol testing and requires the
use of discreet Protocol Data Units (PDUs). The TTCN notation is used in the test cases for RMT,
FBM and MIB. It cannot be used for PCM, ECM and CFM. These three protocols use line states as
the method of conveying information.
The TTCN (P) is similar in structure to TTCN but changes the paradigm from PDUs to line states. A
description of the concept of TTCN (P) can be found in the beginning of section 6, PCM.
2  Normative references
The following normative documents contain provisions which, through reference in this text, constitute
provisions of this part of ISO/IEC 9314. At the time of publication, the editions indicated were valid.
All standards are subject to revision, and parties to agreements based on this part of ISO/IEC 9314
are encouraged to investigate the possibility of applying the most recent editions of the standards
indicated below. Members of IEC and ISO maintain registers of currently valid International
Standards.
ISO/IEC 7498-1:1994, Information technology – Open Systems Interconnection – Basic Reference
Model: The Basic Model
ISO/IEC 9314-1:1989, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 1: Token Ring Physical Layer Protocol (PHY)
ISO/IEC 9314-2:1989, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 2: Token Ring Media Access Control (MAC)
ISO/IEC 9314-3:1990, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 3: Physical Layer Medium Dependent (PMD)
ISO/IEC 9314-6:1998 Information technology – Fibre Distributed Data Interface (FDDI) – Part 6:
Station Management (SMT)
ISO/IEC 9646 (all parts), Information technology – Open Systems Interconnection – Conformance
testing methodology and framework
ISO/IEC 9646-1:1994, Information technology – Open Systems Interconnection – Conformance testing
methodology and framework – Part 1: General concepts
ISO/IEC 9646-2:1994, Information technology – Open Systems Interconnection – Conformance testing
methodology and framework – Part 2: Abstract test suite specification
3 Definitions
For the purposes of this part of ISO/IEC 9314, the following definitions apply.
3.1 Abstract Test Suite (ATS): An ATS is a document, defined in ISO 9646, that depicts the suite
of tests to be run by the test implementor to define conformance to a governing standard.
9314-25  ISO/IEC:1998(E)
3.2 Frame Based Management (FBM): FBM defines the frame formats and protocols used to
manage FDDI stations on a ring in a peer-to-peer relationship.
3.3 Management Information Base (MIB):
The MIB provides the specification and capabilities of
management information and its relationships to systems management.
3.4 Connection Management (CMT):
CMT controls the establishment and maintenance of an
FDDI connection.
3.5 Physical Connection Management (PCM): PCM controls initializations of a Physical
connection, maintenance of the connection and closing of the connection.
3.6 Ring Management (RMT): RMT monitors the MAC functions in an FDDI station and supports
establishment and maintenance of an operational ring.
4  Convention and abbreviations
4.1  Conventions
4.2  Abbreviations
ATS: Abstract Test Suite;
CFM: Configuration Management;
F: Fail (when used in the verdict column of the Dynamic Behavior tables);
I: Inconclusive (when used in the verdict column of the Dynamic Behavior tables);
ILS: Idle Line State;
IUT: Implementation Under Test;
MAC: Media Access Control;
MLS: Master Line State;
P: Pass (when used in the verdict column of the Dynamic Behaviour tables);
PCM: Physical Connection Management;
PDU: Protocol Data Unit defined in terms of SMT and MAC Frames;
PHY: Physical Layer Protocol;
PICS: Protocol Implementation Conformance Statement;
PIXIT: Protocol Implementation extra Information for Testing;
TTCN: Tree and Tabular Combined Notation;
TTCN(P): Tree and Tabular Combined Notation for PCM & CFM;
QLS: Quiet Line State;
ALS: Active Line State;
HLS: Halt Line State;
ERR: Error;
RMT: Ring Management;
MIB: Management Information Base.
5  Timer definition
A set of timers, as described below, is used in the test suite, their values must be initialized prior to the
beginning of test, unless a default value is specified.
T_REQ: the Target Token Rotation Timer
(TTRT) is configured in the IUT's MAC in units of μs. This value will be converted to units of 80 ns for
MAC claim process.
9314-25  ISO/IEC:1998(E)
T_REQ1: μ
an alternate TTRT configured in the IUT's MAC in units of s. This value will be converted
to units of 80 ns for MAC claim process.
T_REQ2: an alternate TTRT configured in the Other's MAC in units of μs. This value will be converted
to units of 80 ns for MAC claim process.
T_Max: the maximum token rotation time in μs.
D_Max: the maximum ring latency. The default value is 1773 μs.
T_Non_Op: time to allow ring recovery to occur before duplicate address conditions are examined.
The default value is 1 s.
RM_React: maximum for the RMT state machine to recognize that transition conditions exist and to
execute the appropriate transition. The default value is 83 ms.
T_Jam:
time for which Jam Beacon is sent. The default value is 370 ms.
T_DBJ: time to start the second Beacon of the Double Beacon Jam after the first Beacon is sent. The
default value is 82 ms.
T-Direct:
time for which a Directed Beacon is sent before the Trace function is invoked. The default
value is 370 ms.
T_Stuck: time to allow a Stuck Beacon to be sent, followed by the initiation of a Trace. The default
value is 8 s.
T_Rmode: the maximum time allowable for Restricted Dialogue on the ring. The default value is zero
seconds for Non-Used Restricted Dialogue.
T_Announce:
the interval between sending Jam Beacons. The default value is 2 500 ms.
T_Limit: The rate-limiting interval for the Status Report Protocol. The default value is 2 s.
Topr: Time required for a test operator to initiate operation on the IUT, for example, triggering NIF
request frame to be sent from the IUT. This is used in conjunction with the TTCN Implicit Send event
for test coordination. This test suite uses a default value of 3 min.
The following are the expiration values of the timers used in PCM test cases. Whenever the name
and the value correspond to ISO/IEC 9314-6 the reference is indicated.
TB_Min
: Minimum Break time for link.
Range: TB_Min ≥ 4.823 ms with default values
Default: 5 ms (SMT PCM);
TB_Max: Break time before the BS_Flag is set. TB_Max shall be sufficiently large so that it will not be
set inadvertently by noise generated by an optical bypass switch, which is bounded by MI_Max.
Range: TB_Max ≥ 30.0 ms with default values
Default: 50 ms (SMT PCM);
MI_Max: Maximum Optical Bypass media interruption time. The range and default value for MI_Max
is specified in the PMD document.
≤ 15.0
Range: MI_Max ms
Default: 15 ms (SMT PCM)
C_Min:
Minimum time required to remain in the Connect State to ensure that the other end has
recognized Halt Line State.
Range: C_Min ≥ 1.2 ms with default values
Default: 1.6 ms (SMT PCM);
C_Second:
A timer used to check PCM wait for a change in the Connect State since it enters
Connector State from Break State and has not yet received HLS.
Default: 1 s;
9314-25  ISO/IEC:1998(E)
PC_React: Maximum time for PCM to make a state transition to Break upon receiving QLS.
Range: PC_React ≤ 3.0 ms
Default: 3 ms (SMT PCM);
LS_Min:
Length of time continuous reception of ILS is required to be used by PCM.
Range: 25 μs ≥ LS_Min ≥ 0.48 μs with default values
Default: 0.48 μs(SMT PCM);
LS_Max:
Maximum time to reestablish the correct line state as specified in the PHY document.
Range: LS_Max ≤ 25 μs
Default: 25 μs (SMT PCM);
TL_Min: Minimum time to transmit a PHY line state before advancing to the Next PCM state.
TL-Min is set to twice the time required for line state recognition(LS_Max).
≥ μ
Range: TL_Min 50 s with default values
μ
Default: 50 s (SMT PCM);
N_Second: A Timer used to check PCM wait to receive ILS in Next State
Default: 1 s;
LS_Less:
A timer which measures the amount of time that it take the IUT to make a correct Line State
transition.
Default: 0.24 μs;
T_Out: Signaling timeout. The minimum time that a PCM State Machine will remain in a state
awaiting a line state change. When a line state change is expected and no transition is made in
T_Out time, a transition shall be made to the Break State.
Range: T_Out ≥ 100 ms
Default: 100 ms (SMT PCM);
LC_Short: Short Link Confidence Test Time
Range: LC_Short > 5*10(4) ns
Default: 50 ms (SMT PCM);
LC_Medium: Medium Link Confidence Test Time.
Range: LC_Medium ≥ 50 *10(LER_Cutoff) ns
Default: 500 ms (SMT PCM);
LC_Long: Long Link Confidence Test Time.
≥
Range: LC_Long 500 * 10 (LER_ Cutoff) ns
Default: 5 s (SMT PCM);
LC_Extended:
Extended Link Confidence Test Time.
Range: LC_Extended ≥ 50 s
Default: 50 s (SMT PCM);
T_Next(7): LC_Test, Time for Link Confidence Test (SMT PCM);
B_Second: A timer used to check when IUT detects Link Error Rate exceeds the LER_Cutoff
threshold; it enters Break State and transmits QLS.
Default: 1 s;
T_Next(9):
Time for the optional MAC Local Loop to prevent deadlock. This allows sufficient time for
MAC recovery process completion and the exchange of neighbor information frames.
Range: T_Next(9) ≥200 ms
Default: 200 ms (SMT PCM).
9314-25  ISO/IEC:1998(E)
NS_Max: The maximum length of time that noise as measured by TNE, is allowed before a connection
is broken down and restarted.
Range: 5.8 ms ≥ NS_Max ≥ 0.7255 ms
Default: 1.3 ms (SMT PCM);
Trace_Max: Maximum propagation time for a Trace on an FDDI topology. Trace_Max places a lower
bound on the detection time for a nonrecovering ring (T_Stuck)
≥
Range: Trace_Max 6.001773 s with default values
Default: 7.0 s
6  Physical Connection Management (PCM) & Entity Coordination
Management (ECM) - Abstract Test Suites
6.1  Notation for PCM Tests
PCM is implemented as a complex state
machine and it is therefore highly desirable to use a formal notation to specify precisely conformance
tests. One such formal notation is the Tree and Tabular Combined Notation (TTCN) as defined in ISO
9646-3. However PCM does not fit the TTCN paradigm well. The primary problem is that TTCN, which
is intended for higher level protocol tests, requires that the protocol uses discrete Protocol Data Units
(PDUs). It assumes that these PDUs are queued when received and that the TTCN "?" operator tests
the PDU at the front of the receive queue. PCM signaling does not use PDUs but instead uses line
states as the method of conveying information.
This document uses a notation called TTCN(P) to express the PCM tests. It is similar to TTCN, but
changes the paradigm somewhat and simplifies the notation.
The key to understanding TTCN(P) is that the Implementation Under Test (IUT) is always considered
to take on one of the following values:
•
Quiet Line State (QLS)
•
Idle Line State (ILS)
• Halt Line State (HLS)
• Master Line State (MLS)
• Active Line State (ALS)
• Noise Line State (NLS)
• Line State Unknown (LSU)
No other values can be set.
NLS is defined to be any condition which occurs in any of the other line states, which satisfies the
conditions for termination of that state but does not satisfy the criteria for entry into any of the other line
state. The tester never transmits NLS, and, in most cases the reception of NLS causes the IUT to fail
the test.
The TTCN(P) "?" operator tests the contents of a received line state register in the tester, for example,
the test ?ILS is satisfied if the current line state is ILS.
The tester is either transmitting a predefined MAC frame, repeating symbols received when its input is
in ALS or is continuously transmitting one of the following:
• QLS
• ILS
• HLS
• MLS
•
ERR
•
Port_Type
ERR is a special pattern transmitted during the Link Confidence Test.
Port_Type is used to mean either HLS or MLS as appropriate. This notation is used to reduce the
number of separate routines. In particular the port type, which is signaled in the Signal States when
9314-25  ISO/IEC:1998(E)
n=1 and n=2, is irrelevant to many test cases. Therefore the tests include subroutines, whose purpose
is simply to step the IUT to the state where the actual test begins, use the Port_Type notation to allow
the same routine to serve several port types.
A TTCN(P) test procedure consists of a sequence of event lines specifying an event or an action to
take place at a given instant during the testing. The time progression is represented by the indentation
number to the left of every event line in the form of [1], [2], etc. An event line may be one of the
following: start transmitting line state symbols, check the current line state, start and test expiration of
timers, invoke other test procedures (tree attachment), and a GOTO statement. These events are
written in the format shown below:
[n] !line-state    /* Start transmitting
line-state symbols as specified, e.g. HLS */
[n] !Repeat      /* Repeat input symbols received while input is in ALS, starting with the J symbol
and stopping with the first V, I or H symbol. When V or H symbols are encountered the Repeat Filter
rules of PHY are observed */
[n]!Packet      /* cause the tester to transmit a single MAC Packet; when transmission of the
packet is complete, the tester transmits ILS */
[n] ?line-state    /* check if the current line state is in a specific state */
[n] ?OTHERWISE    /* any line state */
[n] START timer-name /* start the timer with pre-specified duration */
[n] ?TIMEOUT timer-name /* test for
expiration for the specified timer */
[n] +test-procedure-name  /* call another test procedure */
[n] GOTO label       /* goto another event line with indicated label */
As in many programming languages, a comment is a character string of the following form:
/* Text of comment */
A label for an event line is denoted by a sequence of letters ending with a ":", and appears after the
indentation level number, for example,
[3] L1:?TIMEOUT C_min.
The "!" Transmit event means that the tester begins sending the indicated line state and
continues sending it until another "!" operator is encountered.
The START timer event may be combined with the Transmit (!) or Line state check (?) event lines.
Multiple timers may be started on the same event. For example,
[1] !QLS START TB_Min, START TB_Max.
The event lines are evaluated starting from the first indentation level, [1]. There may be several event
lines at each indentation level. These event lines represent a set of alternatives and the tester must
wait for at least one of them to occur before proceeding to the next indentation level. If multiple events
occur at the same time, the event line appearing first applies. A transmit event line (!) is considered to
have occurred or completed when the transmission of the specified line state symbols is initiated. A
line state check event (?) is satisfied when the current line state matches the specified state.
When an event line is satisfied, the tester moves on to the next indentation level following that event
line. If there is no higher level event line, then the test is complete. If a completed event line contains
a verdict specification, the test is also considered completed, even if there is a higher indentation level
event line following.
The event lines, with the exception of GOTO, SEND and Tree Attachment Event, may assign one of
these verdicts: PASS, FAIL, or INCONCLUSIVE.
A GOTO event can only specify the labels appearing on the first line of an indentation level that is
lower or equal to the current indentation level.
An event line that invokes another procedure is considered not satisfied if none of the first level event
lines in that procedure have occurred.
9314-25  ISO/IEC:1998(E)
−
Note that PCM is intended to operate in very noisy environments (perhaps as bad as a BER of 10
and does not generally react to brief noise events. We do not simulate noise in our PCM tests except
for the Link Quality Tests; rather we expect that the IUT and the tester transmit nothing but clean line
states without any errors. If the IUT transmits NLS or LSU it is always grounds for failure.
"TTCN(P) does not use the normal TTCN Constraints. This is because the Constraints section of
TTCN uses PDUs rather than Line States to define Constraints.
An example illustrates the TTCN(P) notation. This example is the test case To_Next specified in
6.2.1.5:
Procedure:
[1]+Start_To_Connect
[2] !HLS Start C_Min
[3]  A:?Timeout C_Min /*Comment*/
[4]   B:?HLS
[5]    Goto B
[4]   ?ILS Pass
[4]   ?Otherwise Fail(2)
[3]  ?HLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
In To_Next the procedure Start_To_Connect is attached by the first statement:
[1]+Start_To_Connect, which is specified in 6.3.2, is:
Procedure:
[1]!QLS Start TB_Min
[2] ?Timeout TB_Min
[3]  A:?QLS
[4]   Goto A
[3]  ?HLS    /*Comment*/
[3]  ?Otherwise Inconclusive
The key to understanding the attachment is that the attaching test is attached to each of the terminal
leaves of the attached routine. A terminal leaf is any statement other than a GOTO that has no lower
layer and is not qualified with Pass, Fail or Inconclusive verdict. In Start_To_Connect there is one
terminal leaf:
[3]  ?HLS
To_Next
Each test has a specific purpose. The purpose of is to verify that the IUT remains in the
Start_To_Connect
Connect State for at least C_Min before going to the Next State. is used simply to
bring the IUT to the Connect State. Therefore it is a simple routine to progress a correct IUT to the
Connect State and does not attempt to test all the requirements of PCM to get to the Connect State;
these are tested elsewhere in an incremental fashion.
Start_To_Connect
The first statement of , and the only statement at level 1 is:
[1]!QLS Start TB_Min
This statement causes the tester to transmit QLS and to start the TB_Min timer.
Control falls to the next statement at level 2:
[2]   ?Timeout TB_Min
This statement causes the tester to wait, still sending QLS, until the timer TB_Min expires, since there
is no alternative at this level. This should cause the IUT to go to the Break State. There are three
alternatives at level 3:
[3]   A:?QLS
[3]   ?HLS
[3]   ?Otherwise Inconclusive
9314-25  ISO/IEC:1998(E)
Alternatives at the same level are evaluated in order and then the evaluation is repeated until one of
the alternatives becomes true. One of the alternatives is always true because of the otherwise
statement. At this point the IUT should either be transmitting QLS or HLS; if not, something is wrong.
However, because this is not the point of the test, we label the otherwise "Inconclusive" rather than
"fail". If we receive QLS, then we fall down to the following statement at level 4:
[4]    Goto A
This statement just returns the tester to level 3 at A and we loop back and evaluate the same three
alternatives. Eventually the IUT should transmit HLS (signifying that it has entered the Connect State,
the second alternative became true, Start_To_Connect has reached a terminal leaf), and control
passes to the attaching test routine To_Next.
When the Start_To_Connect completes control passes to level 2, where there is one alternative:
[2] !HLS Start C_Min
This statement causes the tester to transmit HLS and to start the timer C_Min. Control then passes to
level 3 and the following alternatives:
[3]   A:?Timeout C_Min /*Comment*/
.
.
[3]   ?HLS
[3]   ?Otherwise  Fail(1)
The test purpose is to see if the IUT remains in the Connect State for at least C_Min before going to
the Next State, therefore if any signal other than HLS (signifying Connect State) is received before
C_Min expires, the Otherwise statement causes the test to fail. The "(1)" is a parameter used to
distinguish between possibly different failure points. As long as HLS is received control will fall to a
GOTO at level 4, which loops control back to B:
[4]    Goto A
Finally, when C_Min times out, control falls to:
[4]   B:?HLS
[5]    Goto B
[4]   ?ILS Pass
[4]   ?Otherwise Fail(2)
As long as HLS is received, the tester continues to loop back to level 4. If ILS is received, then the IUT
has made the transition to the Next State after waiting for at least C_Min and this test is passed. If
anything else is received, then the test is failed.
Note that we can expand the attachment of Start_To_Connect by To_Next and get the following
equivalent test routine:
Procedure:
[1]!QLS Start TB_Min
[2] ?Timeout TB_Min
[3]  A:?QLS
[4]   Goto A
[3]  ?HLS
[4]   !HLS Start C_Min
[5]    B:?Timeout C_Min /*Comment*/
[6]     C:?HLS
[7]      Goto C
[6]     ?ILS Pass
[6]     ?Otherwise Fail(2)
[5]    ?HLS
[6]     Goto B
[5]    ?Otherwise Fail(1)
[3]  ?Otherwise Inconclusive
9314-25  ISO/IEC:1998(E)
6.2  Test Cases
6.2.1  Connection Initialization Test:
6.2.1.1  Case-ID: To_Connect_1
Purpose: Verify that IUT enters the Connect state after remaining in the Break state for at least
TB_Min when it receives QLS.
Test Setup: See figure 1.
LST IUT
X Port
X Port
Tx Rx Tx Rx
Figure 1 - Tester Configuration for Indicated Cases

Procedure:
[1]+Init        /*Comment(1)*/
[2] !QLS Start TB_Min /*Comment(2)*/
[3]  A:?Timeout TB_Min
[4]   B:?QLS
[5]    Goto B
[4]   ?HLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?QLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) The Init function (6.3.1 of this document) is called to let the IUT start from the Break State.
(2) In the Break State, the Tester transmits QLS, starts the timer TB_Min to ensure that the IUT
remains in the Break State for at least TB_Min. (PC-13)
Reasons for Failure:
(1) Initially, the IUT is in the Break State while QLS is transmitted for at least TB_Min. If the IUT does
not transmit QLS within TB_Min, then the IUT fails.
(2) The IUT transmits QLS while in the Break State and HLS when it enters the Connect State. Any
other output is invalid.
6.2.1.2  Case-ID: To_Connect_2
Procedure:
[1]+Init/*Comment(1)*/
[2] !HLS Start TB_Min /*Comment(2)*/
[3]  A:?Timeout TB_Min
[4]   B:?QLS
[5]    Goto B
[4]   ?HLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?QLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
9314-25  ISO/IEC:1998(E)
Extended Comments:
(1) The Init function (6.3.1 of this document) is called to let the IUT start from the Break state.
(2) In the Break state, the Tester transmits HLS, starts the timer TB_Min to ensure that the IUT
remains in the Break state for at least TB_Min. (PC-13)
Reasons for Failure:
(1) IUT must transmit QLS for TB_Min at the beginning of this procedure. If it does not meet this
requirement then the IUT fails.
(2) After remaining in the Break State for longer than TB_Min, the IUT may either stay in Break or
change to Connect. If the IUT transmits any line state other than QLS or HLS, the test fails.
6.2.1.3  Case-ID: Wait_for_Connect

Purpose: Show that the IUT progresses to Connect from the Break State and remains in the Connect
State until HLS is received.
Test Setup: See figure 1.
Procedure:
[1]+Init
[2] !QLS
[3]  A:?QLS
[4]   Goto A
[3]  ?HLS /*Comment(1)*/
[4]   Start C_Second /*Comment(2)*/
[5]    B:?Timeout C_Second Pass
[5]    ?HLS
[6]     Goto B
[5]    ?Otherwise Fail(2)
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) IUT enters the Connect State from the Break State and transmit HLS. (Connect_Actions)
(2) In this step, the IUT is in the Connect State, it is going to receive a sequence of HLS to process to
the Next State. At this point, The Tester keeps sending QLS to the IUT to see what happen on the
IUT. (PC-33)
Reasons for Failure:
(1) IUT transmit QLS when it enters the Break State. After TB_Min, it must enter the Connect State
and transmit HLS. If the IUT does not transmit QLS followed by HLS then the IUT fails.
(2) When the IUT enters the Connect state, it will enter the Next state after receiving sufficient HLS.
The tester remains in the Break state which should cause the IUT to remain in the Connect state
forever. If the IUT transmits other than HLS then it is failed.
6.2.1.4  Case-ID: Connect_Error
Purpose:
Verify that the IUT enters the Break
State if the ILS is received before HLS is received in the Connect State.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Connect /*Comment*/
[2] !ILS Start T_Out
[3]  A:?Timeout T_Out Fail(1)
[3]  ?HLS
[4]   Goto A
[3]  ?QLS Pass
[3]  ?Otherwise Fail(2)
Extended Comments:
The IUT is in the Connect State (see 6.3.2).
9314-25  ISO/IEC:1998(E)
Reasons for Failure:
(1) If the IUT does not enter the Break State within T_Out when ILS is received before HLS is re-
ceived, the IUT fails. (PC-33, PC-31b)
(2) IUT may either be in the Connect State (not changed to Break State yet) or in the Break State
otherwise it is failed.
6.2.1.5  Case-ID: To_Next
Purpose:
Verify that the IUT remains in the Connect State for at least C_Min before entering the Next
State.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Connect
[2] !HLS Start C_Min
[3]  A:?Timeout C_Min /*Comment*/
[4]   B:?HLS
[5]    Goto B
[4]   ?ILS Pass
[4]   ?Otherwise Fail(2)
[3]  ?HLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
IUT enters the Connect State from the Break State and must remain in the Connect State for at least
C_Min. (PC-33, PC-34)
Reasons for Failure:
(1) When the IUT enters the Connect State, it remains for at least C_Min. If the C_Min timer does not
timeout and the IUT does not transmit HLS then the IUT fails.
(2) After C_Min, the IUT may stay in the Connect State or enter the Next State. If the IUT transmits a
Line State other than HLS or ILS then the IUT fails.
6.2.1.6  Case-ID: Next_0
Purpose: Verify that the IUT remains in the Next State for at least TL_Min.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next /*Comment*/
[2] !ILS Start TL_Min
[3]  A:?Timeout TL_Min
[4]   B:?ILS
[5]    Goto B
[4]   ?MLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
IUT is in the Next State with n=0.
Reasons for Failure:
(1) Initially, the IUT is in the Next State, ILS is transmitted for at least TL_Min. After TL_Min, the IUT
may remain in the Next or enter the Signal State. If the IUT does not transmit ILS and TL_Min is not
expired, then the IUT fails. (PC-44b, Next_Actions)
(2) After TL_Min, the IUT may remain in the Next State or enter the Signal State. If the IUT does not
transmit ILS or MLS, then the IUT fails.
9314-25  ISO/IEC:1998(E)
6.2.1.7  Case-ID: Wait_In_Next
Purpose: Verify that the IUT will not enter the Signal State until ILS is received for at least LS_Min.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next
[2] !ILS Start LS_Less, Start N_Second
[3]  A:?Timeout LS_Less /*Comment(1)*/
[4]   !MLS /*Comment(2)*/
[5]    B:?Timeout N_Second Pass
[5]    ?ILS /*Comment(3)*/
[6]     Goto B
[5]    ?QLS Pass
[5]    ?Otherwise Fail(2)
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) LS_Less is a timer which is set to half the time required for LS_Min (the default value of LS_Less
is 0.24 microseconds). It is to verify that the IUT will wait in the Next State without changing to the
Signal State (the Tester sends ILS for 0.24 microseconds) unless it receives ILS for at least LS_Min.
(0.48 microseconds)
(2) Tester continuously transmits MLS to the IUT.
(3) IUT will stay in the Next State, if ILS is not received for longer than LS_Min.
(PC-44a, PC-44b)
Reasons for Failure:
(1) IUT does not remain in the Next State to transmit ILS or LS_Less is not expired.
(2) If the IUT does not receive sufficient ILS, the IUT enters the Next State from the Connect State, it
must wait to receive enough ILS. So, if the IUT does not transmit ILS (IUT may not remain in the Next
State) and the N_Second timer is not expired then the IUT fails.
(PC-44a, PC-44b)
6.2.1.8  Case-ID: Next_Error1
Purpose: Verify that the IUT transitions from the Next state to Break, if QLS is received. (PC-41b)
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next
[2] !QLS Start PC_React
[3]  A:?Timeout PC_React Fail(2)
[3]  ?QLS Pass
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Reasons for Failure:
(1) IUT does not transmit ILS, QLS and PC_React is not expired.
(2) IUT does not enter the Break State within PC_React when QLS is received. (PC-41b, Next_Error,
Break_Actions)
6.2.1.9  Case-ID: Next_Error2
Purpose: Verify that the IUT transitions from the Next state to Break, if T_Out expires prior to the IUT
receiving ILS, with n > zero. (PC-41b)
Test Setup: See figure 1.
9314-25  ISO/IEC:1998(E)
Procedure:
[1]+To_Next_0 /*Comment*/
[2] !MLS Start T_Out
[3]  A:?Timeout T_Out
[4]   ?QLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments: The IUT enters the Next State with n=1.
Reasons for Failure:
(1) IUT does not transmit ILS or T_Out is not expired.
(2) IUT does not enter the Break State from Next because ILS has not been received for T_Out and n
is greater than zero since entering the Next State. (Next_Error, Break_Actions)
6.2.1.10  Case-ID: Signal_Error1
Purpose: Verify that the IUT transitions from the Signal state to Break if QLS is received. (PC-51b)
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next /*Comment(1)*/
[2] !ILS
[3]  A:?ILS /*Comment(2)*/
[4]   Goto A
[3]  ?MLS /*Comment(3)*/
[4]   !QLS Start PC_React
[5]    B:?Timeout PC_React Fail(2)
[5]    ?MLS
[6]     Goto B
[5]    ?QLS Pass
[5]    ?Otherwise Fail(3)
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) IUT is in Next State with n = 0.
(2) Tester keeps receiving ILS from the IUT until the IUT changes to the Signal State and transmits
MLS.
(3) IUT enters the Signal State and transmits MLS. (PC-54, T_Val(0), Signal_Actions)
Reasons for Failure:
(1) Initially, the IUT is in the Next State, ILS is transmitted. After TL-Min, the IUT enters the Signal
State. If the IUT does not transmit ILS, MLS then the IUT fails.
(2) IUT does not enter the Break State while QLS is received for PC_React in the Signal State.
(PC-41b, Next_Error, Break_Actions)
(3) IUT does not transmit QLS, MLS or PC_React has not timed out.
6.2.1.11  Case-ID: Signal_Error2

Purpose: Verify that the IUT transitions from the Signal state to the Break state if the MLS or HLS has
not been received for a period T_Out. (PC-51b)
Test Setup:
See figure 1.
9314-25  ISO/IEC:1998(E)
Procedure:
[1]+Start_To_Next /*Comment(1)*/
[2] !ILS
[3]  A:?ILS /*Comment(2)*/
[4]   Goto A
[3]  ?MLS /*Comment(3)*/
[4]   Start T_Out
[5]    B:?Timeout T_Out
[6]     ?QLS Pass
[6]     ?Otherwise Fail(3)
[5]    ?MLS
[6]     Goto B
[5]    ?Otherwise Fail(2)
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) IUT enters the Next State with n=0.
(2) Tester keeps receiving ILS until IUT enters the Signal State and transmits MLS.
(3) IUT enters the Signal State and transmits MLS. (PC-54, T_Val(0), Signal_Actions)
Reasons for Failure:
(1) Initially, the IUT is in the Next State transmitting ILS for at least TL_Min. The IUT enters the Signal
State and transmits MLS. If the IUT does not transmit ILS or MLS, then the IUT fails.
(2) If the IUT does not transmit MLS, the test fails.
(3) If MLS is not received within T_Out, the IUT transitions to the Break State and transmits QLS. If the
IUT does not transmit QLS, the test fails. This is a test of the break state response.
(PC-
...

INTERNATIONAL
ISO/IEC
STANDARD
9314-25
First edition
1998-10
Information technology –
Fibre Distributed Data Interface (FDDI) −
Part 25:
Abstract Test Suite for FDDI −
Station Management Conformance
Testing (SMT-ATS)
 ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office Case postale 56 CH-1211 Genève 20 Switzerland
• • •
Reference number
PRICE CODE XC
For price, see current catalogue

9314-25  ISO/IEC:1998(E)
Contents
Page
1 Scope . 1
2 Normative references . 1
3 Definitions . 1
4 Convention and abbreviations . 2
5 Timer definition . 2
6 Physical Connection Management (PCM) & Entity Coordination
Management (ECM) - Abstract Test Suites . 5
7 CFM conformance tests . 74
8 Ring Management (RMT) - Abstract Test Suite . 127
9 Frame Base Management (FBM) - Abstract Test Suite . 180
10 Management Information Base (MIB) - Abstract Test Suite . 522
ANNEX A (normative) PIXIT Proforma for Fiber Distributed Data Interface
(FDDI) - Station Management (SMT) - Ring Management (RMT) . 893
ANNEX B (normative) PIXIT Proforma for Fiber Distributed Data Interface
(FDDI) - Station Management (SMT) - Management Information
Base (MIB) . 897
Tables
Table 1 - DAS Configuration Test Case Summary . 109
Table 2 - DAC Configuration Test Case Summary . 110
Table 3 - SAS Configuration Test Summary . 110
Table 4 - SAC Configuration Test Case Summary . 110
ii
9314-25 © ISO/IEC:1998(E)
Figures
Figure 1 - Tester Configuration for Indicated Cases . 9
Figure 2 - Tester Configuration for Indicated Cases . 15
Figure 3 - Tester Configuration for Indicated Cases . 16
Figure 4 - Tester Configuration for Indicated Cases . 17
Figure 5 - Tester Configuration for Indicated Cases . 18
Figure 6 - Tester Configuration for Indicated Cases . 65
Figure 7 - Tester Configuration for Indicated Cases . 67
Figure 8 - Tester Configuration for Indicated Cases . 67
Figure 9 - Tester Configuration for Indicated Cases . 69
Figure 10 - Tester Configuration for Indicated Cases . 70
Figure 11 - Tester Configuration for Indicated Cases . 72
Figure 12 - Single MAC DAS Test Configurations (1 of 3) . 111
Figure 13 - Single MAC DAS Test Configurations (2 of 3) . 112
Figure 14 - Single MAC DAS Test Configurations (3of 3) . 113
Figure 15 - Dual MAC DAS Test Configurations (1 of 3) . 114
Figure 16 - Dual MAC DAS Test Configurations (2 of 3) . 115
Figure 17 - Dual MAC DAS Test Configurations (3 of 3) . 116
Figure 18 - Single MAC DAC Test Configurations (1 of 2) . 117
Figure 19 - Single MAC DAC Test Configurations (2 of 2) . 118
Figure 20 - Dual MAC DAC Test Configurations (1 of 2) . 119
Figure 21 - Dual MAC DAC Test Configurations (2 of 2) . 120
Figure 22 - SAS Test Configurations . 121
Figure 23 - No MAC SAC Test Configurations . 122
Figure 24 - Single MAC SAC Test Configurations . 123
Figure 25 - Optional Master Port Permitted Path Single MAC DAC Test
Configurations . 124
Figure 26 - Optional Master Port Permitted Path Dual MAC DAC Test
Configurations . 125
Figure 27 - Ring Hold Option DAS Test Configurations . 126
iii
9314-25  ISO/IEC:1998(E)
FOREWORD
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in
the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 9314-25 was prepared by Joint Technical Committee ISO/IEC JTC 1 Information
technology, Subcommittee SC 25, Interconnection of information technology equipment.
ISO/IEC 9314 consists of the following parts, under the general title Information technology – Fibre Distributed Data
Interface (FDDI):
– 2CTV����6QMGP�4KPI�2J[UKECN�.C[GT�2TQVQEQN��2*;�
– 2CTV����6QMGP�4KPI�/GFKC�#EEGUU�%QPVTQN��/#%�
– 2CTV����2J[UKECN�.C[GT�/GFKWO�&GRGPFGPV��2/&�
– 2CTV����5KPING�/QFG�(KDTG�2J[UKECN�.C[GT�/GFKWO�&GRGPFGPV��5/(�2/&�
– 2CTV����*[DTKF�4KPI�%QPVTQN��*4%�
– 2CTV����5VCVKQP�/CPCIGOGPV��5/6�
– 2CTV����2J[UKECN�.C[GT�2TQVQEQN��2*;���
– 2CTV����/GFKC�#EEGUU�%QPVTQN����/#%���
– 2CTV����.QY�%QUV�(KDTG�– 2J[UKECN�/GFKWO�&GRGPFGPV��.%(�2/&�
– 2CTV�����6QMGP�4KPI�6YKUVGF�2CKT�2J[UKECN�NC[GT�/GFKWO�&GRGPFGPV���62�2/&�
– 2CTV�����%QPHQTOCPEG�6GUV�2TQVQEQN�+ORNGOGPVCVKQP�%QPHQTOCPEG�5VCVGOGPV
RTQHQTOC��%6�2+%5�
– 2CTV�����2J[UKECN�/GFKWO�&GRGPFGPV�%QPHQTOCPEG�6GUVKPI��2/&�#65�
– 2CTV�����2J[UKECN�.C[GT�2TQVQEQN�%QPHQTOCPEG�6GUVKPI��2*;�#65�
– 2CTV�����#DUVTCEV�6GUV�5WKVG�HQT�FDDI K�5VCVKQP�/CPCIGOGPV�%QPHQTOCPEG�6GUVKPI
�5/6�#65�
– 2CTV�����/GFKC�#EEGUU�%QPVTQN�%QPHQTOCPEG�6GUVKPI��/#%�#65�
iv
9314-25 © ISO/IEC:1998(E)
INTRODUCTION
The International Organization for Standardization (ISO) has developed a standard to
define the procedures required for Conformance Testing. These procedures are set
forth in ISO 9646, Parts 1-7. Part 3 defines the language syntax to be used for writing
Abstract Test Suites (ATS), that language is Tree and Tabular, Combined Notation
(TTCN).
The Station Management (SMT) Abstract Test Suite (ATS) directly supports the FDDI
Protocol Implementation Conformance Statement (PICS) Proforma and works in
correlation with three other FDDI ATS standards.
This ATS for FDDI SMT provides the test procedures and test cases required to test
the station management protocol described in the SMT standards. SMT specified the
local portion of the system management application process for FDDI, including the
control required for proper operation of an FDDI station in an FDDI ring. SMT
provided services such as connection management, station insertion and removal,
station initialization, configuration management, fault recovery, communication
protocol for external authority, scheduling policies and the collection of statistics. SMT
interact with PMD, PHY, and MAC for testing.
The three ATS standards when combined with SMT, that make up the complete
Conformance Test for the FDDI Protocol are:
a) An ATS for FDDI Physical Medium Dependent (PMD) that provides a
conformance test for FDDI PMD. PMD specifies the optical interface of FDDI
stations. PMD is not a protocol standard and this ATS requires the
measurement of physical quantities such as optical power, wavelength and
signal jitter. The PMD ATS differs from the methodology of higher level
protocol conformance tests written using the Tree and Tabular Combined
Notation as specified by ISO 9643-3, because the TTCN notation does not
provide a suitable vehicle for Physical Layer testing, where there is no
concept of a protocol data unit and where physical quantities must be
measured.
b) An ATS for the FDDI Physical Layer Protocol (PHY) that provides a
conformance test for FDDI PHY. PHY specifies the upper sublayer of the
Physical Layer for the FDDI, including the data encode/decode, framing and
clocking, as well as the elasticity buffer, smoothing and repeat filter functions.
FDDI PHY, however, does contain several state machines and implements a
protocol at the level of FDDI code symbols. The only physical quantity that
must be measured in this conformance test is frequency. The PHY ATS
cannot use the TTCN notation. A unique notation is developed in the PHY
ATS for specifying test patterns and expected results in terms of FDDI code
symbol strings.
c) An ATS for FDDI Media Access Control (MAC) that provides a Conformance
test for FDDI MAC. MAC specifies the lower sublayer of the Data Link Layer
for FDDI. It specifies access to the medium, including addressing, data
checking and data framing. MAC also specifies the receiver and transmitter
state machines. Since MAC is a protocol that deals primarily with complete
PDUs, the Tree and Tabular Combined Notation language specified in ISO
9643-3 is used to specify MAC protocol tests.
International Standard ISO/IEC 9314-25:1998, Information technology - Fibre
Distributed Data Interface (FDDI) - Station Management Conformance Testing (SMT-
ATS) was developed by ISO/IEC JTC 1/SC 25.
v
9314-25  ISO/IEC:1998(E)
INFORMATION TECHNOLOGY –
FIBRE DISTRIBUTED DATA INTERFACE (FDDI) –
Part 25: Abstract Test Suite for FDDI – Station Management Conformance
Testing (SMT ATS)
1  Scope
This part of ISO/IEC 9314 contains the Abstract Test Suites for the Fiber Distributed Data Interface
(FDDI) token ring Station Management (SMT) layer protocol. The SMT Protocol is extensive and very
complex. In the development process, the protocol was broken into six separate areas. Those areas
dealt with Physical Connection Management (PCM), Entity Coordination Management (ECM) Ring
Management (RMT), Configuration Management (CMT), Frame Based Management (FBM) and
Management Information Base (MIB).
This SMT ATS is divided along the same boundaries, with the exception that PCM and ECM are
combined. Those two concepts are tested together. The formal description language used for
Abstract Test Suite (ATS) development is Tree and Tabular Combined Notational (TTCN) and is
defined in ISO 9646Framework. TTCN is intended for higher layer protocol testing and requires the
use of discreet Protocol Data Units (PDUs). The TTCN notation is used in the test cases for RMT,
FBM and MIB. It cannot be used for PCM, ECM and CFM. These three protocols use line states as
the method of conveying information.
The TTCN (P) is similar in structure to TTCN but changes the paradigm from PDUs to line states. A
description of the concept of TTCN (P) can be found in the beginning of section 6, PCM.
2  Normative references
The following normative documents contain provisions which, through reference in this text, constitute
provisions of this part of ISO/IEC 9314. At the time of publication, the editions indicated were valid.
All standards are subject to revision, and parties to agreements based on this part of ISO/IEC 9314
are encouraged to investigate the possibility of applying the most recent editions of the standards
indicated below. Members of IEC and ISO maintain registers of currently valid International
Standards.
ISO/IEC 7498-1:1994, Information technology – Open Systems Interconnection – Basic Reference
Model: The Basic Model
ISO/IEC 9314-1:1989, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 1: Token Ring Physical Layer Protocol (PHY)
ISO/IEC 9314-2:1989, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 2: Token Ring Media Access Control (MAC)
ISO/IEC 9314-3:1990, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 3: Physical Layer Medium Dependent (PMD)
ISO/IEC 9314-6:1998 Information technology – Fibre Distributed Data Interface (FDDI) – Part 6:
Station Management (SMT)
ISO/IEC 9646 (all parts), Information technology – Open Systems Interconnection – Conformance
testing methodology and framework
ISO/IEC 9646-1:1994, Information technology – Open Systems Interconnection – Conformance testing
methodology and framework – Part 1: General concepts
ISO/IEC 9646-2:1994, Information technology – Open Systems Interconnection – Conformance testing
methodology and framework – Part 2: Abstract test suite specification
3 Definitions
For the purposes of this part of ISO/IEC 9314, the following definitions apply.
3.1 Abstract Test Suite (ATS): An ATS is a document, defined in ISO 9646, that depicts the suite
of tests to be run by the test implementor to define conformance to a governing standard.
9314-25  ISO/IEC:1998(E)
3.2 Frame Based Management (FBM): FBM defines the frame formats and protocols used to
manage FDDI stations on a ring in a peer-to-peer relationship.
3.3 Management Information Base (MIB):
The MIB provides the specification and capabilities of
management information and its relationships to systems management.
3.4 Connection Management (CMT):
CMT controls the establishment and maintenance of an
FDDI connection.
3.5 Physical Connection Management (PCM): PCM controls initializations of a Physical
connection, maintenance of the connection and closing of the connection.
3.6 Ring Management (RMT): RMT monitors the MAC functions in an FDDI station and supports
establishment and maintenance of an operational ring.
4  Convention and abbreviations
4.1  Conventions
4.2  Abbreviations
ATS: Abstract Test Suite;
CFM: Configuration Management;
F: Fail (when used in the verdict column of the Dynamic Behavior tables);
I: Inconclusive (when used in the verdict column of the Dynamic Behavior tables);
ILS: Idle Line State;
IUT: Implementation Under Test;
MAC: Media Access Control;
MLS: Master Line State;
P: Pass (when used in the verdict column of the Dynamic Behaviour tables);
PCM: Physical Connection Management;
PDU: Protocol Data Unit defined in terms of SMT and MAC Frames;
PHY: Physical Layer Protocol;
PICS: Protocol Implementation Conformance Statement;
PIXIT: Protocol Implementation extra Information for Testing;
TTCN: Tree and Tabular Combined Notation;
TTCN(P): Tree and Tabular Combined Notation for PCM & CFM;
QLS: Quiet Line State;
ALS: Active Line State;
HLS: Halt Line State;
ERR: Error;
RMT: Ring Management;
MIB: Management Information Base.
5  Timer definition
A set of timers, as described below, is used in the test suite, their values must be initialized prior to the
beginning of test, unless a default value is specified.
T_REQ: the Target Token Rotation Timer
(TTRT) is configured in the IUT's MAC in units of μs. This value will be converted to units of 80 ns for
MAC claim process.
9314-25  ISO/IEC:1998(E)
T_REQ1: μ
an alternate TTRT configured in the IUT's MAC in units of s. This value will be converted
to units of 80 ns for MAC claim process.
T_REQ2: an alternate TTRT configured in the Other's MAC in units of μs. This value will be converted
to units of 80 ns for MAC claim process.
T_Max: the maximum token rotation time in μs.
D_Max: the maximum ring latency. The default value is 1773 μs.
T_Non_Op: time to allow ring recovery to occur before duplicate address conditions are examined.
The default value is 1 s.
RM_React: maximum for the RMT state machine to recognize that transition conditions exist and to
execute the appropriate transition. The default value is 83 ms.
T_Jam:
time for which Jam Beacon is sent. The default value is 370 ms.
T_DBJ: time to start the second Beacon of the Double Beacon Jam after the first Beacon is sent. The
default value is 82 ms.
T-Direct:
time for which a Directed Beacon is sent before the Trace function is invoked. The default
value is 370 ms.
T_Stuck: time to allow a Stuck Beacon to be sent, followed by the initiation of a Trace. The default
value is 8 s.
T_Rmode: the maximum time allowable for Restricted Dialogue on the ring. The default value is zero
seconds for Non-Used Restricted Dialogue.
T_Announce:
the interval between sending Jam Beacons. The default value is 2 500 ms.
T_Limit: The rate-limiting interval for the Status Report Protocol. The default value is 2 s.
Topr: Time required for a test operator to initiate operation on the IUT, for example, triggering NIF
request frame to be sent from the IUT. This is used in conjunction with the TTCN Implicit Send event
for test coordination. This test suite uses a default value of 3 min.
The following are the expiration values of the timers used in PCM test cases. Whenever the name
and the value correspond to ISO/IEC 9314-6 the reference is indicated.
TB_Min
: Minimum Break time for link.
Range: TB_Min ≥ 4.823 ms with default values
Default: 5 ms (SMT PCM);
TB_Max: Break time before the BS_Flag is set. TB_Max shall be sufficiently large so that it will not be
set inadvertently by noise generated by an optical bypass switch, which is bounded by MI_Max.
Range: TB_Max ≥ 30.0 ms with default values
Default: 50 ms (SMT PCM);
MI_Max: Maximum Optical Bypass media interruption time. The range and default value for MI_Max
is specified in the PMD document.
≤ 15.0
Range: MI_Max ms
Default: 15 ms (SMT PCM)
C_Min:
Minimum time required to remain in the Connect State to ensure that the other end has
recognized Halt Line State.
Range: C_Min ≥ 1.2 ms with default values
Default: 1.6 ms (SMT PCM);
C_Second:
A timer used to check PCM wait for a change in the Connect State since it enters
Connector State from Break State and has not yet received HLS.
Default: 1 s;
9314-25  ISO/IEC:1998(E)
PC_React: Maximum time for PCM to make a state transition to Break upon receiving QLS.
Range: PC_React ≤ 3.0 ms
Default: 3 ms (SMT PCM);
LS_Min:
Length of time continuous reception of ILS is required to be used by PCM.
Range: 25 μs ≥ LS_Min ≥ 0.48 μs with default values
Default: 0.48 μs(SMT PCM);
LS_Max:
Maximum time to reestablish the correct line state as specified in the PHY document.
Range: LS_Max ≤ 25 μs
Default: 25 μs (SMT PCM);
TL_Min: Minimum time to transmit a PHY line state before advancing to the Next PCM state.
TL-Min is set to twice the time required for line state recognition(LS_Max).
≥ μ
Range: TL_Min 50 s with default values
μ
Default: 50 s (SMT PCM);
N_Second: A Timer used to check PCM wait to receive ILS in Next State
Default: 1 s;
LS_Less:
A timer which measures the amount of time that it take the IUT to make a correct Line State
transition.
Default: 0.24 μs;
T_Out: Signaling timeout. The minimum time that a PCM State Machine will remain in a state
awaiting a line state change. When a line state change is expected and no transition is made in
T_Out time, a transition shall be made to the Break State.
Range: T_Out ≥ 100 ms
Default: 100 ms (SMT PCM);
LC_Short: Short Link Confidence Test Time
Range: LC_Short > 5*10(4) ns
Default: 50 ms (SMT PCM);
LC_Medium: Medium Link Confidence Test Time.
Range: LC_Medium ≥ 50 *10(LER_Cutoff) ns
Default: 500 ms (SMT PCM);
LC_Long: Long Link Confidence Test Time.
≥
Range: LC_Long 500 * 10 (LER_ Cutoff) ns
Default: 5 s (SMT PCM);
LC_Extended:
Extended Link Confidence Test Time.
Range: LC_Extended ≥ 50 s
Default: 50 s (SMT PCM);
T_Next(7): LC_Test, Time for Link Confidence Test (SMT PCM);
B_Second: A timer used to check when IUT detects Link Error Rate exceeds the LER_Cutoff
threshold; it enters Break State and transmits QLS.
Default: 1 s;
T_Next(9):
Time for the optional MAC Local Loop to prevent deadlock. This allows sufficient time for
MAC recovery process completion and the exchange of neighbor information frames.
Range: T_Next(9) ≥200 ms
Default: 200 ms (SMT PCM).
9314-25  ISO/IEC:1998(E)
NS_Max: The maximum length of time that noise as measured by TNE, is allowed before a connection
is broken down and restarted.
Range: 5.8 ms ≥ NS_Max ≥ 0.7255 ms
Default: 1.3 ms (SMT PCM);
Trace_Max: Maximum propagation time for a Trace on an FDDI topology. Trace_Max places a lower
bound on the detection time for a nonrecovering ring (T_Stuck)
≥
Range: Trace_Max 6.001773 s with default values
Default: 7.0 s
6  Physical Connection Management (PCM) & Entity Coordination
Management (ECM) - Abstract Test Suites
6.1  Notation for PCM Tests
PCM is implemented as a complex state
machine and it is therefore highly desirable to use a formal notation to specify precisely conformance
tests. One such formal notation is the Tree and Tabular Combined Notation (TTCN) as defined in ISO
9646-3. However PCM does not fit the TTCN paradigm well. The primary problem is that TTCN, which
is intended for higher level protocol tests, requires that the protocol uses discrete Protocol Data Units
(PDUs). It assumes that these PDUs are queued when received and that the TTCN "?" operator tests
the PDU at the front of the receive queue. PCM signaling does not use PDUs but instead uses line
states as the method of conveying information.
This document uses a notation called TTCN(P) to express the PCM tests. It is similar to TTCN, but
changes the paradigm somewhat and simplifies the notation.
The key to understanding TTCN(P) is that the Implementation Under Test (IUT) is always considered
to take on one of the following values:
•
Quiet Line State (QLS)
•
Idle Line State (ILS)
• Halt Line State (HLS)
• Master Line State (MLS)
• Active Line State (ALS)
• Noise Line State (NLS)
• Line State Unknown (LSU)
No other values can be set.
NLS is defined to be any condition which occurs in any of the other line states, which satisfies the
conditions for termination of that state but does not satisfy the criteria for entry into any of the other line
state. The tester never transmits NLS, and, in most cases the reception of NLS causes the IUT to fail
the test.
The TTCN(P) "?" operator tests the contents of a received line state register in the tester, for example,
the test ?ILS is satisfied if the current line state is ILS.
The tester is either transmitting a predefined MAC frame, repeating symbols received when its input is
in ALS or is continuously transmitting one of the following:
• QLS
• ILS
• HLS
• MLS
•
ERR
•
Port_Type
ERR is a special pattern transmitted during the Link Confidence Test.
Port_Type is used to mean either HLS or MLS as appropriate. This notation is used to reduce the
number of separate routines. In particular the port type, which is signaled in the Signal States when
9314-25  ISO/IEC:1998(E)
n=1 and n=2, is irrelevant to many test cases. Therefore the tests include subroutines, whose purpose
is simply to step the IUT to the state where the actual test begins, use the Port_Type notation to allow
the same routine to serve several port types.
A TTCN(P) test procedure consists of a sequence of event lines specifying an event or an action to
take place at a given instant during the testing. The time progression is represented by the indentation
number to the left of every event line in the form of [1], [2], etc. An event line may be one of the
following: start transmitting line state symbols, check the current line state, start and test expiration of
timers, invoke other test procedures (tree attachment), and a GOTO statement. These events are
written in the format shown below:
[n] !line-state    /* Start transmitting
line-state symbols as specified, e.g. HLS */
[n] !Repeat      /* Repeat input symbols received while input is in ALS, starting with the J symbol
and stopping with the first V, I or H symbol. When V or H symbols are encountered the Repeat Filter
rules of PHY are observed */
[n]!Packet      /* cause the tester to transmit a single MAC Packet; when transmission of the
packet is complete, the tester transmits ILS */
[n] ?line-state    /* check if the current line state is in a specific state */
[n] ?OTHERWISE    /* any line state */
[n] START timer-name /* start the timer with pre-specified duration */
[n] ?TIMEOUT timer-name /* test for
expiration for the specified timer */
[n] +test-procedure-name  /* call another test procedure */
[n] GOTO label       /* goto another event line with indicated label */
As in many programming languages, a comment is a character string of the following form:
/* Text of comment */
A label for an event line is denoted by a sequence of letters ending with a ":", and appears after the
indentation level number, for example,
[3] L1:?TIMEOUT C_min.
The "!" Transmit event means that the tester begins sending the indicated line state and
continues sending it until another "!" operator is encountered.
The START timer event may be combined with the Transmit (!) or Line state check (?) event lines.
Multiple timers may be started on the same event. For example,
[1] !QLS START TB_Min, START TB_Max.
The event lines are evaluated starting from the first indentation level, [1]. There may be several event
lines at each indentation level. These event lines represent a set of alternatives and the tester must
wait for at least one of them to occur before proceeding to the next indentation level. If multiple events
occur at the same time, the event line appearing first applies. A transmit event line (!) is considered to
have occurred or completed when the transmission of the specified line state symbols is initiated. A
line state check event (?) is satisfied when the current line state matches the specified state.
When an event line is satisfied, the tester moves on to the next indentation level following that event
line. If there is no higher level event line, then the test is complete. If a completed event line contains
a verdict specification, the test is also considered completed, even if there is a higher indentation level
event line following.
The event lines, with the exception of GOTO, SEND and Tree Attachment Event, may assign one of
these verdicts: PASS, FAIL, or INCONCLUSIVE.
A GOTO event can only specify the labels appearing on the first line of an indentation level that is
lower or equal to the current indentation level.
An event line that invokes another procedure is considered not satisfied if none of the first level event
lines in that procedure have occurred.
9314-25  ISO/IEC:1998(E)
−
Note that PCM is intended to operate in very noisy environments (perhaps as bad as a BER of 10
and does not generally react to brief noise events. We do not simulate noise in our PCM tests except
for the Link Quality Tests; rather we expect that the IUT and the tester transmit nothing but clean line
states without any errors. If the IUT transmits NLS or LSU it is always grounds for failure.
"TTCN(P) does not use the normal TTCN Constraints. This is because the Constraints section of
TTCN uses PDUs rather than Line States to define Constraints.
An example illustrates the TTCN(P) notation. This example is the test case To_Next specified in
6.2.1.5:
Procedure:
[1]+Start_To_Connect
[2] !HLS Start C_Min
[3]  A:?Timeout C_Min /*Comment*/
[4]   B:?HLS
[5]    Goto B
[4]   ?ILS Pass
[4]   ?Otherwise Fail(2)
[3]  ?HLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
In To_Next the procedure Start_To_Connect is attached by the first statement:
[1]+Start_To_Connect, which is specified in 6.3.2, is:
Procedure:
[1]!QLS Start TB_Min
[2] ?Timeout TB_Min
[3]  A:?QLS
[4]   Goto A
[3]  ?HLS    /*Comment*/
[3]  ?Otherwise Inconclusive
The key to understanding the attachment is that the attaching test is attached to each of the terminal
leaves of the attached routine. A terminal leaf is any statement other than a GOTO that has no lower
layer and is not qualified with Pass, Fail or Inconclusive verdict. In Start_To_Connect there is one
terminal leaf:
[3]  ?HLS
To_Next
Each test has a specific purpose. The purpose of is to verify that the IUT remains in the
Start_To_Connect
Connect State for at least C_Min before going to the Next State. is used simply to
bring the IUT to the Connect State. Therefore it is a simple routine to progress a correct IUT to the
Connect State and does not attempt to test all the requirements of PCM to get to the Connect State;
these are tested elsewhere in an incremental fashion.
Start_To_Connect
The first statement of , and the only statement at level 1 is:
[1]!QLS Start TB_Min
This statement causes the tester to transmit QLS and to start the TB_Min timer.
Control falls to the next statement at level 2:
[2]   ?Timeout TB_Min
This statement causes the tester to wait, still sending QLS, until the timer TB_Min expires, since there
is no alternative at this level. This should cause the IUT to go to the Break State. There are three
alternatives at level 3:
[3]   A:?QLS
[3]   ?HLS
[3]   ?Otherwise Inconclusive
9314-25  ISO/IEC:1998(E)
Alternatives at the same level are evaluated in order and then the evaluation is repeated until one of
the alternatives becomes true. One of the alternatives is always true because of the otherwise
statement. At this point the IUT should either be transmitting QLS or HLS; if not, something is wrong.
However, because this is not the point of the test, we label the otherwise "Inconclusive" rather than
"fail". If we receive QLS, then we fall down to the following statement at level 4:
[4]    Goto A
This statement just returns the tester to level 3 at A and we loop back and evaluate the same three
alternatives. Eventually the IUT should transmit HLS (signifying that it has entered the Connect State,
the second alternative became true, Start_To_Connect has reached a terminal leaf), and control
passes to the attaching test routine To_Next.
When the Start_To_Connect completes control passes to level 2, where there is one alternative:
[2] !HLS Start C_Min
This statement causes the tester to transmit HLS and to start the timer C_Min. Control then passes to
level 3 and the following alternatives:
[3]   A:?Timeout C_Min /*Comment*/
.
.
[3]   ?HLS
[3]   ?Otherwise  Fail(1)
The test purpose is to see if the IUT remains in the Connect State for at least C_Min before going to
the Next State, therefore if any signal other than HLS (signifying Connect State) is received before
C_Min expires, the Otherwise statement causes the test to fail. The "(1)" is a parameter used to
distinguish between possibly different failure points. As long as HLS is received control will fall to a
GOTO at level 4, which loops control back to B:
[4]    Goto A
Finally, when C_Min times out, control falls to:
[4]   B:?HLS
[5]    Goto B
[4]   ?ILS Pass
[4]   ?Otherwise Fail(2)
As long as HLS is received, the tester continues to loop back to level 4. If ILS is received, then the IUT
has made the transition to the Next State after waiting for at least C_Min and this test is passed. If
anything else is received, then the test is failed.
Note that we can expand the attachment of Start_To_Connect by To_Next and get the following
equivalent test routine:
Procedure:
[1]!QLS Start TB_Min
[2] ?Timeout TB_Min
[3]  A:?QLS
[4]   Goto A
[3]  ?HLS
[4]   !HLS Start C_Min
[5]    B:?Timeout C_Min /*Comment*/
[6]     C:?HLS
[7]      Goto C
[6]     ?ILS Pass
[6]     ?Otherwise Fail(2)
[5]    ?HLS
[6]     Goto B
[5]    ?Otherwise Fail(1)
[3]  ?Otherwise Inconclusive
9314-25  ISO/IEC:1998(E)
6.2  Test Cases
6.2.1  Connection Initialization Test:
6.2.1.1  Case-ID: To_Connect_1
Purpose: Verify that IUT enters the Connect state after remaining in the Break state for at least
TB_Min when it receives QLS.
Test Setup: See figure 1.
LST IUT
X Port
X Port
Tx Rx Tx Rx
Figure 1 - Tester Configuration for Indicated Cases

Procedure:
[1]+Init        /*Comment(1)*/
[2] !QLS Start TB_Min /*Comment(2)*/
[3]  A:?Timeout TB_Min
[4]   B:?QLS
[5]    Goto B
[4]   ?HLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?QLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) The Init function (6.3.1 of this document) is called to let the IUT start from the Break State.
(2) In the Break State, the Tester transmits QLS, starts the timer TB_Min to ensure that the IUT
remains in the Break State for at least TB_Min. (PC-13)
Reasons for Failure:
(1) Initially, the IUT is in the Break State while QLS is transmitted for at least TB_Min. If the IUT does
not transmit QLS within TB_Min, then the IUT fails.
(2) The IUT transmits QLS while in the Break State and HLS when it enters the Connect State. Any
other output is invalid.
6.2.1.2  Case-ID: To_Connect_2
Procedure:
[1]+Init/*Comment(1)*/
[2] !HLS Start TB_Min /*Comment(2)*/
[3]  A:?Timeout TB_Min
[4]   B:?QLS
[5]    Goto B
[4]   ?HLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?QLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
9314-25  ISO/IEC:1998(E)
Extended Comments:
(1) The Init function (6.3.1 of this document) is called to let the IUT start from the Break state.
(2) In the Break state, the Tester transmits HLS, starts the timer TB_Min to ensure that the IUT
remains in the Break state for at least TB_Min. (PC-13)
Reasons for Failure:
(1) IUT must transmit QLS for TB_Min at the beginning of this procedure. If it does not meet this
requirement then the IUT fails.
(2) After remaining in the Break State for longer than TB_Min, the IUT may either stay in Break or
change to Connect. If the IUT transmits any line state other than QLS or HLS, the test fails.
6.2.1.3  Case-ID: Wait_for_Connect

Purpose: Show that the IUT progresses to Connect from the Break State and remains in the Connect
State until HLS is received.
Test Setup: See figure 1.
Procedure:
[1]+Init
[2] !QLS
[3]  A:?QLS
[4]   Goto A
[3]  ?HLS /*Comment(1)*/
[4]   Start C_Second /*Comment(2)*/
[5]    B:?Timeout C_Second Pass
[5]    ?HLS
[6]     Goto B
[5]    ?Otherwise Fail(2)
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) IUT enters the Connect State from the Break State and transmit HLS. (Connect_Actions)
(2) In this step, the IUT is in the Connect State, it is going to receive a sequence of HLS to process to
the Next State. At this point, The Tester keeps sending QLS to the IUT to see what happen on the
IUT. (PC-33)
Reasons for Failure:
(1) IUT transmit QLS when it enters the Break State. After TB_Min, it must enter the Connect State
and transmit HLS. If the IUT does not transmit QLS followed by HLS then the IUT fails.
(2) When the IUT enters the Connect state, it will enter the Next state after receiving sufficient HLS.
The tester remains in the Break state which should cause the IUT to remain in the Connect state
forever. If the IUT transmits other than HLS then it is failed.
6.2.1.4  Case-ID: Connect_Error
Purpose:
Verify that the IUT enters the Break
State if the ILS is received before HLS is received in the Connect State.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Connect /*Comment*/
[2] !ILS Start T_Out
[3]  A:?Timeout T_Out Fail(1)
[3]  ?HLS
[4]   Goto A
[3]  ?QLS Pass
[3]  ?Otherwise Fail(2)
Extended Comments:
The IUT is in the Connect State (see 6.3.2).
9314-25  ISO/IEC:1998(E)
Reasons for Failure:
(1) If the IUT does not enter the Break State within T_Out when ILS is received before HLS is re-
ceived, the IUT fails. (PC-33, PC-31b)
(2) IUT may either be in the Connect State (not changed to Break State yet) or in the Break State
otherwise it is failed.
6.2.1.5  Case-ID: To_Next
Purpose:
Verify that the IUT remains in the Connect State for at least C_Min before entering the Next
State.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Connect
[2] !HLS Start C_Min
[3]  A:?Timeout C_Min /*Comment*/
[4]   B:?HLS
[5]    Goto B
[4]   ?ILS Pass
[4]   ?Otherwise Fail(2)
[3]  ?HLS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
IUT enters the Connect State from the Break State and must remain in the Connect State for at least
C_Min. (PC-33, PC-34)
Reasons for Failure:
(1) When the IUT enters the Connect State, it remains for at least C_Min. If the C_Min timer does not
timeout and the IUT does not transmit HLS then the IUT fails.
(2) After C_Min, the IUT may stay in the Connect State or enter the Next State. If the IUT transmits a
Line State other than HLS or ILS then the IUT fails.
6.2.1.6  Case-ID: Next_0
Purpose: Verify that the IUT remains in the Next State for at least TL_Min.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next /*Comment*/
[2] !ILS Start TL_Min
[3]  A:?Timeout TL_Min
[4]   B:?ILS
[5]    Goto B
[4]   ?MLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
IUT is in the Next State with n=0.
Reasons for Failure:
(1) Initially, the IUT is in the Next State, ILS is transmitted for at least TL_Min. After TL_Min, the IUT
may remain in the Next or enter the Signal State. If the IUT does not transmit ILS and TL_Min is not
expired, then the IUT fails. (PC-44b, Next_Actions)
(2) After TL_Min, the IUT may remain in the Next State or enter the Signal State. If the IUT does not
transmit ILS or MLS, then the IUT fails.
9314-25  ISO/IEC:1998(E)
6.2.1.7  Case-ID: Wait_In_Next
Purpose: Verify that the IUT will not enter the Signal State until ILS is received for at least LS_Min.
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next
[2] !ILS Start LS_Less, Start N_Second
[3]  A:?Timeout LS_Less /*Comment(1)*/
[4]   !MLS /*Comment(2)*/
[5]    B:?Timeout N_Second Pass
[5]    ?ILS /*Comment(3)*/
[6]     Goto B
[5]    ?QLS Pass
[5]    ?Otherwise Fail(2)
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) LS_Less is a timer which is set to half the time required for LS_Min (the default value of LS_Less
is 0.24 microseconds). It is to verify that the IUT will wait in the Next State without changing to the
Signal State (the Tester sends ILS for 0.24 microseconds) unless it receives ILS for at least LS_Min.
(0.48 microseconds)
(2) Tester continuously transmits MLS to the IUT.
(3) IUT will stay in the Next State, if ILS is not received for longer than LS_Min.
(PC-44a, PC-44b)
Reasons for Failure:
(1) IUT does not remain in the Next State to transmit ILS or LS_Less is not expired.
(2) If the IUT does not receive sufficient ILS, the IUT enters the Next State from the Connect State, it
must wait to receive enough ILS. So, if the IUT does not transmit ILS (IUT may not remain in the Next
State) and the N_Second timer is not expired then the IUT fails.
(PC-44a, PC-44b)
6.2.1.8  Case-ID: Next_Error1
Purpose: Verify that the IUT transitions from the Next state to Break, if QLS is received. (PC-41b)
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next
[2] !QLS Start PC_React
[3]  A:?Timeout PC_React Fail(2)
[3]  ?QLS Pass
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Reasons for Failure:
(1) IUT does not transmit ILS, QLS and PC_React is not expired.
(2) IUT does not enter the Break State within PC_React when QLS is received. (PC-41b, Next_Error,
Break_Actions)
6.2.1.9  Case-ID: Next_Error2
Purpose: Verify that the IUT transitions from the Next state to Break, if T_Out expires prior to the IUT
receiving ILS, with n > zero. (PC-41b)
Test Setup: See figure 1.
9314-25  ISO/IEC:1998(E)
Procedure:
[1]+To_Next_0 /*Comment*/
[2] !MLS Start T_Out
[3]  A:?Timeout T_Out
[4]   ?QLS Pass
[4]   ?Otherwise Fail(2)
[3]  ?ILS
[4]   Goto A
[3]  ?Otherwise Fail(1)
Extended Comments: The IUT enters the Next State with n=1.
Reasons for Failure:
(1) IUT does not transmit ILS or T_Out is not expired.
(2) IUT does not enter the Break State from Next because ILS has not been received for T_Out and n
is greater than zero since entering the Next State. (Next_Error, Break_Actions)
6.2.1.10  Case-ID: Signal_Error1
Purpose: Verify that the IUT transitions from the Signal state to Break if QLS is received. (PC-51b)
Test Setup: See figure 1.
Procedure:
[1]+Start_To_Next /*Comment(1)*/
[2] !ILS
[3]  A:?ILS /*Comment(2)*/
[4]   Goto A
[3]  ?MLS /*Comment(3)*/
[4]   !QLS Start PC_React
[5]    B:?Timeout PC_React Fail(2)
[5]    ?MLS
[6]     Goto B
[5]    ?QLS Pass
[5]    ?Otherwise Fail(3)
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) IUT is in Next State with n = 0.
(2) Tester keeps receiving ILS from the IUT until the IUT changes to the Signal State and transmits
MLS.
(3) IUT enters the Signal State and transmits MLS. (PC-54, T_Val(0), Signal_Actions)
Reasons for Failure:
(1) Initially, the IUT is in the Next State, ILS is transmitted. After TL-Min, the IUT enters the Signal
State. If the IUT does not transmit ILS, MLS then the IUT fails.
(2) IUT does not enter the Break State while QLS is received for PC_React in the Signal State.
(PC-41b, Next_Error, Break_Actions)
(3) IUT does not transmit QLS, MLS or PC_React has not timed out.
6.2.1.11  Case-ID: Signal_Error2

Purpose: Verify that the IUT transitions from the Signal state to the Break state if the MLS or HLS has
not been received for a period T_Out. (PC-51b)
Test Setup:
See figure 1.
9314-25  ISO/IEC:1998(E)
Procedure:
[1]+Start_To_Next /*Comment(1)*/
[2] !ILS
[3]  A:?ILS /*Comment(2)*/
[4]   Goto A
[3]  ?MLS /*Comment(3)*/
[4]   Start T_Out
[5]    B:?Timeout T_Out
[6]     ?QLS Pass
[6]     ?Otherwise Fail(3)
[5]    ?MLS
[6]     Goto B
[5]    ?Otherwise Fail(2)
[3]  ?Otherwise Fail(1)
Extended Comments:
(1) IUT enters the Next State with n=0.
(2) Tester keeps receiving ILS until IUT enters the Signal State and transmits MLS.
(3) IUT enters the Signal State and transmits MLS. (PC-54, T_Val(0), Signal_Actions)
Reasons for Failure:
(1) Initially, the IUT is in the Next State transmitting ILS for at least TL_Min. The IUT enters the Signal
State and transmits MLS. If the IUT does not transmit ILS or MLS, then the IUT fails.
(2) If the IUT does not transmit MLS, the test fails.
(3) If MLS is not received within T_Out, the IUT transitions to the Break State and transmits QLS. If the
IUT does not transmit QLS, the test fails. This is a test of the break state response.
(PC-
...