IEEE P802.1C-2020 pdf download

IEEE P802.1C-2020 pdf download.Time -Sensitive Net workingfor Fronthaul一Amendment: Enhancements to Fronthaul Profilesto Support New Fronthaul Interface, Synchronization, and Syntonization Standards.
7. Bridge and synchronization functions
Change subelause 7.3 as sliow,i (replace 802.3br with 802.3 or 802.3-2018 as appropriate, and delete footnotes on 8O2.3br:
7.3 Frame preemption
Frame preemption is the suspension of the transmission of a preemptable frame to allow one or more express frames to be transmitted before the transmission of the preemptable frame is resumed. IEEE Std 802.3bt specifies the MAC Merge sublayer, which supports interspersing express traffic with preemptable traffic. The MAC Merge sublayer supports two ways to hold the transmission of preemptable traffic in the presence of express traffic (until subsequent release): the MAC Merge sublayer can preempt (interrupt) preemptable traffic being currently transmitted, and the MAC Merge sublayer can prevent starting the transmission of preemptable traffic (see 99.1 of IEEE Std 802.3br-20lé). The IEEE 802.IQ bridge forwarding process optionally supports frame preemption. The benefits provided by frame preemption decrease as the data rate of a bridge port increases.
Frame preemption takes some time; the express frame cannot be transmitted immediately. If frame preemption is possible, then the express frame can be transmitted only after the transmission of the current fragment of the preemptable frame including the Cyclic Redundancy Check (CRC) of the frame and the Inter Packet Gap (IPG). Preemption occurs only if at least 60 octets of the preemptable frame have been transmitted and at least 64 octets (including the frame CRC) remain to be transmitted. The earliest starting position of preemption is controlled by the addFragSizc variable, which is a 2-bit integer value indicating, in units of 64 octets, the minimum number of octets over 64 octets required in non-final fragments by the receiver (see 99.4.4 and 79.3.7 of IEEE Std 802.3br-2016). Preemption happens within (1240 + 512 x addFragSize) bit times. That is, the worst case is 1240 bit times when addFragSizc = 0, which is used for the worst-case calculations in this document.
If PTP messages are carried by express frames or by frames that are smaller than 124 octets, then they are not preempted.
7.4 Network synchronization
Change item 3) as shown:
3) Timing distribution to a cluster of eRE/R Es from the nearest corn mon master / houndar clock. An example is shown in Figure 7-2, where the nearest common master / boundary clock is implemented in Node n. which is the starting point from where the relative phase deviation can be calculated. This allows for a relatively short synchronization chain, with target performance in terms of maximum absolute TE, relative to Node ii, depending on the length of the chain and the characteristics of the PTP clocks. As an example, 100 ns can be met in a short chain (e.g.. two hops) with properly performing clocks (e.g., Class B or C of ITU-T G.8273.2).
b) Medium I’rlorlty [ronthaul (Mlii data, which has I ms maximum end-to-end one-way latency, thus includes Class 2 User Plane (slow) data and Class 2 C&M Plane (fast) data (see Table I in the Requirements for the eCPRI Transport Network VI .4-2 [B61, and 6.3.2.1 and 6.3.3, respectively);
(‘hange the third paragraph in iii e introductory text as shown:
As Class 1 IQ data [item a) in 6.2. 1] and Class 2 User Plane data [item a) in 6.3.1] belong to HPF [preceding item a)], they are treated the same way in Profile A (8.1) and Profile B (8.2). Thus, Class 2 User Plane data flows are considered as jfthey were CBR data flows, i.e., a User Plane data flow had the same amount of data in each time window (6.3.2). There are Class 2 User Plane data flows that do not use all the bandwidth allocated in the bridged network due to the time windows with no packet (6.3.1). This unused bandwidth can he used by any other traffic, whether fronthaul or not.
Class 2 User Plane (slow) data and Class 2 C&M Plane (fast) data belong to MPF [preceding item b) because they have similar requirements (see Table 1 in the Requirements for the eCPRI Transport Network V1.-l-2 [B6].
8.1 Profile A
8.1.3 Meeting latency targets.