IEEE
`Std 8D2.3u—1995
`
`SUPPLEMENT TO 802.3:
`
`OSI
`
`REFERENCE
`MODEL
`LAYERS
`
`APP|_|CAT|0N
`
`LAN
`CSMNCD
`LAYERS
`
`HIGHER LAYERS
`
`pRE3ENTA11oN
`
`LLC—LOG|CAL LINK CONTROL
`
`MAC—MEDIA ACCESS CONTROL
`RECONCILIATION
`
`'
`
`I
`
`3Es3|0|\|
`TRANSPORT
`
`NETWORK
`
`DATA LINK
`
`PHYSICAL
`
`MDI —pI
`
`‘MEDIUM
`
`To 100 Mbts Baseband Repeater Set
`or to ‘iDDBASE—X PHY (point—to-point link)
`
`MDI = MEDIUM DEPENDENT INTERFACE
`MII = MEDIA INDEPENDENT INTERFACE
`
`PCS = PHYSICAL CODING SUBLAYER
`PMA = PHYSICAL MEDIUM ATTACHMENT
`PHY = PHYSICAL LAYER DEVICE
`PMD = PHYSICAL MEDIUM DEPENDENT
`
`" MII is optional.
`"" AUTONEG communicates with the PMA sublayer through the PMA service interface messages
`PMA_LiNK.request and PMA_L|NK.indicate.
`""‘ AUTONEG is optional.
`
`Figure 24-1—Type 100BASE-X PHY relationship to the ISO Open Systems
`interconnection {OS|) reference model and the IEEE 802.3 CSMAICD LAN model
`
`24.1.4.1 Physical Coding Sublayer (PCS)
`
`The PCS interface is the Media Independent Interface (M11) that provides a uniform interface to the Recon-
`ciliation sublayer
`for all
`IOOBASE-T PHY implementations (e.g.,
`IOOBASE-X and IOOBASE—T4).
`IUOBASE-X, as other IOOBASE-T PHYs, is modeled as providing seivices to the M1]. This is similar to the
`use of an AUI interface.
`
`The IOOBASE-X PCS realizes all services required by the MIL including:
`
`of MII data nibbles to (from) five-bit code-gmups (4Bi5B)_:
`Encoding
`a)
`b) Generating Carrier Sense and Collision Detect indications;
`c)
`Serialization (deserialization) of code-groups for transinission (reception) on the lmderlying serial
`PMA, and
`d) Mapping of Transmit, Receive, Carrier Sense and Collision Detection between the M11 and the
`underlying PMA.
`
`This is anlggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1
`
`01
`
`Aerohive - Exhibit 1025
`0177
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`24.1.4.2 Physical Medium Attachment (PMA) sublayer
`
`The PMA provides a medium—independent means for the PCS and other bit—oriented clients (e.g., repeaters)
`to support the use of a range of physical media. The IOOBASE-X PMA performs the following functions:
`
`a) Mapping of transmit and receive code-bits between the PMA’s client and the underlying PMD;
`b) Generating a control signal indicating the availability of the PMD to a PCS or other client, also syn-
`chronizing with Auto—Negotiation when implemented;
`Optionally, generating indications of activity (carrier) and carrier errors from the underlying PMD;
`Optionally, sensing receive channel failures and transmitting the Far—End Fault Indication; and
`detecting the Far—End Fault Indication; and
`Recovery of clock from the NRZI data supplied by the PMD.
`
`c)
`d)
`
`e)
`
`24.1.4.3 Physical Medium Dependent (PMD) sublayer
`
`l00BASE-X uses the FDDI signaling standards ISO 9314-3: 1990 and ANSI X3.263: l99X (TP-PMD).
`These signaling standards, called PMD sublayers, define 125 Mb/s,
`fu1l—dup1ex signaling systems that
`accommodate multi-mode optical fiber, STP and UTP wiring. l00BASE-X uses the PMDs specified in these
`standards with the PMD Service Interface specified in 24.4.1.
`
`The MDI, logically subsumed within the PMD, provides the actual medium attachment, including connec-
`tors, for the various supported media.
`
`l00BASE-X does not specify the PMD and MDI other than including the appropriate standard by reference
`along with the minor adaptations necessary for l00BASE-X. Figure 24-2 depicts the relationship between
`l00BASE-X and the PMDs of ISO 9314-3: 1990 (for 100BASE-FX) and ANSI X3.263: l99X (for
`l00BASE—TX). The PMDs (and MDIs) for l00BASE—TX and 100BASE—FX are specified in subsequent
`clauses of this standard.
`
`24.1.5 Inter-sublayer interfaces
`
`There are a number of interfaces employed by l00BASE-X. Some (such as the PMA and PMD interfaces)
`use an abstract service model to define the operation of the interface. The PCS Interface is defined as a set of
`physical signals, in a mediurn-independent manner (lVlII). Figure 24-3 depicts the relationship and mapping
`of the services provided by all of the interfaces relevant to l00BASE-X.
`
`It is important to note that, while this specification defines interfaces in terms of bits, nibbles, and
`code-groups, implementations may choose other data path widths for implementation convenience. The only
`exceptions are: a) the M11, which, when implemented, uses a nibble-wide data path as specified in clause 22,
`and b) the MDI, which uses a serial, physical interface.
`
`24.1.6 Functional block diagram
`
`Figure 24-4 provides a fimctional block diagram of the IOOBASE-X PHY.
`
`24.1.7 State diagram conventions
`
`The body of this standard is comprised of state diagrams, including the associated definitions of variables,
`constants, and fimctions. Should there be a discrepancy between a state diagram and descriptive text, the
`state diagram prevails.
`
`The notation used in the state diagrams follows the conventions of 21 .5; state diagram timers follow the con-
`ventions of 14.2.3.2.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanqigrd.
`
`178
`
`1025
`
`Aerohive - Exhibit 1025
`0178
`
`

`
`IEEE
`Std 8D2.3u—1995
`
`SUPPLEMENT TO 802.3:
`
`LAN
`CSMAICD
`LAYERS
`
`HIGH ER LAYERS
`
`LLC—LOG|CAL LINK CONTROL
`
`MAC—MEDIA ACCESS CONTROL
`RECONCILIATION
`
`1DDBASE—X
`PHY
`
`‘MEDIUM
`
`‘E[)|UM To 100 Mbfs Baseband Repeater Set
`or to 1ClClBASE—X PHY (poinI—to—point link}
`
`1[IUBASE—FX
`(PCS, PMA, and Fiber PMD)
`
`\j_fi/_:../
`‘IflOBASE—TX
`(PCS, PMA, and TP—PMD)
`
`|\,|[)| : MEDIUM DEPENDENT INTERFACE PMA 2 PHYSICAL MEDIUM ATTACHMENT
`Mil : MEDIA INDEPENDENT INTERFACE
`PHY = PHYSICAL LAYER DEVICE
`P03 = PHYSICAL CODING SUBLAYER
`fiber PMD = PHYSICAL MEDIUM DEPENDENT SUBLAYER FDR FIBER
`TP—PMD = PHYSICAL MEDIUM DEPENDENT SUBLAYER FOR
`TWISTED PAIRS
`
`NOTE—The PMD sublayers are mutually independent.
`" Mil is optional.
`
`Figure 24-2—Re|ationship of 1UUBASE-X and the PMDs
`
`24.2 Physical Coding Sublayer (PCS)
`
`24.2.1 Service Interface (Mil)
`
`The PCS Service Interface allows the IOOBASE-X PCS to transfer information to and fi'om the MAC (via
`the Reconciliation sublayerj or other PCS client, such as a repeater. The PCS Service Interface is precisely
`defined as the Media Independent Interface (M11) in clause 22.
`
`In this clause, the setting of M11 variables to TRUE or FALSE is equivalent, respectively, to “asserting” or
`“de—assertir1g” them as specified in clause 22.
`
`24.2.2 Functional requirements
`
`The PCS comprises the Transmit, Receive, and Carrier Sense functions for IOOBASE-T. In addition, the col-
`lisionDetect signal required by the MAC (COL on the NIH) is derived from the PMA code-bit stream. The
`PCS shields the Reconciliation sublayer (and MAC) fiom the specific nature of the underlying channel. Spe-
`cifically for receiving, the IOOBASE-X PCS passes to the MH a sequence of data nibbles derived from
`incoming code-groups, each comprised of five code-bits, received from the medium. Code-group alignment
`and MAC packet delimiting is performed by embedding special non-data code-groups. The M1] uses a nib-
`ble-wide, synchronous data path, with packet delimiting being provided by separate TX_EN and RX_DV
`
`This is anlggrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhi o
`
`Aerohive - Exhibit 1025
`0179
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`Interface
`Interface
`
`PMA
`
`PMA Service
`
`PMD Service
`
`TRANSMIT
`
`RECEIVE
`
`CONTROL
`
`2
`
`
`
`signals. The PCS provides the functions necessary to map these two views of the exchanged data. The pro-
`cess is reversed for transmit.
`
`The following provides a detailed specification of the functions performed by the PCS, which comprise five
`parallel processes (Transmit, Transmit Bits, Receive, Receive Bits, and Carrier Sense). Figure 24-4 includes
`a functional block diagram of the PCS.
`
`The Receive Bits process accepts continuous code-bits via the PMA_UNITDATA.indicate primitive.
`Receive monitors these bits and generates RXD <3:O>, RX_DV and RX_ER on the M11, and the internal
`flag, receiving, used by the Canier Sense and Transmit processes.
`
`The Transmit process generates continuous code-groups based upon the Tm) <3:O>, TX_EN, and TX_ER
`signals on the M11. These code-groups are transmitted by Transmit Bits via the PMA_UNITDATA request
`primitive. The Transmit process generates the MII signal COL based on whether a reception is occurring
`simultaneously with transmission. Additionally, it generates the internal flag, transmitting, for use by the
`Carrier Sense process.
`
`The Carrier Sense process asserts the M11 signal CRS when either transmitting or receiving is TRUE. Both
`the Transmit and Receive processes monitor link_status via the PMA_LINK.indicate primitive, to account
`for potential link failure conditions.
`
`24.2.2.1 Code-groups
`
`The PCS maps four-bit nibbles from the MII into five-bit code-groups, and vice versa, using a 4B/5B block
`coding scheme. A code-group is a consecutive sequence of five code-bits interpreted and mapped by the
`PCS. Implicit in the definition of a code-group is an establishment of code-group boundaries by an align-
`ment fimction within the PCS Receive process. It is important to note that, with the sole exception of the
`SSD, which is used to achieve alignment, code-groups are undetectable and have no meaning outside the
`IOOBASE-X physical protocol data unit, called a “stream.”
`
`The coding method used, derived from ISO 9314-1: 1989, provides
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0180
`
`it 1025
`
`Aerohive - Exhibit 1025
`0180
`
`

