Telecommunications and information exchange between information technology systems — Requirements for local and metropolitan area networks — Part 1CM: Time-sensitive networking for fronthaul

This standard defines profiles that select features, options, configurations, defaults, protocols and procedures of bridges, stations, and LANs that are necessary to build networks that are capable of transporting fronthaul streams, which are time-sensitive. NOTE—Stream and flow are used as synonyms in this document.1

Télécommunications et échange entre systèmes informatiques — Exigences pour les réseaux locaux et métropolitains — Partie 1CM: Réseaux à temps critique pour fronthaul

General Information

Status
Published
Publication Date
30-Jul-2019
Current Stage
9093 - International Standard confirmed
Start Date
23-May-2025
Completion Date
30-Oct-2025
Ref Project

Relations

Standard
ISO/IEC/IEEE 8802-1CM:2019 - Telecommunications and information exchange between information technology systems — Requirements for local and metropolitan area networks — Part 1CM: Time-sensitive networking for fronthaul Released:7/31/2019
English language
50 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


INTERNATIONAL ISO/IEC/
STANDARD IEEE
8802-1CM
First edition
2019-07
Telecommunications and information
exchange between information
technology systems — Requirements
for local and metropolitan area
networks —
Part 1CM:
Time-sensitive networking for
fronthaul
Télécommunications et échange entre systèmes informatiques —
Exigences pour les réseaux locaux et métropolitains —
Partie 1CM: Réseaux à temps critique pour fronthaul
Reference number
©
IEEE 2018
© IEEE 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Published in Switzerland
ii © IEEE 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non‐governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of ISO documents should be noted (see www.iso.org/directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards
Coordinating Committees of the IEEE Standards Association (IEEE‐SA) Standards Board. The IEEE
develops its standards through a consensus development process, approved by the American
National Standards Institute, which brings together volunteers representing varied viewpoints and
interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve
without compensation. While the IEEE administers the process and establishes rules to promote
fairness in the consensus development process, the IEEE does not independently evaluate, test, or
verify the accuracy of any of the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be
in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents)
or the IEC list of patent declarations received (see http://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT)
see www.iso.org/iso/foreword.html.
ISO/IEC/IEEE 8802‐1CM was prepared by the LAN/MAN of the IEEE Computer Society (as IEEE Std
802.1CM‐2018) and drafted in accordance with its editorial rules. It was adopted, under the “fast‐track
procedure” defined in the Partner Standards Development Organization cooperation agreement between
ISO and IEEE, by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6,
Telecommunications and information exchange between systems.
A list of all parts in the ISO/IEC/IEEE 8802 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
© IEEE 2018 – All rights reserved
iii
IEEE Std 802.1CM™-2018
IEEE Standard for
Local and metropolitan area networks—
Time-Sensitive Networking for Fronthaul
Sponsor
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 7 May 2018
IEEE-SA Standards Board
Abstract: This standard defines profiles that select features, options, configurations, defaults,
protocols, and procedures of bridges, stations, and LANs that are necessary to build networks that
are capable of transporting fronthaul streams, which are time sensitive.

Keywords: bridged network, fronthaul, IEEE 802 , IEEE 802.1™, IEEE802.1CM™,
synchronization, time-sensitive networking, TSN, Virtual Local Area Network, VLAN, VLAN Bridge
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 8 June 2018. Printed in the United States of America.
IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of
Electrical and Electronics Engineers, Incorporated.
Print: ISBN 978-1-5044-4909-0 STD23131
PDF: ISBN 978-1-5044-4910-6 STDPD23131
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices
and disclaimers, or a reference to this page, appear in all standards and may be found under the heading
“Important Notices and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on
request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a
consensus development process, approved by the American National Standards Institute (“ANSI”), which
brings together volunteers representing varied viewpoints and interests to achieve the final product. IEEE
Standards are documents developed through scientific, academic, and industry-based technical working
groups. Volunteers in IEEE working groups are not necessarily members of the Institute and participate
without compensation from IEEE. While IEEE administers the process and establishes rules to promote
fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the
accuracy of any of the information or the soundness of any judgments contained in its standards.
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure
against interference with or from other devices or networks. Implementers and users of IEEE Standards
documents are responsible for determining and complying with all appropriate safety, security,
environmental, health, and interference protection practices and all applicable laws and regulations.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of
material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort.
IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his
or her own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE
standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON
ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event
that an IEEE standard is translated, only the English version published by IEEE should be considered the
approved IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that his or her views should be considered the personal views of that individual rather than the
formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and
Standards Coordinating Committees are not able to provide an instant response to comments or questions
except in those cases where the matter has previously been addressed. For the same reason, IEEE does not
respond to interpretation requests. Any person who would like to participate in revisions to an IEEE
standard is welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the
provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, IEEE does not waive any rights in copyright to the
documents.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual, non-
commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to
photocopy portions of any individual standard for educational classroom use can also be obtained through
the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. A current IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years
old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of
some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that
they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http://
ieeexplore.ieee.org/ or contact IEEE at the address listed previously. For more information about the IEEE
SA or IEEE’s standards development process, visit the IEEE-SA Website at http://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http://
standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-
SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate
whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or
under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their
.
own responsibility. Further information may be obtained from the IEEE Standards Association
Participants
At the time of approval of this standard, the IEEE 802.1 Working Group had the following membership:
Glenn Parsons, Chair
John Messenger, Vice Chair
János Farkas, Chair, Time-Sensitive Networking Task Group, Editor
Ralf Assmann Marina Gutiérrez Karen Randall
Shenghua Bao Stephen Haddock
Maximilian Riegel
Gordon Bechtel Mark Hantel Jessy V. Rouyer
Jens Bierschenk Marc Holness Soheil Samii
Steinar Bjørnstad Lokesh Kabra Atsushi Sato
Christian Boiger Michael Karl Frank Schewe
Paul Bottorff Stephan Kehrer Michael Seaman
Radhakrishna Canchi Hajime Koto Johannes Specht
David Chen
Yizhou Li Patricia Thaler
Feng Chen Christophe Mangin Paul Unbehagen
Weiying Cheng Scott Mansfield Hao Wang
Paul Congdon James McIntosh Tongtong Wang
Rodney Cummings Robert Moskowitz Xinyuan Wang
Hesham ElBakoury Tero Mustala Karl Weber
Norman Finn Tomoki Ohsawa Brian Weis
Mickaël Fontaine
Donald R. Pannell Jordon Woods
Geoffrey Garner Takahiro Yamaura
Walter Pienciak
Eric W. Gray Michael Potts Xiang Yu
Craig Gunther Wei Qiu Nader Zein
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Thomas Alexander Stephen Haddock Glenn Parsons
Butch Anton Marco Hernandez Bansi Patel
Werner Hoelzl
Stefan Aust Clinton Powell
Gordon Bechtel Noriyuki Ikeuchi Alon Regev
Harry Bims Atsushi Ito Maximilian Riegel
Steinar Bjørnstad Raj Jain Robert Robinson
Christian Boiger SangKwon Jeong Jessy V. Rouyer
Piotr Karocki
Demetrio Bucaneg, Jr. Peter Saunderson
William Byrd Stuart Kerry Michael Seaman
Juan Carreon Yongbum Kim Thomas Starai
Keith Chow Mark Laubach Walter Struppler
Todor Cooklev Han Hyub Lee Bo Sun
Rodney Cummings Hyeong Ho Lee Richard Tse
Lars Ellegaard John Lemon Mark-Rene Uchida
Marc Emmelmann Michael Lynch Dmitri Varsanofiev
Yonggang Fang Elvis Maculuba Kari Vierimaa
János Farkas Richard Maiden George Vlantis
Norman Finn Khurram Waheed
Roger Marks
Avraham Freedman John Messenger Lisa Ward
Matthias Fritsche Michael Montemurro Hung-Yu Wei
Yukihiro Fujimoto Nick S. A. Nikjoo Andreas Wolf
Devon Gayle Satoshi Obara Oren Yuen
Eric W. Gray Nader Zein
Robert O’Hara
Randall Groves Zhen Zhou
When the IEEE-SA Standards Board approved this standard on 7 May 2018, it had the following
membership:
Jean-Philippe Faure, Chair
Gary Hoffman, Vice Chair
John D. Kulick, Past Chair
Konstantinos Karachalios, Secretary
Chuck Adams Thomas Koshy Robby Robson
Masayuki Ariyoshi Joseph L. Koepfinger* Dorothy Stanley
Adrian Stephens
Ted Burse Kevin Lu
Mehmet Ulema
Stephen Dukes Daleep Mohla
Phil Wennblom
Doug Edwards Damir Novosel
Ronald C. Petersen Howard Wolfman
J. Travis Griffith
Annette D. Reilly Yu Yuan
Michael Janezic
*Member Emeritus
Introduction
This introduction is not part of IEEE Std 802.1CM-2018, IEEE Standard for Local and metropolitan area networks—
Time-Sensitive Networking for Fronthaul.
This standard defines profiles that select features, options, configurations, defaults, protocols and procedures
of bridges, stations, and LANs that are necessary to build networks that are capable of transporting fronthaul
streams, which are time-sensitive.
Contents
1. Overview . 10
1.1 Scope. 10
1.2 Purpose. 10
1.3 Introduction. 10
2. Normative references . 12
3. Definitions . 13
4. Acronyms and abbreviations . 14
5. Conformance . 16
5.1 Requirements terminology. 16
5.2 Profile Conformance Statement (PCS) . 16
5.3 Bridge requirements. 16
5.4 Bridge options. 17
5.5 End station requirements . 18
5.6 End station options. 18
6. Fronthaul . 20
6.1 Evolved Universal Terrestrial Radio Access background . 21
6.2 Class 1 requirements. 21
6.3 Class 2 requirements. 23
6.4 Synchronization requirements . 26
7. Bridge and synchronization functions . 31
7.1 Latency components . 31
7.2 Bridge delay calculation . 31
7.3 Frame preemption . 33
7.4 Network synchronization. 33
7.5 Flow control. 37
7.6 Energy Efficient Ethernet . 37
8. Fronthaul profiles . 39
8.1 Profile A. 40
8.2 Profile B. 42
9. Synchronization solutions . 44
9.1 Solution for Category A+ . 44
9.2 Solutions for Category A . 44
9.3 Solutions for Category B . 44
9.4 Solutions for Category C . 44
Annex A (normative) PCS proforma—Time-Sensitive Networking for Fronthaul Profiles. 45
Annex B (informative) Delay calculation examples. 55
Annex C (informative) Bibliography. 59
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
IEEE Standard for
Local and metropolitan area networks—
Time-Sensitive Networking for Fronthaul
1. Overview
1.1 Scope
This standard defines profiles that select features, options, configurations, defaults, protocols and procedures
of bridges, stations, and LANs that are necessary to build networks that are capable of transporting fronthaul
streams, which are time-sensitive.
NOTE—Stream and flow are used as synonyms in this document.
1.2 Purpose
The purpose of this standard is to specify defaults and profiles that enable the transport of time-sensitive
fronthaul streams in Ethernet bridged networks.
1.3 Introduction
Fronthaul provides connectivity between functional blocks of a cellular base station (BS). The fronthaul
flows between these functional blocks have stringent quality of service requirements. The successful support
of fronthaul flows in a bridged network requires the selection of specific features and options that are

specified in a number of different standards, some developed by IEEE Project 802 , and others (in
particular, those that relate to functionality in OSI layer 3 and above; ISO/IEC 7498:1994 [B11]) developed
by other standards organizations.
This standard selects features and options that support OSI layers 1 and 2 in bridges and end stations from
the following specifications:
— Virtual Local Area Network (VLAN) Bridge specification in IEEE Std 802.1Q.
— MAC service specifications in IEEE Std 802.1AC.
Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this
standard.
The numbers in brackets correspond to those of the bibliography in Annex C
Information on references can be found in Clause 2.
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
— MAC/PHY technology specifications in IEEE Std 802.3.
— Interspersing express traffic specification in IEEE Std 802.3br.
— Frame preemption specification in IEEE Std 802.1Q.
— Time synchronization and Precision Time Protocol (PTP) specifications in IEEE Std 1588.
— Telecom profile specification in ITU-T G.8275.1, which is based on IEEE Std 1588.
— Synchronous Ethernet specification in ITU-T G.8261, G.8262, and G.8264.
To specify and explain the selection of features and options, this standard:
a) Describes fronthaul requirements (Clause 6), specifying two classes of requirements (6.2, 6.3) that
depend on the BS functional decomposition, and specifying synchronization requirements (6.4) that
apply to both classes.
b) Describes how the operation of bridges and bridged networks affects the quality of service provided
by the fronthaul bridged network (Clause 7), providing details to assist in the calculation of latency
(7.1, 7.2, 7.3), the selection of network synchronization methods (7.4), and the potential impact of
the use of flow control (7.5) and Energy Efficient Ethernet (EEE, 7.6).
c) Specifies two bridge profiles (Clause 8) that support the construction of bridged networks meeting
fronthaul requirements. Profile A (8.1) is applicable to bridges that do not support frame preemption
(7.3), while Profile B (8.2) involves frame preemption to accommodate larger non-fronthaul flows
and frame sizes while preserving fronthaul traffic guarantees.
d) Discusses the applicability (Clause 9) of the synchronization methods described in 7.4 to the time
synchronization categories defined in 6.4.1.
e) Defines fronthaul profile conformance requirements (Clause 5) for bridges meeting either Profile A
or Profile B requirements, for end stations and for synchronization.
f) Provides a Profile Conformance Statement (PCS, Annex A) to support clear detailed statements of
equipment conformance to fronthaul profile requirements.
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in the text and its relationship to this
document is explained). For dated references, only the edition cited applies. For undated references, the
latest edition of the referenced document (including any amendments or corrigenda) applies.
 4, 5
