throbber
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 [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-
`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-
`fied in 24.2.2.1.
`
`r_bits
`
`9 8 7
`
`6 5 4 3 2
`
`1 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-
`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 µs or greater than 1000 µs. 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.
`
`182
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 201
`
` Dell Inc.
` Exhibit 1009 (Part 3 of 5)
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`BEGIN
`
`link_status *OK
`
`INITIALIZE
`
`r_bits [9:0] <= 1111111111
`canier _status
`<= OFF
`rxerror_status <= NO_ERROR
`
`PMD_UNITDATA.indicate
`
`• RECEIVE NEXT BIT
`
`SHIFTLEFT (r_bits)
`r_bits [0] <= rx_code-bit
`
`ELSE
`
`(carrier_ status = ON) •
`(r_bits [9:0] = 11111 11111 l
`
`CARRIER OFF
`carrier_status <=OFF
`rxerror_status <= NO_ERROR
`
`UCT
`
`(canier_status = OFF) •
`(r_bits [OJ = 0) *
`(r_bits [9:2] * 11 111111)
`r bits [9:0] = 11111 11000
`I CARRIER DETECT
`I carrier_status <=ON I
`r_bits [9:0] * 11111 11000
`
`~
`
`GET NEXT QUINT
`SHIFTLEFT (r_bits)
`r bits [0] <= rx code-bit
`
`
`dicates 5xPMD_ UNITDATAin
`I
`I
`
`CONFIRM K
`
`I
`I
`I
`BAD CARRIER
`rxerror_status = ERROR I r_bits [9:0] * 11000 10001
`UCT
`
`WAIT FOR NEXT
`
`r_bits [9:0] = 11000 10001
`
`PMD _ UNITDATAindicate
`
`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 signal_status=ON. When
`signal_status=OFF, it repetitively generates each cycle of the Far-End Fault Indication until signal_status is
`reasserted.
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this stanOOfd.
`
`Page 202
`
`

`
`IEEE
`Sid 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`BEGIN
`
`(signal_ status = OFF)+
`(link_control = DISABLE)+
`(rctulliny = TRUE)
`
`link_status <= FAIL
`
`signal_ status = ON
`
`HYSTERESIS
`
`link_control =
`SCAN_ FOR_CARRIER
`
`link_status are designated as
`NOTE- The vat~ables link_control and
`link_control_[TX] and link_status_[TX], respectively, by the Auto-Negotiation
`Arbitration state diagram (figure 28-16).
`
`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 figme 24-16 including compliance with the associated state variables as specified in 24.3.3.
`
`24.3.4.6 Far-End Fault Detect
`
`Far-End Fault Detect passively monitors the rx_code-bit sti-eam fi·om 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 of cycles of84 ONEs and a single ZERO (num_cycles). The Far-End Fault lndi(cid:173)
`cation is denoted by three or more cycles, each of 84 ONEs and a single ZERO. Note that the number of con(cid:173)
`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-17 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 sublayer within lOOBASE-X and
`may not be present in other l OOBASE-T PHY specifications. PMD setvices are described in an absb·act
`manner and do not imply any particular implementation. It should be noted that these services are function(cid:173)
`ally identical to those defined in the FDDI standards, such as ISO 9314-3: 1990 and ANSI X3.263: l99X,
`with two exceptions:
`
`This is an1S\j:"chive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 203
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`BEGIN
`
`INITIALIZE
`num_ones~ 0
`
`~
`~
`I CHECK SIGNAL DETECT I
`I
`I
`
`"'
`
`UCT
`
`SEND FEFONE
`tx_code-bit_out ~ONE
`num_ones ~ num_ones + 1
`
`UCT
`
`FORWARD
`tx_code-bit_out ~ tx_code_bit_ in
`num_ones ~ o
`
`PMD _UNITDATA.request •
`signal_status = OFF •
`num_ones < FEF _ONES
`
`PMD_UNITDATA.request •
`signal_ status = ON
`
`PMD_UNITDATA.request •
`signal_ status = OFF •
`num_ones = FEF _ONES
`UCT
`--~L_--~-------,
`SEND FEF ZERO
`tx_code-bit_out ~ZERO
`num ones~o
`
`Figure 24-16-Far-End Fault Generate state diagram
`
`a)
`
`b)
`
`100BASE-X does not include a Station Management (SMT) ftmction; therefore the PMD-to-SMT
`interface defined in ISO 9314-3: 1990 and ANSI X3.263: 199X.
`100BASE-X does not support multiple instances of a PMD in service to a single PMA; therefore, no
`qualifiers <ue needed to identify the unique PMD being referenced.
`
`There are also editorial differences between the interfaces specified here and in the referenced standards, as
`required by the context of 100BASE-X.
`
`The PMD Se1v ice Interface suppo11s the exchange of nrzi-bits between PMA entities. The PMD tl·anslates
`the nrzi-bits to and from signals suitable for the specified medilllll.
`
`The following primitives are defined:
`
`PMD _ UNITDATA.request
`Pl\ID UNITDATA.indicate
`Pl\ID SIGNAL.indicate
`
`24.4.1.1 PMD_UNITDATA.request
`
`This primitive defines the transfer of data (in the fmm of nrzi-bits) from the PMA to the PMD.
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this stan~d.
`
`Page 204
`
`

`
`IEEE
`Sid 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`BEGIN
`
`signal_slalus - OfT
`
`1
`
`RESET
`
`..
`
`num_ones~o
`num_cycles ~ 1
`faulting ~ FALSE
`
`UCT
`
`I
`I
`
`~
`
`GET BIT
`
`I
`I
`PMD _ UNITDATA.indicate
`
`ELSE
`
`I CHECK FAULT
`I
`
`(rx_code-bil = 1) •
`(num_ones = FEF _ONES)*
`I (num_cycles = 1)
`I
`
`(rx_code-bit = 0) •
`
`(num_ ones = FEF _ONES)
`
`I
`(rx_code-bit = 1) •
`(num_ones < FEF _ONES)
`
`POTENTIAL CYCLE
`I num ones~ num ones+ 11
`-
`-
`
`UCT
`
`COUNT CYCLE
`
`UCT
`
`num_cycles ~ num_cycles + 1
`
`num_cycles <
`FEF_CYCLES
`
`I
`CHECK CYCLES
`1 num_ones ~ 0
`
`num_cycles =
`FEF_CYCLES
`
`I
`LINK FAULT
`I faulting ~TRUE
`
`UCT I
`
`I
`
`I
`I
`
`Figure 24-17-Far-End Fault Detect state diagram
`
`24.4.1 .1.1 Semantics of the service primitive
`
`PMD _ UNITDATArequest (tx_nrzi-bit)
`
`The data conveyed by PMD _ UNITDATA request is a continuous sequence of nrzi-bits. The tx_mzi-bit
`parameter can take one of two values: ONE or ZERO.
`
`24.4.1.1.2 When generated
`
`The PMA continuously sends, at a nominal 125 Mb/s rate, the PMD the appropriate mzi-bits for transmis(cid:173)
`sion on the medium.
`
`This is an1S\fchive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 205
`
`

