IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`the PMA performs a conversion from NRZI format and generates a PMA _ UNIIDATA.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(cid:173)
`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 [9:0] 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 shifts the r_bits vector to the left, inserts the newly received code-bit into posi(cid:173)
`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 (1100010001) 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 in the PCS, per the encoding speci(cid:173)
`fied in 24.2.2.1.
`
`r_bits
`
`I'(; 71615141312111 0------------,~
`
`Figure 24-13-Carrier Detect reference diagram
`
`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(cid:173)
`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 sub layer's continuously signaled transmis(cid:173)
`sion scheme, which provides the PMA with a continuous indication of signal detection on the cl1a1mel
`through signal_status as communicated by the PMD_SIGNAL.indicate primitive. It responds to control by
`link_control parameter of
`Auto-Negotiation, when implemented, which is effected through the
`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 JlS or greater than 1000 JlS. If so qualified, Link Monitor sets link_status to READY in
`order to synchronize with Auto-Negotiation, when implemented. Auto-Negotiation permits full operation by
`setting link_control to ENABLE. When Auto-Negotiation is not implemented, Link Monitor operates with
`link_control always set to ENABLE.
`
`RUCKUS Ex 1008-pg. 1
`
`

`

`CSMNCD
`
`BEGIN
`
`IEEE
`Std 802.3U-1995
`
`1
`
`l
`
`!N!T!AUZE
`!:_bits {90] ~ 1111111111
`carrier . ..status
`'~'" OFF
`rxerror _;Status ¢"" NO_ ERROR
`
`PMD _ UN!TDATAir!dicate
`
`RECEIVE NEXT BIT
`SH!FTLEH (r .. bits)
`r_bits [0] ·~ rx code-bit I
`
`!
`
`(carrier .. s1a!us"' ON}"'
`(r ... !Ji!s [9:0]"" 1i11'11ii1'1)
`
`ElSE
`
`(caoier _status ""OFF) "
`(r_bits [Gj"' 0)"
`(r ... bits [9:2]
`.t.
`
`·1 "lt i 1111}
`
`CARRIER OFF
`carrier _status ¢"" OFF
`rxerrou;tattw <-= NO_ERROR
`UCT
`
`GET NEXT QUINT
`SH!HLEFT (r:_bits)
`r ... bits !0} '!= rx ... code-·bit
`
`5xPMD _ UN!TDATA.indicates
`
`~~B~A~D~C~A~R~R~IE~:R~~~--~~~
`i rxerror_status"' ERROR i r_bits [901 if. 11000 !0001
`
`l... ..... ~ ....... ~~~-~-~-~~ .. : ... ~· ........ : ... 1
`
`UCT
`
`r_bits[G:O]"' 11000 IOQ(J!
`i
`~-····················································································-······················
`·····························································~
`
`WAIT FOR NEXT
`
`PMD ... UNITD.AJA.indicate
`
`Figure 24-14-Carrier Detect state diagram
`
`The P:I\JA. shall implement the Link :tvfonitor pmce% as depicted in figure 24-15 including compliance with
`the associated state variables as £t->eci:fied 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 \vhen signal_status=OK \\'hen
`signat_statm;=DFF. it repetitively generates each cycle of the Fru.·~End Fault Indication until signal."status is
`reasserted.
`
`This is an Archive IEEE Standard. it has been superseded by a later v·ersion of this stan1~rrd.
`
`RUCKUS Ex 1008-pg. 2
`
`

`

`IEEE
`Std 302. 3u-l995
`
`SUPPLEMENT TO 002.3
`
`BEGIN
`
`1 ~
`
`(si{!nal ... status "' OFF) +
`(!ink
`_control'" DISABLE)+
`(fuu!\
`ing=TRUE)
`~
`UNKOOWN
`!ink .,.;Status ~"" FAIL
`signatsm
`tus""ON
`........ l
`........................ ~ ....
`HYSTERESIS
`Start stabilize l!mer
`
`["
`
`... l s!atll!ize...J]
`
`UNKREAffi'
`link.,..;status """' READY
`~ link -contn r>I=ENABLE
`
`!Ink_ control "'
`SCAN .... FOR ... CARRIER
`
`LINK UP
`
`!ink_ status<= OK
`
`link status ar~ desiznakd as
`and
`lbk contt<<1
`NOTE--The
`vaJ·i~ahles
`liuk_control_(TX] and tllti:_>tatusjTX], reo,pecti\;ely, by the Auto-Neg<:Jtiatinn
`Arhitmtkm state diagram (fipm:: 28-16}.
`
`Figure 24A5-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 \'ariables as specified in 2433.
`
`Far-End Fault Detect passively monitors the rx_code-bit stream from the R.:X: prQcess kw the Far-End Fault
`Indication. It does so by maintaining counteG for the number of C{lthecutive 01'-l'Tis seen since the last ZERO
`(num_ ones) and the number of cydes of84 01\ts and a single ZERO (num_cydes), The Far-End Fault Indi·
`cation is denutedbythree or more cycles, each of840NEs and a single ZERO. Note that the munbexofc<.m(cid:173)
`se.:::utive ONEs may exceed 84 nn the fir;1;t .:::yde.
`
`If Far-End fault is implemented. the P.MA shall implement the Far-End Fault Detect process as depict<.>d in
`figure 24·17 including compliance with the associated .1>tate Yariahies as specified in 243 ,3,
`
`24.4 Physical Medium Dependent (PMD} sublayer service interface
`
`24.4. 1 PMD service interface
`
`The following spe<::iiks the se1vices provided by the PlviD, The P!viD is n sublayer \vithin lOOBASE-X and
`rnay not be present in other lOOBASE-T PHY specifications. P:t\ID services are described in m1 abstract
`manner and do not imply any particular implementation. It shonhi be noted that these services are fi.mction«
`ally identical to thQse defined in the FDDI standards, sud1 as ISO 9314-3: 1990 and ANSI X3.263: l99X.
`with tvw exceptions:
`
`This is arh~'Chive IEEE Standard. it has been superseded by a later v·ersion of this standard.
`
`RUCKUS Ex 1008-pg. 3
`
`

`

`CSMNCD
`
`IEEE
`Std 802.3U-1995
`
`BEGIN
`
`UCT
`
`SENOFEFONE
`t<u:ooe-bit_out'"' ONE
`num .. on~s ~ num ... ones + 1
`
`UCT
`FORWARD
`tx_code-bit_out ¢'" tx_coof!_bit_in
`num _ones '*'' 0
`
`PMD_UN!TOATAmquest ~
`signal_status "' OFF "
`num .. .on~s < FEF ... ONES
`
`PMO_UNITDATA.request •·
`signal_ status " ON
`
`PMD _ UNITDATAmquest "
`signaU>tatus"' OFF •
`num .. .on~s"' FEF ... :ONFS
`
`UCT
`SEND FEF ZERO
`tx_code-bit_out ~ZERO
`num ... OMS~O
`
`Figure 24-16--Far-End Fault Generate state diagram
`
`a)
`
`b)
`
`lOOBASE-X does not induJe a Station Ivfanagement {S?viT) function: therefore the PkiD-to-StJT
`iuterfu~e defined in ISO 9314-3: 1990 am:lA"l"Sl X326J: 199X.
`lDOBASE-X does not support nmltipie instances of a PJ\ID in seni.ce m a single P~AA; therefore, uo
`qualifiers are needed to identify the unique PkiD being reference&
`
`There are also editorial difterences bertveen the interfaces specified here and in the t-eferenced standards, as
`required by the ,;:ontex.t of lOOBASE-X
`
`The P:tv.ID Serviee Interface supports the exchange of nrzi-bits bet\veen PhLA entities. The PJ\ID translates
`the nrzi-bits to and from signals suitable tor the specified medium.
`
`The fnHmving primitives are defined:
`
`PMD .. 1JNITDATA,t-eqnest
`
`PMD _ UNlTDAIAindic.ate
`
`PMD _SIGNAL indicate
`
`24.4. 1.1 PMCUJNITDATA.request
`
`This primitive defines the transfer of thta (in the fonn nf nn:i-bits) from the P\lA to the Pl'viD.
`
`This is an Archive IEEE Standard. it has been superseded by a later v·ersion of this stan~>d.
`
`RUCKUS Ex 1008-pg. 4
`
`

`

`IEEE
`Std 302. 3u-l995
`
`SUPPLEMENT TO 002.3
`
`BEGIN
`
`signal .. .status = OFF
`
`······················,...x-.--1 ~"
`
`RESET
`
`oum_ooes-¢"' 0
`omn ... cycles <= 1
`faulting <= FAlSE
`
`UCT
`
`PMD ~ UNilDA1A.indicata
`
`rmm. __ cydas <
`........................................................ !
`FEF ... CYCLES
`CHECK CYCLES
`! - , ------+1
`num_cyc!es-¢"' num_cycles + 1
`
`COUNT CYCLE
`
`UCT
`
`num_cyclas ~
`FEF_CYCLES
`L. UNKFAULT
`i tau!ting -¢"'TRUE
`i
`
`- - - '
`
`UCT
`
`····································································································································-·········································-·······
`
`Figure 24·11-Far-End Fault Detect state diagram
`
`24.4.1.1.1 Semantics of the service primitive
`
`P.MD _ tJNiTDATA.request (tx_nrzi-bit)
`
`The dam conveyed hy PMD.JJN1TDAIA request is a contimmm sequence of nrzi-hits. The tx ... nrzi-hit
`parameter can take one of n.vo values: Ol\t or ZERO,
`
`24.4.1.1 ,2 When generated
`
`TI1e P:t\:f./1.. continuou.dy sends, at a nominal 125 :1\.fb/s, rate, the P:\ID the appropriate nrzi-bits for transmis(cid:173)
`sion on the medium.
`
`This is an1~trchive IEEE Standard. it has been superseded by a later v·ersion of this standard.
`
`RUCKUS Ex 1008-pg. 5
`
`

`

`CSMAICD
`
`24.4.1.1.3 Effect of receipt
`
`IEEE
`Std 802.3u-1995
`
`Upon receipt of this primitive, the PMD corwerts the specified nrzi-bit into the appropriate signals on the
`MDI.
`
`24.4.1.2 PMD_UNITDATA.indicate
`
`This primitive defines the transfer of data (in the form of nrzi-bits) from the PlVID to the PMA.
`
`24.4.1.2.1 Semantics of the service primitive
`
`PMD_UNIIDATA.indicate (rx_nrzi-bit)
`
`The data conveyed by PMD _UNIIDATA.indicate is a continuous nrzi-bit sequence. The rx_nrzi-bit param(cid:173)
`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 sub layer.
`
`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(cid:173)
`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 sub layer.
`
`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(cid:173)
`nector. The lOOBASE-X MD Is, defined in subsequent clauses, are specified by reference to the appropriate
`FDDI PMD, such as in ISO 9314-3: 1990 and ANSI X3.263: 199X, together with minor modifications (such
`as connectors and pin-outs) necessary for lOOBASE-X.
`
`RUCKUS Ex 1008-pg. 6
`
`

`

`IEEE
`Std 802.3u-1995
`
`24.5 Compatibility considerations
`
`SUPPLEMENT TO 802.3:
`
`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 Mil, 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(cid:173)
`straints are contained in clause 29.
`
`The reference point for all ~IDI measurements is the 50% point of the mid-cell transition corresponding to
`the reference code-bit, as measured at the l\IIDI. Although IOOBASE-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 Mil)
`
`Every IOOBASE-X PHY with an exposed Mil shall comply with the bit delay constraints specified in table
`24-2. These figures apply for alllOOBASE-X PMDs.
`
`Table 24-2-MDI to Mil delay constraints (exposed Mil)
`
`Sub layer
`measurement
`points
`
`Event
`
`Min Max
`(bits)
`(bits)
`
`Input timing
`reference
`
`Output timing
`reference
`
`MII~MDI
`
`TX_EN Sampled to MDI Output
`
`MDI input to CRS assert
`
`MDI input to CRS de-assert (aligned)
`
`MDI input to CRS de-assert
`(unaligned)
`
`MDI input to COL assert
`
`MDI input to COL de-assert (aligned)
`
`MDI input to COL de-assert
`(unaligned)
`
`TX_EN sampled to CRS assert
`
`TX_EN sampled to CRSde-assert
`
`6
`
`13
`
`13
`
`13
`
`13
`
`0
`0
`
`14
`20
`24
`24
`
`20
`24
`24
`
`4
`
`16
`
`TX _ CLK rising
`
`1st bit of /J/
`
`1st bit of /J/
`
`1st bit of IT/
`
`I stONE
`
`1st bit of /J/
`
`1st bit of IT/
`
`I stONE
`
`TX _ CLK rising
`
`TX _ CLK rising
`
`24.6.2 DTE delay constraints (unexposed Mil)
`
`Every IOOBASE-X DTE with no exposed Mil shall comply with the bit delay constraints specified in table
`24-3. These figures apply for alllOOBASE-X PMDs.
`
`24.6.3 Carrier de-assertion/assertion constraint
`
`To ensure fair access to the network, each DTE shall, additionally, satisfy the following:
`
`RUCKUS Ex 1008-pg. 7
`
`

`

`CSMAICD
`
`Sub layer
`measurement
`points
`MAC ¢:}MDI
`
`IEEE
`Std 802.3u-1995
`
`Table 24-3-DTE delay constraints (unexposed Mil)
`
`Event
`
`Min
`(bits)
`
`Max
`(bits)
`
`Input timing
`reference
`
`Output timing
`reference
`
`MAC transmit start to MDI output
`MDI input to MDI output
`(worst-case nondeferred transmit)
`MDI input to collision detect
`MDI input to MDI output= Jam
`(worst case collision response)
`
`18
`54
`
`28
`54
`
`1st bit of /J/
`
`1st bit of /J/
`1st bit of /J/
`
`1st bit of /J/
`1st bit of /J/
`
`1stbitofjam
`
`(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
`TSO/TEC 11S01: 1995.
`
`RUCKUS Ex 1008-pg. 8
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`24.8 Protocol Implementation Conformance Statement (PICS) proforma for clause 24,
`Physical Coding Sublayer (PCS) and Physical Medium Attachment (PMA) sublayer,
`type 1 OOBASE-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 Attaclunent (PMA) sublayer, type lOOBASE-X, shall com(cid:173)
`plete the following Protocol Implementation Conformance Statement (PTCS) proforma.
`
`A detailed description of the symbols used in the PICS proforma, along with instructions for completing the
`PICS profomm, can be fom1d 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 ancl/or operating
`systems; System Names(s)
`
`NOTES
`1-0nly 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
`(e.g., Type, Series, Model).
`
`24.8.2.2 Protocol summary
`
`Identification of protocol standard
`
`IEEE Std 802.3u-1995, Physical Coding Sublayer (PCS)
`and Physical Medium Attachment (PMA) sub layer, type
`lOODASE-X
`
`Identification of amendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`Have any Exception items been required?
`Yes[]
`No[]
`(See clause 21; the answer Yes means that the implementation does not conform to IEEE Std 802.3u-1995.)
`
`Date of Statement
`
`23Copyrighr release for PJCS proformas Users ofthis standard may ire ely reproduce the P lCS proforma in this annex so that it can be
`used for its intended purpose and may further publish the completed PICS.
`
`RUCKUS Ex 1008-pg. 9
`
`

`

`CSMAICD
`
`24.8.2.3 Major capabilities/options
`
`IEEE
`Std 802.3u-1995
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`*DTE
`
`Supports DTE without Mil
`
`24.4
`
`*REP
`
`*Mil
`
`Supports Repeater without Mil
`
`24.4
`
`Supports exposed Mil inter-
`face
`
`24.4
`
`*PCS
`
`Implements PCS functions
`
`24.2
`
`PMA
`
`Implements PMA RX, TX and
`Link Monitor functions
`
`24.3
`
`*NWC Medium capable of supporting
`Auto-Negotiation
`
`0/1
`
`0/1
`
`011
`
`REP: 0
`DTE:M
`Mil: M
`
`M
`
`0
`
`See clause 28
`
`*FEF
`
`Implements Far-End Fault
`
`24.3.2.1
`
`NWC:X
`
`NWY
`
`Supports Auto-Negotiation
`(clause 28)
`
`NWC:O
`
`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
`
`Item
`
`GNl
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Compliance with Mil require-
`ments
`
`24.4
`
`MII:M
`
`See clause 22
`
`GN2
`
`Enviromnental specifications
`
`24.7
`
`M
`
`24.8.3.2 PCS functions
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`PSI
`
`PS2
`
`PS3
`
`PS4
`
`PS5
`
`Transmit Bits process
`
`24.2.3
`
`PCS:M
`
`Transmit process
`
`24.2.4.2
`
`PCS:M
`
`Receive Bits process
`
`24.2.4.3
`
`PCS:M
`
`Receive process
`
`24.2.4.4
`
`PCS:M
`
`Carrier Sense process
`
`24.2.4.5
`
`PCS:M
`
`RUCKUS Ex 1008-pg. 10
`
`

`

`IEEE
`Std 802.3u-1995
`
`24.8.3.3 PMA functions
`
`SUPPLEMENT TO 802.3:
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`PAl
`
`PA2
`
`PA3
`
`PA4
`
`PAS
`
`TX process
`
`RX process
`
`24.3.4.1
`
`24.3.4.2
`
`M
`
`M
`
`Carrier Detect process
`
`24.3.2.1
`
`REP:M
`
`T ,ink Monitor process
`
`24.3.4.4
`
`M
`
`Far-End Fault Generate pro-
`cess
`
`24.3.4.5
`
`FEF:M
`
`PA6
`
`Far-End Fault Detect process
`
`24.3.4.6
`
`FEF:M
`
`24.8.3.4 Timing
`
`Item
`
`1Ml
`
`1M2
`
`1M3
`
`1M4
`
`1M5
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Support for MII signals
`TX_CLK andRX_CLK
`
`Accuracy of code-bit_ timer
`
`Compliance with PHY bit
`delay constraints
`
`Compliance with DTE bit
`delay constraints
`
`Compliance with Carrier De-
`assert/Assert Constraint
`
`24.2.2.3
`
`MII:M
`
`See clause 22
`
`24.2.3
`
`24.6.1
`
`M
`
`MII:M
`REP: 0
`
`24.6.2
`
`DTE:M
`
`24.6.3
`
`DTE:M
`
`RUCKUS Ex 1008-pg. 11
`
`

`

`CSMAICD
`
`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(cid:173)
`ing, lOOBASE-TX. In order to form a complete 100BASE-TX Physical Layer it shall be integrated with
`the lOOBASE-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 lOOBASE-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(cid:173)
`port for Category 5 unshielded twisted pair (UTP) and shielded twisted pair (STP). For improved legibil(cid:173)
`ity in this clause, ANSI X3.263: 199X (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)
`
`The Scope and General description discussed in TP-PMD 1 and 5 relate to the use of those standards
`with anFDDI PHY, ISO 9314-1: 1989, and MAC, ISO 9314-2: 1989. These sections are not relevant
`to the use of the PMD with lOOBASE-X.
`b) The Normative references, Definitions and Conventions ofTP-PMD 2, 3, and 4 are used only as nec(cid:173)
`essary to interpret the applicable sections ofTP-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 differences between this standard and TP-PMD that do not cause ambi(cid:173)
`guity. The terminology used in 100BASE-X was chosen to be consistent with other IEEE 802 stan(cid:173)
`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.
`
`c)
`
`d)
`
`Table 25-1-lnterpretation of general FDDI terms and concepts
`
`FDDI term or concept
`
`Interpretation for lOOBASE-TX
`
`bypass
`
`<unused>
`
`Connection Management (CMT)
`
`<no comparable entity>
`
`frame
`
`Halt Line State (HLS)
`
`hybrid mode
`
`MAC (orMAC-2)
`
`Master Line State (MLS)
`
`stream
`
`<unused>
`
`<no comparable entity>
`
`MAC
`
`<unused>
`
`maximmn frame size = 9000 symbols
`
`maximmn stream size= 3054 code-groups
`
`PHY (orPHY-2)
`
`PMA; i.e., PMD client
`
`RUCKUS Ex 1008-pg. 12
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Table 25-1-lnterpretation of general FDDI terms and concepts (Continued}
`
`FDDI term or concept
`
`Interpretation for lOOBASE-TX
`
`PHY Service Data Unit (SDU)
`
`stream
`
`PM_ SI GNAL.indication (Signal_ Detect)
`
`PMD _ SI GNAL.indicate (signal_ status)
`
`PM_ UNlTDATAindication (PM _Indication)
`
`PMD _ UNlTDATAindicate (nrzi-bit)
`
`PM_ UNlTDATA request (PM_ Request)
`
`PMD _ UNlTDATA request (nrzi-bit)
`
`preamble
`
`Quiet Line State (QLS)
`
`inter-packet IDLEs
`
`<unused>
`
`SM]M_BYPASS request (Control_Action)
`
`SM _pM_ CONTROL request (Control_ Action)
`
`Assume:
`SM_PM_BYPASS request(Control_Action =Insert)
`
`Assume:
`SM _PM_ CONTROL request (Control_ Action=
`Transmit_ Enable)
`
`SM _PM_ SIGNAL. indication (Signal_ Detect)
`
`<unused>
`
`Station Management (SMf)
`
`<no comparable entity>
`
`symbol
`
`code-group
`
`25.4 Specific requirements and exceptions
`
`The lOOBASE-TX PMD (including MDI) and baseband medium shall comply to the requirements of
`TP-PMD, 7, 8, 9, 10, and 11, and normative annexA with the exceptions listed below. In TP-P"NID, infor(cid:173)
`mative annexes 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
`tllis standard, those of tllis 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.1.1 is optional.
`
`25.4.2 Change to 7.2.3.3, "Loss of synchronization"
`
`The synchronization error triggered by PH_Invalid as defined in TP-PMD 7.2.3.3a is not applicable.
`
`25.4.3 Change to table 8-1, "Contact assignments for unshielded twisted pair"
`
`1 OOBASE-TX for unshielded twisted pair adopts the contact assignments of lOBASE-T. Therefore, the
`contact assignments shown in TP-PMD table 8-1 shall instead be as depicted in table 25-2.
`
`25.4.4 Deletion of 8.3, "Station labelling"
`
`Clause fU ofTP-PMD shall not be applied to lOOBASE-TX.
`
`25.4.5 Change to 9.1.9, "Jitter"
`
`The jitter measurement specified in 9 .1.9 of TP-PJVID may be performed using scrambled IDLEs.
`
`RUCKUS Ex 1008-pg. 13
`
`

`

`CSMAICD
`
`IEEE
`Std 802.3u-1995
`
`Table 25-2-UTP MDI contact assignments
`
`CONTACT
`
`PHYwithout
`internal crossover
`MDI SIGNAL
`
`PHYwith
`internal crossover
`MDI SIGNAL
`
`Transmit+
`
`Transmit-
`
`Receive+
`
`Receive+
`
`Receive-
`
`Transmit+
`
`Receive-
`
`Transmit-
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`25.4.6 Replacement of 11.2, "Crossover function"
`
`Clause 11.2 of TP-PMD is replaced with the following:
`
`A crossover function compliant with 14.5.2 shall be implemented except that a) the signal names are those
`used in TP-PMD, and b) the contact assignments for STP are those shown in table 8-2 ofTP-PMD. Note
`that compliance with 14.5.2 implies a recommendation that crossover (for both UTP and STP) be per(cid:173)
`formed within repeater PHY s.
`
`25.4.7 Change to A.2, "DDJ test pattern for baseline wander measurements"
`
`The length of the test pattern specified in TP-PMD annex A.2 may be shortened to accommodate feasible
`100BASE-X measurements, but shall not be shorter than 3000 code-groups.
`
`NOTE-This pattern is to be applied to the MII. (When applied to the MAC, the nibbles within each byte are to be
`swapped. E.g., as delivered to the MAC, the test pattern would start, "60 c9 16 ... ".)
`
`25.4.8 Change to annex G, "Stream cipher scrambling function"
`
`An example of a stream cipher scrambling implementation is shown in TP-PMD annex G. This may be
`modified to allow synchronization solely on the IDLE sequences between packets.
`
`25.4.9 Change to annex I, "Common mode cable termination"
`
`The contact assignments shown in TP-PMD figures 1-1 and 1-2 shall instead comply with those specified
`in table 25-2.
`
`RUCKUS Ex 1008-pg. 14
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`25.5 Protocol Implementation Conformance Statement (PICS) proforma for clause 25,
`Physical Medium Dependent (PMD) sublayer and baseband medium, type
`1 DO BASE-TX24
`
`25.5.1 Introduction
`
`The supplier of a protocol implementation that is claimed to conform to IEEE Std 802.3u-1995, Physical
`Medium Dependent (PMD) sublayer and baseband medium, type lOOBASE-TX, shall complete the fol(cid:173)
`lowing Protocol Implementation Conformance Statement (PTCS) proforma.
`
`A detailed description of the symbols used in the PICS proforma, along with instructions for completing the
`PICS profomm, can be fom1d in clause 21.
`
`25.5.2 Identification
`
`25.5.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
`1-0nly 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
`(e.g., Type, Series, Model).
`
`25.5.2.2 Protocol summary
`
`Identification of protocol standard
`
`IEEE Std 802. 3u-1995, Physical Medium Dependent
`(PMD) sublayer and baseband medium, type
`lOODASE-TX
`
`Identification of amendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`Have any Exception items been required?
`Yes[]
`No[]
`(See clause 21; the answer Yes means that the implementation does not conform to IEEE Std 802.3u-1995.)
`
`Date of Statement
`
`24Copyrighr release for PJCS proformas Users of this standard may ire ely reproduce the P lCS proforma in this annex so that it can be
`used for its intended purpose and may further publish the completed PICS.
`
`RUCKUS Ex 1008-pg. 15
`
`

`

