CSMNCD
`
`IEEE
`Std BI[]2_3u—1995
`
`The PCS shall implement the Carrier Sense process as depicted in figure 24-12 including compliance with
`the associated state variables as specified in 24.2.3.
`BEGIN
`
`transmitting = TRUE +
`receiving = TRUE
`
`CARRIER SENSE OFF- CARRJER SENSE on
`<
`
`CR3
`
`-:= FALSE
`
`CR5
`
`<= TRUE
`
`transmitting = FALSE t
`receiving 2 FALSE
`
`Figure 24-12—Carrier Sense state diagram
`
`24.3 Physical Medium Attachment (PMA) sublayer
`
`24.3.1 Service interface
`
`The following specifies the service interface provided by the PMA to the PCS or another client, sucl1 as a
`repeater. These services are described in an abstract manner and do not imply any particular implementation.
`
`The PMA Service Interface supports the exchange of code-bits between the PCS and/or Repeater entities.
`The PMA converts code-bits i.nto NRZI format and passes these to the PMD. and vice versa. It also gener-
`ates additional status indications for use by its client.
`
`The following primitives are defined:
`
`PMA_TYPE.indicate
`
`PMA_UN'ITDATA.reque st
`
`PMA_UN1TDATA.indicate
`
`PMA_CARRIER.indicate
`
`PMA_LINK.indicate
`
`PMA_L1NK request
`
`PMA_RXERROR.i.ndicate
`
`24.3.1.1 PMA_TYPE.indicale
`
`This prinlitive is generated by the PMA to indicate the nature ofthe PMA instantiation. The purpose of this
`primitive is to allow clients to support connections to the various types of IOOBASE-T PMA entities in a
`generalized manner.
`
`24.3.1.1.1 Semantics of the service primitive
`
`PMA_TYPE.indicate (pn1a_type)
`
`The pma_type parameter for use with a IOOBASE-X PMA is “X”.
`
`24.3.1.1.2 When generated
`
`The PMA continuously generates this primitive to indicate the value of pn1a_type.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standajd.
`
`Aerohive - Exhibi
`
`Aerohive - Exhibit 1025
`
`0194
`
`

`
`IEEE
`Std 802.3u-1995
`
`24.3.1 .1.3 Effect of receipt
`
`SUPPLEMENT TO 802.3:
`
`The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
`
`24.3.1.2 PMA_UNlTDATA.request
`
`This primitive defines the transfer of data (in the form of code-bits) from the PMA’s client to the PMA.
`
`24.3.1.2.1 Semantics of the service primitive
`
`PMA_UNlTDATA.request (tx_code-bit)
`
`This primitive defines the transfer of data (in the form of code-bits) from the PCS or other client to the PMA.
`The tx_code-bit parameter can take one of two values: ONE or ZERO.
`
`24.3.1.2.2 When generated
`
`The PCS or other client continuously sends, at a nominal 125 Mb/s rate, the appropriate code-bit for trans-
`mission on the medium.
`
`24.3.1.2.3 Effect of receipt
`
`Upon receipt of this primitive, the PMA generates a PMD_UNITDATA request primitive, requesting trans-
`mission of the indicated code-bit, in NRZI format (tx_nrzi-bit), on the MDI.
`
`24.3.1.3 PMA_UNlTDATA.indicate
`
`This primitive defines the transfer of data (in the form of code-bits) from the PMA to the PCS or other client.
`
`24.3.1.3.1 Semantics of the service primitive
`
`PMA_UNITDATA.indicate (rx_code—bit)
`
`The data conveyed by PMA_UNITDATA.indicate is a continuous code-bit sequence at a nominal 125 Mb/s
`rate. The rx_code-bit parameter can take one of two values: ONE or ZERO.
`
`24.3.1.3.2 When generated
`
`to the PCS or other
`code-bits
`The PMA continuously sends
`PMD_UNITDATA.indicate primitives received from the PMD.
`
`client
`
`corresponding to the
`
`24.3.1.3.3 Effect of receipt
`
`The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
`
`24.3.1.4 PMA_CARRIER.indicate
`
`This primitive is generated by the PMA to indicate that a non-squelched, non-IDLE code-bit sequence is
`being received from the PMD. The purpose of this primitive is to give clients the earliest reliable indication
`of activity on the underlying continuous-signaling charmel.
`
`24.3.1.4.1 Semantics of the service primitive
`
`PMA_CARRIER.indicate (carrier_status)
`
`This is anmgchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`195
`
`025
`
`Aerohive - Exhibit 1025
`
`0195
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`The can'ier_status parameter can take on one of two values, ON or OFF, indicating whether a non—squelched,
`non-IDLE code-bit sequence (that is, carrier) is being received (ON) or not (OFF).
`
`24.3.1 .4.2 When generated
`
`The PMA generates this primitive to indicate a change in the value of carrier_status.
`
`24.3.1.4.3 Effect of receipt
`
`The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
`
`24.3.1.5 PMA_LINK.indicate
`
`This primitive is generated by the PMA to indicate the status of the underlying PMD receive link.
`
`24.3.1.5.1 Semantics of the service primitive
`
`PMA_LINK.indicate (link_status)
`
`The link_status parameter can take on one of three values: READY, OK, or FAIL, indicating whether the
`underlying receive channel is intact and ready to be enabled by Auto-Negotiation (READY), intact and
`enabled (OK), or not intact GAIL). Link_status is set to FAIL when the PMD sets signal_status to OFF;
`when Auto-Negotiation (optional) sets link_control to DISABLE; or when Far-End Fault Detect (optional)
`sets faulting to TRUE. When 1ink_status -‘F OK, then rx_code-bit and carrier_status are undefined.
`
`24.3.1.5.2 When generated
`
`The PMA generates this primitive to indicate a change in the value of link_status.
`
`24.3.1.5.3 Effect of receipt
`
`The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
`
`24.3.1.6 PMA_LlNK.request
`
`This primitive is generated by the Auto-Negotiation algorithm, when implemented, to allow it to enable and
`disable operation of the PMA. See clause 28. When Auto-Negotiation is not implemented, the primitive is
`never invoked and the PMA behaves as if1ink_contro1 = ENABLE.
`
`24.3.1.6.1 Semantics of the service primitive
`
`PMA_LlNK request (link_control)
`
`The link_control parameter takes on one of three values: SCAN_FOR_CARRIER, DISABLE, or ENABLE.
`Auto-Negotiation sets link_control to SCAN_FOR_CARRIER prior to receiving any fast link pulses, per-
`mitting the PMA to sense a l00BASE-X signal. Auto-Negotiation sets link_control to DISABLE when it
`senses an Auto-Negotiation partner (fast link pulses) and must temporarily disable the l00BASE-X PHY
`while negotiation ensues. Auto-Negotiation sets link_control to ENABLE when full control is passed to the
`l00BASE-X PHY.
`
`24.3.1.6.2 When generated
`
`Auto-Negotiation generates this primitive to indicate a change in link_control as described in clause 28.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`1025
`196
`
`Aerohive - Exhibit 1025
`
`0196
`
`

`
`IEEE
`Std 802.3u-1995
`
`24.3.1 .6.3 Effect of receipt
`
`SUPPLEMENT TO 802.3:
`
`This primitive affects operation of the PMA Link Monitor function as described in 24.3.4.4.
`
`24.3.1.7 PMA_RXERROR.indicate
`
`This primitive is generated by the PMA to indicate that an error has been detected during a carrier event.
`
`24.3.1.7.1 Semantics of the service primitive
`
`PMA_RXERROR.indicate (rxerror_status)
`
`The rxerror_status parameter can take on one of two values: ERROR or NO_ERROR, indicating whether the
`received carrier event contains a detectable error (ERROR) or not (NO_ERROR). A carrier event is consid-
`ered to be in error when it is not started by a Start—of—Stream Delimiter.
`
`24.3.1.7.2 When generated
`
`The PMA generates this primitive whenever a new, non-squelched carrier event is not started by a Start-of-
`Stream Delirniter.
`
`24.3.1.7.3 Effect of receipt
`
`The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
`
`24.3.2 Functional requirements
`
`The IOOBASE-X PMA comprises the following functions:
`
`b)
`
`a) Mapping of transmit and receive code—bits between the PMA Service Interface and the PMD Service
`Interface;
`Link Monitor, which maps the PMD_SIGNAL.indicate primitive to the PMA_LINK.indicate primi-
`tive, indicating the availability of the underlying PMD;
`Carrier Detection, which generates the PMA_CARRIER.indicate and PMA_RXERROR.indicate
`primitives from inspection of received PMD signals; and
`Far-End Fault (optional), comprised of the Far-End Fault Generate and Far-End Fault Detect pro-
`cesses, which sense receive channel failures and send the Far-End Fault Indication, and sense the
`Far-End Fault Indication.
`
`c)
`
`cl)
`
`Figure 24-4 includes a functional block diagram of the PMA.
`
`24.3.2.1 Far-End fault
`
`Auto—Negotiation provides a Remote Fault capability useful for detection of asymmetric link failures; i.e.,
`channel error conditions detected by the far—end station but not the near—end station. Since Auto—Negotiation
`is specified only for media supporting eight-pin modular connectors, such as used by 10OBASE-TX over
`unshielded twisted pair, Auto-Negotiation’s Remote Fault capability is unavailable to other media for which
`it may be fimctionally beneficial, such as 10OBASE-TX over shielded twisted pair or l00BASE-FX. A
`remote fault capability for l00BASE—FX is particularly usefiil due to this medium’s applicability over longer
`distances (making end-station checking inconvenient) and for backbones (in which detection of link failures
`can trigger redundant systems).
`
`For these reasons, l00BASE-X provides an optional Far-End Fault facility when Auto—Negotiation cannot be
`used. Far-End Fault shall not be implemented for media capable of supporting Auto—Negotiation.
`
`This is anlegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0197
`
`it 1025
`
`Aerohive - Exhibit 1025
`
`0197
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`When no signal is being received, as indicated by the PMD’s signal detect function, the Far—End Fault fea-
`ture permits the station to transmit a special Far—End Fault Indication to its far-end peer. The Far—End Fault
`Indication is sent only when a physical error condition is sensed on the receive channel. In all other situa-
`tions, including reception of the Far—End Fault Indication itself, the PMA passes through tx_code-bit. (Note
`that the Far—End Fault architecture is such that 1DLEs are automatically transmitted when the Far—End Fault
`Indication is detected. This is necessary to re-establish communication when the link is repaired.)
`
`The Far—End Fault Indication is comprised of three or more repeating cycles, each of 84 ONEs followed by a
`single ZERO. This signal is sent in-band and is readily detectable but is constructed so as to not satisfy the
`l00BASE—X carrier sense criterion. It is therefore transparent to the PMA’s client and to stations not imple-
`menting Far—End Fault.
`
`As shown in figure 24-4, Far—End Fault is implemented through the Far—End Fault Generate, Far—End Fault
`Detect and the Link Monitor processes.
`
`The Far—End Fault Generate process, which is interposed between the incoming tx_code-bit stream and the
`TX process, is responsible for sensing a receive channel failure (signal_status=OFF) and transmitting the
`Far—End Fault Indication in response. The transmission of the Far—End Fault Indication may start or stop at
`any time depending only on signal_status.
`
`The Far—End Fault Detect process continuously monitors rx_code-bits from the RX process for the Far—End
`Fault Indication. Detection of the Far—End Fault Indication disables the station by causing the Link Monitor
`process to deassert link_status, which in turn causes the station to source IDLEs. Far—End Fault detection can
`also be used by management functions not specified in this clause.
`
`24.3.2.2 Comparison to previous 802.3 PMAs
`
`Previous 802.3 PMA’s perform the additional functions of SQE Test and Jabber. Neither of these fimctions is
`implemented in the l00BASE—X PMA.
`
`SQE Test is provided in other Physical Layers to check the integrity of the Collision Detection mechanism
`independently of the Transmit and Receive capabilities of the Physical Layer. Since l00BASE—X effects col-
`lision detection by sensing receptions that occur during transmissions, collision detection is dependent on
`the health of the receive charmel. By checking the ability to properly receive signals from the PMD, the Link
`Monitor function therefore functionally subsumes the fimctions previously implemented by SQE Test.
`
`The Jabber function prevents a DTE from causing total network failure under certain classes of faults. When
`using mixing media (e.g., coaxial cables or passive optical star couplers), this fimction must naturally be
`implemented in the DTE.
`l00BASE—X requires the use of an active repeater, with one DTE or repeater
`attached to each port. As an implementation optimization, the Jabber fimction has therefore been moved to
`the repeater in l00BASE—X.
`
`24.3.3 State variables
`
`24.3.3.1 Constants
`
`FEF_CYCLES
`
`The number ofconsecutive cycles (ofFEF_ONES ONES and a single ZERO) necessary to indicate
`the Far—End Fault Indication. This value is 3.
`
`FEF_ONES
`
`The number of consecutive ONEs to be transmitted for each cycle ofthe Far—End Fault Indication.
`This value is 84.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`tl025
`0198
`
`Aerohive - Exhibit 1025
`
`0198
`
`

`
`IEEE
`Std 802.3u-1995
`
`24.3.3.2 Variables
`
`carrier_status
`
`SUPPLEMENT TO 802.3:
`
`The carrier_status parameter to be communicated by the Carrier Detect process through the
`PMA_CARRIER.indicate primitive. Carrier is defined as receipt of 2 noncontiguous ZEROes in
`10 code-bits.
`
`Values: ON; carrier is being received
`OFF; carrier is not being received
`
`faulting
`
`The faulting variable set by the Far-End Fault Detect process, when implemented, indicating
`whether or not a Far-End Fault Indication is being sensed. This variable is used by the Link
`Monitor process to force link_status to FAIL.When Far-End Fault is not implemented, this
`variable is always FALSE.
`
`Values: TRUE; Far-End Fault Indication is being sensed
`FALSE; Far-End Fault Indication is not being sensed
`
`link_control
`
`The link_control parameter as communicated by the PMA_LINK.request primitive. When Auto-
`Negotiation is not implemented, the value of link_control is always ENABLE. See clause 28 for a
`complete definition.
`
`link_status
`
`The 1ink_status parameter as communicated by the Link Monitor process through 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
`
`r_bits [9:O]
`
`In Carrier Detect, a vector of the 10 most recently received code-bits from the PMD RX process.
`r_bits [0] is the most recently received (newest) code—bit; r_bits [9] is the least recently received
`code-bit (oldest). r_bits is an internal variable used exclusively by the Carrier Detect process.
`
`rx_code—bit
`
`The rx_code-bit parameter as delivered by the RX process, which operates in synchronism with
`the PMD_UNITDATA.indicate primitive. rx_code—bit is the most recently received code-bit from
`the PMD after conversion from NRZI.
`
`rxerror_status
`
`The rxerror_status parameter to be communicated by the Carrier Detect process through the
`PMA_RXERROR.indicate primitive.
`
`Values: NO_ERROR; no error detected in the carrier event being received
`ERROR; the carrier event being received is in error
`
`signal_status
`
`The signa1_status parameter as communicated by the PMD_SIGNAL.indicate primitive.
`
`Values: ON; the quality and level of the received signal is satisfactory
`OFF; the quality and level of the received signal is not satisfactory
`
`tx_code-bit_in
`
`In Link Fault Generate, the tx_code—bit parameter as conveyed to the PMA from the PMA client
`by the PMA_UNITDATA request.
`
`tx_code-bit_out
`
`In Link Fault Generate, the tx_code—bit parameter to be passed to the TX process. Note that this is
`called tx_code—bit by the TX process.
`
`This is anlggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0199
`
`tl025
`
`Aerohive - Exhibit 1025
`
`0199
`
`

