ISO 21111-6:2021

INTERNATIONAL ISO
STANDARD 21111-6
First edition
2021-11
Road vehicles — In-vehicle Ethernet —
Part 6:
Electrical 100-Mbit/s physical entity
requirements and conformance test
plan
Véhicules routiers — Ethernet embarqué —
Partie 6: Exigences et plan de tests de conformité de l’entité physique
à 100-Mbit/s électrique
Reference number
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword . vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.2
4.1 Symbols . 2
4.2 Abbreviated terms . 2
5 Conventions . 4
6 Wake-up and sleep features.4
6.1 Extension of physical coding sub-layer . 4
6.2 Service primitives and interfaces . 6
6.3 Power sequencing states . 7
6.4 Command definitions . 8
6.4.1 General . 8
6.4.2 Low power sleep (LPS) . 8
6.4.3 Wake-up request (WUR) . 9
6.4.4 Wake-up pulse (WUP) . 9
6.5 Generation of scrambling bits Sdn[2:0] . 9
6.6 PCS PHY control state diagram . . 10
7 CTP test system and CTC structure .12
7.1 General .12
7.2 Test system set-up – Transmit test system . 13
7.3 Test system set-up – Receive test system . 14
7.4 CTC structure . 15
8 PHY – Control IUT conformance test plan (with MII access) .16
8.1 PHY – Group 1: PHY control and timers (with MII access) . 16
8.1.1 Overview . 16
8.1.2 CTC_4.1.1 – PMA reset (with MII access) . 16
8.1.3 CTC_4.1.2 – Value of minwait_timer – minwait_timer in TRAINING state
(with MII access) . 17
8.1.4 CTC_4.1.3 – Value of maxwait_timer (with MII access) . 21
8.1.5 CTC_4.1.4 – Value of stabilize_timer (with MII access) .22
8.2 PHY – Group 2: PHY control state diagram (with MII access) . 23
8.2.1 Overview . 23
8.2.2 CTC_4.2.1 – PHY control state diagram - DISABLE TRANSMITTER state (with
MII access) . 23
8.2.3 CTC_4.2.2 – PHY control state diagram - SLAVE SILENT state (with MII
access) . 24
8.2.4 CTC_4.2.3 – PHY control state diagram – TRAINING state (with MII access) .25
8.2.5 CTC_4.2.4 – PHY control state diagram – SEND IDLE state (with MII access) .28
8.2.6 CTC_4.2.5 – PHY control state diagram – SEND IDLE OR DATA state (with
MII access) . 31
8.3 PHY – Group 3: PHY link monitor state diagram (with MII access). 35
8.3.1 Overview . 35
8.3.2 CTC_4.3.1 – Link monitor state diagram – IUT does not enter the LINK OK
state (with MII access).36
9 PCS – IUT conformance test plan (with MII access) .38
9.1 PCS – Group 1: PCS transmit (with MII access).38
9.1.1 Overview .38
9.1.2 CTC_3.1.1 – PCS signalling (with MII access) .39
iii
9.1.3 CTC_3.1.2 – PCS reset (with MII access) . 41
9.1.4 CTC_3.1.3 – PCS transmit proper SSD (with MII access) . 41
9.1.5 CTC_3.1.4 – PCS transmit proper ESD (with MII access) . 42
9.1.6 CTC_3.1.5 – PCS transmit ESD with tx_error (with MII access). 43
9.1.7 CTC_3.1.6 – PCS transmission of stuff bits (with MII access) .44
9.1.8 CTC_3.1.7 – PCS tx_error (with MII access) .44
9.2 PCS – Group 2: PCS transmit state diagram (with MII access) .46
9.2.1 Overview .46
9.2.2 CTC_3.2.1 – PCS transmit state diagram - SEND IDLE state (with MII access) .46
9.2.3 CTC_3.2.2 – PCS transmit state diagram - SSD1 VECTOR and SSD2 VECTOR
states (with MII access) . 47
9.2.4 CTC_3.2.3 – PCS transmit state diagram - SSD3 VECTOR state (with MII
access) . 47
9.2.5 CTC_3.2.4 – PCS transmit state diagram - TRANSMIT DATA state (with MII
access) .49
9.2.6 CTC_3.2.5 – PCS transmit state diagram - ESD1 VECTOR state (with MII
access) .50
9.2.7 CTC_3.2.6 – PCS transmit state diagram - ESD2 VECTOR state (with MII
access) .50
9.2.8 CTC_3.2.7 – PCS transmit state diagram - ESD3 VECTOR state (with MII
access) . 51
9.2.9 CTC_3.2.8 – PCS transmit state diagram - ERR ESD1 VECTOR state (with MII
access) . 52
9.2.10 CTC_3.2.9 – PCS transmit state diagram - ERR ESD2 VECTOR state (with MII
access) . 53
9.2.11 CTC_3.2.10 – PCS transmit state diagram - ERR ESD3 VECTOR state (with
MII access) .54
9.3 PCS – Group 3: PCS receive (with MII access) .54
9.3.1 Overview .54
9.3.2 CTC_3.3.1 – PCS receive signalling (with MII access) .54
9.3.3 CTC_3.3.2 – PCS automatic polarity detection (with MII access) .55
9.3.4 CTC_3.3.3 – PCS receive SSD (with MII access) .56
9.3.5 CTC_3.3.4 – PCS receive ESD (with MII access) . 57
9.3.6 CTC_3.3.5 – PCS receive ERR ESD3 (with MII access) . 57
9.3.7 CTC_3.3.6 – PCS reception of stuff bits (with MII access) .58
9.3.8 CTC_3.3.7 – PCS de-interleave ternary pairs (with MII access) . 59
9.4 PCS – Group 4: PCS receive state diagram (with MII access) . 59
9.4.1 Overview . 59
9.4.2 CTC_3.4.1 – PCS receive state diagram (with MII access) - IDLE state . 59
9.4.3 CTC_3.4.2 – PCS receive state diagram (with MII access) - CHECK SSD2 state .60
9.4.4 CTC_3.4.3 – PCS receive state diagram (with MII access) - CHECK SSD3 state . 61
9.4.5 CTC_3.4.4 – PCS receive state diagram (with MII access) - SSD state . 61
9.4.6 CTC_3.4.5 – PCS receive state diagram (with MII access) - BAD SSD state . 62
9.4.7 CTC_3.4.6 – PCS receive state diagram (with MII access) - FIRST SSD state .63
9.4.8 CTC_3.4.7 – PCS receive state diagram (with MII access) - SECOND SSD state .64
9.4.9 CTC_3.4.8 – PCS receive state diagram (with MII access) - THIRD SSD state .65
9.4.10 CTC_3.4.9 – PCS receive state diagram (with MII access) - DATA state .65
9.4.11 CTC_3.4.10 – PCS receive state diagram (with MII access) - CHECK ESD2
state .66
9.4.12 CTC_3.4.11 – PCS receive state diagram (with MII access) - CHECK ESD3
state . 67
9.4.13 CTC_3.4.12 – PCS receive state diagram (with MII access) – BAD ESD2 state .68
9.4.14 CTC_3.4.13 – PCS receive state diagram (with MII access) - BAD END and
RX ERROR states . 69
9.5 PCS – Group 5: PCS JAB state diagram (with MII access) . 70
9.5.1 Overview . 70
9.5.2 CTC_3.5.1 – PCS JAB state diagram (with MII access) - rcv_max_timer . 70
10 PMA – IUT requirements and conformance test plan (with MII access) .71
iv
10.1 PMA – Group 1: PMA electrical measurements (with MII access) . 71
10.1.1 Overview . 71
10.1.2 CTC_5.1.1 – PMA maximum transmitter output droop (with MII access) . 71
10.1.3 CTC_5.1.2 – PMA transmitter distortion (with MII access) .72
10.1.4 CTC_5.1.3 – PMA transmitter timing jitter (with MII access) .73
10.1.5 CTC_5.1.4 – PMA transmitter power spectral density (PSD) (with MII
access) .74
10.1.6 CTC_5.1.5 – PMA transmit clock frequency (with MII access). 76
10.1.7 CTC_5.1.6 – PMA MDI return loss (with MII access) .77
10.1.8 CTC_5.1.7 – PMA MDI mode conversion loss (with MII access) .79
10.1.9 CTC_5.1.8 – PMA transmitter peak differential output (with MII access) .82
10.2 PMA – Group 2: PMA receive tests (with MII access) .83
10.2.1 Group 2 overview.83
10.2.2 CTC_5.2.1 – PMA bit error rate verification (with MII access) .83
10.2.3 CTC_5.2.2 – PMA receiver frequency tolerance (with MII access) .84
10.2.4 CTC_5.2.3 – PMA alien crosstalk noise rejection (with MII access).85
Annex A (informative) PHY control – Test suite .87
Annex B (normative) PCS – Test suite .91
Annex C (normative) PMA – Test system set-ups .110
Bibliography . 123
v
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
A list of all parts in the ISO 21111 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
vi
Introduction
The ISO 21111 series includes in-vehicle Ethernet requirements and test plans that are disseminated in
other International Standards and complements them with additional test methods and requirements.
The resulting requirement and test plans are structured in different documents following the Open
Systems Interconnection (OSI) reference model and grouping the documents that depend on the
physical media and bit rate used.
In general, the Ethernet requirements are specified in ISO/IEC/IEEE 8802-3. The ISO 21111 series
provides supplemental specifications (e.g. wake-up, I/O functionality), which are required for in-vehicle
Ethernet applications. In road vehicles, Ethernet networks are used for different purposes requiring
different bit-rates. Currently, the ISO 21111 series specifies the 1-Gbit/s optical and 100-Mbit/s
electrical physical layer.
The ISO 21111 series contains requirement specifications and test methods related to the in-vehicle
Ethernet. This includes requirement specifications for physical layer entity (e.g. connectors, physical
layer implementations) providers, device (e.g. electronic control units, gateway units) suppliers, and
system (e.g. network systems) designers. Additionally, there are test methods specified for conformance
testing and for interoperability testing.
Safety (electrical safety, protection, fire, etc.) and electromagnetic compatibility (EMC) requirements
are out of the scope of the ISO 21111 series.
The structure of the specifications given in the ISO 21111 series complies with the Open Systems
[1] [3]
Interconnection (OSI) reference model is specified in ISO/IEC 7498-1 and ISO/IEC 10731 .
ISO 21111-1 defines the terms which are used in this series of standards and provides an overview
of the standards for in-vehicle Ethernet including the complementary relations to ISO/IEC/IEEE 8802-
3 and the amendments, the document structure, type of physical entities, in-vehicle Ethernet specific
functionalities, and so on.
ISO 21111-2 specifies the interface between reconciliation sublayer and physical entity including
reduced gigabit media independent interface (RGMII), and the common physical entity wake-up and
synchronised link sleep functionalities, independent from physical media and bit rate.
ISO 21111-3 specifies supplemental requirements to a physical layer capable of transmitting
1-Gbit/s over plastic optical fibre compliant with ISO/IEC/IEEE 8802-3, with specific application to
communications inside road vehicles, and a test plan for physical entity conformance testing.
[3]
ISO 21111-4 specifies the optical components requirements and test methods for 1-Gbit/s optical in-
vehicle Ethernet.
ISO 21111-5 specifies, for 1-Gbit/s optical in-vehicle Ethernet, requirements on the physical layer at
system level, requirements on the interoperability test set-ups, the interoperability test plan that checks
the requirements for the physical layer at system level, requirements on the device-level physical layer
conformance test set-ups, and device-level physical layer conformance test plan that checks a set of
requirements for the OSI physical layer that are relevant for device vendors.
This document specifies advanced features of an ISO/IEC/IEEE 8802-3 in-vehicle Ethernet physical
layer (often also called transceiver), e.g. for diagnostic purposes for in-vehicle Ethernet physical layers.
It specifies advanced physical layer features, wake-up and sleep features, physical layer test suite,
physical layer control requirements and conformance test plan, physical sublayers test suite, and
physical sublayers requirements and conformance test plan.
ISO 21111-7 specifies the implementation for ISO/IEC/IEEE 8802-3, which defines the interface
implementation for automotive applications together with requirements on components used to realize
this Bus Interface Network (BIN). ISO 21111-7 also defines further testing and system requirements
for systems implemented according to the system specification. In addition, ISO 21111-7 defines
the channels for tests of transceivers with a test wiring harness that simulates various electrical
communication channels.
vii
ISO 21111-8 specifies the transmission media, the channel performance, and the tests for an ISO/IEC/
IEEE 8802-3 in-vehicle Ethernet.
ISO 21111-9 specifies the data link layer requirements and conformance test plan. It specifies the
requirements and test plan for devices and systems with bridge functionality.
ISO 21111-10 specifies the application to session layer requirements and conformance test plan. It
specifies the requirements and conformance test plan for devices and systems that include functionality
related with OSI layers from 7 to 5.
ISO 21111-11 specifies the transport to network layer requirements and conformance test plan. It
specifies the requirements and conformance test plan for devices and systems that include functionality
related with OSI layers from 4 and 3.
Figure 1 shows the parts of the ISO 21111 series and the document structure.
Figure 1 — In-vehicle Ethernet document reference according to OSI model
viii
INTERNATIONAL STANDARD ISO 21111-6:2021(E)
Road vehicles — In-vehicle Ethernet —
Part 6:
Electrical 100-Mbit/s physical entity requirements and
conformance test plan
1 Scope
This document specifies advanced features of an ISO/IEC/IEEE 8802-3 automotive Ethernet PHY (often
also called transceiver), e.g. for diagnostic purposes for automotive Ethernet PHYs.
This document specifies:
— advanced PHY features;
— wake-up and sleep features;
— PHY test suite;
— PHY control IUT requirements and conformance test plan;
— PCS test suite;
— PCS IUT requirements and conformance test plan;
— PMA test suite; and
— PMA IUT requirements and conformance test plan.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9646-1, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 1: General concepts
ISO 21111-1, Road vehicles — In-vehicle Ethernet — Part 1: General information and definitions
ISO 21111-2, Road vehicles — In-vehicle Ethernet — Part 2: Common physical entity requirements
ISO/IEC/IEEE 8802-3:2021, Telecommunications and exchange between information technology systems
— Requirements for local and metropolitan area networks — Part 3: Standard for Ethernet
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21111-1, ISO/IEC 9646-1 and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
automotive cable
balanced 100-Ω one pair cable having characteristics defined in ISO/IEC/IEEE 8802-3:2021, 96.7
physical layer specifications and management parameters for 100-Mbit/s operation over a single
balanced twisted pair cable
3.2
short automotive cable
cable complying with automotive cable (3.1) used for test purposes and limited in length to reduce the
amount of loss between the IUT transmitter and test and measurement equipment
3.3
PHY frame
normal data transmission consisting of SEND_N code groups defined in ISO/IEC/IEEE 8802-3:2021,
96.3.3.3.7 and which begins with a valid start-of-stream delimiter (SSD) and ends with a valid end-of-
stream delimiter (ESD)
3.4
monitor
test system used to capture and decode the transmissions from the IUT
Note 1 to entry: See B.2.
4 Symbols and abbreviated terms
4.1 Symbols
⎼ empty table cell or feature undefined
Sdc11
L
CL
longitudinal conversion loss ( )
Sdc22
L longitudinal conversion transmission loss
CTL
P power spectral density
SD
T transverse conversion loss
CL
T transverse conversion transmission loss
CTL
X
2 binary wild card value representation
4.2 Abbreviated terms
ADC analogue to digital converter
AFEXTDC alien far end cross conversion loss common to differential
ANEXTDC alien near end cross conversion loss common to differential
AWGN additive white Gaussian noise
BER bit error rate
BI_DA bi-directional data signal pair A
COM communication ready (status bit)
COR polarity correct
CTC conformance test case
CTP conformance test plan
Cvt convention
DCQ dynamic channel quality
DD defect distance
DET polarity detection
DSP digital signal processing
ECU electronic control unit
GMII gigabit media independent interface
HDD harness defect detection
ICMP Internet Control Message Protocol
IOL interoperability laboratory
IUT implementation under test
LCL longitudinal conversion loss
LCTL longitudinal conversion transmission loss
LFL link failures and losses
LP link partner
LPF low-pass filter
LQ link quality
LRT local receiver time
LTT link-training time
LU link-up time
M mandatory
MAC media access control
MDC management data clock
MDI medium dependent interface
MII media independent interface
MSE mean square error
MSE_WC mean square error_worst-case
O optional
OS OPEN/SHORT detection
PAM3 pulse amplitude modulation (3 level)
PCB printed circuit board
PCS physical coding sub-layer
PEC pulse error correction
PHY physical layer
pMSE peak MSE
PLL phase locked loop
POL polarity (detection and correction)
PSAACRF power sum attenuations to alien crosstalk ratio far end
PSANEXT power sum alien near end crosstalk loss
PSD power spectral density
RBW resolution bandwidth
RGMII reduced gigabit media independent interface
RRT remote receiver time
SA RF spectral analyser
SNR signal to noise ratio
SQI signal quality index
TDR time domain reflectometer
TIE time interval error
UI unit interval
VBW video bandwidth
VNA RF network analyser
5 Conventions
[2]
This document is based on OSI service conventions as specified in ISO/IEC 10731 .
6 Wake-up and sleep features
6.1 Extension of physical coding sub-layer
This subclause describes the modification of the physical coding sub-layer of ISO/IEC/IEEE 8802-
3:2021.
REQ 1.1 Wake-up and sleep features – Extension of physical coding sub-layer
Figure 2 specifies the state diagram of the power state machine, which implements the two-way hand-
shake protocol.
Figure 2 — Power sequencing ISO/IEC/IEEE 8802-3:2021
In case the link is up (tx_mode = SEND_N) and Sleep.request is asserted, the PHY enters the Sleep.
Request state and sends LPS commands. The link partner receiving those LPS commands enters SLEEP_
ACK state and starts sleep_ack_timer. If loc_sleep_abort is asserted, the sleep is aborted because
of an incoming data message. If sleep reject is not done, the link partner enters SLEEP_REQUEST state
and sends LPS commands. If the PHY detects that it sends and receives LPS commands, it transits to
SLEEP_SILENT state and eventually to SLEEP. On the other hand, if the handshaking is not done before
the sleep_req_timer timeout, the PHY enters SLEEP_FAIL and transits back to SEND IDLE OR DATA state.
The signalling of a Wakeup.request depends on the state of the link. If the link is up (tx_mode = SEND_N)
the PHY transmits a WUR command over the active link during IDLE times. If the link is down (tx_mode
= SEND_Z) the PHY transmits a WUP pulse. If the link is not yet established (!loc_rcvr_status), for
instance because the link is still in training (tx_mode = SEND_I), the link is first established, then a WUR
command is sent.
REQ 1.2 Wake-up and sleep features – Selective wake-up forwarding mechanism
Multi-PHY devices (e.g. switches) shall implement a selective wake-up forwarding mechanism. If a
multi-PHY device detects a Wakeup.request (either WUR or WUP) on one port, it shall be possible to
forward the request to other PHYs of the device and to any other Single-PHY or Multi-PHY device.