`
`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_UNITDATA.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 PMD_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 100BASE-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: 199X, together with minor modifications (such
`as connectors and pin-outs) necessary for 100BASE-X.
`
`187
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 206
`
`

`
`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 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 MII)
`
`Every 100BASE-X PHY with an exposed MII shall comply with the bit delay constraints specified in table
`24-2. These figures apply for all 100BASE-X PMDs.
`
`Sublayer
`measurement
`points
`MII (cid:219) MDI
`
`Table 24-2—MDI to MII delay constraints (exposed MII)
`
`Event
`
`Min
`(bits)
`
`Max
`(bits)
`
`Input timing
`reference
`
`Output timing
`reference
`
`1st bit of /J/
`
`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 /T/
`1st ONE
`
`1st bit of /J/
`1st bit of /T/
`1st ONE
`
`TX_CLK rising
`TX_CLK rising
`
`24.6.2 DTE delay constraints (unexposed MII)
`
`Every 100BASE-X DTE with no exposed MII shall comply with the bit delay constraints specified in table
`24-3. These figures apply for all 100BASE-X PMDs.
`
`24.6.3 Carrier de-assertion/assertion constraint
`
`To ensure fair access to the network, each DTE shall, additionally, satisfy the following:
`
`188
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 207
`
`

`
`CSMA/CD
`
`Sublayer
`measurement
`points
`MAC (cid:219) MDI
`
`IEEE
`Std 802.3u-1995
`
`Table 24-3—DTE delay constraints (unexposed MII)
`
`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/
`
`1st bit of jam
`
`(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.
`
`189
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 208
`
`

`
`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 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 100BASE-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
`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
`(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) sublayer, type
`100BASE-X
`
`Identification of amendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`No [ ] Yes [ ]
`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.)
`
`Date of Statement
`
`23Copyright release for PICS proformas Users of this standard may freely reproduce the PICS proforma in this annex so that it can be
`used for its intended purpose and may further publish the completed PICS.
`
`190
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 209
`
`

`
`CSMA/CD
`
`24.8.2.3 Major capabilities/options
`
`IEEE
`Std 802.3u-1995
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`*DTE
`
`Supports DTE without MII
`
`24.4
`
`*REP
`
`Supports Repeater without MII
`
`24.4
`
`*MII
`
`Supports exposed MII 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
`
`*FEF
`
`NWY
`
`Implements Far-End Fault
`
`24.3.2.1
`
`Supports Auto-Negotiation
`(clause 28)
`
`O/1
`
`O/1
`
`O/1
`
`REP: O
`DTE: M
`MII: M
`
`M
`
`O
`
`NWC: X
`
`NWC: O
`
`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
`
`Item
`
`GN1
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Compliance with MII require-
`ments
`
`24.4
`
`MII:M
`
`See clause 22
`
`GN2
`
`Environmental specifications
`
`24.7
`
`M
`
`24.8.3.2 PCS functions
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`PS1
`
`PS2
`
`PS3
`
`PS4
`
`PS5
`
`Transmit Bits process
`
`Transmit process
`
`Receive Bits process
`
`Receive process
`
`Carrier Sense process
`
`24.2.3
`
`24.2.4.2
`
`24.2.4.3
`
`24.2.4.4
`
`24.2.4.5
`
`PCS:M
`
`PCS:M
`
`PCS:M
`
`PCS:M
`
`PCS:M
`
`191
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 210
`
`

`
`IEEE
`Std 802.3u-1995
`
`24.8.3.3 PMA functions
`
`SUPPLEMENT TO 802.3:
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`PA1
`
`PA2
`
`PA3
`
`PA4
`
`PA5
`
`TX process
`
`RX process
`
`Carrier Detect process
`
`Link Monitor process
`
`Far-End Fault Generate pro-
`cess
`
`24.3.4.1
`
`24.3.4.2
`
`24.3.2.1
`
`24.3.4.4
`
`24.3.4.5
`
`M
`
`M
`
`REP: M
`
`M
`
`FEF: M
`
`PA6
`
`Far-End Fault Detect process
`
`24.3.4.6
`
`FEF: M
`
`24.8.3.4 Timing
`
`Item
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`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
`
`24.2.2.3
`
`MII:M
`
`See clause 22
`
`24.2.3
`
`24.6.1
`
`24.6.2
`
`M
`
`MII:M
`REP: O
`
`DTE:M
`
`Compliance with Carrier De-
`assert/Assert Constraint
`
`24.6.3
`
`DTE:M
`
`TM1
`
`TM2
`
`TM3
`
`TM4
`
`TM5
`
`192
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 211
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`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: 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)
`
`b)
`
`c)
`
`d)
`
`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 differences 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—Interpretation of general FDDI terms and concepts
`
`FDDI term or concept
`
`Interpretation for 100BASE-TX
`
`bypass
`
`<unused>
`
`Connection Management (CMT)
`
`<no comparable entity>
`
`frame
`
`Halt Line State (HLS)
`
`hybrid mode
`
`MAC (or MAC-2)
`
`Master Line State (MLS)
`
`stream
`
`<unused>
`
`<no comparable entity>
`
`MAC
`
`<unused>
`
`maximum frame size = 9000 symbols
`
`maximum stream size = 3054 code-groups
`
`PHY (or PHY-2)
`
`PMA; i.e., PMD client
`
`193
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 212
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`
`
`Table 25-1—Interpretation of general FDDI terms and concepts (Continued)
`
`FDDI term or concept
`
`Interpretation for 100BASE-TX
`
`PHY Service Data Unit (SDU)
`
`stream
`
`PM_SIGNAL.indication (Signal_Detect)
`
`PMD_SIGNAL.indicate (signal_status)
`
`PM_UNITDATA.indication (PM_Indication)
`
`PMD_UNITDATA.indicate (nrzi-bit)
`
`PM_UNITDATA request (PM_Request)
`
`PMD_UNITDATA request (nrzi-bit)
`
`preamble
`
`Quiet Line State (QLS)
`
`inter-packet IDLEs
`
`<unused>
`
`SM_PM_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 (SMT)
`
`<no comparable entity>
`
`symbol
`
`code-group
`
`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 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
`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.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”
`
`100BASE-TX for unshielded twisted pair adopts the contact assignments of 10BASE-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 8.3 of TP-PMD shall not be applied to 100BASE-TX.
`
`25.4.5 Change to 9.1.9, “Jitter”
`
`The jitter measurement specified in 9.1.9 of TP-PMD may be performed using scrambled IDLEs.
`
`194
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 213
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`Table 25-2—UTP MDI contact assignments
`
`CONTACT
`
`PHY without
` internal crossover
`MDI SIGNAL
`
`PHY with
` 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 of TP-PMD. Note
`that compliance with 14.5.2 implies a recommendation that crossover (for both UTP and STP) be per-
`formed within repeater PHYs.
`
`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 I-1 and I-2 shall instead comply with those specified
`in table 25-2.
`
`195
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 214
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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
`24
`100BASE-TX
`
`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 100BASE-TX, shall complete the fol-
`lowing 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.
`
`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—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
`(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
`100BASE-TX
`
`Identification of amendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`No [ ] Yes [ ]
`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.)
`
`Date of Statement
`
`24
` Users of this standard may freely reproduce the PICS proforma in this annex so that it can be
`Copyright release for PICS proformas
`used for its intended purpose and may further publish the completed PICS.
`
`196
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 215
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`25.5.3 Major capabilities/options
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Item
`
`*TXU
`
`Supports unshielded twisted
`pair
`
`25.2
`
`TXS
`
`Supports shielded twisted pair
`
`25.2
`
`O/1
`
`O/1
`
`25.5.4 PICS proforma tables for the Physical Medium Dependent (PMD) sublayer and base-
`band medium, type 100BASE-TX
`
`25.5.4.1 General compatibility considerations
`
`Item
`
`GN1
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Integrates 100BASE-X PMA
`and PCS
`
`25.1
`
`M
`
`See clause 24
`
`25.5.4.2 PMD compliance
`
`Item
`
`PD1
`
`PD2
`
`PD3
`
`PD4
`
`PD5
`
`PD6
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/Comment
`
`Compliance with 100BASE-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
`
`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
`25.4.5
`
`25.4
`
`25.4.4
`25.4.10
`
`25.4.7
`
`Minimum jitter test pattern
`length
`
`25.4.8
`
`M
`
`M
`
`M
`
`TXU: M
`
`M
`
`M
`
`See 24.2.3
`
`3000 code-groups
`
`197
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 216
`
`

