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.
`
`197
`
`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.
`
`
`
`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.
`
`
`
`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_stalus = 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 [911] e 11111 11000 L
`5H|F1'|_EFr (r_bgt5)
`Lb;-is [[3] ¢: m_code_bi[
`
`1 5xPMD_UNlTDATA_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 - Exhib
`
`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
`
`Iink_contro| _
`SCAN_FOR_CARR| ER
`
`Iink_status <: OK
`
`= ENABLE
`
`as
`designated
`are
`li.nk_stat:us
`and
`link_control
`variables
`NOTE—Tl1e
`li.nk_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 tl1e 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 243.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 sublayer 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 - Exhibi
`
`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 =r
`signal_5tatus = ON
`
`PMD_UNITDATA,request *
`signal_status = OFF =t
`
`UCT
`num_ones : FEF_ONES '
`SEND FEF ZERO
`
`tx_code—bi't_out <= ZERO
`num_ones <= 0
`
`Figure 24-16—Far-End Fault Generate state diagram
`
`a)
`
`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 edifonirrf 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 n.1'zi-bits between PMA entities. The PMD translates
`the mzi-bits to and from signals suitable for the specified medium.
`
`The following p1'irn.iti\'es are defined:
`
`P1VJD_UNITDATA.reque st
`
`PMD_UNITDATA.indicate
`
`PMD_SIGNAL.indicate
`
`24.4.1.1 PMD_UNlTDATA.request
`
`This priniitive defines the transfer of data (in the form of 1n‘zi-bits) from the PMA to the PMD.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`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 Tb
`
`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 continuotls 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‘ans1:n.is-
`sion on the medilml.
`
`This is anlégrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhib
`
`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.
`
`
`
`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.8.1 Introduction
`
`The supplier of a protocol implementation that is claimed to conform to IEEE Std 802.3u-1995, Physical
`Coding Sublayer (PCS) and Physical Medium Attachment (PMA) sublayer, type l00BASE-X, shall com-
`plete the following Protocol Implementation Conformance Statement (PICS) proforma.
`
`A detailed description of the symbols used in the PICS proforma, along with instructions for completing the
`PICS proforma, can be found in clause 21.
`
`24.8.2 Identification
`
`24.8.2.1 Implementation identification
`
`Supplier
`
`Contact point for enquiries about the PICS
`
`Implementation Name(s) and Version(s)
`
`Other information necessary for full identification—e.g.,
`name(s) and Version(s) for machines and/or operating
`systems; System Names(s)
`
`NOTES
`
`(e.g., Type, Series, Model).
`
`1—Only the first three items are required for all implementations; other information may be completed as appropri-
`ate in meeting the requirements for the identification.
`2—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s terminology
`
`24.8.2.2 Protocol summary
`
`Identification of protocol standard
`
`IEEE Std 802.3u-1995, Physical Coding Sublayer (PCS)
`and Physical Medium Attachment (PMA) sublayer, type
`l00BASE-X
`
`Date of Statement
`
`Identification ofamendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`Yes [ ]
`No [ ]
`Have any Exception items been required?
`(See clause 21; the answer Yes means that the implementation does not conform to IEEE Std 802.3u-1995.)
`
`23Capyright releasefor PICSpmformas Users of this standard may fi'eely reproduce the PICS proforma in this annex so that it can be
`used for its intended purpose and may further publish the completed PICS.
`
`This is anlegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0209
`
`Aerohive - Exhibit 1025
`0209
`
`

`
`CSMA/CD
`
`24.8.2.3 Major capabilitiesloptions
`
`IEEE
`Std 802.3u-1995
`
`Subclause
`
`Value/Comment
`
`(clause 28)
`
`Supports DTE without MII
`
`Supports Repeater without MII
`
`Supports exposed MII inter-
`face
`
`Implements PCS fl.lI1Cti0I1S
`
`Implements PMA RX, TX and
`Link Monitor functions
`
`Medium capable of supporting
`Auto-Negotiation
`
`Implements Far-End Fault
`
`Supports Auto-Negotiation
`
`See clause 28
`
`See clause 28
`
`24.8.3 PICS proforma tables for the Physical Coding Sublayer (PCS) and Physical Medium
`Attachment (PMA) sublayer, type 100BASE-X
`
`24.8.3.1 General compatibility considerations
`
`GN1
`
`Compliance with MII require-
`ments
`
`24.4
`
`See clause 22
`
`24.7
`
`Environmental specifications
`
`24.8.3.2 PCS functions
`
`Subclause
`
`Value/Comment
`
`Carrier Sense process
`
`Transmit Bits process
`
`Transmit process
`
`Receive Bits process
`
`Receive process
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`021 O
`
`Aerohive - Exhibit 1025
`0210
`
`

`
`IEEE
`Std 802.3u-1995
`
`24.8.3.3 PMA functions
`
`SUPPLEMENT TO 802.3:
`
`Subclause
`
`Value/Comment
`
`Far-End Fault Detect process
`
`TX process
`
`RX process
`
`Carrier Detect process
`
`Link Monitor process
`
`Far-End Fault Generate pro-
`cess
`
`24.8.3.4 Timing
`
`Subclause
`
`Value/Comment
`
`assert/Assert Constraint
`
`Support for MII signals
`TX_CLK and RX_CLK
`
`Accuracy of code-bit_timer
`
`Compliance with PHY bit
`delay constraints
`
`Compliance with DTE bit
`delay constraints
`
`Compliance with Carrier De-
`
`See clause 22
`
`This is anlagrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`021 l
`
`Aerohive - Exhibit 1025
`0211
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`25. Physical Medium Dependent (PMD) sublayer and baseband medium, type
`100BASE-TX
`
`25.1 Overview
`
`This clause specifies the 100BASE—X PMD (including MDI) and baseband medium for twisted—pair wir-
`ing, 100BASE-TX. In order to form a complete 100BASE-TX Physical Layer it shall be integrated with
`the 100BASE—X PCS and PMA of clause 24, which are assumed incorporated by reference. As such, the
`100BASE-TX PMD shall comply with the PMD service interface specified in 24.4.1.
`
`25.2 Functional specifications
`
`The 100BASE-TX PMD (and MDI) is specified by incorporating the FDDI TP-PMD standard, ANSI
`X3.263: 199X (TP-PMD), by reference, with the modifications noted below. This standard provides sup-
`port for Category 5 unshielded twisted pair (UTP) and shielded twisted pair (STP). For improved legibil-
`ity in this clause, ANSI X3.263: l99X (TP-PMD), will henceforth be referred to as TP-PMD.
`
`25.3 General exceptions
`
`The 100BASE-TX PMD is precisely the PMD specified as TP-PMD, with the following general modifications:
`
`a)
`
`b)
`
`c)
`
`(1)
`
`The Scope and General description discussed in TP-PMD 1 and 5 relate to the use of those standards
`with an FDDI PHY, ISO 9314-1: 1989, and MAC, ISO 9314-2: 1989. These sections are not relevant
`to the use of the PMD with 100BASE—X.
`
`The Normative references, Definitions and Conventions of TP-PMD 2, 3, and 4 are used only as nec-
`essary to interpret the applicable sections of TP-PMD referenced in this clause.
`The PMD Service Specifications of TP-PMD 6 are replaced by those specified in 24.4.1. The
`100BASE-TX PMD Service specification is a proper subset of the PMD Service Specification in
`TP-PMD.
`
`There are minor terminology dilferences between this standard and TP-PMD that do not cause ambi-
`guity. The terminology used in 100BASE—X was chosen to be consistent with other IEEE 802 stan-
`dards, rather than with FDDI. Terminology is both defined and consistent within each standard.
`Special note should be made of the interpretations shown in table 25-1.
`
`Table 25-1—lnterpretation of general FDDI terms and concepts
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgajd.
`
`
`
`Aerohive - Exhibit 1025
`0212
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Table 25-1—lnterpretation of general FDDI terms and concepts (Continued)
`
`25.4 Specific requirements and exceptions
`
`The 100BASE-TX PMD (including MDI) and baseband medium shall comply to the requirements of
`TP-PMD, 7, 8, 9, 10, and 11, and normative annex A with the exceptions listed below. In TP-PMD, infor-
`mative armexes B, C, E, F, G, I, and J, with exceptions listed below, provide additional information useful
`to PMD sublayer implementors. Where there is conflict between specification in TP—PMD and those in
`this standard, those of this standard shall prevail.
`
`25.4.1 Change to 7.2.3.1.1, “Line state patterns”
`
`Descrambler synchronization on the Quiet Line State (QLS), Halt Line State (HLS), and Master Line
`State (MLS) Line State Patterns cited in TP—PMD 7.2.3.l.1 is optional.
`
`25.4.2 Change to 7.2.3.3, “Loss of synchronization”
`
`The