REQ 1.3 Wake-up and sleep features – Selective wake-up forwarding mechanism Single PHY
device
Single-PHY devices shall implement a selective wake-up forwarding mechanism. If a Single-PHY
device detects a Wakeup.request (either WUR or WUP), it shall be possible to forward the request to
other Single-PHY or Multi-PHY devices.

REQ 1.4 Wake-up and sleep features – wake-up over a passive link (WUP) and active link
(WUR)
It shall be possible to forward a wake-up over a passive link (WUP) as well as a wake-up over an ac-
tive link (WUR) immediately to another port (or PHY).
The Wakeup.indicate should be generated upon wake-up events. In case the link is down, this service
primitive is generated upon the reception of WUP pulses (wup_recv) or if a local wake-up request (loc_
wake_req) or a WUR is received (wur_recv). The implementation of the energy detection process is left
to the PHY vendor.
REQ 1.5 Wake-up and sleep features – Energy detection
The energy detection process shall not take longer than 2 ms.

REQ 1.6 Wake-up and sleep features – IDLE pattern on the link triggers the energy detection
It shall be ensured that any transmitted IDLE pattern on the link triggers the energy detection (wup_
recv = TRUE).
REQ 1.7 Wake-up and sleep features – PHY detects a wake-up request
If the PHY detects a wake-up request, while the sleep process has already been started, going into
sleep shall be terminated and the wake-up shall be processed if possible.