`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 217
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`26. Physical Medium Dependent (PMD) sublayer and baseband medium, type
`100BASE-FX
`
`26.1 Overview
`
`This clause specifies the 100BASE-X PMD (including MDI) and fiber optic medium for multi-mode fiber,
`100BASE-FX. In order to form a complete 100BASE-FX 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-FX PMD shall comply with the PMD service interface specified in 24.4.1.
`
`26.2 Functional specifications
`
`The 100BASE-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 100BASE-FX PMD is precisely the PMD specified as fiber-PMD, with the following general modifi-
`cations:
`
`a)
`
`b)
`
`c)
`
`d)
`
`The Scope and General description discussed in fiber-PMD 1 and 5 relate to the use of those stan-
`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 100BASE-X.
`The Normative references, Definitions and Conventions of fiber-PMD 2, 3, and 4 are used only as
`necessary to interpret the applicable sections of fiber-PMD referenced in this clause.
`The PMD Service Specifications of fiber-PMD 6 are replaced by those specified in 24.4.1. The
`100BASE-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-PMD that do not cause
`ambiguity. The terminology used in 100BASE-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.
`
`Table 26-1—Interpretation of general FDDI terms and concepts
`
`FDDI term or concept
`
`Interpretation for 100BASE-X
`
`bypass
`
`<unused>
`
`Connection Management (CMT)
`
`<no comparable entity>
`
`frame
`
`Halt Line State (HLS)
`
`hybrid mode
`
`MAC (or MAC-2)
`
`Master Line State (MLS)
`
`stream
`
`<unused>
`
`<no comparable entity>
`
`MAC
`
`<unused>
`
`maximum frame size = 9000 symbols
`
`maximum stream size = 3054 code-groups
`
`199
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 218
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`
`
`Table 26-1—Interpretation of general FDDI terms and concepts (Continued)
`
`FDDI term or concept
`
`Interpretation for 100BASE-X
`
`PHY (or PHY-2)
`
`PMA; i.e., PMD client
`
`PHY Service Data Unit (SDU)
`
`stream
`
`PM_SIGNAL.indication (Signal_Detect)
`
`PMD_SIGNAL.indicate (signal_status)
`
`PM_UNITDATA.indication (PM_Indication)
`
`PMD_UNITDATA.indicate (nrzi-bit)
`
`PM_UNITDATA request (PM_Request)
`
`PMD_UNITDATA request (nrzi-bit)
`
`preamble
`
`Quiet L

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket