`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`MII
`MP
`NEXT
`
`NLP
`NPA
`NRZI
`
`PCS
`PDV
`PHY
`PICS
`PLS
`PMA
`PMD
`PMI
`PVV
`RS
`SSD
`
`SDV
`SFD
`
`SR
`ST
`STA
`STP
`SVV
`UCT
`
`UP
`UTP
`
`media independent interface
`message page
`near-end crosstalk
`
`normal link pulse
`next page algorithm
`non return to zero and invert on ones
`
`physical coding sublayer
`path delay value
`Physical Layer entity sublayer
`protocol implementation conformance statement
`physical signaling sublayer
`physical medium attachment
`physical medium dependent
`physical medium independent
`path variability value
`reconciliation sublayer
`start-of-stream delimiter
`
`segment delay value
`start-of-frame delimiter
`
`symbol rate
`symbol time
`station management entity
`shielded twisted pair (copper)
`segment variability value
`unconditional transition
`
`unformatted page
`unshielded twisted pair
`
`21.3 References
`
`References are shown beginning on pages 2 and 23 of this document (as updates to 1.3 and annex A).
`
`21.4 Definitions
`
`Definitions are shown beginning on page 5 of this document (as an update to 1.4).
`
`21.5 State diagrams
`
`State machine diagrams take precedence over text.
`
`The conventions of 1.2 are adopted, with the following extensions.
`
`21.5.1 Actions inside state blocks
`
`The actions inside a state block execute instantaneously. Actions inside state blocks are atomic (i.e., uninter-
`ruptible).
`
`After performing all the actions listed in a state block one time, the state block then continuously evaluates
`its exit conditions until one is satisfied, at which point con1:rol passes through a transition arrow to the next
`block. While the state awaits fiilfillrnent of one of its exit conditions, the actions inside do not implicitly
`repeat.
`
`This is an3Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`0046
`
`
`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`The characters 0 and [bracket] are not used to denote any special meaning.
`
`Valid state actions may include .indicate and request messages.
`
`No actions are taken outside of any state block.
`
`21.5.2 State diagram variables
`
`Once set, variables retain their Values as long as succeeding blocks contain no references to them.
`
`Setting the parameter of a formal interface message assures that, on the next transmission of that message,
`the last parameter value set will be transmitted.
`
`Testing the parameter of a formal interface messages tests the value of that message parameter that was
`received on the last transmission of said message. Message parameters may be assigned default values that
`persist until the first reception of the relevant message.
`
`21.5.3 State transitions
`
`The following terms are valid transition qualifiers:
`
`Boolean expressions
`a)
`b) An event such as the expiration of a timer: timer_done
`c) An event such as the reception of a message: PMA_UNITDATA.indicate
`d) An unconditional transition: UCT
`e) A branch taken when other exit conditions are not satisfied: ELSE
`
`Any open arrow (an arrow with no source block) represents a global transition. Global transitions are evalu-
`ated continuously whenever any state is evaluating its exit conditions. When a global transition becomes
`true, it supersedes all other transitions, including UCT, returning control to the block pointed to by the open
`arrow.
`
`21.5.4 Operators
`
`The state machine operators are shown in table 21-1.
`
`Table 21-1—State machine operators
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgrd.
`
`
`
`Aerohive - Exhibit 1025
`0047
`
`
`
`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.
`
`
`
`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.
`
`
`
`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.
`
`
`
`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.
`
`0052
`
`it 1025
`
`Aerohive - Exhibit 1025
`0052
`
`
`
`CSMNCD
`
`IEEE
`Std 302.3, 1993 Edition
`
`22. Reconciliation Sublayer (RS) and Media Independent Interface (Mll)
`
`22.1 Overview
`
`This clause defines the logical, electrical, and mechanical characteristics for the Reconciliation 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
`REFER EN C E
`MOQEL
`LAY ERS
`
`LAN
`
`CSMNCD
`LAYERS
`
`App|_|cAT|oN
`
`HIGHER LAYERS
`
`PRESENTATION
`
`LLC—LOG|CAL LINK CONTFDL
`
`SESSION
`‘[RAN5pQRT
`NETWORK
`
`DATA LINK
`PHYSICAL
`
`’
`
`MAC—MEDlA ACCESS CONTROL
`RECONCILIKIION
`Wm _’
`
`4—
`
`PCS
`PMA
`" PMD
`‘“"“‘AUTON EG 4—
`MDI —>
`2 MEDIUM;
`100 Mbts
`
`MDI = MEDIUM DEPENDENT INTERFIICE
`MII = MEDIUM INDEPENDENT INTERPICE
`
`PCS = PHYSICAL CODING SUBLNER
`PMA = PHYSICAL MEDIUM HTACHMENT
`PHY 2 PHYSICAL LNER ENTITY
`PMD = PHYSICAL MEDIUM DEPENDENT
`
`" MI] is optional br 10 Mbfs DTEs and hr 100 Mbfs systems and is not spechd lor1 Mbls systems
`“' PMD is speciled tor 1DDBASE—TX and —F)( on|y;1DDBASE—T4 does not use this later.
`“" AUTONEG comrrunicates with the PMA sutlayer through the PMA sewice interface messages
`PMA_L|NK.request and PMA_L|NK.indit:ate
`“"‘ AIJTONEG is optional.
`
`Figure 22-1—M|| location in the protocol stack
`
`The purpose of this interface is to provide a simple, inexpensive, and easy-to-implement interconnection
`between Media Access Control (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 fou1' 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 arbep§q5}ir.@1tE¢fifi§tan§igr.d5e,I);,j]as been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1
`
`00
`
`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.
`
`‘ erohive - Exhi o
`
`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.
`
`0055
`
`it 1025
`
`Aerohive - Exhibit 1025
`0055
`
`
`
`IEEE
`Std 802.3, 1993 Edition
`
`LOCAL AND METROPOLITAN AREA NETWORKS:
`
`PLS Service Primitives
`
`..
`
`.
`
`PLS_DATA.reque5t
`
`PLS_SiGNALindicate
`
`PLS_DATA.indicate
`
`PLS_CARR|ER.indicate
`
`Station Management
`
`Mil Signals
`
`TX_ER
`T)(D<3:l]>
`
`“LE”
`T)(_Ct_K
`
`COL
`RXD<3:D>
`
`RX_ER
`Rx_cu<
`
`§’F§§D“'
`
`MDIO
`
`Figure 22-3—Reconciliation Sublayer (RS) inputs and outputs
`and STA connections to MII
`
`22.2.1.1.3 When generated
`
`The TX_C‘LK signal is generated by the PHY. The TXD<3:0> and TX_EN sigials are generated by the Rec-
`onciliation sublayer after every group of four PLS_DATA request transactions from the MAC sublayer to
`request the tzransmission 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.iI1dicate to the MIT signals RXD<3:0>_. RX_DV, RX_ER, and RX_CLK.
`
`22.2.1 .2.2 Semantics of the service primitive
`
`PLS_DATA.indicate (]NPUT_UN1T)
`
`The ]NPUT_UNIT parameter can take one of two values: ONE or ZERO. It represents a single data bit. The
`values ONE and ZERO are 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 MIL
`
`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.ir1dicate t1'ans-
`actions.
`
`This is amfitrchive IEEE Standard.
`
`it has been superseded by0ap{a§er@;g§§iQgEqt..ti;;_,i%$;9gadard.
`
`Aerohive - Exhibi
`
`I
`
`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.
`
`
`
`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.
`
`
`
`Aerohive - Exhibit 1025
`0058
`
`
`
`CSMNCD
`
`IEEE
`Std 302.3, 1993 Edition
`
`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 CR8 and the assertion of
`RX_DV at the beginning of a frame, the 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 snblayer 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 M11. 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 frame transmission with no collisions.
`
`TX_EN
`
`/
`
`\
`
`TXD<3:|J>
`
`fl'fi'E'B'm‘B'll'I'fl‘I'I'I‘I’I'I‘I
`1
`1
`1
`1
`1
`1
`1
`1 E 1
`1
`1
`1
`1
`1
`1
`1
`
`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:0>) that are driven by the Reconciliation sublayer. TXD<3:0>
`shall transition synchronously with respect to the TX_CLK. For each IX_CLK period in which TX_EN is
`asserted, TXD<3'.O> are accepted for transmission by the PHY. TXD<0 >is the least significant bit. While
`TX_EN is de-asserted, TXD<3:0> 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 "IXD<3:0>, TX_EN, and TX_ER.
`
`22.2.2.5 TX_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 arb&5qQii.@1tE¢fifi§tan§grQ5eA);Khas been superseded by a later version of this stancgrd.
`
`Aerohive - Exhi
`
`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_D