IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`21.6 Protocol Implementation Conformance Statement (PICS) proforma
`
`21.6.1 Introduction
`
`The supplier of a protocol implementation that is claimed to conform to any part of the IEEE 802.3u
`IOOBASE-T clauses 21 through 30 shall complete a Protocol Implementation Conformance Statement
`(PICS) proforma.
`
`A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of
`which capabilities and options of the protocol have been implemented. A PICS is included at the end of each
`clause as appropriate. The PICS can be used for a variety of purposes by various parties, including the
`following:
`
`a)
`
`As a checklist by the protocol implementor, to reduce the risk of failure to conform to the standard
`through oversight;
`b) As a detailed indication of the capabilities of the implementation, stated relative to the common
`basis for understanding provided by the standard PICS proforma, by the supplier and acquirer, or
`potential acquirer, of the implementation;
`c) As a basis for initially checking the possibility of interworking with another implementation by the
`user, or potential user, of the implementation (note that, while interworking can never be guaranteed,
`failure to interwork can often be predicted from incompatible PICS);
`d) As the basis for selecting appropriate tests against which to assess the claim for conformance of the
`implementation, by a protocol tester.
`
`21.6.2 Abbreviations and special symbols
`
`The following symbols are used in the PICS proforma:
`
`M
`0
`O.<n>
`
`O/<n>
`
`X
`<item>:
`<iteml>*<item2>:
`
`mandatory field/function
`optional field/function
`optional field/fimction, but at least one ofthe group of options labeled by
`the same numeral <n> is required
`optional field/function, but one and only one of the group of options
`labeled by the same numeral <n> is required
`prohibited field/function
`simple-predicate condition, dependent on the support marked for <item>
`AND-predicate condition, the requirement must be met if both optional
`items are implemented
`
`21.6.3 Instructions for completing the PICS proforma
`
`The first part of the PICS proforma, Implementation Identification and Protocol Summary, is to be com-
`pleted as indicated with the information necessary to identify fully both the supplier and the implementation.
`
`The main part of the PICS proforma is a fixed-format questionnaire divided into subclauses, each containing
`a group of items. Answers to the questionnaire items are to be provided in the right-most column, either by
`simply marking an answer to indicate a restricted choice (usually Yes, No, or Not Applicable), or by entering
`a value or a set or range of values. (Note that there are some items where two or more choices from a set of
`possible answers can apply; all relevant choices are to be marked.)
`
`Each item is identified by an item reference in the first column; the second column contains the question to
`be answered; the third colurrm contains the reference or references to the material that specifies the item in
`the main body of the standard; the sixth column contains values and/or comments pertaining to the question
`
`This is an3¢\rchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0048
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`to be answered. The remaining columns record the status of the items—whether the support is mandatory,
`optional or conditional—and provide the space for the answers.
`
`The supplier may also provide, or be required to provide, further information, categorized as either Addi-
`tional Inforrnation or Exception Information. When present, each kind of further information is to be pro-
`vided in a further subclause of items labeled A<i> or X<i>, respectively, for cross-referencing purposes,
`where <i> is any unambiguous identification for the item (e.g., simply a numeral); there are no other restric-
`tions on its format or presentation.
`
`A completed PICS proforma, including any Additional Information and Exception Information, is the Proto-
`col Implementation Conformance Statement for the implementation in question.
`
`Note that where an implementation is capable of being configured in more than one way, according to the
`items listed under Major Capabilities/Options, a single PICS may be able to describe all such configurations.
`However, the supplier has the choice of providing more than one PICS, each covering some subset of the
`implementation’s configuration capabilities, if that would make presentation of the information easier and
`clearer.
`
`21.6.4 Additional information
`
`Items of Additional Information allow a supplier to provide further information intended to assist the inter-
`pretation of the PICS. It is not intended or expected that a large quantity will be supplied, and the PICS can
`be considered complete without any such information. Examples nright be an outline of the ways in which a
`(single) implementation can be set up to operate in a variety of environments and configurations; or a brief
`rationale, based perhaps upon specific application needs, for the exclusion of features that, although
`optional, are nonetheless commonly present in implementations.
`
`References to items of Additional Information may be entered next to any answer in the questionnaire, and
`may be included in items of Exception Information.
`
`21.6.5 Exceptional information
`
`It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status
`(after any conditions have been applied) in a way that conflicts with the indicated requirement. No pre-
`printed answer will be found in the Support column for this; instead, the supplier is required to write into the
`Support column an X<i> reference to an item of Exception Information, and to provide the appropriate ratio-
`nale in the Exception item itself.
`
`An implementation for which an Exception item is required in this way does not conform to this standard.
`
`Note that a possible reason for the situation described above is that a defect in the standard has been
`reported, a correction for which is expected to change the requirement not met by the implementation.
`
`21.6.6 Conditional items
`
`The PICS proforma contains a number of conditional items. These are items for which both the applicability
`of the item itself, and its status if it does apply—mandatory, optional, or prohibited—are dependent upon
`whether or not certain other items are supported.
`
`Individual conditional items are indicated by a conditional symbol of the form “<item>:<s>” in the Status
`column, where “<item>” is an item reference that appears in the first colurrm of the table for some other
`item, and “<s>” is a status symbol, M (Mandatory), 0 (Optional), or X (Not Applicable).
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0049
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`If the item referred to by the conditional symbol is marked as supported, then 1) the conditional item is
`applicable, 2) its status is given by “<s>”, and 3) the support column is to be completed in the usual Way.
`Otherwise, the conditional item is not relevant and the Not Applicable (N/A) answer is to be marked.
`
`Each item whose reference is used in a conditional symbol is indicated by an asterisk in the Item colunm.
`
`21.7 Relation of 100BASE-T to other standards
`
`Suitable entries for table G1 of ISO/IEC 11801: 1995, armex G, would be as follows:
`
`a) Within the section Balanced Cable Link Class C (specified up to 16 MHz):
`CSMA/CD l00BASE-T4
`ISO/IEC 8802-3/DAD 1995 4
`
`b) Within the section Optical Link:
`CSMA/CD 100BASE-FX
`
`ISO/IEC 8802-3/DAD 1995 2
`
`c) Within the section Balanced Cable Link Class D (Defined up to 100 MHz):
`CSMA/CD l00BASE-TX
`ISO/IEC 8802-3/DAD 1995 2
`
`NOTE—To support l00BASE-T4 applications, class C links shall have a NEXT value of at least 3 dB in excess of the
`values specified in 6.2.4.
`
`Suitable entries for table G2 of ISO/IEC 11801: 1995, annex G, would be as follows:
`
`
`
`‘ 8802-3 imposes additional requirements on propagation delay.
`
`This is an34\rchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0050
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`A suitable entry for table G3 of ISO/IEC 11801: 1995, armex G, would be as follows:
`
`per 5, 7, and 8
`
`Horizontal
`
`Building backbone
`
`Fibre
`
`Optical link per clause 8
`
`Campus backbone -3.3.-
`
`21.8 MAC delay constraints (exposed Mll)
`
`100BASE-T makes the following assumptions about MAC performance. These assumptions apply to any
`MAC with an exposed M11 used with a IOOBASE-T PHY.
`
`Table 21-2—MAC delay assumptions (exposed Mll)
`
`Sublayer
`measurement
`points
`
`Input timing
`reference
`
`Output timing
`reference
`
`nibble ofjam
`
`MAC transmit start to TX_EN
`sampled
`CRS assert to MAC detect
`
`CRS de-assert to MAC detect
`
`CRS assert to TX_EN sampled
`(worst case nondeferred transmit)
`COL assert to MAC detect
`
`COL de-assert to MAC detect
`
`COL assert to TXD = Jam
`sampled (worst-case collision
`response)
`
`TX_CLK
`rising; first
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgd.
`
`Aerohive - Exhibit 1025
`
`005 1
`
`Aerohive - Exhibit 1025
`0051
`
`