REQ 1.8 Wake-up and sleep features – Entering the SLEEP state
If the PHY detects a wake-up request while the transit into SLEEP state is irreversible, this wake-up
request shall be stored and executed immediately upon entering the SLEEP state.
No wakeup request should be lost.
6.2 Service primitives and interfaces
Figure 3 shows the ISO/IEC/IEEE 8802-3:2021 service primitives.
Figure 3 — ISO/IEC/IEEE 8802-3:2021 service primitives
REQ 1.9 Wake-up and sleep features – Mapping between this document and ISO 21111-2 ser-
vice primitives
Table 1 specifies the mapping between this document and ISO 21111-2 service primitives which shall
be followed.
Table 1 — Mapping between this document and ISO 21111-2 service primitives
ISO 21111-6 (this document) service primitives ISO 21111-2 service primitives
SleepConfig.request PHY_ConfigSleepReject.request
Inhibit.indication PHY_SleepStatus.indication
Sleep.request PHY_LinkSleep.request
Sleep.indication PHY_LinkSleepRequestEvent.indication
Wakeup.indication PHY_WakeUp.indication
Wakeup.request PHY_WakeUp.request
SleepFail.indication PHY_LinkSleep.indication
SleepAbort.request PHY_ LinkSleepRequestAbort.request
6.3 Power sequencing states
The following requirements specify power sequencing states.
REQ 1.10 Wake-up and sleep features – Power sequencing states
The power sequencing states NORMAL, SLEEP_ACK, SLEEP_REQ, SLEEP_SILENT, SLEEP_FAIL and SLEEP
shall be implemented as specified in Figure 2.