`
`CSMA/CD
`
`24.3.3.3 Functions
`
`SHIFTLEFT (rx_bits)
`
`IEEE
`Std 802.3u-1995
`
`In Carrier Detect, 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].
`
`24.3.3.4 Timers
`
`stabilize_tirner
`
`An implementation-dependent delay timer between 330 its and 1000 us, inclusive, to ensure that
`the link is stable.
`
`24.3.3.5 Counters
`
`num_cycles
`
`In Link Fault Detect, a counter containing the number of consecutive Far-End Fault cycles
`currently sensed. This counter gets reset on intialization or when the bit stream fails to qualify as
`a potential Far-End Fault Indication. It never exceeds FEF_CYCLES.
`num_ones
`
`This represents two separate and independent counters: In Link Fault Generate, a counter
`containing the number of consecutive ONEs already sent during this cycle of the Far-End Fault
`Indication. In Link Fault Detect, a counter containing the number of consecutive ONES currently
`sensed; it gets reset whenever a ZERO is detected or when the bit stream fails to qualify as a
`potential Far-End Fault Indication. These counters never exceed FEF_ONES.
`
`24.3.3.6 Messages
`
`PMD_UNITDATA.indicate (rx_nrzi-bit)
`
`A signal sent by the PMD signifying that the next nrzi-bit is available from the medium. nrzi-bit
`is converted (instantaneously) to code—bit by the RX process and used by the Carrier Detect
`process.
`
`5xPMD_UNITDATA.indicates
`
`In Carrier Detect, this shorthand notation represents repetition of the preceding state five times
`synchronized with five successive PMD_UNITDATA.indicates.
`
`PMA_UNITDATA request (tx_code-bit)
`
`A signal sent by the PMA’s client signifying that the next nrzi-bit is available for transmission. For
`this process, the tx_code-bit parameter is interpreted as tx_code-bit_in.
`
`24.3.4 Process specifications and state diagrams
`
`24.3.4.1 TX
`
`The TX process passes data from the PMA’s client directly to the PMD. The PMA shall implement the TX
`process as follows: Upon receipt of a PMA_UNITDATA request (tx_code-bit), the PMA performs a conver-
`sion to NRZI format and generates a PMD_UNITDATA request (tx_nrzi-bit) primitive with the same logical
`value for the tx_nrzi-bit parameter. Note that tx_code-bit is equivalent to tx_code-bit_out of the Link Fault
`Generate process when implemented.
`
`24.3.4.2 RX
`
`The RX process passes data from the PMD directly to the PMA’s client and to the Carrier Detect process. The
`PMA shall implement the RX process as follows: Upon receipt of a PMD_UNITDATA.indicate (rx_nrzi—bit),
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0200
`
`t 1025
`
`Aerohive - Exhibit 1025
`
`0200
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`the PMA performs a conversion from NRZI format and generates a PMA_UNITDATA.indicate (rx_code-bit)
`primitive with the same logical value for the rx_code-bit parameter.
`
`24.3.4.3 Carrier detect
`
`The PMA Carrier Detect process provides repeater clients an indication that a carrier event has been sensed
`and an indication if it is deemed in error. A carrier event is defined as receipt of two non-contiguous ZEROS
`within any 10 rx_code—bits. A carrier event is in error if it does not start with an SSD. The Carrier Detect pro-
`cess performs this function by continuously monitoring the code-bits being delivered by the RX process, and
`checks for specific patterns which indicate non—IDLE activity and SSD bit patterns.
`
`The Carrier Detect process collects code-bits from the PMD RX process. r_bits [920] represents a sliding,
`10-bit window on the code—bit sequence, with newly received code-bits from the RX process being shifted
`into r_bits [0]. The process shifis the r_bits vector to the left, inserts the newly received code—bit into posi-
`tion 0, and waits for the next PMD.UNITDATA.indicate before repeating the operation. This is depicted in
`figure 24-13. The Carrier Detect process monitors the r_bits vector until it detects two noncontiguous
`ZEROS in the incoming code—bit sequence. This signals a transition of carrier_status from OFF to ON. Each
`new carrier is further examined for a leading SSD (1 100010001) with rxerror_status set to ERROR if it is
`not confirmed. A pattern of 10 contiguous ONEs in the stream indicates a return to carrier_status = OFF.
`Code-bit patterns of contiguous ONES correspond to IDLE code-groups hi the PCS, per the encoding speci-
`fied in 24.2.2.1.
`
`r bits
`
`/
`9876543210
`
`rx_code-bit
`
`The PMA shall, if it is supporting a repeater, implement the Carrier Detect process as depicted in figure 24-
`14 including compliance with the associated state variables as specified in 24.3.3.
`
`24.3.4.4 Link Monitor
`
`The Link Monitor process is responsible for determining whether the underlying receive channel is provid-
`ing reliable data. Failure of the underlying channel typically causes the PMA’s client to suspend normal
`actions. The Link Monitor process takes advantage of the PMD sublayer’s continuously signaled transmis-
`sion scheme, which provides the PMA with a continuous indication of signal detection on the channel
`through signal_status as communicated by the PMD_SIGNAL.indicate primitive. It responds to control by
`Auto-Negotiation, when implemented, which is effected through the link_control parameter of
`PMA_SIGNAL request.
`
`The Link Monitor process monitors signal_status, setting link_status to FAIL whenever signal_status is OFF
`or when Auto-Negotiation sets link_control to DISABLE. The link is deemed to be reliably operating when
`signal_status has been continuously ON for a period of time. This period is implementation dependent but
`not less than 330 us or greater than 1000 as. If so qualified, Link Monitor sets 1ink_status to READY in
`order to synchronize with Auto-Negotiation, when implemented. Auto-Negotiation permits fiill operation by
`setting link_control to ENABLE. When Auto-Negotiation is not implemented, Link Monitor operates with
`link_control always set to ENABLE.
`
`This is anlggrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`
`0201
`
`

`
`CSMNCD
`
`IEEE
`Std BI[]2_3u—1995
`
`BEGIN
`
`|ink_status at OK
`
`INITIALIZE
`
`c= 1111111111
`r_bits[9:IJ]
`carrier_status
`<: OFF
`rxerror_status -.= NO_ERROR
`
`PMD_UN|TDATA_indicate
`
`RECEIVE NEXT BIT
`
`SH1FTLEF|' (r_bits]
`r_bils [El]
`-1:
`rx_code-bit
`
`{carrier_staius = ON) =i=
`(r_bits[9:i]]:1111111111)
`
`ELSE
`
`CARRIER OFF
`
`carrier_status <= OFF
`lXerr0r_statuS -:= NO_ERROR
`UCT
`
`{carrier_status = OFF) =1
`(r_bits [D] = D) 1
`(r_bits[9:2]
`=* 11111111)
`ribits [91]] = 11111 1100!]
`
`CARR1ER DETECT
`1
`carrieI_status <= ON
`r_biis [13:01 i 11111 11000 L
`5H||.—r|_E|.‘|' (Lmts)
`Lb;-is [[3] ¢: m_c0de_b';[
`
`1 5xPMD_UNiTDATA_indicates
`
`CON FiRM K
`
`Y B
`
`AD CARRIER 4%
`rxerror_status : ERROR Lbits [930] =* 11000 10001
`UCT
`
`V
`
`Y
`
`WAIT FOR NEXT
`
`4
`
`r_bits [13:01 = 11000 10001
`
`PMD_UN|TDATA_indicate
`
`Figure 24-14—Carrier Detect state diagram
`
`The PMA shall implement the Link Monitor process as depicted in figure 24-15 including compliance with
`the associated state variables as specified in 24.3.3.
`
`24.3.4.5 Far-End Fault Generate
`
`Far-End Fault Generate simply passes tx_code-bits to the TX process when 5ig1al_status=ON. ‘When
`sig1a[_statu5=OFF, it repetitively generates each cycle of the Far-End Fault Indication until sig:nal_status is
`reasserted.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanqigd.
`
`Aerohive - Exhibit
`
`Aerohive - Exhibit 1025
`
`0202
`
`

`
`IEEE
`Std 8D2_3u—1995
`
`SUPPLEMENT TO 802.3:
`
`BEGIN
`
`(signaI_status = OFF) +
`(|ink_control = DISABLE) +
`(faulting = TRUE)
`
`LINK DOWN
`
`|ink_s1atus <= FAIL
`
`signaI_status = ON
`
`V
`HYSTE RESIS
`
`Start stabi|ize_timer
`
`stabi|i2e_limer_done
`
`Y
`LINK READY
`
`|ink_status <: READY
`
`|ink_t:ontro| = ENABLE
`T
`LINK UP
`
`Iink_status <: OK
`
`Iink_contro| _
`SCAN_FOR_CARR| ER
`
`as
`designated
`are
`li.nk_status
`and
`link_control
`variables
`NOTE—The
`li.nl«:_control_[TX] and l:ink_status_|_TX]_. respectively. by the Auto-Negotiation
`A.rbit1'ation state diagram (figure 28-1
`
`Figure 24-15—Link Monitor state diagram
`
`If Far-End Fault is implemented, the PMA shall implement the Far-End Fault Generate process as depicted
`in figure 24-16 including compliance with the associated state variables as specified i.n 24.3.3.
`
`24.3.4.6 Far-End Fault Detect
`
`Far-End Fault Detect passively monitors the rx_code-bit stream from the RX process for the Far-End Fault
`Indication. It does so by maintaining counters for the number of consecutive ONEs seen since the last ZERO
`(num_ones) and the number ofcycles of 84 ONES and a single ZERO (num_cycles). The Far-End Fault Indi-
`cation is denoted by three or more cycles, each of 84 ONEs and a single ZERO. Note that the number of con-
`secutive ONES may exceed 84 on the first cycle.
`
`If Far-End Fault is implemented, the PMA shall implement the Far-End Fault Detect process as depicted in
`figure 24-I7 including compliance with the associated state variables as specified in 24.3.3.
`
`24.4 Physical Medium Dependent (PMD) sublayer service interface
`
`24.4.1 PMD service interface
`
`The following specifies the services provided by the PMD. The PMD is a sublayei‘ within IOOBASE-X and
`may not be present in other IOOBASE-T PHY specifications. PMD secrvices are described in an abstract
`manner and do not imply any particular implementation. It should be noted that these services are function-
`ally identical to those defined in the FDDI standards, such as ISO 9314-3: 1990 and ANSI X3263: l99X.
`with two exceptions:
`
`This is anlgrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1
`
`Aerohive - Exhibit 1025
`
`0203
`
`

`
`CSMNCD
`
`IEEE
`Std BI[]2_3u—1995
`
`INITIALIZE
`num_ones <: (I
`
`Jr‘
`
`CHECK SIGNAL DEFECT
`
`UCT
`SEND FEF ONE
`
`tx_code_b;1_out (: QNE
`num_ones -:= num_ones + 1
`
`;
`
`UCT
`FORWARD
`
`tx_code—bit_out <= tx_code_bit_in
`num_ones <= 0
`
`PMD_UN|TDATA_request *
`signa|_status = OFF =r
`num_ones < FEF_DNES
`
`PMD_UN|TDATA_request =t
`signal_status = ON
`
`PMD_UNITDATA,request *
`signal_status = OFF =t
`
`UCT
`num_ones : FEF_ONES '
`SEND FEF ZERO
`
`tx_code—bit_out <= ZERO
`num_0nes -:= 0
`
`Figure 24-16—Far-End Fault Generate state diagram
`
`3)
`
`b)
`
`IOOBASE-X does not include a Station Management (SMT} function; therefore the PMD-to-SMT
`interface defined in ISO 9314-3: 1990 andANSI X3263: 199X.
`
`IOOBASE-X does not support multiple instances of a PMD i.n service to a single PMA; therefore, no
`qualifiers are needed to identify the unique PMD being referenced.
`
`There are also ediforfaf differences between the interfaces specified here and in the referenced standards, as
`required by the context of IOOBASE-X.
`
`The PMD Service Interface supports the exchange of nrzi-bits between PMA entities. The PMD translates
`the nrzi-bits to and froin signzrls suitable for the specified medium.
`
`The following prirnitives are defined:
`
`PMD_UN'ITDATA.reque st
`
`PMD_UN'ITDATA.indicate
`
`PMD_SIGNAL.indicate
`
`24.4.1.1 PMD_UNlTDATA.request
`
`This primitive defines the transfer of data (in the form of znrzi-bits) fi‘o1:n the PMA to the PMD.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanqiajd.
`
`Aerohive - Exhibit
`
`Aerohive - Exhibit 1025
`
`0204
`
`