`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`0052
`
`

`
`CSMNCD
`
`IEEE
`Std 302.3, 1998 Edition
`
`22. Reconciliation Sublayer (RS) and Media Independent Interface (Mil)
`
`22.1 Overview
`
`This clause defines the logical, electrical, and n1ecl1an.ical characteristics for the Recoiiciliation Sublayer
`(RS) and Media Independent Interface (MII) between CSMAICD media access controllers and vaiious
`PHYS. Figure 22-1 shows the relationship of the Reconciliation sublayer and MII to the ISO (IEEE) OSI
`reference model.
`
`OSI
`REFERENCE
`MODEL
`LAYERS
`
`LAN
`
`CSMNCD
`LAYERS
`
`APP|_|CAT|O|\|
`
`HIGHER LAYERS
`
`PRESENTATION
`
`LLC—LOG|CAL LINK CONTFDL
`
`SESSION
`mmspom
`NETWORK
`
`_
`
`DATA LINK
`PHYSICAL
`
`’
`
`MAC—MEDlA ACCESS CONTROL
`RECONCILIATION
`'M"_’
`
`4—
`
`PCS
`PMA
`" PMD
`“"‘“'AUTONEG 4—
`MDI —>
`2 MEDIUM;
`100 Mbls
`
`MDI = MEDIUM DEPENDENT INTERHXCE
`MII = MEDIUM INDEPENDENT INTEREHCE
`
`PCS = PHYSICAL CODING SUBLNER
`PMA = PHYSICAL MEDIUM AITACHMENT
`PHY 2 PHYSICAL LNER ENTITY
`PMD = PHYSICAL MEDIUM DEPENDENT
`
`" MII is optional br 10 Mbfs DTEs and {Jr 101] Mbfs systems and is not spechd Ior1 Mbls systems
`“‘ PMD is speciied for 1DOBASE—TX and —FX on|y;1DDBASE—T4 does not use this later.
`“‘ AUTONEG comrrunicates with the PMA sutlayer through the PMA service interface messages
`PMA_L|NK_request and PMA_L|NK_indicate
`“"“ AUTONEG is optional.
`
`Figure 22-1—M|l location in the protocol stack
`
`The purpose of this interface is to provide a simple, inexpensive, and easy-to-implement interconnection
`between Media Access Contml (MAC) sublayer and PHYS, and between PHYS and Station Management
`(STA) entities.
`
`This interface has the following characteristics:
`
`It is capable of supporting both 10 Mb/S and 100 Mbis data rates.
`a)
`b) Data and deliniiters are synchronous to clock references.
`c)
`It provides independent four bit wide transmit and receive data paths.
`d)
`It uses TTL signal levels, compatible with common digital CMOS ASIC processes.
`e)
`It provides a simple management interface.
`t)
`It is capable of driving a limited length of shielded cable.
`
`This is a|'I(3&|;fiI§}III.@1IE¢I:_|&§fifi|'-El-fiI'.d5e,I;t,.;I]aS been superseded by a later version of this standard.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0053
`
`

`
`IEEE
`Std 802.3, 1993 Edilion
`
`22.1.1 Summary of major concepts
`
`LOCAL AND METROPOUTAN AREA NETWORKS:
`
`a)
`
`b)
`
`Each direction of data transfer is serviced with seven (making a total of 14) signals: Data (a four-bit
`bundle), Delimiter, Error, and Clock.
`
`Two media status signals are provided. One indicates the presence of carrier, and the other indicates
`the occurrence of a collision.
`
`c) A management interface comprised of two signals provides access to management parameters and
`services.
`
`d)
`
`The Reconciliation sublayer maps the signal set provided at the M11 to the PLS service definition
`specified ir1 clause 6.
`
`22.1.2 Application
`
`This clause applies to the interface between MAC sublayer and PHYs, and between PHYs and Station Man-
`agement entities. The implementation of the interface may assume any of the following three forms:
`
`a) A chip-to-chip (integrated circuit to integrated circuit) interface implemented with traces on a
`printed circuit board.
`
`b) A motherboard to danghterboard interface between two or more printed circuit boards.
`
`c)
`
`An interface between two printed circuit assemblies that are attached with a length of cable and an
`appropriate connector.
`
`Figure 22-2 provides an example of the third application environment listed above. All MI! conformance
`tests are performed at the mating surfaces of the M11 connector, identified by the line A-A.
`
`Mil Connector
`
`Figure 22-2—Example application showing location of conformance test
`
`This interface is used to provide media independence for various forms of unshielded twisted-pair wiring,
`shielded twisted-pair wiring, fiber optic cabling, and potentially other media, so that identical media access
`controllers may be used with any of these media.
`
`To allow for the possibility that multiple PHYs may be controlled by a single Station Managernent entity, the
`M11 management interface has provisions to accommodate up to 32 PHYs, with the restriction that a maxi-
`mum of one PHY may be attached to a management interface via the mechanical interface defined in 22.6.
`
`This is angerrchive IEEE Standard.
`
`it has been superseded bygap{a;er@1¢g§§@9Eqt..t.Eg,iaS$;a,r;rd§rrd.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0054
`
`

`
`CSMA/CD
`
`22.1.3 Rates of operation
`
`IEEE
`Std 802.3, 1998 Edition
`
`The MII can support two specific data rates, 10 Mb/s and 100 Mb/s. The functionality is identical at both
`data rates, as are the signal timing relationships. The only difference between 10 Mb/s and 100 Mb/s opera-
`tion is the nominal clock frequency.
`
`PHYs that provide an lVlII are not required to support both data rates, and may support either one or both.
`PHYS must report the rates they are capable of operating at via the management interface, as described in
`22.2.4.
`
`22.1.4 Allocation of functions
`
`The allocation of flll1Cl2l01'1S at the MII is such that it readily lends itself to implementation in both PHYS and
`MAC sublayer entities. The division of functions balances the need for media independence with the need
`for a simple and cost-effective interface.
`
`While the Attachment Unit Interface (AUI) was defined to exist between the Physical Signaling (PLS) and
`Physical Media Attachment (PMA) sublayers for 10 Mb/s DTEs, the MH maximizes media independence by
`cleanly separating the Data Link and Physical Layers of the ISO (IEEE) seven-layer reference model. This
`allocation also recognizes that implementations can benefit from a close coupling of the PLS or PCS sub-
`layer and the PMA sublayer.
`
`22.2 Functional specifications
`
`The M11 is designed to make the differences among the various media absolutely transparent to the MAC
`sublayer. The selection of logical control signals and the functional procedures are all designed to this end.
`Additionally, the MII is designed to be easily implemented at minimal cost using conventional design tech-
`niques and manufacturing processes.
`
`22.2.1 Mapping of MII signals to PLS service primitives and Station Management
`
`The Reconciliation sublayer maps the signals provided at the MII to the PLS service primitives defined in
`clause 6. The PLS service primitives provided by the Reconciliation sublayer behave in exactly the same
`manner as defined in clause 6. The MII signals are defined in detail in 22.2.2 below.
`
`Figure 22-3 depicts a schematic view of the Reconciliation sublayer inputs and outputs, and demonstrates
`that the MH management interface is controlled by the Station Management entity (STA).
`
`22.2.1.1 Mapping of PLS_DATA.request
`
`22.2.1.1.1 Function
`
`Map the primitive PLS_DATA request to the MII signals T}G)<3:0>, TX_EN and TX_CLK.
`
`22.2.1.1.2 Semantics of the service primitive
`
`PLS_DATA request (OUTPUT_UNIT)
`
`The OUTPUT_UNIT parameter can take one of three values: ONE, ZERO, or DATA_COMPLETE. It repre-
`sents a single data bit. The values ONE and ZERO are conveyed by the signals TXD<3>, TXD<2>,
`TXD<l> and TXD<0>, each of which conveys one bit of data while TX_EN is asserted. The value
`DATA_COMPLETE is conveyed by the de—assertion of TX_EN. Synchronization between the Reconcilia-
`tion sublayer and the PHY is achieved by way of the TX_CLK signal.
`
`This is arbetgfigii/@1bEfiEE§tanggr,d,e,lt.,,has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0055
`
`

`
`IEEE
`Std 802.3, 1993 Edition
`
`LOCAL AND METROPOUTAN AREA NETWORKS:
`
`PLS Service Primitives
`
`..
`
`.
`
`PLS_DATA.request
`
`PLS_SlGNAl_.indicate
`
`PLS_DATA.indicate
`
`PLS_CARR|ER.indicate
`
`Station Management
`
`Mil Signals
`
`TX_ER
`T)(D<3:0>
`
`“LE”
`T)(_CLK
`
`COL
`RXD<3:D>
`
`RX_ER
`RX_CLK
`
`Eiféw
`
`MDIO
`
`Figure 22-3—Reconci|iation Sublayer (RS) inputs and outputs
`and STA connections to will
`
`22.2.1.1.3 When generated
`
`The TX_C‘LK signal is generated by the PHY. The '1'XD<3:0> and TX_EN sigaals are generated by the Rec-
`onciliation sublayer after every group of four PLS_DATA request transactions from the MAC subiayer to
`request the transmission of four data bits on the physical medium or to stop transmission.
`
`22.2.1.2 Mapping of PLS_DATA.indicate
`
`22.2.1.2.1 Function
`
`Map the primitive PLS_DATA.i11dicate to the MH signals RXD<3:0>. RX_DV, RX_ER, and RX_CLK.
`
`22.2.1 .2.2 Semantics of the service primitive
`
`PLS_DATA.indicate (]INPUT_UN1T)
`
`The ]NPUT_UN'IT parameter can take one of two values: ONE or ZERO. It represents a single data bit. The
`values ONE and ZERO a.1'e derived from the signals RXD<3>, RXD<2>, RXD<l>, and RXD<0>_. each of
`which represents one bit of data while RX_DV is asserted.
`
`The value of the data transferred to the MAC is controlled by the RX_ER signal, see 22.2.1.5, Response to
`RX_ER indication from MI].
`
`Synchronization between the PHY and the Reconciliation sublayer is achieved by way of the RX_CLK
`signal.
`
`22.2.1.2.3 When generated
`
`This primitive is generated to all MAC sublayer entities in the network after a PLS_DATA.request is issued.
`Each nibble of data transferred on RXD<3 20> will result in the generation of four PLS_DATA.indicate trans-
`actions.
`
`This is amfiirchive IEEE Standard.
`
`It has been superseded by0gp{a§er@1fgij§@igq;qt..t.hi_,i§S$;ag;i:;l§ird.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0056
`
`

`
`CSMA/CD
`
`22.2.1.3 Mapping of PLS_CARRIER.indicate
`
`22.2.1 .3.1 Function
`
`IEEE
`Std 802.3, 1998 Edition
`
`Map the primitive PLS_CARRIER.indicate to the MH signals CRS and RX_DV.
`
`22.2.1.3.2 Semantics of the service primitive
`
`PLS_CARRIER.indicate (CARRIER_STATUS)
`
`The CARRIER_STATUS parameter can take one of two values: CARRIER_ON or CARRIER_OFF. The
`values CARRIER_ON and CARRIER_OFF are derived from the MII signals CRS and RX_DV.
`
`22.2.1.3.3 When generated
`
`The PLS_CARRIER.indicate service primitive is generated by the Reconciliation sublayer whenever the
`CARRIER_STATUS parameter changes from CARRIER_ON to CARRIER_OFF or vice versa.
`
`While the RX_DV signal is de-asserted, any transition of the CRS signal from de-asserted to asserted must
`cause a transition of CARRIER_STATUS from the CARRIER_OFF to the CARRIER_ON value, and any
`transition of the CRS signal from asserted to de-asserted must cause a transition of CARRIER_STATUS
`from the CARRIER_ON to the CARRIER_OFF value. At any time after CRS and RX_DV are both asserted,
`de-assertion of RX_DV must cause CARRIER_STATUS to transition to the CARRIER_OFF value. This
`transition of CARRIER_STATUS from the CARRIER_ON to the CARRIER_OFF value must be recog-
`nized by the MAC sublayer, even if the CRS signal is still asserted at the time.
`
`NOTE—The behavior of the CRS signal is specified within this clause so that it can be mapped directly (with the appro-
`priate implementation-specific synchronization) to the carriersense variable in the MAC process Deference, which is
`described in 4.2.8. The behavior of the RX_DV signal is specified within this clause so that it can be mapped directly to
`the carriersense variable in the MAC process BitReceiver, which is described in 4.2.9, provided that the MAC process
`BitReceiver is implemented to receive a nibble of data on each cycle through the inner loop.
`
`22.2.1.4 Mapping of PLS_SIGNAL.indicate
`
`22.2.1.4.1 Function
`
`Map the primitive PLS_SIGNAL.indicate to the M11 signal COL.
`
`22.2.1.4.2 Semantics of the service primitive
`
`PLS_SIGNAL.indicate (SIGNAL_STATUS)
`
`SIGNAL_ERROR or
`values:
`two
`of
`one
`take
`can
`parameter
`SIGNAL_STATUS
`The
`NO_SIGNAL_ERROR. SIGNAL_STATUS assumes the value SIGNAL_ERROR when the MII signal COL
`is asserted, and assumes the value NO_SIGNAL_ERROR when COL is de-asserted.
`
`22.2.1.4.3 When generated
`
`The PLS_SIGNAL.indicate service primitive is generated whenever SIGNAL_STATUS makes a transition
`from SIGNAL_ERROR to NO_SIGNAL_ERROR or vice versa.
`
`22.2.1.5 Response to RX_ER indication from Mll
`
`If, during frame reception, both RX_DV and RX_ER are asserted, the Reconciliation sublayer shall ensure
`that the MAC will detect a FrameCheckError in that frame.
`
`This is arbegfigii/@1bEfiEE§tanggrg,e,l1.,.has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0057
`
`

`
`IEEE
`Std 802.3, 1998 Edition
`
`LOCAL AND METROPOLITAN AREA NETWORKS:
`
`This requirement may be met by incorporating a function in the Reconciliation sublayer that produces a
`result that is guaranteed to be not equal to the CRC result, as specified by the algorithm in 3.2.8, of the
`sequence of nibbles comprising the received flame as delivered to the MAC sublayer. The Reconciliation
`sublayer must then ensure that the result of this function is delivered to the MAC sublayer at the end of the
`received flame in place of the last nibble(s) received flom the MII.
`
`Other techniques may be employed to respond to RX_ER, provided that the result is that the MAC sublayer
`behaves as though a FrameCheckError occurred in the received frame.
`
`22.2.1.6 Conditions for generation of TX_ER
`
`If, during the process of transmitting a frame, it is necessary to request that the PHY deliberately corrupt the
`contents of the frame in such a manner that a receiver will detect the corruption with the highest degree of
`probability, then the signal TX_ER may be generated.
`
`For example, a repeater that detects an RX_ER during flame reception on an input port may propagate that
`error indication to its output ports by asserting TX_ER during the process of transmitting that flame.
`
`Since there is no mechanism in the definition of the MAC sublayer by which the transmit data stream can be
`deliberately corrupted, the Reconciliation sublayer is not required to generate TX_ER.
`
`22.2.2 Mll signal functional specifications
`
`22.2.2.1 TX_CLK (transmit clock)
`
`TX_CLK (Transmit Clock) is a continuous clock that provides the timing reference for the transfer of the
`TX_EN, TXD, and TX_ER signals flom the Reconciliation sublayer to the PHY. TX_CLK is sourced by the
`PHY.
`
`The TX_CLK flequency shall be 25% of the nominal tlansmit data rate :|: 100 ppm. For example, a PHY
`operating at 100 Mb/s must provide a TX_CLK flequency of 25 MHz, and a PHY operating at 10 Mb/s must
`provide a TX_CLK flequency of 2.5 MHz. The duty cycle of the TX_CLK signal shall be between 35% and
`65% inclusive.
`
`NOTE—See additional information in 22.2.4.1.5.
`
`22.2.2.2 RX_CLK (receive clock)
`
`RX_CLK is a continuous clock that provides the timing reference for the transfer of the RX_DV, RXD, and
`RX_ER signals flom the PHY to the Reconciliation sublayer. RX_CLK is sourced by the PHY. The PHY
`may recover the RX_CLK reference from the received data or it may derive the RX_CLK reference from a
`nominal clock (e.g., the TX_CLK reference).
`
`The minimum high and low times of RX_CLK shall be 35% of the nominal period under all conditions.
`
`While RX_DV is asserted, RX_CLK shall be synchronous with recovered data, shall have a frequency equal
`to 25% of the data rate of the received signal, and shall have a duty cycle of between 35% and 65% inclusive.
`
`When the signal received flom the medium is continuous and the PHY can recover the RX_CLK reference
`and supply the RX_CLK on a continuous basis, there is no need to transition between the recovered clock
`reference and a nominal clock reference on a flame-by-flame basis. If loss of received signal flom the
`medium causes a PHY to lose the recovered RX_CLK reference, the PHY shall source the RX_CLK flom a
`nominal clock reference.
`
`This is an4¢\rchive IEEE Standard.
`
`It has been superseded byogplgggrg/g§§iggEg(..ti{§i§,s;agag@rd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0058
`
`

`
`CSMNCD
`
`IEEE
`Std 302.3, 1998 Edtlion
`
`Transitions from nominal clock to recovered clock or from recovered clock to nominal clock shall be made
`
`only while RX_DV is de—asserted. During the interval between the assertion of CR3 and the assertion of
`RX_DV at the beginning of a frame, tl1e PHY may extend a cycle of RX_CLK by holding it in either the
`high or low condition until the PHY has successfully locked onto the recovered clock. Following the de-
`assertion of RX_DV' at the end of a frame, the PHY may extend a cycle of RX_CLK by holding it in either
`the high or low condition for an interval that shall not exceed twice the nominal clock period.
`
`NOTE—This standard neither requires nor assumes a guaranteed phase relationship between the RX_CLK and
`TX_CLK signals. See additional infonnation ir1 22.2.4.1.5.
`
`22.2.2.3 TX_EN {transmit enable}
`
`TX_EN indicates that the Reconciliation sublayer is presenting nibbles on the M11 for transmission. It shall
`be asserted by the Reconciliation sublayer synchronously with the first nibble of the preamble and shall
`remain asserted while all nibbles to be transmitted are presented to the MII. TX_EN shall be negated prior to
`the first TX_CLK following the final nibble of a frame. TX_EN is driven by the Reconciliation sublayer and
`shall transition synchronously with respect to the TX_CLK.
`
`Figure 22-4 depicts TX_EN behavior during a flame transmission with no collisions.
`
`TX_EN
`
`/
`
`\
`
`WE"B'fl'|iI'I"C'I'I'I'I'I'I'I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`CRS
`
`COL
`
`Figure 22-4—Transmission with no collision
`
`22.2.2.4 TXD (transmit data)
`
`TXD is a bundle of 4 data signals (TXD<:3:O>) that are driven by the Reconciliation sublayer. TXD<3:0>
`shall transition synchronously with respect to the TX_CLK. For each TX_CLK period in which TX_EN is
`asserted, TXD€3'.0> are accepted for transmission by the PHY. TXD<O >is the least significant bit. While
`TX_EN is de-asserted, TXD<370> shall have no effect upon the PHY.
`
`Figure 22-4 depicts TXD<3:0> behavior during the transmission of a frame.
`
`Table 22-] summarizes the permissible encodings of TXD<3:0>._ TX_EN, and TX_ER.
`
`22.2.2.5 T)(_ER {transmit coding error)
`
`TX_ER. shall transition synchronously with respect to the TX_CLK. When TX_ER is asserted for one or
`more TX_CLK periods while TX_EN is also asserted, the PHY shall emit one or more symbols that are not
`
`This is arb5g,q5}iti@1$¢fi&§tan§l@r.q5e,i,t,j]as been superseded by a later version of this stancgrd.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0059
`
`

`
`IEEE
`Std 802.3, 1998 Edition
`
`LOCAL AND METROPOLITAN AREA NETWORKS:
`
`Table 22-1—Permissib|e encodings of TXD<3:0>, TX_EN, and TX_ER
`
`
`
`part of the valid data or delimiter set somewhere in the frame being transmitted. The relative position of the
`error within the frame need not be preserved.
`
`Assertion of the TX_ER signal shall not affect the transmission of data when a PHY is operating at 10 Mb/s,
`or when TX_EN is de—asserted.
`
`Figure 22-5 shows the behavior of TX_ER during the transmission of a frame propagating an error.
`
`Table 22-1 summarizes the permissible encodings of TXD<3:0>, TX_EN, and TX_ER.
`
`TX_EN
`
`/
`
`\
`
`TXD<3:0>
`
`B‘B‘E'G'ii|'G'll'E'E'H'I'I'I'I'I'I
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`
`TX_ER
`
`I
`
`\
`
`The TX_ER signal shall be implemented at the M11 of a PHY, may be implemented at the M11 of a repeater
`that provides an MII port, and may be implemented in MAC sublayer devices. If a Reconciliation sublayer
`or a repeater with an MII port does not actively drive the TX_ER signal, it shall ensure that the TX_ER sig-
`nal is pulled down to an inactive state at all times.
`
`22.2.2.6 RX_DV (Receive Data Valid)
`
`RX_DV (Receive Data Valid) is driven by the PHY to indicate that the PHY is presenting recovered and
`decoded nibbles on the RXD<3:0> bundle and that the data on RXD<3:O> is synchronous to RX_CLK.
`RX_DV shall transition synchronously with respect to the RX_CLK. RX_DV shall remain asserted continu-
`ously from the first recovered nibble of the frame through the final recovered nibble and shall be negated
`prior to the first RX_CLK that follows the final nibble. In order for a received frame to be correctly inter-
`preted by the Reconciliation sublayer and the MAC sublayer, RX_DV must encompass the frame, starting
`no later than the Start Frame Delirniter (SFD) and excluding any End-of-Frame delimiter.
`
`Figure 22-6 shows the behavior of RX_DV during frame reception.
`
`This is an44\rchive IEEE Standard.
`
`It has been superseded byogplagerg/g§§iggEg(..ti{gs$s;agagard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0060
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3, 1998 Edition
`
`RX_DV
`
`[
`
`\
`
`RXD<3:0>
`
`RXER
`
`riiliilfilfilfllfllflldillilJIEIIIIEIIIIEIJ
`
`
`
`LGGBIVE lalal
`
`RXD is a bundle of four data signals (RXD<3:0>) that transition synchronously with respect to the RX_CLK.
`RXD<3:0> are driven by the PHY. For each RX_CLK period in which RX_DV is asserted, RXD<3 :0> transfer
`four bits of recovered data firom the PHY to the Reconciliation sublayer. RXD<0> is the least significant bit.
`While RX_DV is de—asser1ed, RXD<3:0> shall have no efl‘ect on the Reconciliation sublayer.
`
`While RX_DV is de-asserted, the PHY may provide a False Carrier indication by asserting the RX_ER sig-
`nal while driving the value <1 1 10> onto RXD<3:0>. See 24.2.4.4.2 for a description of the conditions under
`which a PHY will provide a False Carrier indication.
`
`In order for a frame to be correctly interpreted by the MAC sublayer, a completely formed SFD must be
`passed across the M11. A PHY is not required to loop data transmitted on TXD<3:0> back to RXD<3:0>
`unless the loopback mode of operation is selected as defined in 22.2.4.l.2.
`
`Figure 22-6 shows the behavior of RXD<3:0> during frame reception.
`
`Table 22-2 summarizes the permissible encoding of RXD<3:0>, RX_ER, and RX_DV, along with the spe-
`cific indication provided by each code.
`
`Table 2—Permissible encoding of RXD<3:0>, RX_ER, and RX_DV
`
`
`
`This is arbeigfigii/@1EfiEE§tanggrg,e,lt,‘has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0061
`
`

`
`IEEE
`Std 802.3, 1998 Edition
`
`22.2.2.8 R)(_ER (receive error}
`
`LOCAL AND METROPOLITAN AREA NETWORKS:
`
`RX_ER (Receive Error) is driven by the PHY. RX_ER shall be asserted for one or more RX_CLK periods to
`indicate to the Reconciliation sublayer that an error (e.g., a coding error, or any error that the PHY is capable
`of detecting, and that may otheiwise be undetectable at the MAC sublayer) was detected somewhere in the
`frame presently being transferred from the PHY to the Reconciliation sublayer. RX_ER shall transition syn-
`chronously with respect to RX_CLK. While RX_DV' is de-asserted, RX_ER shall have no effect on the Rec-
`onciliation sublayer.
`
`While RX_DV is de-asserted. the PHY may provide a False Carrier indication by asserting the RX_ER sig-
`nal fo1' at least one cycle of the RX_CLK while driving the appropriate value onto RXD<3:0>, as defined in
`22.2.2.7. See 24.2.4.4.2 for a description of the conditions under which a PHY will provide a False Carrier
`indication.
`
`The effect of RX_ER on the Reconciliation sublayer is defined in 22.2.1.5, Response to RX_ER indication
`from MII.
`
`Figure 22-? shows the behavior of RX_ER during the reception of a frame with errors,
`
`Figure 22-7—Reception with errors
`
`Figure 22-8 shows the behavior of RX_ER, RX_DV and RXD<:3 :O> during a False Carrier indication.
`
`RXEN
`
`nxn-=a:u>
`
`rrrrrrvvrrrrrvr
`..E.@M..@.Mi&3MM..MMM
`
`Figure 22-8—Fa|se Carrier indication
`
`This is amgirchive IEEE Standard.
`
`It has been superseded byga,,ia§eg'@ig1j§iQigiEq{..t.h_,i§s$;@m;i§ird.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0062
`
`

`
`CSMNCD
`
`22.2.2.9 CRS {carrier sense)
`
`IEEE
`Std 302.3, 1998 Edition
`
`CRS shall be asserted by the PHY when either the transmit or receive medium is nonidle. CRS shall be de-
`asserted by the PHY when both the transmit and receive media are idle. The