IEEE Std 802 , IEEE Standard for Local and Metropolitan Area Networks—Overview and Architecture.
IEEE Std 802.1AC, IEEE Standard for Local and Metropolitan Area Networks—Media Access Control
(MAC) Service Definition.
IEEE Std 802.1Q, IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged
Networks.
IEEE Std 802.3, IEEE Standard for Ethernet.
IEEE Std 802.3br, IEEE Standard for Ethernet—Amendment 5: Specification and Management
Parameters for Interspersing Express Traffic.
IEEE Std 1588, IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems.
ITU-T G.8261, Timing and synchronization aspects in packet networks.
ITU-T G.8262, Timing characteristics of a synchronous Ethernet equipment slave clock.
ITU-T G.8264, Distribution of timing information through packet networks.
ITU-T G.8271.1, Network limits for time synchronization in packet networks.
ITU-T G.8272, Timing characteristics of primary reference time clocks.
ITU-T G.8272.1, Timing characteristics of enhanced primary reference time clocks.
ITU-T G.8273.2, Timing characteristics of telecom boundary clocks and telecom time slave clocks.
ITU-T G.8273.3, Timing characteristics of telecom transparent clocks.
ITU-T G.8275.1, Precision time protocol telecom profile for phase/time synchronization with full timing
support from the network.
MEF 10.3, Ethernet Services Attributes Phase 3.
IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
ITU-T publications are available from the International Telecommunications Union (http://www.itu.int/).
MEF technical specifications are available from the MEF Forum (https://www.mef.net/).
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
3. Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards
Dictionary Online should be consulted for terms not defined in this clause.
This standard makes use of the following terms defined in IEEE Std 802:
— bridge
— end station
— Ethernet
—forwarding
—frame
— Local Area Network (LAN)
This standard makes use of the following terms defined in IEEE Std 802.1Q:
— bridged network
— latency
— port
— priority-tagged frame
— traffic class
— untagged frame
— Virtual Local Area Network (VLAN)
— VLAN Bridge
— VLAN-tagged frame
The following terms are specific to this standard:
Category: An identifier of time synchronization requirements.
NOTE—See 6.4.1.
Class: A collective term for fronthaul interfaces that applies a particular functional decomposition of a
cellular base station and a particular treatment of fronthaul information flows.
NOTE—See 6.2 and 6.3.
fronthaul: The connectivity between the functional blocks (e.g., baseband processing and radio frequency
blocks) of a cellular base station.
periodic: Repeating continuously, with a constant time (the period) between each occurrence.
Synchronous Ethernet: A method to distribute frequency synchronization over the Ethernet physical layer
according to IEEE Std 802.3 and ITU-T Recommendations G.8261, G.8262, G.8264.
time window: A time interval (among back-to-back time intervals of the same duration), within which
packets of a specified flow can be sent.
IEEE Standards Dictionary Online is available at: http://dictionary.ieee.org.
The Categories used in this standard are defined by the Requirements for the eCPRI Transport Network [B6].
Synchronous Ethernet has been defined to be fully conformant to IEEE Std 802.3, as documented in the relevant ITU-T
Recommendations G.8261, G.8262, G.8264.
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
4. Acronyms and abbreviations
3GPP 3rd Generation Partnership Project
BC boundary clock
BS base station
C&M Control and Management
CBR Constant Bit Rate
CPRI Common Public Radio Interface
CRC Cyclic Redundancy Check
cTE constant Time Error
C-VLAN Customer VLAN
dTE dynamic Time Error
eRE eCPRI Radio Equipment
eREC eCPRI Radio Equipment Control
EEE Energy Efficient Ethernet
EISS Enhanced Internal Sublayer Service
ESMC Ethernet Synchronization Messaging Channel
E-UTRA Evolved Universal Terrestrial Radio Access
FID Filtering Identifier
FLR Frame Loss Ratio
GM Grandmaster
GNSS Global Navigation Satellite System
GPS Global Positioning System
HPF High Priority Fronthaul
IET Interspersing Express Traffic
IPG Inter Packet Gap
IQ In-phase and Quadrature modulation
ISS Internal Sublayer Service
LAN Local Area Network
LPF Low Priority Fronthaul
LPI Low Power Idle
MAC Medium Access Control
eCPRI is a not an acronym; eCPRI is specified by the eCPRI Interface Specification [B5].
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
max|TE| maximum absolute Time Error
max|TE| maximum absolute relative Time Error
relative
MPF Medium Priority Fronthaul
OFDM Orthogonal Frequency Division Multiplexing
PCS Profile Conformance Statement
PDU Protocol Data Unit
PHY physical layer
PICS Protocol Implementation Conformance Statement
PRTC Primary Reference Time Clock
PTP Precision Time Protocol
PVID Port VID
RE Radio Equipment
REC Radio Equipment Control
RSTP Rapid Spanning Tree Protocol
SC Slave Clock
SFD Start Frame Delimiter
SyncE Synchronous Ethernet
TAI Temps Atomique International—International Atomic Time
T-BC Telecom Boundary Clock
TC transparent clock
TE Time Error
TDM Time Division Multiplexing
T-GM Telecom Grandmaster
TSN Time-Sensitive Networking
T-TC Telecom Transparent Clock
T-TSC Telecom Time Slave Clock
UE User Equipment
UNI User Network Interface
VID VLAN Identifier
VLAN Virtual LAN
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
5. Conformance
A claim of conformance to this standard is a claim that the behavior of an implementation of a bridge
(5.3, 5.4) or of an end station (5.5, 5.6) meets the mandatory requirements of this standard and may support
options identified in this standard.
5.1 Requirements terminology
For consistency with existing IEEE and IEEE 802.1 standards, requirements placed upon conformant
implementations of this standard are expressed using the following terminology:
a) Shall is used for mandatory requirements;
b) May is used to describe implementation or administrative choices (“may” means “is permitted to,”
and hence, “may” and “may not” mean precisely the same thing);
c) Should is used for recommended choices (the behaviors described by “should” and “should not” are
both permissible but not equally desirable choices).
The Profile Conformance Statement (PCS) proformas (see Annex A) reflect the occurrences of the words
“shall,” “may,” and “should” within the standard.
The standard avoids needless repetition and apparent duplication of its formal requirements by using is, is
not, are, and are not for definitions and the logical consequences of conformant behavior. Behavior that is
permitted but is neither always required nor directly controlled by an implementer or administrator, or
whose conformance requirement is detailed elsewhere, is described by can. Behavior that never occurs in a
conformant implementation or system of conformant implementations is described by cannot. The word
allow is used as a replacement for the phrase “support the ability for,” and the word capability means “can
be configured to.”
5.2 Profile Conformance Statement (PCS)
The supplier of an implementation that is claimed to conform to this standard shall provide the information
necessary to identify both the supplier and the implementation, and shall complete a copy of the PCS
proforma provided in Annex A.
5.3 Bridge requirements
This subclause defines the conformance requirements for bridge implementations claiming conformance to
this standard. Each bridge implementation supports one or more profiles defined in this standard. Each
profile includes the common bridge requirements (5.3.1). A bridge implementation that conforms to the
provisions of this standard shall support Profile A requirements (5.3.2).
5.3.1 Common bridge requirements
A minimum set of features specified in IEEE Std 802.1Q are required for a bridge to support this standard.
That is, the bridge shall be a VLAN Bridge supporting the minimum set of features identified in this
subclause. The requirements of this subclause do not imply that a VLAN Bridge implementation that
conforms to the provisions of this standard has to support options specified in IEEE Std 802.1Q-2018 other
than those identified in this subclause.
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
A bridge implementation that conforms to the provisions of this standard shall:
a) Conform to the relevant standard for the MAC technology implemented at each port in support of
the MAC Internal Sublayer Service (ISS), as specified in IEEE Std 802.1AC;
b) Implement full duplex IEEE 802.3 MAC with data rate of 1 Gbps or greater on each port;
c) Support the capability of 2000 octets maximum size MAC Protocol Data Unit (PDU) on each port;
d) Support the capability to disable MAC control PAUSE if it is implemented;
e) Support the capability not to assert Low Power Idle (LPI) on each port that supports Energy
Efficient Ethernet (EEE, specified in IEEE Std 802.3);
f) Meet the VLAN Bridge requirements stated in items a) through f) in 5.4 of IEEE Std 802.1Q-2018;
g) Support an active topology enforcement mechanism;
h) Meet the VLAN Bridge requirements stated in items g) and h) in 5.4 of IEEE Std 802.1Q-2018 if the
supported active topology enforcement mechanism is the Rapid Spanning Tree Protocol (RSTP);
i) Meet the VLAN Bridge requirements stated in items i) through n) in 5.4 of IEEE Std 802.1Q-2018;
j) Support at least the Acceptable Frame Types parameter value of Admit All frames on each port [see
item l) in 5.4 of IEEE Std 802.1Q-2018];
k) Support the use of at least one VLAN Identifier (VID);
l) Meet the VLAN Bridge requirements stated in items p) through r) in 5.4 of IEEE Std 802.1Q-2018;
m) Support the ability to allocate the Port VID (PVID) and all other VIDs to the single Filtering
Identifier (FID) if only a single FID is supported [item q) in 5.4 of IEEE Std 802.1Q-2018], i.e.,
support shared VLAN learning (8.8.8 of IEEE Std 802.1Q-2018);
n) Support a minimum of three traffic classes (3.268 of IEEE Std 802.1Q-2018) on all ports;
o) Support the strict priority algorithm for transmission selection (8.6.8.1 of IEEE Std 802.1Q-2018)
on each port for each traffic class;
p) Support flow metering (8.6.5 of IEEE Std 802.1Q-2018) with the token bucket bandwidth profile
specified in MEF 10.3;
q) Support the capability to disable Priority-based flow control if it is implemented (Clause 36 of
IEEE Std 802.1Q-2018).
5.3.2 Bridge requirements for Profile A
A bridge implementation for which a claim of conformance to Profile A (8.1) is made, shall support items a)
through q) of the common bridge requirements (5.3.1).
5.4 Bridge options
A bridge implementation that conforms to the provisions of this standard may:
a) Support MEF 10.3 token sharing for the token bucket bandwidth profile, which is used for flow
metering [item p) in 5.3.1; 8.6.5 of IEEE Std 802.1Q-2018];
b) Support Profile B (5.4.1, 8.2);
c) Support synchronization in the bridged network (5.4.2, Clause 9).
5.4.1 Bridge requirements for Profile B
A bridge implementation for which a claim of conformance to Profile B (8.2) is made, shall:
Support of synchronization in the bridged network is optional if methods [items c) and d) in 7.4] that put no requirements on the
bridged network are available to be used to support synchronization.
IEEE Std 802.1CM-2018
IEEE Standard for Local and metropolitan area networks—Time-Sensitive Networking for Fronthaul
a) Support items a) through q) of the common bridge requirements (5.3.1);
b) Support Frame Preemption, i.e.,
1) Support item ad) in 5.4.1 of IEEE Std 802.1Q-2018 (see also 7.3);
2) Support Interspersing Express Traffic (IEEE Std 802.3br, see also 7.3) ;
3) Support Frame Preemption and Interspersing Express Traffic on each port whose data rate is
not higher than 10Gbps;
4) Support the configuration of 64-octet fragment size for Interspersing Express Traffic at each
port for which Interspersing Express Traffic is enabled.
5.4.2 Bridge requirements for synchronization
A bridge implementation for which a claim of conformance to support synchronization in the bridged
network (Clause 9) is made, shall:
a) Support untagged frames on all ports;
b) Support the ITU-T G.8275.1 telecom profile
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...