`
`IEEE
`Std 8D2_3u—1995
`
`SUPPLEMENT TO 802.3:
`
`signa|_status = OFF
`
`num_ones c= D
`num_cyc|es -:= 1
`faulting -:= FALSE
`
`PM D_UN|TDATA_indicate
`
`(rx_oo-de—bit = 1) *
`
`ELSE
`
`CHECK FAULT
`
`{num_ones = FEF_ONES) =+
`(num_cyc!es = 1)
`
`(rx_code—bit = 0) #
`{numfines = FEF_ONES)
`
`(rx_code4)it = 1) *
`[num_ones < FEF ONES)
`
`POTENTIAL CYCLE
`num_ones <= num_ones +1
`
`num_cyc|es <
`FEF_CYCLES
`Y
`CHECK CYCLES at
`
`COUNT CYCLE
`
`FIUITLOHGS <= 0
`
`num_I:yc|es ¢= num_cyI:|es + 1
`
`num_cyI:|es =
`FEF_CYCLES
`
`Y
`LINK FAULT
`
`faulting -:= TRUE
`
`UCT
`
`Figure 24-17—Far-End Fault Detect state diagram
`
`24.4.1.1.1 Semantics of the service primitive
`
`PMD_UNITDATA.reque st (tx_nrzi-bit)
`
`The data conveyed by PMD_UNITDATA request is a continuous sequence of nrzi-bits. The tx_n.1'zi-bit
`parameter can take o11e of two values: ONE or ZERO.
`
`24.4.1 .1 .2 When generated
`
`The PMA continuously sends, at a nominal 125 Mbfs rate, the PMD the appropriate nrzi-bits for t1‘ansn1.is-
`sion on the mediunl.
`
`This is anlégrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 10
`
`02
`
`Aerohive - Exhibit 1025
`
`0205
`
`