REQ 1.11 Wake-up and sleep features – NORMAL state
The NORMAL state shall be the substate of SEND IDLE OR DATA with normal data transmission. On en-
tering NORMAL state, lps_recv and loc_sleep_abort shall be deasserted.

REQ 1.12 Wake-up and sleep features – SLEEP_ACK state
The SLEEP_ACK state is also a substate of SEND IDLE OR DATA which allows a higher layer implicit
acknowledgement during the time sleep_ack_timer. During SLEEP_ACK the sleep handshake can be
aborted (loc_sleep_abort = TRUE) and the PHY transitions to NORMAL. The link partner senses the
aborted sleep handshake (loc_sleep_abort = TRUE) and the PHY of the IUT transitions to NORMAL.
When this happens the link partner sets sleep_req_timer_done and eventually transitions to SLEEP_
FAIL.
REQ 1.13 Wake-up and sleep features –SLEEP_REQ state
The SLEEP_REQ state is entered when the PHY is requested to enter SLEEP state over the LinkSleep.
request primitive or after an implicit acknowledgement (sleep_ack_timer_done). In this state it is ex-
pected that the peer PHY also sends an LPS to acknowledge the flow. If the PHY has sent its own LPS
command and also received LPS, then SLEEP_SILENT is entered. Otherwise the PHY enters SLEEP_FAIL
after sleep_req_timer expires.