`
`IEEE
`Std 8D2_3u—1995
`
`SUPPLEMENT TO 802.3:
`
`CARRIER
`SENSE
`
`receiving
`transmitting
`4
`
`4*
`
`rx_bits 19:0]
`
`RECEIVE BITS
`
`A
`
`°?* CARRIER
`DETECT
`
`'
`
`r ---------- - -1_
`FAR—END FAULT
`DETECT
`'
`o—r:_ __________ ___,
`
`LINK MONITOR
`‘II
`
`IIII
`
`signa|_status
`
`|ink_contro|
`
`Y
`TRANSMIT
`
`ll
`tx_bits [413]
`
`H
`
`TRANSMIT BITS
`
`FAR—END FAULT
`GENERATE
`
`Figure 24-4—Funcliona| block diagram
`
`This is amggrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibi
`
`Aerohive - Exhibit 1025
`0181
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`a) Adequate codes (32) to provide for all Data code-groups (16) plus necessary control code—groups;
`b) Appropriate coding efliciency (4 data bits per 5 code-bits; 80%) to effect a 100 Mb/s Physical Layer
`interface on a 125 Mb/s physical channel as provided by FDDI PMDs; and
`Sufficient transition density to facilitate clock recovery (when not scrambled).
`
`c)
`
`Table 24-1 specifies the interpretation assigned to each five bit code-group, including the mapping to the nib-
`ble-wide (TXD or RXD) Data signals on the MII. The 32 code-groups are divided into four categories, as
`shown.
`
`For clarity in the remainder of this clause, code-group names are shown between /slashes/. Code-group
`sequences are shown in succession, e.g.: /1/2/....
`
`The indicated code-group mapping is identical to ISO 9314-1: 1989, with four exceptions:
`
`a)
`
`b)
`c)
`
`d)
`
`The FDDI term symbol is avoided in order to prevent confusion with other IOOBASE-T terminology.
`Ir1 general, the term code-group is used in its place.
`The /S/ and /Q/ code-groups are not used by 100BASE—X and are interpreted as INVALID.
`The /R/ code-group is used in 100BASE—X as the second code-group of the End-of-Stream delimiter
`rather than to indicate a Reset condition.
`
`The /H/ code-group is used to propagate receive errors rather than to indicate the Halt Line State.
`
`24.2.2.1.1 Data code-groups
`
`A Data code-group conveys one nibble of arbitrary data between the MII and the PCS. The sequence of Data
`code-groups is arbitrary, where any Data code-group can be followed by any other Data code-group. Data
`code-groups are coded and decoded but not
`interpreted by the PCS. Successful decoding of Data
`code-groups depends on proper receipt of the Start-of-Stream delimiter sequence, as defined in table 24-1.
`
`24.2.2.1.2 Idle code-groups
`
`The Idle code-group (/I/) is transferred between streams. It provides a continuous fill pattern to establish and
`maintain clock synchronization. Idle code-groups are emitted from, and interpreted by, the PCS.
`
`24.2.2.1.3 control code-groups
`
`The Control code-groups are used in pairs (/J/K/, /T/R/) to delimit MAC packets. Control code-groups are
`emitted from, and interpreted by, the PCS.
`
`24.2.2.1.4 Start-of-Stream Delimiter (IJIKI)
`
`A Start-of-Stream Delimiter (SSD) is used to delineate the boundary of a data transmission sequence and to
`authenticate carrier events. The SSD is unique in that it may be recognized independently of previously
`established code-group boundaries. The Receive function within the PCS uses the SSD to establish
`code-group boundaries. A SSD consists of the sequence /J/K/.
`
`On transmission, the first 8 bits of the MAC preamble are replaced by the SSD, a replacement that is
`reversed on reception.
`
`24.2.2.1.5 End-of-Stream delimiter (ITIRI)
`
`An End-of-Stream delimiter (ESD) terminates all normal data transmissions. Unlike the SSD, an ESD can-
`not be recognized independent of previously established code-group boundaries. An ESD consists of the
`sequence /T/R/.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`182
`
`1025
`
`Aerohive - Exhibit 1025
`0182
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Table 24-1—4BI5B code-groups
`
`PCS code-group
`[420]
`432 1 0
`
`MII (TXD/RXD)
`<3:0>
`3 2 1 0
`
`Interpretation
`
`D
`
`1;‘
`A
`
`C
`0
`N
`E
`O
`L
`
`I
`N
`X
`L
`I
`D
`
`1 1 1 1 O
`
`0 1 0 0 1
`1 O 1 O O
`1 O 1 0 1
`O 1 O 1 0
`0 1 O 1 1
`0 1 1 1 0
`O 1 1 1 1
`1 O O 1 O
`O O 1 1
`O 1 1 O
`O 1 1 1
`. 1 O 1 O
`1 O 1 1
`. 1 1 0 O
`1 1 O 1
`
`0 O O O O
`0 O O 0 1
`O O O 1 O
`O O O 1 1
`0 O 1 0 1
`0 O 1 1 O
`0 1 O O O
`0 1 1 0 O
`1 O O O O
`1 1 O 0 1
`
`0
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`A
`B
`C
`D
`E
`F
`
`H
`
`V
`V
`V
`V
`V
`V
`V
`V
`V
`V
`
`O
`
`0
`O
`0
`O
`O
`O
`O
`1
`1
`1
`1
`1
`1
`1
`1
`
`0
`
`0
`O
`O
`1
`1
`1
`1
`O
`O
`O
`0
`1
`1
`1
`1
`
`Data0
`
`Datal
`Data2
`Data3
`Data4
`Data5
`Data6
`Data7
`Data8
`Data9
`DataA
`DataB
`DataC
`DataD
`DataE
`DataF
`
`undefined
`
`IDLE;
`used as inter-stream fill code
`
`Start-of-Stream Delimiter, Part 1 of 2;
`always used in pairs with K
`Start-of-Stream Delimiter, Part 2 of 2;
`always used in pairs with J
`End-of-Stream Delimiter, Part 1 of 2;
`always used in pairs with R
`End-of-Stream Delimiter, Part 2 of 2;
`always used in pairs with T
`
`Transmit Error;
`used to force signaling errors
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`Invalid code
`
`undefined
`
`undefined
`
`Undefined
`
`Undefined
`Undefined
`Undefined
`Undefined
`Undefined
`Undefined
`Undefined
`Undefined
`Undefined
`Undefined
`
`This is anlgrrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`O1 83
`
`Aerohive - Exhibit 1025
`0183
`
`