`
`CSMA/CD
`
`24.4.1 .1.3 Effect of receipt
`
`IEEE
`Std 802.3u-1995
`
`Upon receipt of this primitive, the PMD converts the specified nrzi—bit into the appropriate signals on the
`MDI.
`
`24.4.1.2 PMD_UNlTDATA.indicate
`
`This primitive defines the transfer of data (in the form of nrzi-bits) from the PMD to the PMA.
`
`24.4.1.2.1 Semantics of the service primitive
`
`PMD_UNITDATA.indicate (rx_nrzi-bit)
`
`The data conveyed by PlVfl)_UNITDATA.indicate is a continuous nrzi—bit sequence. The rx_nrzi-bit param-
`eter can take one of two values: ONE or ZERO.
`
`24.4.1.2.2 When generated
`
`The PMD continuously sends nrzi-bits to the PMA corresponding to the signals received from the MDI.
`
`24.4.1.2.3 Effect of receipt
`
`The effect of receipt of this primitive by the client is unspecified by the PMD sublayer.
`
`24.4.1.3 PMD_SIGNAL.indicate
`
`This primitive is generated by the PMD to indicate the status of the signal being received from the MDI.
`
`24.4.1.3.1 Semantics of the service primitive
`
`PMD_SIGNAL.indicate (signal_status)
`
`The signal_status parameter can take on one of two values: ON or OFF, indicating whether the quality and
`level of the received signal is satisfactory (ON) or unsatisfactory (OFF). When signal_status = OFF, then
`rx_nrzi-bit is undefined, but consequent actions based on PMD_SIGNAL.indicate, where necessary, inter-
`pret rx_nrzi-bit as logic ZERO.
`
`24.4.1.3.2 When generated
`
`The PMD generates this primitive to indicate a change in the value of signal_status.
`
`24.4.1.3.3 Effect of receipt
`
`The effect of receipt of this primitive by the client is unspecified by the PMD sublayer.
`
`24.4.2 Medium Dependent Interface (MDI)
`
`The MDI, a physical interface associated with a PMD, is comprised of an electrical or optical medium con-
`nector. The 10OBASE—X MDIs, defined in subsequent clauses, are specified by reference to the appropriate
`FDDI PMD, such as in ISO 9314-3: 1990 and ANSI X3.263: l99X, together with minor modifications (such
`as connectors and pin-outs) necessary for l00BASE-X.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`
`0206
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`24.5 Compatibility considerations
`
`There is no requirement for a compliant device to implement or expose any of the interfaces specified for the
`PCS, PMA, or PMD. However, if an exposed interface is provided to the PCS, it shall comply with the
`requirements for the MII, as specified in clause 22.
`
`24.6 Delay constraints
`
`Proper operation of a CSMA/CD LAN demands that there be an upper bound on the propagation delays
`through the network. This implies that MAC, PHY, and repeater implementors must conform to certain delay
`minima and maxima, and that network planners and administrators conform to constraints regarding the
`cable topology and concatenation of devices. MAC constraints are contained in clause 21. Topological con-
`straints are contained in clause 29.
`
`The reference point for all MDI measurements is the 50% point of the mid-cell transition corresponding to
`the reference code-bit, as measured at the MDI. Although 100BASE-TX output is scrambled, it is assumed
`that these measurements are made via apparatuses that appropriately account for this.
`
`24.6.1 PHY delay constraints (exposed Mll)
`
`Every l00BASE-X PHY with an exposed MII shall comply with the bit delay constraints specified in table
`24-2. These figures apply for all l00BASE-X PMDs.
`
`Table 24-2—MDl to Mll delay constraints (exposed Mll)
`
`
`
`24.6.2 DTE delay constraints (unexposed Mll)
`
`Every l00BASE-X DTE with no exposed MII shall comply with the bit delay constraints specified in table
`24-3. These figures apply for all l00BASE-X PMDs.
`
`24.6.3 Carrier de-assertionlassertion constraint
`
`To ensure fair access to the network, each DTE shall, additionally, satisfy the following:
`
`This is anlggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`
`0207
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`Table 24-3—DTE delay constraints (unexposed Mll)
`
`
`
`(MAX MDI to MAC Carrier De-assert Detect) — (MIN MDI to MAC Carrier Assert Detect) < 13
`
`24.7 Environmental specifications
`
`All equipment subject to this clause shall conform to the requirements of 14.7 and applicable sections of
`ISO/IEC 11801: 1995.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanqigrd.
`
`0208
`
`t 1025
`
`Aerohive - Exhibit 1025
`
`0208
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`24.8 Protocol Implementation Conformance Statement (PICS) profonna for clause 24,
`Physical Coding Sublayer (PCS) and Physical Medium Attachment (PMA) sublayer,
`type 100BASE-X23
`
`24.