REQ 1.14 Wake-up and sleep features – SLEEP_SILENT state
In SLEEP_SILENT the PHYs transmitter remains silent (tx_mode=SEND_Z) but the energy detection
circuitry remains disabled to prevent spurious wup_recv glitches. This acts as a safeguard to prevent
a mutual wake-up through LPS commands. SLEEP state is entered if both PHYs are silent (loc_act_
detect = FALSE).
REQ 1.15 Wake-up and sleep features – SLEEP_FAIL state
The SLEEP_FAIL state is entered if either one or both PHYs cannot finish handshaking before the
sleep_req_timer timeout. The sleep flow is terminated and the PHYs go back to SEND IDLE OR DATA
state.
REQ 1.16 Wake-up and sleep features – SLEEP state
In SLEEP the transmitter shall be powered down and waits for a wake-up pulse or software wake-up.
6.4 Command definitions
6.4.1 General
This document specifies three commands, which are used to request a power down and signal a wake-
up over an active as well as a passive link.
6.4.2 Low power sleep (LPS)
LPS is encoded in the scrambler stream as specified in 6.5.
REQ 1.17 Wake-up and sleep features – Cmd – LPS
The LPS command shall be sent for a minimum of 64 bit.
The detection of an LPS command is left to the implementer. Aborting an LPS command may lead to
sending less than 64 bit.
6.4.3 Wake-up request (WUR)
The WUR is encoded in the scrambler stream as specified in 6.4.
REQ 1.18 Wake-up and sleep features – Cmd – WUR
The WUR command shall be sent for a minimum of 64 bit.
The detection of a WUR command is left to the implementer. Aborting a WUR command may lead to
sending less than 64 bit. In addition, the maximum number of hops of a wake-up network is 4.
6.4.4 Wake-up pulse (WUP)
WUP are link-training codes transmitted on the network by a node in tx_mode = SEND_I or switch PHY
to distribute the wake-up request over a link, which is down. The activity on the twisted-pair lines is
detected by the partner PHY as a remote wake-up.
REQ 1.19 Wake-up and sleep features – Cmd – WUP
The wake-up pulse shall have a minimum duration of 1 ms ± 0,3 ms.
REQ 1.18 allows reliable detection.
The energy detection of a WUP command is implementation-specific.
6.5 Generation of scrambling bits Sdn[2:0]
Commands are transmitted in the IDLE state of the PCS state machine. Therefore, the side stream
scrambler is modified. The generation of Sd [1:0] of ISO/IEC/IEEE 8802-3:2021 is modified. The bit
n
Sd [2] remains identical to ISO/IEC/IEEE 8802-3:2021.
n
The bit Sd [1] is used to scramble the data bit tx_data [1] during data mode and to encode LPS
n n
otherwise. It is defined below.
IF (tx_enable = 1)
n-3
Sd [1] = (Sc [1] Λ tx_data [1])
n n n
ELSE IF ((tx_lps = TRUE) & (loc_wake_req = FALSE) & (tx_mode = SEND_N))
Sd [1] = Sc [1] Λ 1
n n
ELSE
Sd [1] = Sc [1]
n n
The bit Sd [0] is used to scramble the data bit tx_data [0] during data mode and to encode WUR
n n
otherwise. It is defined below.
IF (tx_enable = 1)
n-3
Sd [0] = (Sc [0] Λ tx_data [0])
n n n
ELSE IF ((tx_lps = TRUE) & (loc_wake_req = TRUE) & (tx_mode = SEND_N))
Sd [0] = Sc [0] Λ 1
n n
ELSE
Sd [0] = Sc [0]
n n
6.6 PCS PHY control state diagram
Each variable shall have its own REQ statement with a reference to Figure 4.
REQ 1.20 Wake-up and sleep features – PCS PHY control state diagram
The PCS PHY control state machine, which implements parts of the power sequencing state machine,
shall be implemented as specified in Figure 4.

