ISO/IEC/IEEE 8802-1BA:2023

INTERNATIONAL ISO/
STANDARD IEC/IEEE
8802-1BA
Second edition
2023-03
Information technology —
Telecommunications and information
exchange between systems — Local
and metropolitan area networks —
Specific requirements —
Part 1BA:
Audio video bridging (AVB) systems
Technologies de l'information — Télécommunications et échange
d'informations entre systèmes — Réseaux de zones locales et
métropolitaines — Exigences spécifiques —
Partie 1BA: Systèmes de pontage audio-vidéo (AVB)
Reference number
© IEEE 2021
© IEEE 2023
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
Website: www.ieee.org
Published in Switzerland
ii
© IEEE 2021 – 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/IEC documents should be noted. (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
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 https://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. In the IEC, see www.iec.ch/understanding-standards.
ISO/IEC/IEEE 8802-1BA was prepared by the LAN/MAN of the IEEE Computer Society (as IEEE
Std 802.1BA-2021) 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.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 8802-1BA:2016) which has been
technically revised.
A list of all parts in the ISO/IEC/IEEE 8802 series can be found on the ISO and IEC websites.
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 and www.iec.ch/national-
committees.
© IEEE 2021 – All rights reserved iii

IEEE Std 802.1BA™-2021
(Revision of IEEE Std 802.1BA-2011)
IEEE Standard for
Local and Metropolitan Area Networks—
Audio Video Bridging (AVB) Systems
Developed by the
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 8 December 2021
IEEE SA Standards Board
Abstract: 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 time-sensitive audio and/or video data streams are defined in this standard.
Keywords: audio video bridging, AVB, Bridged Local Area Networks, IEEE 802.1BA, LANs, local area
networks, MAC Bridges, MANs, metropolitan area networks, time-sensitive data streams,
time-sensitive networking, TSN, Virtual Bridged Local Area Networks, virtual LANs
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 17 December 2021. 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.
PDF: ISBN 978-1-5044-8239-4 STD25135
Print: ISBN 978-1-5044-8240-0 STDPD25135
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 Standards documents are made available for use subject to important notices and legal disclaimers.
These notices and disclaimers, or a reference to this page (https://standards.ieee.org/ipr/disclaimers.html),
appear in all standards and may be found under the heading “Important Notices and Disclaimers Concerning
IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE SA) Standards Board. IEEE develops its standard s
through an accredited consensus development process, which brings together volunteers representing varied
viewpoints and interests to achieve the final product. IEEE Standards are documents developed by
volunteers with scientific, academic, and industry-based expertise in technical working groups. Volunteers
are not necessarily members of IEEE or IEEE SA, and participate without compensation from IEEE. While
IEEE administers the process and establishes rules to promote fairness in the consensus developmen t
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 makes no warranties or representations concerning its standards, and expressly disclaims all
warranties, express or implied, concerning this standard, including but not limited to the warranties o f
merchantability, fitness for a particular purpose and non-infringement. In addition, IEEE does not warrant or
represent that the use of the material contained in its standards is free from patent infringement. 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 t o
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: THE
NEED TO PROCURE 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 even t
that an IEEE standard is translated, only the English version published by IEEE is 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, nor 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 the presenter's views should be considered the personal views of that individual rather than
the formal position of IEEE, IEEE SA, the Standards Committee, or the Working Group.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations,
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 wit h
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 evaluating comments or in revisions to an IEEE standard is welcome
to join the relevant IEEE working group. You can indicate interest in a working group using the Interests tab
in the Manage Profile & Interests area of the IEEE SA myProject system. An IEEE Account is needed to
access the application.
Comments on standards should be submitted using the Contact Us form.
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 constitute 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.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and
data ownership in the context of assessing and using the standards in compliance with applicable laws and
regulations.
Available at: https://development.standards.ieee.org/myproject-web/public/view.html#landing.
Available at: https://standards.ieee.org/content/ieee-standards/en/about/contact/index.html.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under US 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 licensing fees, 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;
https://www.copyright.com/. 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. An official 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 10 years. When a document is more than 10 years
old and has not undergone a revision process, it is reasonable to conclude that its contents, although still o f
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 IEEE Xplore or contact IEEE. For more
information about the IEEE SA or IEEE's standards development process, visit the IEEE SA Website.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard number
and year of approval to access the web page of the published standard. Errata links are located under the
Additional Resources Details section. Errata are also available in IEEE Xplore. Users are encouraged to
periodically check for errata.
Patents
IEEE Standards are developed in compliance with the IEEE SA Patent Policy.
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
Available at: https://ieeexplore.ieee.org/browse/standards/collection/ieee.
Available at: https://standards.ieee.org/standard/index.html.
Available at: https://standards.ieee.org/about/sasb/patcom/materials.html.
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE SA Website at https://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 o f
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 o r
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.
IMPORTANT NOTICE
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensur e
against interference with or from other devices or networks. IEEE Standards development activities consider
research and information presented to the standards development group in developing any safety
recommendations. Other information about safety practices, changes in technology or technology
implementation, or impact by peripheral systems also may be pertinent to safety considerations during
implementation of the standard. 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.
Participants
At the time this standard was submitted to the IEEE SA Standards Board for approval, the IEEE 802.1
Working Group had the following membership:
Glenn Parsons, Chair
Jessy Rouyer, Vice Chair
Paul Congdon, Chair, Maintenance Task Group
David McCall, Editor
Astrit Ademaj Woojung Huh Silvana Rodrigues
Ralf Assmann Satoko Itaya Atsushi Sato
Rudy Belliardi Yoshihiro Ito
Frank Schewe
Christian Boiger Michael Karl
Michael Seaman
Paul Bottorff Stephan Kehrer
Maik Seewald
Radhakrishna Canchi Randy Kelsey
Ramesh Sivakolundu
David Chen Gavin Lai
Johannes Specht
Feng Chen James Lawlis
Marius Stanica
Rodney Cummings Joao Lopes
Guenter Steindl
Lily Lv
Josef Dorr
Liyang Sun
Christophe Mangin
Hesham Elbakoury
Karim Traore
Anna Engelmann Scott Mansfield
Max Turner
Thomas Enzinger Kenichi Maruhashi
Balazs Varga
Janos Farkas Olaf Mater
Ganesh Venkatesan
Donald Fedyk Larry McMillan
Tongtong Wang
Norman Finn John Messenger
Xinyuan Wang
Geoffrey Garner Hiroki Nakano
Karl Weber
Amrit Gopal Bob Noseworthy
Ludwig Winkel
Craig Gunther Hiroshi Ohue
Jordon Woods
Marina Gutierrez Donald R. Pannell
Takahiro Yamaura
Stephen Haddock Michael Potts
Yue Yin
Mark Hantel Dieter Proell
Nader Zein
Jerome Henry Wei Qiu
Marc Holness Karen Randall William Zhao
Daniel Hopf Maximilian Riegel Helge Zinner
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Philippe Astier Pranav Jha Dieter Proell
Lokesh Kabra
Christian Boiger R. K. Rannow
Piotr Karocki Alon Regev
Rich Boyer
Ashley Butterworth Stephan Kehrer Maximilian Riegel
William Byrd Randy Kelsey Silvana Rodrigues
Paul Cardinal Stuart Kerry Benjamin Rolfe
Paul Congdon Evgeny Khorov Jessy Rouyer
Charles Cook Yongbum Kim Eugene Stoudenmire
Rodney Cummings Hyeong Ho Lee Walter Struppler
Janos Farkas James Lepp Max Turner
Avraham Freedman Ting Li John Vergis
Geoffrey Garner Jonathon McLendon Lisa Ward
Devon Gayle Rajesh Murthy Stephen Webb
Craig Gunther Satoshi Obara Karl Weber
Marco Hernandez Glenn Parsons Scott Willy
Andreas Wolf
Werner Hoelzl Bansi Patel
Oliver Holland Arumugam Paventhan Yu Yuan
Raj Jain Clinton Powell Oren Yuen
When the IEEE SA Standards Board approved this standard on 8 December 2021, it had the following
membership:
Gary Hoffman, Chair
Jon Walter Rosdahl, Vice Chair
John D. Kulick, Past Chair
Konstantinos Karachalios, Secretary
Edward A. Addy Howard Li Mehmet Ulema
Doug Edwards Daozhuang Lin Lei Wang
Ramy Ahmed Fathy Kevin Lu F. Keith Waters
J. Travis Griffith Daleep C. Mohla Karl Weber
Thomas Koshy Chenhui Niu Sha Wei
Joseph L. Koepfinger* Damir Novosel Howard Wolfman
Annette Reilly Daidi Zhong
David J. Law
Dorothy Stanley
*Member Emeritus
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
Introduction
This introduction is not part of IEEE Std 802.1BA-2021, IEEE Standard for Local and Metropolitan Area
Networks—Audio Video Bridging (AVB) Systems.
This standard contains state-of-the-art material. The area covered by this standard is undergoing evolution.
Revisions are anticipated within the next few years to clarify existing material, to correct possible errors, and
to incorporate new related material. Information on the current revision state of this and other IEEE 80 2
standards may be obtained from
Secretary, IEEE SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854
USA
Contents
1. Overview. 13
1.1 Scope. 13
1.2 Purpose. 13
1.3 Word usage . 13
1.4 Introduction. 14
1.5 Objectives . 14
2. Normative references. 15
3. Definitions . 16
4. Acronyms and abbreviations . 17
5. Architecture of AVB networks . 18
6. AVB functions . 22
6.1 Energy Efficient Ethernet . 22
6.2 Flow control. 22
6.3 Frame sizes . 23
6.4 Detection of AVB domains. 23
6.5 Credit based shaper combined with timed gate operation . 24
6.6 Meeting latency targets for SR classes A and B. 25
6.7 Variable data rate LANs . 28
6.8 Basic support for streams. 28
6.9 Minimum Bridge requirements. 30
6.10 IEEE 802.1AS time-synchronization event message transmission interval . 31
6.11 Effect of hop count on IEEE 802.1AS accuracy . 31
7. AVB profiles. 32
7.1 Introduction to PCS proformas . 32
7.2 Abbreviations and special symbols. 33
7.3 Instructions for completing the PCS proforma . 33
7.4 Common requirements . 35
Annex A (informative) Bibliography . 43
List of figures
Figure 5-1 An AVB network . 18
Figure 5-2 AVB domain boundaries created by non-AVB systems. 19
Figure 5-3 AVB domain boundaries created by different SR class A priorities . 20
Figure 5-4 AVB domain boundaries created by different SR class B priorities. 21
List of tables
Table 6-1 AVB support in LAN technologies . 24
Table 6-2 Latency targets for SR classes A and B. 25
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
IEEE Standard for 
Local and Metropolitan Area Networks—
Audio Video Bridging (AVB) Systems
1. Overview
1.1 Scope
This standard defines profiles that select features, options, configurations, defaults, protocols, and
procedures of bridges, stations, and Local Area Networks (LANs) that are necessary to build networks that
are capable of transporting time-sensitive audio and/or video data streams.
1.2 Purpose
The purpose of this standard is to specify defaults and profiles that manufacturers of LAN equipment can
use to develop AVB-compatible LAN components, and to enable a person not skilled in networking to buil d
a network, using those components, that does not require configuration to provide working audio and/o r
video services.
1.3 Word usage
The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard
6, 7
and from which no deviation is permitted (shall equals is required to).
The word should indicates that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessaril y
required (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals
is permitted to).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can
equals is able to).
The use of the word must is deprecated and cannot be used when stating mandatory requirements; must is used only to describe
unavoidable situations.
The use of will is deprecated and cannot be used when stating mandatory requirements; will is only used in statements of fact.
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
1.4 Introduction
The successful support of time-sensitive audio and/or video data streams in a Bridged LAN requires the
selection of specific features and options that are specified in a number of different standards, some of which ®
are standards developed in IEEE 802 , and others (in particular, those that relate to functionality in OSI
layer 3 and above in ISO/IEC 7498-1:1994 [B7]) that are developed by other bodies. In this standard, it is
the selection of features and options that support OSI layer 1 and 2 LAN functionality that is of interest, in
order to specify the requirements for LAN support in Bridges and the end stations that attach to them.
The standards from which features and options are selected by this standard are as follows:
a) The VLAN Bridge specification in IEEE Std 802.1Q.
b) The time-synchronization standard, IEEE Std 802.1AS.
c) The MAC and PHY standards specified for the various LAN MAC/PHY technologies, such as IEEE
Std 802.3, IEEE Std 802.11, ITU-T G.9960 & ITU-T G.9961 (Powerline), and MoCA.
These features and options are selected by means of the profiles described in Clause 7. These profiles
support specific functions within an AVB network, such as the Bridges and LAN technologies used to carry
the AV streams, and the end stations that attach to the LAN and that provide the source(s) and the
destination(s) of the stream data.
In some cases, there are functions that are needed in order to construct a usable AVB network, but that are
not described in any other standard. In those cases, the technical specification is included in Clause 6 of this
standard, along with a statement of the conformance requirements associated with the function, so that the
function can be referenced by a profile in the same way as functions defined in any other standard.
Clause 5 introduces the architecture for AVB systems and AVB networks, and some of the terminology used
in describing them.
1.5 Objectives
The architecture described in Clause 5, the AVB functions specified in Clause 6, and the profiles specified in
Clause 7, are intended to meet the following objectives:
a) Describe the components that can be combined to form an AVB network (i.e., a network whose
components cooperate and interoperate to allow the transmission of AV streams) and how those
components can be combined.
b) Describe some of the consequences and limitations for AVB streaming that result from the
incorporation of non-AV capable devices in an AVB network.
c) Define additional functions that are required for AVB operation that are not otherwise documented
in contributing standards.
d) Provide guidance in terms of meeting the end-to-end latency requirements for successful AVB
operation.
e) Define conformance requirements for AVB systems, in terms of the standards to which conformance
is required for the various system components and the optional features of those standards that are
required to be implemented. These conformance requirements address the guaranteed delivery,
end-to-end latency, and time-synchronization requirements for successful AVB operation.
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
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.
® 8, 9
IEEE Std 802 , IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture.
TM
IEEE Std 802.1AS , IEEE Standard for Local and Metropolitan Area Networks—Timing and
Synchronization for Time-Sensitive Applications.
TM
IEEE Std 802.1Q , IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged
Networks.
TM
IEEE Std 802.1Qcc , IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged
Networks—Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance
Improvements.
TM
IEEE Std 802.3 , IEEE Standard for Ethernet.
TM
IEEE Std 802.11 , IEEE Standard for Information Technology—Telecommunications and Information
Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
ITU-T Recommendation G.9960 (11/2018), Unified high-speed wireline-based home networking
transceivers—System architecture and physical layer specification.
ITU-T Recommendation G.9961 (11/2018), Unified high-speed wireline-based home networking
transceivers—Data link layer specification.
MoCA MAC/PHY SPECIFICATION v2.0, (MoCA-M/P-SPEC-V2.0-170601) Multimedia over Coax
Alliance (www.mocalliance.org).
MoCA MAC/PHY SPECIFICATION v2.5, (MoCA-M/P-SPEC-V2.5-170601) Multimedia over Coax
Alliance (www.mocalliance.org).
IEEE publications are available from the Institute of Electrical and Electronics Engineers (https://standards.ieee.org/).
The IEEE standards or products referred to in Clause 2 are trademarks of the Institute of Electrical and Electronics Engineers ,
Incorporated.
ITU-T publications are available from the International Telecommunications Union (https://www.itu.int/).
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
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.
AV Bridge: Relay device (e.g., an IEEE 802.1Q Bridge or an IEEE 802.11 access point) that conforms to
the requirements stated in the AVB profile for a Bridge as specified in this standard.
AVB domain: The intersection of a gPTP domain 0, which implements BMCA, and an SRP domain.
NOTE—The term “SRP domain” is defined in IEEE Std 802.1Q. The terms “gPTP domain” and “BMCA” are defined
in IEEE Std 802.1AS. IEEE Std 802.1AS supports multiple gPTP domains. AVB operation requires support for a single
domain 0.
AVB network: A contiguous set of Bridges and end stations that meet the conformance requirements o f
IEEE Std 802.1BA.
AVB profile: A set of feature and option selections that specifies aspects of Bridge and end station
operation, and states the conformance requirements for support of AVB functionality for a specific class of
user applications.
AVB stream: A data stream associated with a stream reservation established using the Stream Reservation
Protocol (SRP).
AVB system: A system (a piece of equipment that implements Bridge and/or end station functionality) that
meets the conformance requirements for an AVB profile.
end station, station: These terms are defined in IEEE Std 802.
grandmaster-capable PTP instance: This term is defined in IEEE Std 802.1AS.
Listener: An end station that is the destination, receiver, or consumer of a stream.
MRP participant: The MRP state machine that participates in MRP protocol, as defined in Clause 10 of
IEEE Std 802.1Q-2018 and Clause 10 of IEEE Std 802.1Qcc-2018. There are five variants as follows:
a) Full Participant
b) Full Participant, point-to-point subset
c) New-Only Participant
d) Applicant-Only Participant
e) Simple-Applicant Participant
Talker: An end station that is the source, transmitter, or producer of a stream.
The IEEE Standards Dictionary Online is available at https://dictionary.ieee.org/. An IEEE Account is required for access to the
dictionary, and one can be created at no charge on the dictionary sign-in page.
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
4. Acronyms and abbreviations
AV audio/video
AVB audio video bridging
BMCA Best Master Clock Algorithm
C-VLAN Customer VLAN (IEEE Std 802.1Q)
CSN coordinated shared network
EISS Extended Internal Sublayer Service (IEEE Std 802.1Q)
IPG interpacket gap
FID Filtering Identifier (IEEE Std 802.1Q)
FQTSS Forwarding and Queuing Enhancements for Time-Sensitive Streams (IEEE Std 802.1Q)
G.hn ITU-T G.9960 and ITU-T G.9961
gPTP generalized precision time protocol
LAN Local Area Network (IEEE Std 802.1Q)
MTIE Maximum Time Interval Error
PCS Profile Conformance Statement
PICS Protocol Implementation Conformance Statement
PVID Port VLAN identifier (IEEE Std 802.1Q)
SFD start-of-frame delimiter
SR stream reservation (IEEE Std 802.1Q)
SR_PVID Stream Reservation Port VLAN Identifier (IEEE Std 802.1Q)
SRP Stream Reservation Protocol (IEEE Std 802.1Q)
MAC Media Access Control
MMRP Multiple MAC Registration Protocol (IEEE Std 802.1Q)
MSRP Multiple Stream Registration Protocol (IEEE Std 802.1Q)
MVRP Multiple VLAN Registration Protocol (IEEE Std 802.1Q)
TSpec traffic specification (IEEE Std 802.1Q)
VID VLAN identifier (IEEE Std 802.1Q)
VLAN Virtual LAN (IEEE Std 802.1Q)
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
5. Architecture of AVB networks
This standard is concerned with the requirements for layer 2 support in bridged networks that support AV
traffic. In that context, an AVB network is considered to consist of the following:
a) End stations that act as Talkers
b) End stations that act as Listeners
c) End stations that act as Talkers and Listeners
d) MAC Bridges that support the bridging requirements of the AVB network
e) Individual LANs that interconnect the Bridges, Talkers, and Listeners
NOTE 1—A non-exhaustive list of LAN technologies can be found in Table 6-1. For the purposes of this standard,
LANs are taken to include IEEE 802 LANs and any other LAN technologies that are able to provide the internal
sublayer service (ISS) defined in Clause 11 of IEEE Std 802.1AC-2016 [B6].
Figure 5-1 gives an example of how these components can be combined in an AVB network.
Listener
end Talker &
Talker
Listener
station
end
end
station
station
AV AV AV
AV
Bridge Bridge Bridge Bridge
Listener
end
Listener Talker
station
end end
station station
AV
Bridge
AV
Listener
Bridge
Talker
end
end
station
station
Talker &
Listener
Listener
end
end
station
station
LAN
Figure 5-1—An AVB network
Practical installations of AVB equipment frequently include non-AVB components (Bridges and end
stations) that are connected to the AVB network, but do not themselves participate in the transmission, relay,
or receipt of AV traffic.
Figure 5-2 illustrates the effect of the establishment of AVB domains (see 6.4) on the ability of AVB systems
to communicate streams. AVB stream communication can be established with MSRP versions 0x00 and
0x01, as implementations of the latter are backward compatible with the former. End stations 1 and 2 are
within AVB domain 1, and can therefore communicate stream traffic between them, via the AV Bridge that
connects them. Similarly, end stations 3, 4, and 5 are all within AVB domain 2, and can therefor e
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
communicate stream traffic among them. However, because end stations 1 and 3 are connected via a region
of the network that is not AVB-capable, they are in distinct AVB domains, and therefore cannot establish
AVB stream communication between them, but all non-AVB communications continue between these end
stations. End station 6 is the only device within AVB domain 3, and therefore cannot establish AVB stream
communication with any other AVB end station. AVB end station 7 and AVB end station 8 are connected
only to each other and form AVB domain 4, which is isolated; stations 7 and 8 can only communicate with
each other.
NOTE 2—A consequence of the registration process and SRP operation is that any given end station is a member of only
one domain.
The non-AV Bridges shown in Figure 5-2 could be conformant IEEE 802.1Q Bridges that do not meet the
minimum requirements of the AVB profile in use in the network, or they could be non-conformant bridges
that forward frames addressed to the reserved addresses in Table 8-1, Table 8-2, and Table 8-3 of IEEE St d
802.1Q-2018. In the former case, the detection of the domain boundary is the result of the operation of
MSRP; in the latter case, the boundary detection is achieved by the determination of “asCapable” o f
domain 0 by the generalized precision time protocol (gPTP) defined in IEEE Std 802.1AS (see 10.2.5.1 of
IEEE Std 802.1AS-2020).
AVB domain 2
non-AVB
AVB
end
end
station
AVB
station 3
end
station 5
non-AV AV
Bridge Bridge
AV
Bridge
AV
non-AVB
end Bridge
station
AVB
end
station 4
AV
Bridge
non-AVB
non-AV
end
AVB
Bridge
AVB
station
end
end
station 6
station 1
AVB
AVB AVB
end AVB domain 3
non- AVB
end end
station 2
end
station 7 station 8
station
AVB domain 1
AVB domain boundary port
AVB domain 4
LAN carrying non-AVB traffic
LAN carrying AVB traffic
Figure 5-2—AVB domain boundaries created by non-AVB systems
IEEE Std 802.1BA-2021
Local and Metropolitan Area Networks—Audio Video Bridging (AVB) Systems
AVB domain boundaries are also created in a network if the priority to SR class associations are not
consistent across the network. For example, if some Bridges use the default values shown in Table 6-5 o f
IEEE Std 802.1Q-2018, where priority 3 is associated with SR Class A traffic and priority 2 is associated
with SR class B traffic, and others associate, say, priority 4 with SR class A traffic and priority 2 with SR
class B traffic, then, because AVB domains are created per SR class, all of the devices are in the same AV B
domain for SR class B traffic, but adjacent devices that use different pri
...