`
`CSMA/CD
`
`24.2.2.1.6 Invalid code-groups
`
`IEEE
`Std 802.3u-1995
`
`The /H/ code-group indicates that the PCS’s client wishes to indicate a Transmit Error to its peer entity. The
`normal use of this indicator is for repeaters to propagate received errors. Transmit Error code-groups are
`emitted flom the PCS, at the request of the PCS’s client through the use of the TX_ER signal, as described in
`24.2.4.2.
`
`The presence of any invalid code-group on the medium, including /H/, denotes a collision artifact or an error
`condition. Invalid code-groups are not intentionally transmitted onto the medium by DTE's. The PCS indi-
`cates the reception of an Invalid code-group on the M11 through the use of the RX_ER signal, as described in
`24.2.4.4.
`
`24.2.2.2 Encapsulation
`
`The IOOBASE-X PCS accepts flames flom the MAC through the Reconciliation sublayer and M11. Due to
`the continuously signaled nature of the underlying PMA, and the encoding performed by the PCS, the
`100BASE—X PCS encapsulates the MAC frame (100BASE—X Service Data Unit, SDU) into a Physical
`Layer stream (IOOBASE-X Protocol Data Unit, PDU).
`
`Except for the two code-group SSD, data nibbles within the SDU (including the non—SSD portions of the
`MAC preamble and SFD) are not interpreted by the 100BASE-X PHY. The conversion from a MAC flame
`to a Physical Layer stream and back to a MAC flame is transparent to the MAC.
`
`Figure 24-5 depicts the mapping between MAC flames and Physical Layer streams.
`
`MAC Frame
`
`46-1500
`
`
`
`Physical Layer stream
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgrd.
`
`84
`
`025
`
`Aerohive - Exhibit 1025
`0184
`
`

`
`IEEE
`Std 8D2.3u—1995
`
`SUPPLEMENT TO 802.3:
`
`A properly formed stream can be viewed as comprising th.ree elements:
`
`a)
`
`Sfai'!—0f—Strenm Defimirei: The start of a Physical Layer stream is indicated by a SSD. as defined in
`24.2.2.1. The SSD replaces the first octet of the preamble from the MAC frame and vice versa.
`b) Dara Code—gro1l5ns. Between delimiters (SSD and ESD). the PCS conveys Data code-groups corre-
`sponding to the data nibbles of the MII. These Data code-groups comprise the IOOBASE-X Service
`Data Unit (SDU). Data nibbles within the SDU (including those corresponding to the MAC pream-
`ble and SFD) are not interpreted by the IOOBASE-X PCS.
`End—ofSl‘reani Deffmfrerz The end of a properly formed stream is indicated by an ESD, as defined in
`24.221. The ESD is transmitted by the PCS following the de-assertion of TX_EN on the M11.
`which corresponds to the last data nibble composing the FCS from the MAC. It is transmitted during
`the period considered by the MAC to be the interframe gap
`On reception, ESD is interpreted
`by the PCS as terminating the SDU.
`
`Between strean1s_. IDLE code-groups are conveyed between the PCS and PMA.
`
`24.2.2.3 Data delay
`
`The PCS maps a non-aligned code-bit data path from the PMA to an aligled, nibble-wide data path on the
`MH, both for Transmit and Receive. Logically, received bits must be buffered to facilitate SSD detection and
`aligmnent, coding translation, and ESD detection. These functions necessitate an intemal PCS delay of at
`least two code-groups. I.n practice. alignment may necessitate even longer delays of the incoming code-bit
`stream.
`
`When the M11 is present as an exposed interface, the MII signals TX_CLK and RX_CLK, not depicted in the
`following state diagrams, shall be generated by the PCS i.n accordance with clause 22.
`
`24.2.2.4 Mapping between Mll and PMA
`
`Figure 24-6 depicts the mapping of the nibble-wide data path of the M11 to the five-bit-wide code-groups
`(internal to the PCS) and the code-bit path of the PMA interface.
`
`TXD <3:0>
`3211]
`
`RXD -<3:lJ>
`3210
`
`Mll
`(25 million nibblesls)
`
`I
`
`MII
`(25 million nibblesls}
`
`5Bl4B
`Decoder
`
`PCS Encoding
`(25 million codegroupsfs)
`
`PCS Decoding
`(25 million code-groupsls)
`
`l
`
`PMA Interface
`(125 million nmi—b'rls.’s)
`
`4
`
`I
`
`4
`
`9BT654321C|
`
`PMA Interface
`(125 million nmi—bl's)
`
`Figure 24-6—PCS reference diagram
`
`This is anlggrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1
`
`Aerohive - Exhibit 1025
`0185
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`Upon receipt of a nibble from the M11, the PCS encodes it into a five—bit code-group, according to 24.2.2.1.
`Code-groups are serialized into code-bits and passed to the PMA for transmission on the underlying
`medium, according to figure 24-6. The first transmitted code-bit of a code-group is bit 4, and the last
`code-bit transmitted is bit 0. There is no numerical significance ascribed to the bits within a code-group; that
`is, the code-group is simply a five-bit pattern that has some predefined interpretation.
`
`Similarly, the PCS deserializes code-bits received from the PMA, according to figure 24-6. After alignment
`is achieved, based on SSD detection, the PCS converts code-groups into MII data nibbles, according to
`24.2.2.1.
`
`24.2.3 State variables
`
`24.2.3.1 Constants
`
`DATA
`
`ESD
`
`ESD1
`
`ESD2
`
`HALT
`
`IDLE
`
`IDLES
`
`SSD
`
`SSD1
`
`SSD2
`
`The set of 16 code-groups corresponding to valid DATA, as specified in 24.2.2. 1. (In the Receive
`state diagram, the set operators e and as are used to represent set membership and non-
`membership, respectively.)
`
`The code-group pair corresponding to the End-of-Stream delimiter, as specified in 24.2.2.1.
`
`The code-group pair corresponding to the End-of-Stream delimiter, Part 1 (/T/), as specified in
`24.2.2.1.
`
`The code-group pair corresponding to the End-of-Stream delimiter, Part 2 (/R/), as specified in
`24.2.2.1.
`
`The Transmit Error code-group (/HO, as specified in 24.2.2. 1.
`
`The IDLE code-group, as specified in 24.2.2.1.
`
`A code-group pair comprised of /I/I/; /I/ as specified in 24.2.2.1.
`
`The code-group pair corresponding to the Start-of-Stream delimiter, as specified in 24.2.2.1.
`
`The code-group corresponding to the Start-of-Stream delimiter, Part 1 (/J/), as specified in
`24.2.2.1.
`
`The code-group corresponding to the Start-of-Stream delimiter, Part 2 (/K/), as specified in
`24.2.2.1.
`
`24.2.3.2 Variables
`
`In the following, values for the M11 parameters are definitively specified in clause 22.
`
`COL
`
`CRS
`
`The COL signal of the M11 as specified in clause 22.
`
`The CRS signal of the MII as specified in clause 22.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`0186
`
`tl025
`
`Aerohive - Exhibit 1025
`0186
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`link_status
`The link_status parameter as communicated by the PMA_LINK.indicate primitive.
`
`Values: FAIL; the receive channel is not intact
`READY; the receive channel is intact and ready to be enabled by Auto—Negotiation
`OK; the receive channel is intact and enabled for reception
`
`receiving
`A boolean set by the Receive process to indicate non—IDLE activity (after squelch). Used by the
`Carrier Sense process, and also interpreted by the Transmit process for indicating a collision.
`
`Values: TRUE; unsquelched carrier being received
`FALSE; carrier not being received
`
`rx_bits [920]
`A vector of the 10 most recently received code-bits from the PMA as assembled by Receive Bits
`and processed by Receive. rx_bits [0] is the most recently received (newest) code-bit; rx_bits [9]
`is the least recently received code-bit (oldest). When alignment has been achieved, it contains the
`last two code-groups.
`rx code-bit
`
`The rx_code-bit parameter as communicated by the most recent PMA_UNITDATA.indicate
`primitive (that is, the value of the most recently received code-bit from the PMA).
`
`RX_DV
`
`RX_ER
`
`The RX_DV signal of the M11 as specified in clause 22. Set by the Receive process, RX_DV is
`also interpreted by the Receive Bits process as an indication that rx_bits is code-group aligned.
`
`The RX_ER signal of the lVlII as specified in clause 22.
`RXD <3:0>
`
`The RXD <3:0> signal of the MII as specified in clause 22.
`
`transmitting
`A boolean set by the Transmit Process to indicate a transmission in progress. Used by the Carrier
`Sense process.
`
`Values: TRUE; the PCS’s client is transmitting
`FALSE; the PCS’s client is not transmitting
`
`tx_bits [420]
`A vector of code-bits representing a code-group prepared for transmission by the Transmit Process
`and transmitted to the PMA by the Transmit Bits process.
`
`TX_EN
`
`TX_ER
`
`The TX_EN signal of the lVlII as specified in clause 22.
`
`The TX_ER signal of the MII as specified in clause 22.
`TXD <3:0>
`
`The TXD <3:0> signal of the MII as specified in clause 22.
`
`24.2.3.3 Functions
`
`nibble DECODE (code-group)
`In Receive, this function takes as its argument a five-bit code-group and returns the corresponding
`MII RXD <3:0> nibble, per table 24-1.
`
`code-group ENCODE (nibble)
`In the Transmit process, this fimction takes as its argument an M11 TXD <3 :0> nibble, and returns
`the corresponding five-bit code-group per table 24-1.
`
`SHIFTLEFT (rx_bits)
`In Receive Bits, this function shifts rx_bits left one bit placing rx_bits [8] in rx_bits [9], rx_bits [7]
`in rx_bits [8] and so on until rx_bits [1] gets rx_bits [0].
`
`This is anlggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0187
`
`it 1025
`
`Aerohive - Exhibit 1025
`0187
`
`

`
`CSMA/CD
`
`24.2.3.4 Timers
`
`code-bit_timer
`
`IEEE
`Std 802.3u-1995
`
`In the Transmit Bits process, the timer governing the output of code—bits from the PCS to the PMA
`and thereby to the medium with a nominal 8 ns period. This timer shall be derived from a fixed
`frequency oscillator with a base frequency of 125 MHz i 0.005% and phase jitter above 20 kHz
`less than i 8°.
`
`24.2.3.5 Messages
`
`gotCodeGroup.indicate
`
`A signal sent to the Receive process by the Receive Bits process after alignment has been achieved
`signifying completion of reception of the next code-group in rx_bits(4:0), with the preceding
`code-group moved to tx_bits [9:5]. rx_bits [9:5] may be considered as the “current” code-group.
`
`PMA_UNITDATA.indicate (rx_code-bit)
`
`A signal sent by the PMA signifying that the next code-bit fi'om the medium is available in
`rx_code-bit.
`
`sentCodeGroup.indicate
`
`A signal sent to the Transmit process from the Transmit Bits process signifying the completion of
`transmission of the code-group in tx_bits [4:0].
`
`24.2.4 State diagrams
`
`24.2.4.1 Transmit Bits
`
`Transmit Bits is responsible for taking code—groups prepared by the Transmit process and transmitting them
`to the PMA using PMA_UNITDATA request,
`the frequency of which determines the transmit clock.
`Transmit deposits these code—groups in tx_bits with Transmit Bits signaling completion of a code-group
`transmission with sentCodeGroup.indicate.
`
`The PCS shall implement the Transmit Bits process as depicted in figure 24-7 including compliance with the
`associated state variables as specified in 24.2.3.
`
`24.2.4.2 Transmit
`
`The Transmit process sends code—groups to the PMA via tx_bits and the Transmit Bits process. When ini-
`tially invoked, and between streams (delimited by TX_EN on the MII), the Transmit process sources contin-
`uous Idle code—groups (/I/) to the PMA. Upon the assertion of TX_EN by the MII, the Transmit process
`passes an SSD (/J/K/) to the PMA, ignoring the TXD <3:0> nibbles during these two code-group times. Fol-
`lowing the SSD, each TXD <3:0> nibble is encoded into a five-bit code-group until TX_EN is deasserted. If,
`while TX_EN is asserted, the TX_ER signal is asserted, the Transmit process passes Transmit Error
`code—groups (/H/) to the PMA. Following the de-assertion of TX_EN, an ESD (/T/R/) is generated, after
`which the transmission of Idle code—groups is resumed by the IDLE state.
`
`Collision detection is implemented by noting the occurrence of carrier receptions during transmissions, fol-
`lowing the model of IOBASE-T. The indication of 1ink_status at OK by the PMA at any time causes an
`immediate transition to the IDLE state and supersedes any other Transmit process operations.
`
`The PCS shall implement the Transmit process as depicted in figure 24-8 including compliance with the
`associated state variables as specified in 24.2.3.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanqiajd.
`
`0188
`
`tl025
`
`Aerohive - Exhibit 1025
`0188
`
`

`
`IEEE
`Std 8D2.3u—1995
`
`SUPPLEMENT TO 802.3:
`
`l
`
`OUTPUT 1
`
`PMA_UN|TDATA.request (tx_bits [4})
`Start code—bit_timer
`
`l code—bit_timer_done
`
`OUTPUT 2
`
`PMA_UNITDATA.request (tx_bits [3])
`Start code—bit_lirner
`
`l code—bit_timer_done
`OUTPUT 3
`
`PMA_UN|TDATA.request (Ix_bits [2})
`Start I:ode—b'rt_timer
`
`i code—bit_timer_done
`OUTPUT 4
`
`PMA_UN|TDATA.rc-quest (Ix_bits [1])
`Start code—bit_timer
`
`l code-bit_timer_done
`OUTPUT 5
`
`code—bil_timer_done
`
`PMA UN|TDATA.request (tx_bits [0])
`senlCodeGroup.indicate
`Start code—bit_timer
`
`Figure 24-7—Transm it Bits state diagram
`
`24.2.4.3 Receive Bits
`
`The Receive Bits process collects code-bits from the PMA interface passing them to the Receive process via
`rx_bits. 1x_bits [9:0] represents a sliding, 10-bit window on the PMA code-bits, with newly received
`code-bits fiorn the PMA (rx_code-bit) being shifted into rx_bits [0]. This is depicted in figure 24-9. Bits are
`collected serially until Receive indicates alignment by asserting RX_DV, after which Receive Bits signals
`Receive for every five code-bits accumulated. Serial processing resumes with the de-assertion of RX_DV.
`
`The PCS shall implement the Receive Bits process as depicted in fig1u‘e 24-10 including compliance with the
`associated state variables as specified in 24.2.3.
`
`24.2.4.4 Receive
`
`The Receive process state machine can be viewed as comprising two sections: prealigned and aligned. In the
`prealigned states, ]DLE_. CARRIER DETECT, and CONFIRM K, the Receive process is waiting for an indi-
`cation of channel activity followed by a SSD. After successful alignnent, the incoming code-groups are
`decoded while waiting for stream terrnination.
`
`This is anmrrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit
`
`Aerohive - Exhibit 1025
`0189
`
`

`
`CSMNCD
`
`IEEE
`Std B[|2_3u—1995
`
`link_status =t OK
`
`IDLE
`.
`_
`transmitting ~: FALSE
`COL = FALSE
`tx_b'rt5{4:D]
`<= |[)|_E
`sentco-:ieGroup_indicate t
`1-x_EN = TRUE *
`Semcodeemupjnuicate *
`T}(_ER = FALSE
`TX EN = FALSE
`—
`START STREAM J
`transmit ing
`«-=
`TRUE
`COL
`a:
`receiving
`tx_b'rIs [4:D]
`«:= SSD1
`sentCodeGroup_indicate t
`sentC0deGroup_indiI:ate *
`TX_ER = FALSE
`T)(_ER =TRUE
`START STREAM K
`
`i
`
`<2:
`COL
`tx_t)'rls[4:l}]
`
`receiving
`.= sso2
`
`sentCodeGroup_indicate
`
`t
`l
`ERRO R C HECK
`
`i §entCodeGroup_indicate t
`
`TX_EN = TRUE *
`TX ER=TRUE
`T
`
`START ERROR J
`transmit "mg = TRUE
`COL ~:=
`receiving
`tx_bil:-'. [4:l)] c: 3391
`5entCodeG roupindioate
`
`START ERROR K
`
`<2:
`COL
`tx_b'rts[d:I)]
`
`receiving
`¢= ssm
`
`sentCodeG roup_indicate
`
`TX_EN = TRUE *
`
`‘r)(_ER: FALSE l
`
`TRANSMIT DATA
`
`T)(_EN = TRUE *
`
`l TX_ER =TRUE
`
`TRANSMIT ERROR
`
`Y
`
`COL c= reI:e'rvir‘g
`tx_nrts[4o]
`¢=
`ENCODE (rxo<a:n>)
`
`-==
`COL
`D(_bit5 [411]
`
`reoeiving
`.=
`HALT
`
`sentCodeGroup_indicate
`
`TK_EN = FALSE
`EN D STREAM T
`
`59F|tC0dBG FOUP-indicaie
`
`transmitting
`COL c=
`tx_bi13 [411]
`
`«:= FALSE
`FALSE
`e: ESD1
`l sentCodeGroup_indir:ate
`END STREAM R
`tx_btts [am]
`<:
`ESD2
`
`SBI'IiCOdBGl'(]Up,ll'Ifll|33IE
`
`Figure 24-8—Transmit state diagram
`
`24.2.4.4.1 Detecting channel activity
`
`The detection of activity on the underlying channel is used both by the MAC (Via the M11 CRS signal and
`the Reconciliation sublayer) for deferral purposes, and by the Transmit process for collision detection.
`Activity, signaled by the assertion of receiving, is indicated by the receipt of two non-contiguous ZEROS
`within any 10 code-bits of the incoming code-bit stream.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - EXhib'
`
`Aerohive - Exhibit 1025
`0190
`
`

`
`IEEE
`Std 8D2.3u—1995
`
`SUPPLEMENT TO 802.3:
`
`/
`93?6543210
`
`EHIDJIDE \
`
`rx_code-bit
`
`Figure 24-9—Receive Bits reference diagram
`
`24.2.4.4.2 Code-group alignment
`
`After channel activity is detected, the Receive process first aligns the incoming code-bits on code-group
`boundaries for subsequent data decoding. This is achieved by scanning the rx_bits vector for a SSD (KI;/KI).
`The MII RX_DV sigial remains deasserted during this time, which ensures that the Reconciliation sublayer
`will ignore any signals on RXD <3:0>. Detection of the SSD causes the Receive process to enter the START
`OF STREAM J state.
`
`W'ell-formed streams contain SSD (/J/K/) in place of the first eight preamble bits. In the event that something
`else is sensed immediately following detection of carrier, a False Caiiier Indication is signaled to the M11 by
`asserting RX_ER and setting RXD to 1110 while RX_DV remains de-asserted. The associated carrier event,
`as terminated by 10 ONES, is otherwise ignored.
`
`24.2.!-1.4.3 Stream decoding
`
`The Receive process substitutes a sequence of alternating ONE and ZERO data-bits for the SSD, which is
`consistent with the preamble pattern expected by the MAC.
`
`The Receive process then performs the DECODE function on the incoming code-groups, passing decoded
`data to the M1], including those coiresponding to the remai.nder of the MAC preamble and SFD. The NIH
`signal RX_ER is asserted upon decoding any code-group following the SSD that is neither a valid Data
`code—g1'oup nor a valid stream termination sequence.
`
`24.2.4.4.4 Stream termination
`
`There are two means of effecting stream termination in the Receive process (figure 24-1 1).
`
`A normal stream termination is caused by detection of an ESD (IT/R/) in the rx_bits vector. In order to pre-
`serve the ability of the MAC to properly delimit the FCS at the end of the frame (that is, to avoid incorrect
`AlignmentErrors in the MAC) the internal signal receiving (and through it, the MJI CRS signal, per clause
`22) is de-asserted immediately following the last code-bit in the stream that n1aps to the FCS. Note that the
`condition link_status ¢ OK during stream reception (that is, when receiving = TRUE) causes an immediate
`transition to the LINK FAILED state and supersedes any other Receive process operations.
`
`A premature stream termination is caused by the detection of two Idle code-groups (IIJI) in the 1x_bits vector
`prior to an ESD. Note that RX_DV remains asserted during the nibble corresponding to the fir