REQ 1.21 Wake-up and sleep features – PCS PHY control state diagram – Local activity detec-
tion signal
The variable loc_act_detect shall be set to FALSE if consecutive symbols of zeros were received; otherwise
shall be set to TRUE. The value of loc_act_detect shall be set to TRUE (FALSE) within 1 µs (see Figure 4).

REQ 1.22 Wake-up and sleep features – PCS PHY control state diagram – Low power sleep received
The variable lps_recv shall be set if the LPS command is entirely received (see Figure 4).

REQ 1.23 Wake-up and sleep features – PCS PHY control state diagram – Wake-up request
received
The variable wur_recv shall be set if the WUR command is entirely received (see Figure 4).

REQ 1.24 Wake-up and sleep features – PCS PHY control state diagram – Wake-up pulse received
The variable wup_recv shall be set if the WUP pulses are sensed (see Figure 4).

REQ 1.25 Wake-up and sleep features – PCS PHY control state diagram – Low power sleep
transmitted
The variable tx_lps shall be set if the LPS bits are transmitted by the scrambler (see Figure 4).

REQ 1.26 Wake-up and sleep features – PCS PHY control state diagram – Low power sleep
transmitted done
The variable tx_lps_done shall be set if the LPS command is entirely sent (at least 64-bi
...