`CSMAICD
`
`25.5.3 Major capabilities/options
`
`IEEE
`Std 802.3u-1995
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Item
`
`*TXU
`
`Supports unshielded twisted
`parr
`
`25.2
`
`1XS
`
`Supports shielded twisted pair
`
`25.2
`
`0/1
`
`Oil
`
`25.5.4 PICS proforma tables for the Physical Medium Dependent (PMD) sublayer and base(cid:173)
`band medium, type 100BASE-TX
`
`25.5.4.1 General compatibility considerations
`
`Item
`
`GNl
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Integrates lOODASE-X PMA
`andPCS
`
`25.1
`
`M
`
`See clause 24
`
`25.5.4.2 PMD compliance
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`PDI
`
`PD2
`
`PD3
`
`PD4
`
`PD5
`
`PD6
`
`Compliance with 1 OOBASE-X
`PMD Service Interface
`
`25.1
`
`Compliance with ANSI
`X3.237: 199X, 7, 8 (excluding
`8.3), 9. 10,11 and normative
`annex A, with listed exceptions
`
`25.4
`25.4.5
`
`M
`
`M
`
`See 24.2.3
`
`Precedence over ANSI
`X3.237-199X
`
`MDI contact assignments for
`unshielded twisted pair
`
`Compliance with crossover
`function of 14.5.2 with listed
`adaptations
`
`25.4
`
`M
`
`25.4.4
`25.4.10
`
`25.4.7
`
`Minimmnjitter test pattern
`length
`
`25.4.8
`
`TXU:M
`
`M
`
`M
`
`3000 code-groups
`
`RUCKUS Ex 1008-pg. 16
`
`

`

`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`RUCKUS Ex 1008-pg. 17
`
`RUCKUS Ex 1008-pg. 17
`
`

`

`CSMAICD
`
`IEEE
`Std 802.3u-1995
`
`26. Physical Medium Dependent (PMD) sublayer and baseband medium, type
`100BASE-FX
`
`26.1 Overview
`
`This clause specifies the lOOBASE-X PMD (including MDI) and fiber optic medium for multi-mode fiber,
`lOOBASE-FX. In order to form a complete lOOBASE-FX Physical Layer it shall be integrated with the
`lOOBASE-X PCS and PMA of clause 24, which are assumed incorporated by reference. As such, the
`lOOBASE-FX PMD shall comply with the PMD service interface specified in 24.4.1.
`
`26.2 Functional specifications
`
`The lOOBASE-FX PMD (and MDI) is specified by incorporating the FDDI PMD standard, ISO 9314-3:
`1990, by reference, with the modifications noted below. This standard provides support for two optical
`fibers. For improved legibility in this clause, ISO 9314-3: 1990 will henceforth be referred to as
`fiber-PMD.
`
`26.3 General exceptions
`
`The lOOBASE-FX PMD is precisely the PMD specified as fibcr-PMD, with the following general modifi(cid:173)
`cations:
`
`a)
`
`The Scope and General description discussed in fiber-PMD 1 and 5 relate to the use of those stan(cid:173)
`dards with an FDDI PHY, ISO 9314-1: 1989, and MAC, ISO 9314-2: 1989. These clauses are not
`relevant to the use of the PMD with lOOBASE-X.
`b) The Normative references, Definitions and Con:ventions of fiber-PMD 2, 3, and 4 are used only as
`necessary to interpret the applicable sections offiber-PMD referenced in this clause.
`The PMD Service Specifications of fiber-PMD 6 are replaced by those specified in 24.4.1. The
`lOOBASE-FX PMD Service specification is a proper subset of the PMD service specification in
`fiber-PMD.
`There are minor terminology differences between this standard and fiber-PJVID that do not cause
`ambiguity. The terminology used in lOOBASE-X was chosen to be consistent with other IEEE 802
`standards, rather than with FDDI. Terminology is both defined and consistent within each standard.
`Special note should be made of the interpretations shown in table 26-1.
`
`c)
`
`d)
`
`Table 26-1-lnterpretation of general FDDI terms and concepts
`
`FDDI term or concept
`
`Interpretation for lOOBASE-X
`
`bypass
`
`<llllused>
`
`Connection Management (CMT)
`
`<no comparable entity>
`
`frame
`
`Halt Line State (HLS)
`
`hybrid mode
`
`MAC (orMAC-2)
`
`Master Line Stale (MLS)
`
`stream
`
`<llllused>
`
`<no comparable entity>
`
`MAC
`
`<unused>
`
`maximum frame size = 9000 symbols
`
`maximum stream size= 3054 code-groups
`
`RUCKUS Ex 1008-pg. 18
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Table 26-1-lnterpretation of general FDDI terms and concepts (Continued}
`
`FDDI term or concept
`
`Interpretation for lOOBASE-X
`
`PHY (orPHY-2)
`
`PMA; i.e., PMD client
`
`PHY Service Data Unit (SDU)
`
`stream
`
`PM_ SI GNAL.indication (Signal_ Detect)
`
`PMD _SIGNAL. indicate (signal_ status)
`
`PM_ UNITDATAindication (PM_ Indication)
`
`PMD _ UNITDATAindicate (nrzi-bit)
`
`PM_ UNITDATA request (PM_ Request)
`
`PMD _ UNITDATA request (nrzi-bit)
`
`preamble
`
`Quiet Line State (QLS)
`
`inter-packet IDLEs
`
`<unused>
`
`SM_FM_BYPASS request (Control_Action)
`
`SM _FM _CONTROL request (Control_ Action)
`
`Assume:
`SM_FM_BYPASS request (Control_Action =Insert)
`
`Assume:
`SM_PM_ CONTROL request (Control_Action =
`Transmil