Internet Engineering Task Force (IETF) E. Grossman, Ed.
Request for Comments: 8578 DOLBY
Category: Informational May 2019
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Grossman, Ed.
Request for Comments: 8578 DOLBY
Category: Informational May 2019
ISSN: 2070-1721
Deterministic Networking Use Cases
确定性网络用例
Abstract
摘要
This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.
本文档介绍了对“确定性流”有共同需求的不同行业的用例。在这种情况下，“确定性”意味着此类流提供有保证的带宽、有界延迟以及与时间敏感数据传输密切相关的其他属性。这些用例在网络拓扑和特定的期望行为方面存在显著差异，为确定性网络（DetNet）提供了广泛的行业背景。对于每个用例，本文档将确定用例，确定当前使用的代表性解决方案，并描述DetNet可以实现的潜在改进。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8578.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8578.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................6
2. Pro Audio and Video .............................................7
2.1. Use Case Description .......................................7
2.1.1. Uninterrupted Stream Playback .......................8
2.1.2. Synchronized Stream Playback ........................9
2.1.3. Sound Reinforcement .................................9
2.1.4. Secure Transmission ................................10
2.1.4.1. Safety ....................................10
2.2. Pro Audio Today ...........................................10
2.3. Pro Audio in the Future ...................................10
2.3.1. Layer 3 Interconnecting Layer 2 Islands ............10
2.3.2. High-Reliability Stream Paths ......................11
2.3.3. Integration of Reserved Streams into IT Networks ...11
2.3.4. Use of Unused Reservations by Best-Effort Traffic ..11
2.3.5. Traffic Segregation ................................11
2.3.5.1. Packet-Forwarding Rules, VLANs,
and Subnets ...............................12
2.3.5.2. Multicast Addressing (IPv4 and IPv6) ......12
2.3.6. Latency Optimization by a Central Controller .......12
2.3.7. Reduced Device Costs due to Reduced Buffer Memory ..13
2.4. Pro Audio Requests to the IETF ............................13
3. Electrical Utilities ...........................................14
3.1. Use Case Description ......................................14
3.1.1. Transmission Use Cases .............................14
3.1.1.1. Protection ................................14
3.1.1.2. Intra-substation Process Bus
Communications ............................21
3.1.1.3. Wide-Area Monitoring and Control Systems ..23
3.1.1.4. WAN Engineering Guidelines
Requirement Classification ................25
1. Introduction ....................................................6
2. Pro Audio and Video .............................................7
2.1. Use Case Description .......................................7
2.1.1. Uninterrupted Stream Playback .......................8
2.1.2. Synchronized Stream Playback ........................9
2.1.3. Sound Reinforcement .................................9
2.1.4. Secure Transmission ................................10
2.1.4.1. Safety ....................................10
2.2. Pro Audio Today ...........................................10
2.3. Pro Audio in the Future ...................................10
2.3.1. Layer 3 Interconnecting Layer 2 Islands ............10
2.3.2. High-Reliability Stream Paths ......................11
2.3.3. Integration of Reserved Streams into IT Networks ...11
2.3.4. Use of Unused Reservations by Best-Effort Traffic ..11
2.3.5. Traffic Segregation ................................11
2.3.5.1. Packet-Forwarding Rules, VLANs,
and Subnets ...............................12
2.3.5.2. Multicast Addressing (IPv4 and IPv6) ......12
2.3.6. Latency Optimization by a Central Controller .......12
2.3.7. Reduced Device Costs due to Reduced Buffer Memory ..13
2.4. Pro Audio Requests to the IETF ............................13
3. Electrical Utilities ...........................................14
3.1. Use Case Description ......................................14
3.1.1. Transmission Use Cases .............................14
3.1.1.1. Protection ................................14
3.1.1.2. Intra-substation Process Bus
Communications ............................21
3.1.1.3. Wide-Area Monitoring and Control Systems ..23
3.1.1.4. WAN Engineering Guidelines
Requirement Classification ................25
3.1.2. Generation Use Case ................................26
3.1.2.1. Control of the Generated Power ............26
3.1.2.2. Control of the Generation Infrastructure ..27
3.1.3. Distribution Use Case ..............................32
3.1.3.1. Fault Location, Isolation, and
Service Restoration (FLISR) ...............32
3.2. Electrical Utilities Today ................................33
3.2.1. Current Security Practices and Their Limitations ...34
3.3. Electrical Utilities in the Future ........................35
3.3.1. Migration to Packet-Switched Networks ..............36
3.3.2. Telecommunications Trends ..........................37
3.3.2.1. General Telecommunications Requirements ...37
3.3.2.2. Specific Network Topologies of
Smart-Grid Applications ...................38
3.3.2.3. Precision Time Protocol ...................38
3.3.3. Security Trends in Utility Networks ................39
3.4. Electrical Utilities Requests to the IETF .................41
4. Building Automation Systems (BASs) .............................41
4.1. Use Case Description ......................................41
4.2. BASs Today ................................................42
4.2.1. BAS Architecture ...................................42
4.2.2. BAS Deployment Model ...............................44
4.2.3. Use Cases for Field Networks .......................45
4.2.3.1. Environmental Monitoring ..................45
4.2.3.2. Fire Detection ............................46
4.2.3.3. Feedback Control ..........................46
4.2.4. BAS Security Considerations ........................46
4.3. BASs in the Future ........................................46
4.4. BAS Requests to the IETF ..................................47
5. Wireless for Industrial Applications ...........................47
5.1. Use Case Description ......................................47
5.1.1. Network Convergence Using 6TiSCH ...................48
5.1.2. Common Protocol Development for 6TiSCH .............48
5.2. Wireless Industrial Today .................................49
5.3. Wireless Industrial in the Future .........................49
5.3.1. Unified Wireless Networks and Management ...........49
5.3.1.1. PCE and 6TiSCH ARQ Retries ................51
5.3.2. Schedule Management by a PCE .......................52
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests .....52
5.3.2.2. 6TiSCH IP Interface .......................54
5.3.3. 6TiSCH Security Considerations .....................54
5.4. Wireless Industrial Requests to the IETF ..................54
3.1.2. Generation Use Case ................................26
3.1.2.1. Control of the Generated Power ............26
3.1.2.2. Control of the Generation Infrastructure ..27
3.1.3. Distribution Use Case ..............................32
3.1.3.1. Fault Location, Isolation, and
Service Restoration (FLISR) ...............32
3.2. Electrical Utilities Today ................................33
3.2.1. Current Security Practices and Their Limitations ...34
3.3. Electrical Utilities in the Future ........................35
3.3.1. Migration to Packet-Switched Networks ..............36
3.3.2. Telecommunications Trends ..........................37
3.3.2.1. General Telecommunications Requirements ...37
3.3.2.2. Specific Network Topologies of
Smart-Grid Applications ...................38
3.3.2.3. Precision Time Protocol ...................38
3.3.3. Security Trends in Utility Networks ................39
3.4. Electrical Utilities Requests to the IETF .................41
4. Building Automation Systems (BASs) .............................41
4.1. Use Case Description ......................................41
4.2. BASs Today ................................................42
4.2.1. BAS Architecture ...................................42
4.2.2. BAS Deployment Model ...............................44
4.2.3. Use Cases for Field Networks .......................45
4.2.3.1. Environmental Monitoring ..................45
4.2.3.2. Fire Detection ............................46
4.2.3.3. Feedback Control ..........................46
4.2.4. BAS Security Considerations ........................46
4.3. BASs in the Future ........................................46
4.4. BAS Requests to the IETF ..................................47
5. Wireless for Industrial Applications ...........................47
5.1. Use Case Description ......................................47
5.1.1. Network Convergence Using 6TiSCH ...................48
5.1.2. Common Protocol Development for 6TiSCH .............48
5.2. Wireless Industrial Today .................................49
5.3. Wireless Industrial in the Future .........................49
5.3.1. Unified Wireless Networks and Management ...........49
5.3.1.1. PCE and 6TiSCH ARQ Retries ................51
5.3.2. Schedule Management by a PCE .......................52
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests .....52
5.3.2.2. 6TiSCH IP Interface .......................54
5.3.3. 6TiSCH Security Considerations .....................54
5.4. Wireless Industrial Requests to the IETF ..................54
6. Cellular Radio .................................................54
6.1. Use Case Description ......................................54
6.1.1. Network Architecture ...............................54
6.1.2. Delay Constraints ..................................55
6.1.3. Time-Synchronization Constraints ...................57
6.1.4. Transport-Loss Constraints .........................59
6.1.5. Cellular Radio Network Security Considerations .....60
6.2. Cellular Radio Networks Today .............................60
6.2.1. Fronthaul ..........................................60
6.2.2. Midhaul and Backhaul ...............................60
6.3. Cellular Radio Networks in the Future .....................61
6.4. Cellular Radio Networks Requests to the IETF ..............64
7. Industrial Machine to Machine (M2M) ............................64
7.1. Use Case Description ......................................64
7.2. Industrial M2M Communications Today .......................66
7.2.1. Transport Parameters ...............................66
7.2.2. Stream Creation and Destruction ....................67
7.3. Industrial M2M in the Future ..............................67
7.4. Industrial M2M Requests to the IETF .......................67
8. Mining Industry ................................................68
8.1. Use Case Description ......................................68
8.2. Mining Industry Today .....................................68
8.3. Mining Industry in the Future .............................69
8.4. Mining Industry Requests to the IETF ......................70
9. Private Blockchain .............................................70
9.1. Use Case Description ......................................70
9.1.1. Blockchain Operation ...............................71
9.1.2. Blockchain Network Architecture ....................71
9.1.3. Blockchain Security Considerations .................72
9.2. Private Blockchain Today ..................................72
9.3. Private Blockchain in the Future ..........................72
9.4. Private Blockchain Requests to the IETF ...................72
10. Network Slicing ...............................................73
10.1. Use Case Description .....................................73
10.2. DetNet Applied to Network Slicing ........................73
10.2.1. Resource Isolation across Slices ..................73
10.2.2. Deterministic Services within Slices ..............74
10.3. A Network Slicing Use Case Example - 5G Bearer Network ...74
10.4. Non-5G Applications of Network Slicing ...................75
10.5. Limitations of DetNet in Network Slicing .................75
10.6. Network Slicing Today and in the Future ..................75
10.7. Network Slicing Requests to the IETF .....................75
11. Use Case Common Themes ........................................76
11.1. Unified, Standards-Based Networks ........................76
11.1.1. Extensions to Ethernet ............................76
11.1.2. Centrally Administered Networks ...................76
11.1.3. Standardized Data-Flow Information Models .........76
6. Cellular Radio .................................................54
6.1. Use Case Description ......................................54
6.1.1. Network Architecture ...............................54
6.1.2. Delay Constraints ..................................55
6.1.3. Time-Synchronization Constraints ...................57
6.1.4. Transport-Loss Constraints .........................59
6.1.5. Cellular Radio Network Security Considerations .....60
6.2. Cellular Radio Networks Today .............................60
6.2.1. Fronthaul ..........................................60
6.2.2. Midhaul and Backhaul ...............................60
6.3. Cellular Radio Networks in the Future .....................61
6.4. Cellular Radio Networks Requests to the IETF ..............64
7. Industrial Machine to Machine (M2M) ............................64
7.1. Use Case Description ......................................64
7.2. Industrial M2M Communications Today .......................66
7.2.1. Transport Parameters ...............................66
7.2.2. Stream Creation and Destruction ....................67
7.3. Industrial M2M in the Future ..............................67
7.4. Industrial M2M Requests to the IETF .......................67
8. Mining Industry ................................................68
8.1. Use Case Description ......................................68
8.2. Mining Industry Today .....................................68
8.3. Mining Industry in the Future .............................69
8.4. Mining Industry Requests to the IETF ......................70
9. Private Blockchain .............................................70
9.1. Use Case Description ......................................70
9.1.1. Blockchain Operation ...............................71
9.1.2. Blockchain Network Architecture ....................71
9.1.3. Blockchain Security Considerations .................72
9.2. Private Blockchain Today ..................................72
9.3. Private Blockchain in the Future ..........................72
9.4. Private Blockchain Requests to the IETF ...................72
10. Network Slicing ...............................................73
10.1. Use Case Description .....................................73
10.2. DetNet Applied to Network Slicing ........................73
10.2.1. Resource Isolation across Slices ..................73
10.2.2. Deterministic Services within Slices ..............74
10.3. A Network Slicing Use Case Example - 5G Bearer Network ...74
10.4. Non-5G Applications of Network Slicing ...................75
10.5. Limitations of DetNet in Network Slicing .................75
10.6. Network Slicing Today and in the Future ..................75
10.7. Network Slicing Requests to the IETF .....................75
11. Use Case Common Themes ........................................76
11.1. Unified, Standards-Based Networks ........................76
11.1.1. Extensions to Ethernet ............................76
11.1.2. Centrally Administered Networks ...................76
11.1.3. Standardized Data-Flow Information Models .........76
11.1.4. Layer 2 and Layer 3 Integration ...................76
11.1.5. IPv4 Considerations ...............................76
11.1.6. Guaranteed End-to-End Delivery ....................77
11.1.7. Replacement for Multiple Proprietary
Deterministic Networks ............................77
11.1.8. Mix of Deterministic and Best-Effort Traffic ......77
11.1.9. Unused Reserved Bandwidth to Be Available
to Best-Effort Traffic ............................77
11.1.10. Lower-Cost, Multi-Vendor Solutions ...............77
11.2. Scalable Size ............................................78
11.2.1. Scalable Number of Flows ..........................78
11.3. Scalable Timing Parameters and Accuracy ..................78
11.3.1. Bounded Latency ...................................78
11.3.2. Low Latency .......................................78
11.3.3. Bounded Jitter (Latency Variation) ................79
11.3.4. Symmetrical Path Delays ...........................79
11.4. High Reliability and Availability ........................79
11.5. Security .................................................79
11.6. Deterministic Flows ......................................79
12. Security Considerations .......................................80
13. IANA Considerations ...........................................80
14. Informative References ........................................80
Appendix A. Use Cases Explicitly Out of Scope for DetNet ..........90
A.1. DetNet Scope Limitations ...................................90
A.2. Internet-Based Applications ................................90
A.2.1. Use Case Description ...................................91
A.2.1.1. Media Content Delivery .............................91
A.2.1.2. Online Gaming ......................................91
A.2.1.3. Virtual Reality ....................................91
A.2.2. Internet-Based Applications Today ......................91
A.2.3. Internet-Based Applications in the Future ..............91
A.2.4. Internet-Based Applications Requests to the IETF .......92
A.3. Pro Audio and Video - Digital Rights Management (DRM) ......92
A.4. Pro Audio and Video - Link Aggregation .....................92
A.5. Pro Audio and Video - Deterministic Time to Establish
Streaming ..................................................93
Acknowledgments ...................................................93
Contributors ......................................................95
Author's Address ..................................................97
11.1.4. Layer 2 and Layer 3 Integration ...................76
11.1.5. IPv4 Considerations ...............................76
11.1.6. Guaranteed End-to-End Delivery ....................77
11.1.7. Replacement for Multiple Proprietary
Deterministic Networks ............................77
11.1.8. Mix of Deterministic and Best-Effort Traffic ......77
11.1.9. Unused Reserved Bandwidth to Be Available
to Best-Effort Traffic ............................77
11.1.10. Lower-Cost, Multi-Vendor Solutions ...............77
11.2. Scalable Size ............................................78
11.2.1. Scalable Number of Flows ..........................78
11.3. Scalable Timing Parameters and Accuracy ..................78
11.3.1. Bounded Latency ...................................78
11.3.2. Low Latency .......................................78
11.3.3. Bounded Jitter (Latency Variation) ................79
11.3.4. Symmetrical Path Delays ...........................79
11.4. High Reliability and Availability ........................79
11.5. Security .................................................79
11.6. Deterministic Flows ......................................79
12. Security Considerations .......................................80
13. IANA Considerations ...........................................80
14. Informative References ........................................80
Appendix A. Use Cases Explicitly Out of Scope for DetNet ..........90
A.1. DetNet Scope Limitations ...................................90
A.2. Internet-Based Applications ................................90
A.2.1. Use Case Description ...................................91
A.2.1.1. Media Content Delivery .............................91
A.2.1.2. Online Gaming ......................................91
A.2.1.3. Virtual Reality ....................................91
A.2.2. Internet-Based Applications Today ......................91
A.2.3. Internet-Based Applications in the Future ..............91
A.2.4. Internet-Based Applications Requests to the IETF .......92
A.3. Pro Audio and Video - Digital Rights Management (DRM) ......92
A.4. Pro Audio and Video - Link Aggregation .....................92
A.5. Pro Audio and Video - Deterministic Time to Establish
Streaming ..................................................93
Acknowledgments ...................................................93
Contributors ......................................................95
Author's Address ..................................................97
This memo documents use cases for diverse industries that require deterministic flows over multi-hop paths. Deterministic Networking (DetNet) flows can be established from either a Layer 2 or Layer 3 (IP) interface, and such flows can coexist on an IP network with best-effort traffic. DetNet also provides for highly reliable flows through provision for redundant paths.
本备忘录记录了需要多跳路径上确定性流的不同行业的用例。确定性网络（DetNet）流可以从第2层或第3层（IP）接口建立，并且这些流可以在IP网络上与尽力而为的流量共存。DetNet还通过提供冗余路径提供高度可靠的流。
The DetNet use cases explicitly do not suggest any specific design for DetNet architecture or protocols; these are topics for other DetNet documents.
DetNet用例明确地不建议DetNet架构或协议的任何特定设计；这些是其他DetNet文档的主题。
The DetNet use cases, as originally submitted, explicitly were not considered by the DetNet Working Group (WG) to be concrete requirements. The DetNet WG and Design Team considered these use cases, identifying which of their elements could be feasibly implemented within the charter of DetNet; as a result, certain originally submitted use cases (or elements thereof) were moved to Appendix A ("Use Cases Explicitly Out of Scope for DetNet") of this document.
DetNet工作组（WG）明确认为最初提交的DetNet用例不是具体需求。DetNet工作组和设计团队考虑了这些用例，确定了在DetNet章程中哪些元素可以切实实施；因此，某些最初提交的用例（或其元素）被移至本文件附录a（“明确超出DetNet范围的用例”）。
This document provides context regarding DetNet design decisions. It also serves a long-lived purpose of helping those learning (or new to) DetNet understand the types of applications that can be supported by DetNet. It also allows those WG contributors who are users to ensure that their concerns are addressed by the WG; for them, this document (1) covers their contributions and (2) provides a long-term reference regarding the problems that they expect will be served by the technology, in terms of the short-term deliverables and also as the technology evolves in the future.
本文件提供了有关DetNet设计决策的上下文。它还有一个长期的目的，就是帮助那些学习DetNet（或新手）的人理解DetNet可以支持的应用程序类型。它还允许作为用户的工作组贡献者确保工作组解决他们的问题；对于他们来说，本文件（1）涵盖了他们的贡献，（2）提供了一份长期参考资料，说明他们预期技术将解决的问题、短期可交付成果以及未来技术的发展。
This document has served as a "yardstick" against which proposed DetNet designs can be measured, answering the question "To what extent does a proposed design satisfy these various use cases?"
本文件作为一个“尺度”，用于衡量拟议的DetNet设计，回答了“拟议的设计在多大程度上满足这些不同的用例？”
The industries covered by the use cases in this document are
本文档中用例涵盖的行业包括
o professional audio and video (Section 2)
o 专业音频和视频（第2节）
o electrical utilities (Section 3)
o 电力设施（第3节）
o building automation systems (BASs) (Section 4)
o 楼宇自动化系统（BASs）（第4节）
o wireless for industrial applications (Section 5)
o 工业无线应用（第5节）
o cellular radio (Section 6)
o 蜂窝无线电（第6节）
o industrial machine to machine (M2M) (Section 7)
o 工业机器对机器（M2M）（第7节）
o mining (Section 8)
o 采矿（第8节）
o private blockchain (Section 9)
o 私有区块链（第9节）
o network slicing (Section 10)
o 网络切片（第10节）
For each use case, the following questions are answered:
对于每个用例，回答以下问题：
o What is the use case?
o 用例是什么？
o How is it addressed today?
o 今天如何处理？
o How should it be addressed in the future?
o 今后应如何解决这一问题？
o What should the IETF deliver to enable this use case?
o IETF应该提供什么来支持这个用例？
The level of detail in each use case is intended to be sufficient to express the relevant elements of the use case but no more than that.
每个用例中的详细程度旨在足以表达用例的相关元素，但仅此而已。
DetNet does not directly address clock distribution or time synchronization; these are considered to be part of the overall design and implementation of a time-sensitive network, using existing (or future) time-specific protocols (such as [IEEE-8021AS] and/or [RFC5905]).
DetNet不直接解决时钟分配或时间同步问题；这些被视为使用现有（或未来）特定于时间的协议（如[IEEE-8021AS]和/或[RFC5905]）的时间敏感网络总体设计和实施的一部分。
Section 11 enumerates the set of common properties implied by these use cases.
第11节列举了这些用例隐含的一组公共属性。
The professional audio and video industry ("ProAV") includes:
专业音频和视频行业（“ProAV”）包括：
o Music and film content creation
o 音乐与电影内容创作
o Broadcast
o 广播
o Cinema
o 电影院
o Live sound
o 现场声音
o Public address, media, and emergency systems at large venues (e.g., airports, stadiums, churches, theme parks)
o 大型场馆（如机场、体育场馆、教堂、主题公园）的公共广播、媒体和应急系统
These industries have already transitioned audio and video signals from analog to digital. However, the digital interconnect systems remain primarily point to point, with a single signal or a small number of signals per link, interconnected with purpose-built hardware.
这些行业已经将音频和视频信号从模拟转换为数字。然而，数字互连系统仍然主要是点对点的，每个链路只有一个信号或少量信号，并与专用硬件互连。
These industries are now transitioning to packet-based infrastructures to reduce cost, increase routing flexibility, and integrate with existing IT infrastructures.
这些行业现在正在向基于数据包的基础设施过渡，以降低成本，提高路由灵活性，并与现有IT基础设施集成。
Today, ProAV applications have no way to establish deterministic flows from a standards-based Layer 3 (IP) interface; this is a fundamental limitation of the use cases described here. Today, deterministic flows can be created within standards-based Layer 2 LANs (e.g., using IEEE 802.1 TSN ("TSN" stands for "Time-Sensitive Networking")); however, these flows are not routable via IP and thus are not effective for distribution over wider areas (for example, broadcast events that span wide geographical areas).
如今，ProAV应用程序无法从基于标准的第3层（IP）接口建立确定性流；这是这里描述的用例的一个基本限制。今天，可以在基于标准的第2层局域网内创建确定性流（例如，使用IEEE 802.1 TSN（“TSN”代表“时间敏感网络”）；但是，这些流无法通过IP路由，因此无法有效地在更广泛的区域（例如，跨越广泛地理区域的广播事件）上分发。
It would be highly desirable if such flows could be routed over the open Internet; however, solutions of more-limited scope (e.g., enterprise networks) would still provide substantial improvements.
如果这些流量能够通过开放的互联网进行路由，这将是非常理想的；然而，范围更为有限的解决方案（如企业网络）仍将提供实质性的改进。
The following sections describe specific ProAV use cases.
以下部分描述了特定的ProAV用例。
Transmitting audio and video streams for live playback is unlike common file transfer in that uninterrupted stream playback in the presence of network errors cannot be achieved by retrying the transmission; by the time the missing or corrupt packet has been identified, it is too late to execute a retry operation. Buffering can be used to provide enough delay to allow time for one or more retries; however, this is not an effective solution in applications where large delays (latencies) are not acceptable (as discussed below).
传输实时播放的音频和视频流与普通文件传输不同，因为在存在网络错误的情况下，无法通过重试传输来实现不间断的流播放；当发现丢失或损坏的数据包时，执行重试操作已经太迟了。缓冲可用于提供足够的延迟，以允许一次或多次重试；但是，在不能接受大延迟（延迟）的应用程序中，这不是一个有效的解决方案（如下所述）。
Streams with guaranteed bandwidth can eliminate congestion on the network as a cause of transmission errors that would lead to playback interruption. The use of redundant paths can further mitigate transmission errors and thereby provide greater stream reliability.
具有保证带宽的流可以消除网络上的拥塞，这是导致播放中断的传输错误的原因。使用冗余路径可以进一步减轻传输错误，从而提供更高的流可靠性。
Additional techniques, such as Forward Error Correction (FEC), can also be used to improve stream reliability.
还可以使用诸如前向纠错（FEC）之类的附加技术来提高流的可靠性。
Latency in this context is the time between when a signal is initially sent over a stream and when it is received. A common example in ProAV is time-synchronizing audio and video when they take separate paths through the playback system. In this case, the latency of both the audio stream and the video stream must be bounded and consistent if the sound is to remain matched to the movement in the video. A common tolerance for audio/video synchronization is one National Television System Committee (NTSC) video frame (about 33 ms); to maintain the audience's perception of correct lip-sync, the latency needs to be consistent within some reasonable tolerance -- for example, 10%.
此上下文中的延迟是信号最初通过流发送到接收之间的时间。ProAV中的一个常见示例是音频和视频在播放系统中采用不同路径时的时间同步。在这种情况下，如果声音要保持与视频中的运动相匹配，则音频流和视频流的延迟必须有界且一致。音频/视频同步的常见公差是一个国家电视系统委员会（NTSC）视频帧（约33 ms）；为了保持观众对正确的口型同步的感知，延迟需要在一定的合理范围内保持一致——例如，10%。
A common architecture for synchronizing multiple streams that have different paths through the network (and thus potentially different latencies) enables measurement of the latency of each path and has the data sinks (for example, speakers) delay (buffer) all packets on all but the slowest path. Each packet of each stream is assigned a presentation time that is based on the longest required delay. This implies that all sinks must maintain a common time reference of sufficient accuracy, which can be achieved by various techniques.
用于同步通过网络具有不同路径（因此可能具有不同延迟）的多个流的公共体系结构允许测量每个路径的延迟，并使数据接收器（例如，扬声器）延迟（缓冲）除最慢路径之外的所有路径上的所有包。根据所需的最长延迟，为每个流的每个数据包分配一个表示时间。这意味着所有接收器必须保持足够精度的公共时间参考，这可以通过各种技术实现。
This type of architecture is commonly implemented using a central controller that determines path delays and arbitrates buffering delays.
这种类型的体系结构通常使用确定路径延迟和仲裁缓冲延迟的中央控制器来实现。
Consider the latency (delay) between the time when a person speaks into a microphone and when their voice emerges from the speaker. If this delay is longer than about 10-15 ms, it is noticeable and can make a sound-reinforcement system unusable (see slide 6 of [SRP_LATENCY]). (If you have ever tried to speak in the presence of a delayed echo of your voice, you might be familiar with this experience.)
考虑一个人说话到麦克风的时间和扬声器发出声音时的延迟（延迟）。如果延迟时间超过约10-15毫秒，则很明显，并可能导致扩声系统无法使用（参见[SRP_延迟]的幻灯片6）。（如果您曾经试图在声音延迟回音的情况下说话，您可能熟悉这种经历。）
Note that the 15 ms latency bound includes all parts of the signal path -- not just the network -- so the network latency must be significantly less than 15 ms.
请注意，15毫秒延迟范围包括信号路径的所有部分，而不仅仅是网络，因此网络延迟必须明显小于15毫秒。
In some cases, local performers must perform in synchrony with a remote broadcast. In such cases, the latencies of the broadcast stream and the local performer must be adjusted to match each other, with a worst case of one video frame (33 ms for NTSC video).
在某些情况下，本地表演者的表演必须与远程广播同步。在这种情况下，必须调整广播流和本地表演者的延迟以彼此匹配，最坏的情况是一个视频帧（对于NTSC视频为33 ms）。
In cases where audio phase is a consideration -- for example, beam-forming using multiple speakers -- latency can be in the 10 us range (one audio sample at 96 kHz).
在需要考虑音频相位的情况下（例如，使用多个扬声器形成波束），延迟可以在10 us范围内（96 kHz时一个音频采样）。
Professional audio systems can include amplifiers that are capable of generating hundreds or thousands of watts of audio power. If used incorrectly, such amplifiers can cause hearing damage to those in the vicinity. Apart from the usual care required by the systems operators to prevent such incidents, the network traffic that controls these devices must be secured (as with any sensitive application traffic).
专业音频系统可以包括能够产生数百或数千瓦音频功率的放大器。如果使用不当，此类放大器可能会对附近的人造成听力损害。除了系统运营商为防止此类事件所需的常规注意之外，还必须保护控制这些设备的网络流量（与任何敏感应用程序流量一样）。
Some proprietary systems have been created that enable deterministic streams at Layer 3; however, they are "engineered networks" that require careful configuration to operate and often require that the system be over-provisioned. Also, it is implied that all devices on the network voluntarily play by the rules of that network. To enable these industries to successfully transition to an interoperable multi-vendor packet-based infrastructure requires effective open standards. Establishing relevant IETF standards is a crucial factor.
已经创建了一些专有系统，在第3层启用确定性流；然而，它们是“工程网络”，需要仔细配置才能运行，并且通常需要过度配置系统。此外，这意味着网络上的所有设备自愿遵守该网络的规则。为了使这些行业能够成功地过渡到可互操作的基于多供应商数据包的基础设施，需要有效的开放标准。建立相关的IETF标准是一个关键因素。
It would be valuable to enable IP to connect multiple Layer 2 LANs.
启用IP连接多个第2层LAN是很有价值的。
As an example, ESPN constructed a state-of-the-art 194,000 sq. ft., $125-million broadcast studio called "Digital Center 2" (DC2). The DC2 network is capable of handling 46 Tbps of throughput with 60,000 simultaneous signals. Inside the facility are 1,100 miles of fiber feeding four audio control rooms (see [ESPN_DC2]).
例如，ESPN建设了一个占地194000平方英尺、耗资1.25亿美元的一流广播工作室，名为“数字中心2”（DC2）。DC2网络能够处理46 TB的吞吐量和60000个同步信号。设施内有1100英里长的光纤，为四个音频控制室供电（见[ESPN_DC2]）。
In designing DC2, they replaced as much point-to-point technology as they could with packet-based technology. They constructed seven individual studios using Layer 2 LANs (using IEEE 802.1 TSN) that were entirely effective at routing audio within the LANs. However, to interconnect these Layer 2 LAN islands together, they ended up using dedicated paths in a custom SDN (Software-Defined Networking) router because there is no standards-based routing solution available.
在设计DC2时，他们用基于数据包的技术尽可能多地取代了点对点技术。他们使用第二层局域网（使用IEEE 802.1 TSN）构建了七个单独的工作室，这些局域网在路由音频方面完全有效。然而，为了将这些第2层LAN岛互连在一起，它们最终在自定义SDN（软件定义网络）路由器中使用专用路径，因为没有基于标准的路由解决方案可用。
On-air and other live media streams are often backed up with redundant links that seamlessly act to deliver the content when the primary link fails for any reason. In point-to-point systems, this redundancy is provided by an additional point-to-point link; the analogous requirement in a packet-based system is to provide an alternate path through the network such that no individual link can bring down the system.
“空中传送”和其他实时媒体流通常使用冗余链接进行备份，当主链接因任何原因出现故障时，这些链接可以无缝地传递内容。在点对点系统中，这种冗余由额外的点对点链路提供；在基于分组的系统中，类似的要求是提供通过网络的备用路径，以便没有单独的链路可以使系统停机。
A commonly cited goal of moving to a packet-based media infrastructure is that costs can be reduced by using off-the-shelf, commodity-network hardware. In addition, economy of scale can be realized by combining media infrastructure with IT infrastructure. In keeping with these goals, stream-reservation technology should be compatible with existing protocols and should not compromise the use of the network for best-effort (non-time-sensitive) traffic.
转向基于分组的媒体基础设施的一个常见目标是，通过使用现成的、商品化的网络硬件，可以降低成本。此外，通过将媒体基础设施与IT基础设施相结合，可以实现规模经济。为了与这些目标保持一致，流保留技术应与现有协议兼容，并且不应影响网络对尽力而为（非时间敏感）流量的使用。
In cases where stream bandwidth is reserved but not currently used (or is underutilized), that bandwidth must be available to best-effort (i.e., non-time-sensitive) traffic. For example, a single stream may be "nailed up" (reserved) for specific media content that needs to be presented at different times of the day, ensuring timely delivery of that content, yet in between those times the full bandwidth of the network can be utilized for best-effort tasks such as file transfers.
在保留流带宽但当前未使用（或未充分利用）的情况下，该带宽必须可用于尽力而为（即，非时间敏感）流量。例如，对于需要在一天中的不同时间呈现的特定媒体内容，单个流可以被“锁定”（保留），以确保该内容的及时交付，然而在这些时间之间，网络的全部带宽可以被用于诸如文件传输之类的尽力而为的任务。
This also addresses a concern of IT network administrators that are considering adding reserved-bandwidth traffic to their networks that "users will reserve large quantities of bandwidth and then never unreserve it even though they are not using it, and soon the network will have no bandwidth left."
这也解决了IT网络管理员的一个问题，他们正在考虑将保留带宽流量添加到他们的网络中，即“用户将保留大量带宽，即使他们不使用，也不会取消保留，很快网络将没有剩余带宽。”
Sink devices may be low-cost devices with limited processing power. In order to not overwhelm the CPUs in these devices, it is important to limit the amount of traffic that these devices must process.
接收器设备可以是处理能力有限的低成本设备。为了不使这些设备中的CPU负担过重，必须限制这些设备必须处理的通信量。
As an example, consider the use of individual seat speakers in a cinema. These speakers are typically required to be cost reduced, since the quantities in a single theater can reach hundreds of seats. Discovery protocols alone in a 1,000-seat theater can generate enough broadcast traffic to overwhelm a low-powered CPU. Thus, an
作为一个例子，考虑在电影院中使用单独的座位扬声器。这些扬声器通常需要降低成本，因为单个剧院的数量可以达到数百个座位。在一个有1000个座位的剧院中，单是发现协议就可以产生足够的广播流量，足以压倒低功耗的CPU。因此
installation like this will benefit greatly from some type of traffic segregation that can define groups of seats to reduce traffic within each group. All seats in the theater must still be able to communicate with a central controller.
这样的安装将从某种类型的交通隔离中受益匪浅，这种隔离可以定义座椅组，以减少每组内的交通量。剧院的所有座位必须仍然能够与中央控制器通信。
There are many techniques that can be used to support this feature, including (but not limited to) the following examples.
有许多技术可用于支持此功能，包括（但不限于）以下示例。
Packet-forwarding rules can be used to eliminate some extraneous streaming traffic from reaching potentially low-powered sink devices; however, there may be other types of broadcast traffic that should be eliminated via other means -- for example, VLANs or IP subnets.
分组转发规则可用于消除到达潜在低功率接收器设备的一些无关的流式传输流量；但是，可能还有其他类型的广播流量应该通过其他方式消除——例如，VLAN或IP子网。
Multicast addressing is commonly used to keep bandwidth utilization of shared links to a minimum.
多播寻址通常用于将共享链路的带宽利用率保持在最低限度。
Because Layer 2 bridges by design forward Media Access Control (MAC) addresses, it is important that a multicast MAC address only be associated with one stream. This will prevent reservations from forwarding packets from one stream down a path that has no interested sinks simply because there is another stream on that same path that shares the same multicast MAC address.
因为第2层通过设计前向媒体访问控制（MAC）地址来桥接，所以多播MAC地址只与一个流相关联是很重要的。这将防止保留将数据包从一个流转发到一个没有感兴趣的接收器的路径，因为在同一路径上有另一个流共享同一个多播MAC地址。
In other words, since each multicast MAC address can represent 32 different IPv4 multicast addresses, there must be a process in place to make sure that any given multicast MAC address is only associated with exactly one IPv4 multicast address. Requiring the use of IPv6 addresses could help in this regard, due to the much larger address range of IPv6; however, due to the continued prevalence of IPv4 installations, solutions that are effective for IPv4 installations would be practical in many more use cases.
换句话说，由于每个多播MAC地址可以代表32个不同的IPv4多播地址，因此必须有一个适当的过程来确保任何给定的多播MAC地址仅与一个IPv4多播地址关联。在这方面，要求使用IPv6地址可能会有所帮助，因为IPv6的地址范围要大得多；然而，由于IPv4安装的持续普及，对IPv4安装有效的解决方案将在更多的用例中实用。
A central network controller might also perform optimizations based on the individual path delays; for example, sinks that are closer to the source can inform the controller that they can accept greater latency, since they will be buffering packets to match presentation times of sinks that are farther away. The controller might then move a stream reservation on a short path to a longer path in order to free up bandwidth for other critical streams on that short path. See slides 3-5 of [SRP_LATENCY].
中央网络控制器还可以基于各个路径延迟执行优化；例如，距离源较近的接收器可以通知控制器，它们可以接受较大的延迟，因为它们将缓冲数据包以匹配较远接收器的呈现时间。然后，控制器可以将短路径上的流保留移动到较长路径，以便为该短路径上的其他关键流释放带宽。参见[SRP_延迟]的幻灯片3-5。
Additional optimization can be achieved in cases where sinks have differing latency requirements; for example, at a live outdoor concert, the speaker sinks have stricter latency requirements than the recording-hardware sinks. See slide 7 of [SRP_LATENCY].
在接收器具有不同延迟要求的情况下，可以实现额外的优化；例如，在现场室外音乐会上，扬声器接收器比录音硬件接收器具有更严格的延迟要求。请参见[SRP_延迟]的幻灯片7。
Device costs can be reduced in a system with guaranteed reservations with a small bounded latency due to the reduced requirements for buffering (i.e., memory) on sink devices. For example, a theme park might broadcast a live event across the globe via a Layer 3 protocol. In such cases, the size of the buffers required is defined by the worst-case latency and jitter values of the worst-case segment of the end-to-end network path. For example, on today's open Internet, the latency is typically unacceptable for audio and video streaming without many seconds of buffering. In such scenarios, a single gateway device at the local network that receives the feed from the remote site would provide the expensive buffering required to mask the latency and jitter issues associated with long-distance delivery. Sink devices in the local location would have no additional buffering requirements, and thus no additional costs, beyond those required for delivery of local content. The sink device would be receiving packets identical to those sent by the source and would be unaware of any latency or jitter issues along the path.
由于接收器设备上的缓冲（即内存）需求减少，因此在具有保证保留的系统中，设备成本可以降低，并且延迟有限。例如，主题公园可以通过第3层协议在全球范围内直播活动。在这种情况下，所需缓冲区的大小由端到端网络路径的最坏情况段的最坏情况延迟和抖动值定义。例如，在今天的开放互联网上，如果没有几秒钟的缓冲，音频和视频流的延迟通常是不可接受的。在这种情况下，从远程站点接收提要的本地网络上的单个网关设备将提供所需的昂贵缓冲，以掩盖与远程交付相关的延迟和抖动问题。本地位置的接收器设备将没有额外的缓冲要求，因此除了本地内容交付所需的缓冲要求之外，没有额外的成本。接收器设备将接收与源设备发送的数据包相同的数据包，并且不知道路径上存在任何延迟或抖动问题。
o Layer 3 routing on top of Audio Video Bridging (AVB) (and/or other high-QoS (Quality of Service) networks)
o 音频视频桥接（AVB）（和/或其他高QoS（服务质量）网络）之上的第3层路由
o Content delivery with bounded, lowest possible latency
o 以尽可能低的有限延迟交付内容
o IntServ and DiffServ integration with AVB (where practical)
o 与AVB的IntServ和DiffServ集成（如果可行）
o Single network for A/V and IT traffic
o A/V和IT流量的单一网络
o Standards-based, interoperable, multi-vendor solutions
o 基于标准、可互操作、多供应商的解决方案
o IT-department-friendly networks
o IT部门友好网络
o Enterprise-wide networks (e.g., the size of San Francisco but not the whole Internet (yet...))
o 企业级网络（例如，旧金山的大小，但不是整个互联网（但…））
Many systems that an electrical utility deploys today rely on high availability and deterministic behavior of the underlying networks. Presented here are use cases for transmission, generation, and distribution, including key timing and reliability metrics. In addition, security issues and industry trends that affect the architecture of next-generation utility networks are discussed.
如今，电力公司部署的许多系统依赖于底层网络的高可用性和确定性行为。这里介绍的是传输、发电和配电的用例，包括关键时间和可靠性指标。此外，还讨论了影响下一代公用事业网络体系结构的安全问题和行业趋势。
"Protection" means not only the protection of human operators but also the protection of the electrical equipment and the preservation of the stability and frequency of the grid. If a fault occurs in the transmission or distribution of electricity, then severe damage can occur to human operators, electrical equipment, and the grid itself, leading to blackouts.
“保护”不仅指对人类操作员的保护，还包括对电气设备的保护以及对电网稳定性和频率的保护。如果在输电或配电过程中发生故障，则可能对操作员、电气设备和电网本身造成严重损坏，从而导致停电。
Communication links, in conjunction with protection relays, are used to selectively isolate faults on high-voltage lines, transformers, reactors, and other important electrical equipment. The role of the teleprotection system is to selectively disconnect a faulty part by transferring command signals within the shortest possible time.
通信链路与保护继电器一起用于选择性隔离高压线路、变压器、电抗器和其他重要电气设备上的故障。远程保护系统的作用是通过在尽可能短的时间内传输命令信号，有选择地断开故障部件。
The key criteria for measuring teleprotection performance are command transmission time, dependability, and security. These criteria are defined by International Electrotechnical Commission (IEC) Standard 60834 [IEC-60834] as follows:
衡量远程保护性能的关键标准是命令传输时间、可靠性和安全性。这些标准由国际电工委员会（IEC）标准60834[IEC-60834]定义如下：
o Transmission time (speed): The time between the moment when a state change occurs at the transmitter input and the moment of the corresponding change at the receiver output, including propagation delay. The overall operating time for a teleprotection system is the sum of (1) the time required to initiate the command at the transmitting end, (2) the propagation delay over the network (including equipment), and (3) the time required to make the necessary selections and decisions at the receiving end, including any additional delay due to a noisy environment.
o 传输时间（速度）：发射机输入发生状态变化的时刻与接收机输出发生相应变化的时刻之间的时间，包括传播延迟。远程保护系统的总运行时间是（1）在发送端启动命令所需的时间，（2）通过网络（包括设备）的传播延迟，以及（3）在接收端进行必要选择和决策所需的时间之和，包括因噪音环境造成的任何额外延迟。
o Dependability: The ability to issue and receive valid commands in the presence of interference and/or noise, by minimizing the Probability of Missing Commands (PMC). Dependability targets are typically set for a specific Bit Error Rate (BER) level.
o 可靠性：通过最小化丢失命令的概率（PMC），在存在干扰和/或噪声的情况下发出和接收有效命令的能力。可靠性目标通常针对特定的误码率（BER）级别设置。
o Security: The ability to prevent false tripping due to a noisy environment, by minimizing the Probability of Unwanted Commands (PUC). Security targets are also set for a specific BER level.
o 安全性：通过最小化不需要的命令（PUC）的概率，防止由于嘈杂环境而导致错误跳闸的能力。还为特定的BER级别设置了安全目标。
Additional elements of the teleprotection system that impact its performance include:
影响远程保护系统性能的其他元件包括：
o Network bandwidth
o 网络带宽
o Failure recovery capacity (aka resiliency)
o 故障恢复能力（又称恢复能力）
Most power-line equipment can tolerate short circuits or faults for up to approximately five power cycles before sustaining irreversible damage or affecting other segments in the network. This translates to a total fault clearance time of 100 ms. As a safety precaution, however, the actual operation time of protection systems is limited to 70-80% of this period, including fault recognition time, command transmission time, and line breaker switching time.
大多数电力线设备在遭受不可逆转的损坏或影响网络中的其他部分之前，最多可承受五次电源循环的短路或故障。这意味着总故障清除时间为100 ms。但是，作为安全预防措施，保护系统的实际运行时间限制在该时间段的70-80%，包括故障识别时间、命令传输时间和线路断路器切换时间。
Some system components, such as large electromechanical switches, require a particularly long time to operate and take up the majority of the total clearance time, leaving only a 10 ms window for the telecommunications part of the protection scheme, independent of the distance of travel. Given the sensitivity of the issue, new networks impose requirements that are even more stringent: IEC Standard 61850-5:2013 [IEC-61850-5:2013] limits the transfer time for protection messages to 1/4-1/2 cycle or 4-8 ms (for 60 Hz lines) for messages considered the most critical.
一些系统部件，如大型机电开关，需要特别长的运行时间，并占用总清除时间的大部分，保护方案的电信部分只留下10毫秒的窗口，与行程距离无关。鉴于这一问题的敏感性，新网络提出了更为严格的要求：IEC标准61850-5:2013[IEC-61850-5:2013]将保护信息的传输时间限制为1/4-1/2周期或4-8 ms（对于60 Hz线路），对于被认为最关键的信息。
Teleprotection channels that are differential must be synchronous; this means that any delays on the transmit and receive paths must match each other. Ideally, teleprotection systems support zero asymmetric delay; typical legacy relays can tolerate delay discrepancies of up to 750 us.
差动的远程保护通道必须是同步的；这意味着传输和接收路径上的任何延迟必须相互匹配。理想情况下，远程保护系统支持零不对称延迟；典型的传统继电器可以承受高达750 us的延迟差异。
Some tools available for lowering delay variation below this threshold are as follows:
可用于将延迟变化降低到该阈值以下的一些工具如下：
o For legacy systems using Time-Division Multiplexing (TDM), jitter buffers at the multiplexers on each end of the line can be used to offset delay variation by queuing sent and received packets. The length of the queues must balance the need to regulate the rate of transmission with the need to limit overall delay, as larger buffers result in increased latency.
o 对于使用时分复用（TDM）的传统系统，线路每一端的复用器处的抖动缓冲器可用于通过排队发送和接收的数据包来抵消延迟变化。队列的长度必须平衡调节传输速率的需要和限制总延迟的需要，因为较大的缓冲区会导致延迟增加。
o For jitter-prone IP networks, traffic management tools can ensure that the teleprotection signals receive the highest transmission priority to minimize jitter.
o 对于易抖动的IP网络，流量管理工具可以确保远程保护信号接收最高的传输优先级，以最小化抖动。
o Standard packet-based synchronization technologies, such as the IEEE 1588-2008 Precision Time Protocol (PTP) [IEEE-1588] and synchronous Ethernet (syncE) [syncE], can help keep networks stable by maintaining a highly accurate clock source on the various network devices.
o 基于数据包的标准同步技术，如IEEE 1588-2008精确时间协议（PTP）[IEEE-1588]和同步以太网（syncE）[syncE]，可以通过在各种网络设备上保持高度精确的时钟源来帮助保持网络稳定。
Table 1 captures the main network metrics. (These metrics are based on IEC Standard 61850-5:2013 [IEC-61850-5:2013].)
表1显示了主要的网络指标。（这些指标基于IEC标准61850-5:2013[IEC-61850-5:2013]。）
+---------------------------------+---------------------------------+
| Teleprotection Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 4-10 ms |
| | |
| Asymmetric delay required | Yes |
| | |
| Maximum jitter | Less than 250 us (750 us for |
| | legacy IEDs) |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% to 1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| Teleprotection Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 4-10 ms |
| | |
| Asymmetric delay required | Yes |
| | |
| Maximum jitter | Less than 250 us (750 us for |
| | legacy IEDs) |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% to 1% |
+---------------------------------+---------------------------------+
Table 1: Teleprotection Network Requirements
表1：远程保护网络要求
"Inter-tripping" is the signal-controlled tripping of a circuit breaker to complete the isolation of a circuit or piece of apparatus in concert with the tripping of other circuit breakers.
“联动跳闸”是指断路器的信号控制跳闸，以完成与其他断路器跳闸一致的电路或装置的隔离。
+---------------------------------+---------------------------------+
| Inter-trip Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| Inter-trip Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 2: Inter-trip Protection Network Requirements
表2：跳闸间保护网络要求
Current differential protection is commonly used for line protection and is typically used to protect parallel circuits. At both ends of the lines, the current is measured by the differential relays; both relays will trip the circuit breaker if the current going into the line does not equal the current going out of the line. This type of protection scheme assumes that some form of communication is present between the relays at both ends of the line, to allow both relays to compare measured current values. Line differential protection schemes assume that the telecommunications delay between both relays is very low -- often as low as 5 ms. Moreover, as those systems are
电流差动保护通常用于线路保护，通常用于保护并联电路。在线路两端，电流由差动继电器测量；如果流入线路的电流不等于流出线路的电流，两个继电器将使断路器跳闸。这种类型的保护方案假设线路两端的继电器之间存在某种形式的通信，以允许两个继电器比较测量的电流值。线路差动保护方案假设两个继电器之间的通信延迟非常低——通常低至5ms。此外，这些系统也是如此
often not time-synchronized, they also assume that the delay over symmetric telecommunications paths is constant; this allows the comparison of current measurement values taken at exactly the same time.
通常不是时间同步的，他们还假设对称通信路径上的延迟是恒定的；这允许在完全相同的时间比较当前测量值。
+---------------------------------+---------------------------------+
| Current Differential Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | Yes |
| | |
| Maximum jitter | Less than 250 us (750 us for |
| | legacy IEDs) |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| Current Differential Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | Yes |
| | |
| Maximum jitter | Less than 250 us (750 us for |
| | legacy IEDs) |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 3: Current Differential Protection Metrics
表3：电流差动保护指标
The distance (impedance relay) protection scheme is based on voltage and current measurements. The network metrics are similar (but not identical) to the metrics for current differential protection.
距离（阻抗继电器）保护方案基于电压和电流测量。网络指标与电流差动保护的指标类似（但不完全相同）。
+---------------------------------+---------------------------------+
| Distance Protection Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| Distance Protection Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 4: Distance Protection Requirements
表4：距离保护要求
This use case describes the exchange of sampled values and/or GOOSE (Generic Object Oriented Substation Events) messages between Intelligent Electronic Devices (IEDs) in two substations for protection and tripping coordination. The two IEDs are in master-slave mode.
本用例描述了两个变电站中的智能电子设备（IED）之间的采样值和/或GOOSE（通用面向对象变电站事件）消息交换，以进行保护和跳闸协调。这两个IED处于主从模式。
The Current Transformer or Voltage Transformer (CT/VT) in one substation sends the sampled analog voltage or current value to the Merging Unit (MU) over hard wire. The MU sends the time-synchronized sampled values (as specified by IEC 61850-9-2:2011 [IEC-61850-9-2:2011]) to the slave IED. The slave IED forwards the
一个变电站中的电流互感器或电压互感器（CT/VT）通过硬线将采样的模拟电压或电流值发送到合并单元（MU）。MU将时间同步采样值（按照IEC 61850-9-2:2011[IEC-61850-9-2:2011]的规定）发送至从属IED。那奴隶把箱子向前推
information to the master IED in the other substation. The master IED makes the determination (for example, based on sampled value differentials) to send a trip command to the originating IED. Once the slave IED/relay receives the GOOSE message containing the command to trip the breaker, it opens the breaker. It then sends a confirmation message back to the master. All data exchanges between IEDs are through sampled values and/or GOOSE messages.
向另一变电站的主IED发送信息。主IED确定（例如，基于采样值差）向原始IED发送跳闸命令。一旦从IED/继电器接收到GOOSE消息，其中包含使断路器跳闸的命令，它将断开断路器。然后它向主机发送一条确认消息。IED之间的所有数据交换都是通过采样值和/或GOOSE消息进行的。
+---------------------------------+---------------------------------+
| Inter-substation Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| Inter-substation Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
+---------------------------------+---------------------------------+
Table 5: Inter-substation Protection Requirements
表5：变电站间保护要求
This use case describes the data flow from the CT/VT to the IEDs in the substation via the MU. The CT/VT in the substation sends the analog voltage or current values to the MU over hard wire. The MU converts the analog values into digital format (typically time-synchronized sampled values as specified by IEC 61850-9-2:2011 [IEC-61850-9-2:2011]) and sends them to the IEDs in the substation. The Global Positioning System (GPS) Master Clock can send 1PPS or IRIG-B format to the MU through a serial port or IEEE 1588 protocol
本用例描述了通过MU从CT/VT到变电站IED的数据流。变电站中的CT/VT通过硬线向MU发送模拟电压或电流值。MU将模拟值转换为数字格式（通常为IEC 61850-9-2:2011[IEC-61850-9-2:2011]规定的时间同步采样值），并将其发送至变电站中的IED。全球定位系统（GPS）主时钟可通过串行端口或IEEE 1588协议向MU发送1PPS或IRIG-B格式
via a network. 1PPS (One Pulse Per Second) is an electrical signal that has a width of less than 1 second and a sharply rising or abruptly falling edge that accurately repeats once per second. 1PPS signals are output by radio beacons, frequency standards, other types of precision oscillators, and some GPS receivers. IRIG (Inter-Range Instrumentation Group) time codes are standard formats for transferring timing information. Atomic frequency standards and GPS receivers designed for precision timing are often equipped with an IRIG output. Process bus communication using IEC 61850-9-2:2011 [IEC-61850-9-2:2011] simplifies connectivity within the substation, removes the requirement for multiple serial connections, and removes the slow serial-bus architectures that are typically used. This also ensures increased flexibility and increased speed with the use of multicast messaging between multiple devices.
通过网络。1PPS（每秒一个脉冲）是一种宽度小于1秒的电信号，具有每秒准确重复一次的急剧上升或突然下降边缘。1PPS信号由无线电信标、频率标准、其他类型的精密振荡器和一些GPS接收机输出。IRIG（量程间仪表组）时间代码是传输定时信息的标准格式。为精确计时而设计的原子频率标准和GPS接收机通常配备IRIG输出。使用IEC 61850-9-2:2011[IEC-61850-9-2:2011]的过程总线通信简化了变电站内的连接，消除了对多个串行连接的要求，并消除了通常使用的慢速串行总线体系结构。通过在多个设备之间使用多播消息传递，这也确保了灵活性和速度的提高。
+---------------------------------+---------------------------------+
| Intra-substation Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes or No |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| Intra-substation Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes or No |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 6: Intra-substation Protection Requirements
表6：变电站内保护要求
The application of synchrophasor measurement data from Phasor Measurement Units (PMUs) to wide-area monitoring and control systems promises to provide important new capabilities for improving system stability. Access to PMU data enables more-timely situational awareness over larger portions of the grid than what has been possible historically with normal SCADA (Supervisory Control and Data Acquisition) data. Handling the volume and the real-time nature of synchrophasor data presents unique challenges for existing application architectures. The Wide-Area Management System (WAMS) makes it possible for the condition of the bulk power system to be observed and understood in real time so that protective, preventative, or corrective action can be taken. Because of the very high sampling rate of measurements and the strict requirement for time synchronization of the samples, the WAMS has stringent telecommunications requirements in an IP network, as captured in Table 7:
将来自相量测量单元（PMU）的同步相量测量数据应用于广域监控系统，有望为提高系统稳定性提供重要的新功能。与以往使用常规SCADA（监控和数据采集）数据相比，对PMU数据的访问能够在电网的较大部分实现更及时的态势感知。处理同步相量数据的容量和实时性对现有应用架构提出了独特的挑战。广域管理系统（WAMS）可以实时观察和了解大容量电力系统的状况，以便采取保护、预防或纠正措施。由于测量的采样率非常高，且对样本的时间同步有严格要求，WAMS在IP网络中有严格的电信要求，如表7所示：
+---------------------------------+---------------------------------+
| WAMS Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 50 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint, multipoint to |
| | multipoint |
| | |
| Bandwidth | 100 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
| | |
| Consecutive packet loss | At least one packet per |
| | application cycle must be |
| | received. |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| WAMS Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 50 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint, multipoint to |
| | multipoint |
| | |
| Bandwidth | 100 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
| | |
| Consecutive packet loss | At least one packet per |
| | application cycle must be |
| | received. |
+---------------------------------+---------------------------------+
Table 7: WAMS Special Communication Requirements
表7:WAMS特殊通信要求
The IEC has published a technical report (TR) that offers guidelines on how to define and deploy Wide-Area Networks (WANs) for the interconnection of electric substations, generation plants, and SCADA operation centers. IEC TR 61850-90-12:2015 [IEC-61850-90-12:2015] provides four classes of WAN communication requirements, as summarized in Table 8:
IEC已经发布了一份技术报告（TR），该报告提供了如何定义和部署广域网（WAN）的指南，用于变电站、发电厂和SCADA操作中心的互连。IEC TR 61850-90-12:2015[IEC-61850-90-12:2015]提供了四类广域网通信要求，如表8所示：
+----------------+-----------+----------+----------+----------------+
| WAN | Class WA | Class WB | Class WC | Class WD |
| Requirement | | | | |
+----------------+-----------+----------+----------+----------------+
| Application | EHV | HV (High | MV | General- |
| field | (Extra- | Voltage) | (Medium | purpose |
| | High | | Voltage) | |
| | Voltage) | | | |
| | | | | |
| Latency | 5 ms | 10 ms | 100 ms | >100 ms |
| | | | | |
| Jitter | 10 us | 100 us | 1 ms | 10 ms |
| | | | | |
| Latency | 100 us | 1 ms | 10 ms | 100 ms |
| asymmetry | | | | |
| | | | | |
| Time accuracy | 1 us | 10 us | 100 us | 10 to 100 ms |
| | | | | |
| BER | 10^-7 to | 10^-5 to | 10^-3 | |
| | 10^-6 | 10^-4 | | |
| | | | | |
| Unavailability | 10^-7 to | 10^-5 to | 10^-3 | |
| | 10^-6 | 10^-4 | | |
| | | | | |
| Recovery delay | Zero | 50 ms | 5 s | 50 s |
| | | | | |
| Cybersecurity | Extremely | High | Medium | Medium |
| | high | | | |
+----------------+-----------+----------+----------+----------------+
+----------------+-----------+----------+----------+----------------+
| WAN | Class WA | Class WB | Class WC | Class WD |
| Requirement | | | | |
+----------------+-----------+----------+----------+----------------+
| Application | EHV | HV (High | MV | General- |
| field | (Extra- | Voltage) | (Medium | purpose |
| | High | | Voltage) | |
| | Voltage) | | | |
| | | | | |
| Latency | 5 ms | 10 ms | 100 ms | >100 ms |
| | | | | |
| Jitter | 10 us | 100 us | 1 ms | 10 ms |
| | | | | |
| Latency | 100 us | 1 ms | 10 ms | 100 ms |
| asymmetry | | | | |
| | | | | |
| Time accuracy | 1 us | 10 us | 100 us | 10 to 100 ms |
| | | | | |
| BER | 10^-7 to | 10^-5 to | 10^-3 | |
| | 10^-6 | 10^-4 | | |
| | | | | |
| Unavailability | 10^-7 to | 10^-5 to | 10^-3 | |
| | 10^-6 | 10^-4 | | |
| | | | | |
| Recovery delay | Zero | 50 ms | 5 s | 50 s |
| | | | | |
| Cybersecurity | Extremely | High | Medium | Medium |
| | high | | | |
+----------------+-----------+----------+----------+----------------+
Table 8: Communication Requirements (Courtesy of IEC TR 61850-90-12:2015)
表8：通信要求（由IEC TR 61850-90-12-2015提供）
Energy generation systems are complex infrastructures that require control of both the generated power and the generation infrastructure.
发电系统是一种复杂的基础设施，需要对发电和发电基础设施进行控制。
The electrical power generation frequency must be maintained within a very narrow band. Deviations from the acceptable frequency range are detected, and the required signals are sent to the power plants for frequency regulation.
发电频率必须保持在非常窄的频带内。检测到与可接受频率范围的偏差，并将所需信号发送至发电厂进行频率调节。
Automatic Generation Control (AGC) is a system for adjusting the power output of generators at different power plants, in response to changes in the load.
自动发电控制（AGC）是一种根据负荷变化调整不同发电厂发电机功率输出的系统。
+---------------------------------+---------------------------------+
| FCAG (Frequency Control | Attribute |
| Automatic Generation) | |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 500 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point |
| | |
| Bandwidth | 20 kbps |
| | |
| Availability | 99.999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | N/A |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| FCAG (Frequency Control | Attribute |
| Automatic Generation) | |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 500 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point |
| | |
| Bandwidth | 20 kbps |
| | |
| Availability | 99.999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | N/A |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
+---------------------------------+---------------------------------+
Table 9: FCAG Communication Requirements
表9:FCAG通信要求
The control of the generation infrastructure combines requirements from industrial automation systems and energy generation systems. This section describes the use case for control of the generation infrastructure of a wind turbine.
发电基础设施的控制结合了工业自动化系统和发电系统的要求。本节描述控制风力涡轮机发电基础设施的用例。
Figure 1 presents the subsystems that operate a wind turbine.
图1显示了操作风力涡轮机的子系统。
|
|
| +-----------------+
| | +----+ |
| | |WTRM| WGEN |
WROT x==|===| | |
| | +----+ WCNV|
| |WNAC |
| +---+---WYAW---+--+
| | |
| | | +----+
|WTRF | |WMET|
| | | |
Wind Turbine | +--+-+
Controller | |
WTUR | | |
WREP | | |
WSLG | | |
WALG | WTOW | |
|
|
| +-----------------+
| | +----+ |
| | |WTRM| WGEN |
WROT x==|===| | |
| | +----+ WCNV|
| |WNAC |
| +---+---WYAW---+--+
| | |
| | | +----+
|WTRF | |WMET|
| | | |
Wind Turbine | +--+-+
Controller | |
WTUR | | |
WREP | | |
WSLG | | |
WALG | WTOW | |
Figure 1: Wind Turbine Control Network
图1：风力涡轮机控制网络
The subsystems shown in Figure 1 include the following:
图1所示的子系统包括：
o WROT (rotor control)
o WROT（转子控制）
o WNAC (nacelle control) (nacelle: housing containing the generator)
o WNAC（机舱控制）（机舱：包含发电机的外壳）
o WTRM (transmission control)
o WTRM（变速箱控制）
o WGEN (generator)
o WGEN（发电机）
o WYAW (yaw controller) (of the tower head)
o WYAW（偏航控制器）（塔头）
o WCNV (in-turbine power converter)
o WCNV（涡轮功率转换器内）
o WTRF (wind turbine transformer information)
o WTRF（风力涡轮机变压器信息）
o WMET (external meteorological station providing real-time information to the tower's controllers)
o WMET（向塔台控制器提供实时信息的外部气象站）
o WTUR (wind turbine general information)
o WTUR（风力涡轮机一般信息）
o WREP (wind turbine report information)
o WREP（风力涡轮机报告信息）
o WSLG (wind turbine state log information)
o WSLG（风力涡轮机状态日志信息）
o WALG (wind turbine analog log information)
o WALG（风力涡轮机模拟日志信息）
o WTOW (wind turbine tower information)
o WTOW（风力涡轮机风塔信息）
Traffic characteristics relevant to the network planning and dimensioning process in a wind turbine scenario are listed below. The values in this section are based mainly on the relevant references [Ahm14] and [Spe09]. Each logical node (Figure 1) is a part of the metering network and produces analog measurements and status information that must comply with their respective data-rate constraints.
以下列出了与风力涡轮机场景中的网络规划和尺寸确定过程相关的流量特征。本节中的数值主要基于相关参考文献[Ahm14]和[Spe09]。每个逻辑节点（图1）都是计量网络的一部分，产生模拟测量和状态信息，这些信息必须符合各自的数据速率约束。
+-----------+--------+----------+-----------+-----------+-----------+
| Subsystem | Sensor | Analog | Data Rate | Status | Data Rate |
| | Count | Sample | (bytes/s) | Sample | (bytes/s) |
| | | Count | | Count | |
+-----------+--------+----------+-----------+-----------+-----------+
| WROT | 14 | 9 | 642 | 5 | 10 |
| | | | | | |
| WTRM | 18 | 10 | 2828 | 8 | 16 |
| | | | | | |
| WGEN | 14 | 12 | 73764 | 2 | 4 |
| | | | | | |
| WCNV | 14 | 12 | 74060 | 2 | 4 |
| | | | | | |
| WTRF | 12 | 5 | 73740 | 2 | 4 |
| | | | | | |
| WNAC | 12 | 9 | 112 | 3 | 6 |
| | | | | | |
| WYAW | 7 | 8 | 220 | 4 | 8 |
| | | | | | |
| WTOW | 4 | 1 | 8 | 3 | 6 |
| | | | | | |
| WMET | 7 | 7 | 228 | - | - |
+-----------+--------+----------+-----------+-----------+-----------+
+-----------+--------+----------+-----------+-----------+-----------+
| Subsystem | Sensor | Analog | Data Rate | Status | Data Rate |
| | Count | Sample | (bytes/s) | Sample | (bytes/s) |
| | | Count | | Count | |
+-----------+--------+----------+-----------+-----------+-----------+
| WROT | 14 | 9 | 642 | 5 | 10 |
| | | | | | |
| WTRM | 18 | 10 | 2828 | 8 | 16 |
| | | | | | |
| WGEN | 14 | 12 | 73764 | 2 | 4 |
| | | | | | |
| WCNV | 14 | 12 | 74060 | 2 | 4 |
| | | | | | |
| WTRF | 12 | 5 | 73740 | 2 | 4 |
| | | | | | |
| WNAC | 12 | 9 | 112 | 3 | 6 |
| | | | | | |
| WYAW | 7 | 8 | 220 | 4 | 8 |
| | | | | | |
| WTOW | 4 | 1 | 8 | 3 | 6 |
| | | | | | |
| WMET | 7 | 7 | 228 | - | - |
+-----------+--------+----------+-----------+-----------+-----------+
Table 10: Wind Turbine Data-Rate Constraints
表10：风力涡轮机数据速率限制
QoS constraints for different services are presented in Table 11. These constraints are defined by IEEE Standard 1646 [IEEE-1646] and IEC Standard 61400 Part 25 [IEC-61400-25].
不同服务的QoS约束如表11所示。这些约束由IEEE标准1646[IEEE-1646]和IEC标准61400第25部分[IEC-61400-25]定义。
+---------------------+---------+-------------+---------------------+
| Service | Latency | Reliability | Packet Loss Rate |
+---------------------+---------+-------------+---------------------+
| Analog measurement | 16 ms | 99.99% | <10^-6 |
| | | | |
| Status information | 16 ms | 99.99% | <10^-6 |
| | | | |
| Protection traffic | 4 ms | 100.00% | <10^-9 |
| | | | |
| Reporting and | 1 s | 99.99% | <10^-6 |
| logging | | | |
| | | | |
| Video surveillance | 1 s | 99.00% | No specific |
| | | | requirement |
| | | | |
| Internet connection | 60 min | 99.00% | No specific |
| | | | requirement |
| | | | |
| Control traffic | 16 ms | 100.00% | <10^-9 |
| | | | |
| Data polling | 16 ms | 99.99% | <10^-6 |
+---------------------+---------+-------------+---------------------+
+---------------------+---------+-------------+---------------------+
| Service | Latency | Reliability | Packet Loss Rate |
+---------------------+---------+-------------+---------------------+
| Analog measurement | 16 ms | 99.99% | <10^-6 |
| | | | |
| Status information | 16 ms | 99.99% | <10^-6 |
| | | | |
| Protection traffic | 4 ms | 100.00% | <10^-9 |
| | | | |
| Reporting and | 1 s | 99.99% | <10^-6 |
| logging | | | |
| | | | |
| Video surveillance | 1 s | 99.00% | No specific |
| | | | requirement |
| | | | |
| Internet connection | 60 min | 99.00% | No specific |
| | | | requirement |
| | | | |
| Control traffic | 16 ms | 100.00% | <10^-9 |
| | | | |
| Data polling | 16 ms | 99.99% | <10^-6 |
+---------------------+---------+-------------+---------------------+
Table 11: Wind Turbine Reliability and Latency Constraints
表11：风力涡轮机可靠性和延迟约束
A wind turbine is composed of a large set of subsystems, including sensors and actuators that require time-critical operation. The reliability and latency constraints of these different subsystems are shown in Table 11. These subsystems are connected to an intra-domain network that is used to monitor and control the operation of the turbine and connect it to the SCADA subsystems. The different components are interconnected using fiber optics, industrial buses, industrial Ethernet, EtherCAT [EtherCAT], or a combination thereof. Industrial signaling and control protocols such as Modbus [MODBUS], PROFIBUS [PROFIBUS], PROFINET [PROFINET], and EtherCAT are used directly on top of the Layer 2 transport or encapsulated over TCP/IP.
风力涡轮机由大量子系统组成，包括需要时间关键操作的传感器和执行器。这些不同子系统的可靠性和延迟约束如表11所示。这些子系统连接到域内网络，该网络用于监测和控制涡轮机的运行，并将其连接到SCADA子系统。不同组件使用光纤、工业总线、工业以太网、EtherCAT[EtherCAT]或其组合进行互连。工业信号和控制协议，如Modbus[Modbus]、PROFIBUS[PROFIBUS]、PROFINET[PROFINET]和EtherCAT，直接用于第2层传输或通过TCP/IP封装。
The data collected from the sensors and condition-monitoring systems is multiplexed onto fiber cables for transmission to the base of the tower and to remote control centers. The turbine controller continuously monitors the condition of the wind turbine and collects
从传感器和状态监测系统收集的数据被多路传输到光缆上，以便传输到塔架底部和远程控制中心。涡轮机控制器持续监控风力涡轮机的状况并收集
statistics on its operation. This controller also manages a large number of switches, hydraulic pumps, valves, and motors within the wind turbine.
关于其运作的统计数字。该控制器还管理风力涡轮机内的大量开关、液压泵、阀门和电机。
There is usually a controller at the bottom of the tower and also in the nacelle. The communication between these two controllers usually takes place using fiber optics instead of copper links. Sometimes, a third controller is installed in the hub of the rotor and manages the pitch of the blades. That unit usually communicates with the nacelle unit using serial communications.
通常在风塔底部和风舱中都有一个控制器。这两个控制器之间的通信通常使用光纤而不是铜链路。有时，第三个控制器安装在转子的轮毂上，并管理叶片的节距。该装置通常使用串行通信与机舱装置进行通信。
A remote control center belonging to a grid operator regulates the power output, enables remote actuation, and monitors the health of one or more wind parks in tandem. It connects to the local control center in a wind park over the Internet (Figure 2) via firewalls at both ends. The Autonomous System (AS) path between the local control center and the wind park typically involves several ISPs at different tiers. For example, a remote control center in Denmark can regulate a wind park in Greece over the normal public AS path between the two locations.
电网运营商的远程控制中心可调节功率输出，实现远程驱动，并同时监控一个或多个风电场的健康状况。它通过互联网（图2）通过两端的防火墙连接到风电场的本地控制中心。本地控制中心和风电场之间的自主系统（AS）路径通常涉及不同层级的多个ISP。例如，丹麦的一个远程控制中心可以将希腊的一个风力发电场作为两个地点之间的路径，通过正常的公众进行管理。
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX X XXXXX | |
+---+ XXX | Remote Control |
XXX Internet +----+ Center |
+----+X XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX X XXXXX | |
+---+ XXX | Remote Control |
XXX Internet +----+ Center |
+----+X XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
Figure 2: Wind Turbine Control via Internet
图2：通过互联网控制风力涡轮机
The remote control center is part of the SCADA system, setting the desired power output to the wind park and reading back the result once the new power output level has been set. Traffic between the remote control center and the wind park typically consists of protocols like IEC 60870-5-104 [IEC-60870-5-104], OPC XML-Data Access
远程控制中心是SCADA系统的一部分，设置风电场所需的功率输出，并在设置新的功率输出水平后读取结果。远程控制中心和风电场之间的通信量通常由IEC 60870-5-104[IEC-60870-5-104]和OPC XML数据访问等协议组成
(XML-DA) [OPCXML], Modbus [MODBUS], and SNMP [RFC3411]. At the time of this writing, traffic flows between the remote control center and the wind park are best effort. QoS requirements are not strict, so no Service Level Agreements (SLAs) or service-provisioning mechanisms (e.g., VPNs) are employed. In the case of such events as equipment failure, tolerance for alarm delay is on the order of minutes, due to redundant systems already in place.
（XML-DA）[OPCXML]、Modbus[Modbus]和SNMP[RFC3411]。在撰写本文时，远程控制中心和风电场之间的交通流量是最大的努力。QoS要求并不严格，因此未采用服务级别协议（SLA）或服务提供机制（如VPN）。在发生设备故障等事件时，由于冗余系统已经就位，警报延迟的容差大约为分钟。
Future use cases will require bounded latency, bounded jitter, and extraordinarily low packet loss for inter-domain traffic flows due to the softwarization and virtualization of core wind-park equipment (e.g., switches, firewalls, and SCADA server components). These factors will create opportunities for service providers to install new services and dynamically manage them from remote locations. For example, to enable failover of a local SCADA server, a SCADA server in another wind-park site (under the administrative control of the same operator) could be utilized temporarily (Figure 3). In that case, local traffic would be forwarded to the remote SCADA server, and existing intra-domain QoS and timing parameters would have to be met for inter-domain traffic flows.
由于核心风电场设备（如交换机、防火墙和SCADA服务器组件）的软件化和虚拟化，未来用例将要求域间流量具有有限的延迟、有限的抖动和极低的数据包丢失。这些因素将为服务提供商提供安装新服务并从远程位置动态管理这些服务的机会。例如，为了实现本地SCADA服务器的故障切换，可以临时使用另一个风电场站点（在同一运营商的管理控制下）中的SCADA服务器（图3）。在这种情况下，本地流量将转发到远程SCADA服务器，域间流量必须满足现有的域内QoS和定时参数。
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX XXXXX | |
+---+ Operator- XXX | Remote Control |
XXX Administered +----+ Center |
+----+X WAN XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX XXXXX | |
+---+ Operator- XXX | Remote Control |
XXX Administered +----+ Center |
+----+X WAN XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
Figure 3: Wind Turbine Control via Operator-Administered WAN
图3：通过操作员管理的广域网控制风力涡轮机
"Fault Location, Isolation, and Service Restoration (FLISR)" refers to the ability to automatically locate the fault, isolate the fault, and restore service in the distribution network. This will likely be the first widespread application of distributed intelligence in the grid.
“故障定位、隔离和服务恢复（FLISR）”指在配电网中自动定位故障、隔离故障和恢复服务的能力。这可能是分布式智能在网格中的首次广泛应用。
The static power-switch status (open/closed) in the network dictates the power flow to secondary substations. Reconfiguring the network in the event of a fault is typically done manually on site to energize/de-energize alternate paths. Automating the operation of substation switchgear allows the flow of power to be altered automatically under fault conditions.
网络中的静态电源开关状态（打开/关闭）指示二次变电站的功率流。在发生故障时，通常在现场手动重新配置网络，以便为备用路径通电/断电。变电站开关设备的自动化操作允许在故障条件下自动改变功率流。
FLISR can be managed centrally from a Distribution Management System (DMS) or executed locally through distributed control via intelligent switches and fault sensors.
FLISR可以从配电管理系统（DMS）集中管理，也可以通过智能交换机和故障传感器的分布式控制在本地执行。
+---------------------------------+---------------------------------+
| FLISR Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 80 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | 40 ms |
| | |
| Topology | Point to point, point to |
| | multipoint, multipoint to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Depends on customer impact |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| FLISR Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 80 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | 40 ms |
| | |
| Topology | Point to point, point to |
| | multipoint, multipoint to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Depends on customer impact |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 12: FLISR Communication Requirements
表12:FLISR通信要求
Many utilities still rely on complex environments consisting of multiple application-specific proprietary networks, including TDM networks.
许多公用事业公司仍然依赖于由多个特定于应用程序的专有网络（包括TDM网络）组成的复杂环境。
In this kind of environment, there is no mixing of Operation Technology (OT) and IT applications on the same network, and information is siloed between operational areas.
在这种环境中，操作技术（OT）和IT应用程序不会在同一网络上混合使用，信息在操作区域之间呈筒仓式分布。
Specific calibration of the full chain is required; this is costly.
需要对整个链条进行具体校准；这是昂贵的。
This kind of environment prevents utility operations from realizing operational efficiency benefits, visibility, and functional integration of operational information across grid applications and data networks.
这种环境使公用事业运营无法实现跨网格应用程序和数据网络的运营信息的运营效率、可视性和功能集成。
In addition, there are many security-related issues, as discussed in the following section.
此外，还有许多与安全相关的问题，将在下一节中讨论。
Grid-monitoring and control devices are already targets for cyber attacks, and legacy telecommunications protocols have many intrinsic network-related vulnerabilities. For example, the Distributed Network Protocol (DNP3) [IEEE-1815], Modbus, PROFIBUS/PROFINET, and other protocols are designed around a common paradigm of "request and respond". Each protocol is designed for a master device such as an HMI (Human-Machine Interface) system to send commands to subordinate slave devices to perform data retrieval (reading inputs) or control functions (writing to outputs). Because many of these protocols lack authentication, encryption, or other basic security measures, they are prone to network-based attacks, allowing a malicious actor or attacker to utilize the request-and-respond system as a mechanism for functionality similar to command and control. Specific security concerns common to most industrial-control protocols (including utility telecommunications protocols) include the following:
电网监控设备已经成为网络攻击的目标，传统电信协议存在许多固有的网络相关漏洞。例如，分布式网络协议（DNP3）[IEEE-1815]、Modbus、PROFIBUS/PROFINET和其他协议都是围绕“请求和响应”的通用范例设计的。每个协议都是为主设备（如HMI（人机界面）系统）设计的，用于向从属从属设备发送命令，以执行数据检索（读取输入）或控制功能（写入输出）。由于其中许多协议缺乏身份验证、加密或其他基本安全措施，因此它们容易受到基于网络的攻击，从而使恶意参与者或攻击者能够利用请求和响应系统作为类似于命令和控制的功能机制。大多数工业控制协议（包括公用电信协议）常见的特定安全问题包括：
o Network or transport errors (e.g., malformed packets or excessive latency) can cause protocol failure.
o 网络或传输错误（例如，数据包格式错误或延迟过长）可能导致协议失败。
o Protocol commands may be available that are capable of forcing slave devices into inoperable states, including powering devices off, forcing them into a listen-only state, or disabling alarming.
o 协议命令可用于强制从设备进入不可操作状态，包括关闭设备电源、强制设备进入仅侦听状态或禁用报警。
o Protocol commands may be available that are capable of interrupting processes (e.g., restarting communications).
o 可以使用能够中断进程（例如，重新启动通信）的协议命令。
o Protocol commands may be available that are capable of clearing, erasing, or resetting diagnostic information such as counters and diagnostic registers.
o 协议命令可用于清除、擦除或重置诊断信息，如计数器和诊断寄存器。
o Protocol commands may be available that are capable of requesting sensitive information about the controllers, their configurations, or other need-to-know information.
o 协议命令可用于请求有关控制器、其配置或其他需要了解的信息的敏感信息。
o Most protocols are application-layer protocols transported over TCP; it is therefore easy to transport commands over non-standard ports or inject commands into authorized traffic flows.
o 大多数协议是通过TCP传输的应用层协议；因此，通过非标准端口传输命令或将命令注入授权的通信流是很容易的。
o Protocol commands may be available that are capable of broadcasting messages to many devices at once (i.e., a potential DoS).
o 可以使用能够同时向多个设备广播消息的协议命令（即，潜在的DoS）。
o Protocol commands may be available that will query the device network to obtain defined points and their values (i.e., perform a configuration scan).
o 协议命令可用于查询设备网络，以获取定义的点及其值（即，执行配置扫描）。
o Protocol commands may be available that will list all available function codes (i.e., perform a function scan).
o 可以使用协议命令列出所有可用的功能代码（即，执行功能扫描）。
These inherent vulnerabilities, along with increasing connectivity between IT and OT networks, make network-based attacks very feasible. By injecting malicious protocol commands, an attacker could take control over the target process. Altering legitimate protocol traffic can also alter information about a process and disrupt the legitimate controls that are in place over that process. A man-in-the-middle attack could result in (1) improper control over a process and (2) misrepresentation of data that is sent back to operator consoles.
这些固有的漏洞，加上IT和OT网络之间的连通性不断增强，使得基于网络的攻击非常可行。通过注入恶意协议命令，攻击者可以控制目标进程。更改合法的协议流量还可以更改有关进程的信息，并破坏对该进程的合法控制。中间人攻击可能导致（1）对进程的不当控制和（2）发送回操作员控制台的数据的误报。
The business and technology trends that are sweeping the utility industry will drastically transform the utility business from the way it has been for many decades. At the core of many of these changes is a drive to modernize the electrical grid with an integrated telecommunications infrastructure. However, interoperability concerns, legacy networks, disparate tools, and stringent security requirements all add complexity to the grid's transformation. Given the range and diversity of the requirements that should be addressed by the next-generation telecommunications infrastructure, utilities need to adopt a holistic architectural approach to integrate the electrical grid with digital telecommunications across the entire power delivery chain.
席卷公用事业行业的业务和技术趋势将使公用事业行业从几十年前的状况发生巨大变化。其中许多变革的核心是推动电网现代化，建立综合电信基础设施。然而，互操作性问题、遗留网络、不同的工具和严格的安全要求都增加了网格转换的复杂性。考虑到下一代电信基础设施应满足的要求的范围和多样性，公用事业公司需要采用整体架构方法，在整个电力输送链上将电网与数字电信集成。
The key to modernizing grid telecommunications is to provide a common, adaptable, multi-service network infrastructure for the entire utility organization. Such a network serves as the platform for current capabilities while enabling future expansion of the network to accommodate new applications and services.
电网电信现代化的关键是为整个公用事业机构提供一个通用的、适应性强的、多服务的网络基础设施。这样一个网络可以作为当前能力的平台，同时使未来的网络扩展能够容纳新的应用程序和服务。
To meet this diverse set of requirements both today and in the future, the next-generation utility telecommunications network will be based on an open-standards-based IP architecture. An end-to-end IP architecture takes advantage of nearly three decades of IP technology development, facilitating interoperability and device management across disparate networks and devices, as has already been demonstrated in many mission-critical and highly secure networks.
为了满足当今和未来的这一多样化需求，下一代公用电信网络将基于基于开放标准的IP架构。端到端IP体系结构利用了近三十年的IP技术发展，促进了跨不同网络和设备的互操作性和设备管理，这在许多任务关键型和高度安全的网络中已经得到了证明。
IPv6 is seen as a future telecommunications technology for the smart grid; the IEC and different national committees have mandated a specific ad hoc group (AHG8) to define the strategy for migration to IPv6 for all the IEC Technical Committee 57 (TC 57) power automation standards. The AHG8 has finalized its work on the migration strategy, and IEC TR 62357-200:2015 [IEC-62357-200:2015] has been issued.
IPv6被视为智能电网的未来电信技术；IEC和不同的国家委员会已授权一个特定的特设小组（AHG8）为所有IEC技术委员会57（TC 57）电力自动化标准定义向IPv6迁移的策略。AHG8已完成其移民战略工作，并发布了IEC TR 62357-200:2015[IEC-62357-200:2015]。
Cloud-based SCADA systems will control and monitor the critical and non-critical subsystems of generation systems -- for example, wind parks.
基于云的SCADA系统将控制和监控发电系统的关键和非关键子系统，例如风力发电场。
Throughout the world, utilities are increasingly planning for a future based on smart-grid applications requiring advanced telecommunications systems. Many of these applications utilize packet connectivity for communicating information and control signals across the utility's WAN, made possible by technologies such as Multiprotocol Label Switching (MPLS). The data that traverses the utility WAN includes:
在全世界范围内，公用事业公司越来越多地规划基于需要先进电信系统的智能电网应用的未来。其中许多应用程序利用数据包连接性在公用事业公司的广域网上传输信息和控制信号，这是由多协议标签交换（MPLS）等技术实现的。通过公用事业WAN的数据包括：
o Grid monitoring, control, and protection data
o 网格监控、控制和保护数据
o Non-control grid data (e.g., asset data for condition monitoring)
o 非控制网格数据（例如，用于状态监测的资产数据）
o Data (e.g., voice and video) related to physical safety and security
o 与人身安全和安保相关的数据（如语音和视频）
o Remote worker access to corporate applications (voice, maps, schematics, etc.)
o 远程工作人员访问公司应用程序（语音、地图、示意图等）
o Field area network Backhaul for smart metering
o 用于智能计量的现场区域网络回程
o Distribution-grid management
o 配电网管理
o Enterprise traffic (email, collaboration tools, business applications)
o 企业流量（电子邮件、协作工具、业务应用程序）
WANs support this wide variety of traffic to and from substations, the transmission and distribution grid, and generation sites; between control centers; and between work locations and data centers. To maintain this rapidly expanding set of applications, many utilities are taking steps to evolve present TDM-based and frame relay infrastructures to packet systems. Packet-based networks are designed to provide greater functionalities and higher levels of service for applications, while continuing to deliver reliability and deterministic (real-time) traffic support.
广域网支持变电站、输配电网和发电站之间的各种通信；控制中心之间；以及在工作地点和数据中心之间。为了维护这一快速扩展的应用程序集，许多实用程序正在采取步骤，将现有的基于TDM的和帧中继的基础设施发展到分组系统。基于分组的网络旨在为应用程序提供更大的功能和更高的服务级别，同时继续提供可靠性和确定性（实时）流量支持。
These general telecommunications topics are provided in addition to the use cases that have been addressed so far. These include both current and future telecommunications-related topics that should be factored into the network architecture and design.
除了到目前为止已经讨论过的用例之外，还提供了这些一般电信主题。这些包括当前和未来的电信相关主题，这些主题应纳入网络架构和设计中。
o IP connectivity everywhere
o IP连接无处不在
o Monitoring services everywhere, and from different remote centers
o 监控服务无处不在，而且来自不同的远程中心
o Moving services to a virtual data center
o 将服务移动到虚拟数据中心
o Unified access to applications/information from the corporate network
o 从公司网络统一访问应用程序/信息
o Unified services
o 统一服务
o Unified communications solutions
o 统一通信解决方案
o Mix of fiber and microwave technologies - obsolescence of the Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) or TDM
o 光纤和微波技术的混合.同步光网络/同步数字体系（SONET/SDH）或TDM的过时
o Standardizing grid telecommunications protocols to open standards, to ensure interoperability
o 将网格电信协议标准化为开放标准，以确保互操作性
o Reliable telecommunications for transmission and distribution substations
o 输电和配电变电站的可靠通信
o IEEE 1588 time-synchronization client/server capabilities
o IEEE 1588时间同步客户端/服务器功能
o Integration of multicast design
o 多播设计的集成
o Mapping of QoS requirements
o QoS需求映射
o Enabling future network expansion
o 支持未来的网络扩展
o Substation network resilience
o 变电站网络弹性
o Fast convergence design
o 快速收敛设计
o Scalable headend design
o 可伸缩前端设计
o Defining SLAs and enabling SLA monitoring
o 定义SLA并启用SLA监控
o Integration of 3G/4G technologies and future technologies
o 3G/4G技术与未来技术的融合
o Ethernet connectivity for station bus architecture
o 用于站点总线体系结构的以太网连接
o Ethernet connectivity for process bus architecture
o 过程总线体系结构的以太网连接
o Protection, teleprotection, and PMUs on IP
o IP上的保护、远程保护和PMU
Utilities often have very large private telecommunications networks that can cover an entire territory/country. Until now, the main purposes of these networks have been to (1) support transmission network monitoring, control, and automation, (2) support remote control of generation sites, and (3) provide FCAPS (Fault, Configuration, Accounting, Performance, and Security) services from centralized network operation centers.
公用事业公司通常拥有覆盖整个领土/国家的大型私人电信网络。到目前为止，这些网络的主要目的是（1）支持输电网络监测、控制和自动化，（2）支持发电站的远程控制，以及（3）从集中的网络运营中心提供FCAP（故障、配置、计费、性能和安全）服务。
Going forward, one network will support the operation and maintenance of electrical networks (generation, transmission, and distribution), voice and data services for tens of thousands of employees and for exchanges with neighboring interconnections, and administrative services. To meet those requirements, a utility may deploy several physical networks leveraging different technologies across the country -- for instance, an optical network and a microwave network. Each protection and automation system between two points has two telecommunications circuits, one on each network. Path diversity between two substations is key. Regardless of the event type (hurricane, ice storm, etc.), one path needs to stay available so the system can still operate.
未来，一个网络将支持电力网络（发电、输电和配电）的运行和维护，为数万名员工提供语音和数据服务，并支持与相邻互联网络的交换，以及管理服务。为了满足这些要求，公用事业公司可以在全国部署多个利用不同技术的物理网络——例如，光网络和微波网络。两点之间的每个保护和自动化系统有两个电信电路，每个网络上有一个。两个变电站之间的路径多样性是关键。无论事件类型如何（飓风、冰暴等），都需要一条路径保持可用，以便系统仍能运行。
In the optical network, signals are transmitted over more than tens of thousands of circuits using fiber optic links, microwave links, and telephone cables. This network is the nervous system of the utility's power transmission operations. The optical network represents tens of thousands of kilometers of cable deployed along the power lines, with individual runs as long as 280 km.
在光网络中，信号通过光纤链路、微波链路和电话电缆通过数万条电路传输。该网络是公用事业公司电力传输操作的神经系统。光网络代表了沿着电力线部署的数万公里的电缆，单个线路长达280公里。
Some utilities do not use GPS clocks in generation substations. One of the main reasons is that some of the generation plants are 30 to 50 meters deep underground and the GPS signal can be weak and unreliable. Instead, atomic clocks are used. Clocks are synchronized amongst each other. Rubidium clocks provide clock and 1 ms timestamps for IRIG-B.
一些公用事业公司在发电变电站中不使用GPS时钟。其中一个主要原因是，一些发电厂位于地下30至50米深处，GPS信号微弱且不可靠。取而代之的是原子钟。时钟是相互同步的。铷时钟为IRIG-B提供时钟和1毫秒时间戳。
Some companies plan to transition to PTP [IEEE-1588], distributing the synchronization signal over the IP/MPLS network. PTP provides a mechanism for synchronizing the clocks of participating nodes to a high degree of accuracy and precision.
一些公司计划过渡到PTP[IEEE-1588]，通过IP/MPLS网络分发同步信号。PTP提供了一种机制，用于高精度地同步参与节点的时钟。
PTP operates based on the following assumptions:
PTP基于以下假设运行：
o The network eliminates cyclic forwarding of PTP messages within each communication path (e.g., by using a spanning tree protocol).
o 该网络消除了每个通信路径内PTP消息的循环转发（例如，通过使用生成树协议）。
o PTP is tolerant of an occasional missed message, duplicated message, or message that arrived out of order. However, PTP assumes that such impairments are relatively rare.
o PTP可以容忍偶尔丢失的消息、重复的消息或到达时出现故障的消息。然而，PTP假设此类损害相对较少。
o As designed, PTP expects a multicast communication model; however, PTP also supports a unicast communication model as long as the behavior of the protocol is preserved.
o 根据设计，PTP需要一个多播通信模型；然而，只要协议的行为保持不变，PTP也支持单播通信模型。
o Like all message-based time transfer protocols, PTP time accuracy is degraded by delay asymmetry in the paths taken by event messages. PTP cannot detect asymmetry, but if such delays are known a priori, time values can be adjusted to correct for asymmetry.
o 与所有基于消息的时间传输协议一样，PTP时间精度因事件消息所采用路径的延迟不对称而降低。PTP无法检测到不对称性，但如果这种延迟是先验的，则可以调整时间值以纠正不对称性。
The use of PTP for power automation is defined in IEC/IEEE 61850-9-3:2016 [IEC-IEEE-61850-9-3:2016]. It is based on Annex B of IEC 62439-3:2016 [IEC-62439-3:2016], which offers the support of redundant attachment of clocks to Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR) networks.
电力自动化中PTP的使用在IEC/IEEE 61850-9-3:2016[IEC-IEEE-61850-9-3:2016]中有定义。它基于IEC 62439-3:2016[IEC-62439-3:2016]的附录B，该附录提供了对并行冗余协议（PRP）和高可用性无缝冗余（HSR）网络时钟冗余连接的支持。
Although advanced telecommunications networks can assist in transforming the energy industry by playing a critical role in maintaining high levels of reliability, performance, and manageability, they also introduce the need for an integrated security infrastructure. Many of the technologies being deployed to support smart-grid projects such as smart meters and sensors can increase the vulnerability of the grid to attack. Top security concerns for utilities migrating to an intelligent smart-grid telecommunications platform center on the following trends:
尽管先进的电信网络在保持高水平的可靠性、性能和可管理性方面发挥着关键作用，有助于能源行业的转型，但它们也带来了对集成安全基础设施的需求。许多用于支持智能电网项目的技术，如智能电表和传感器，都会增加电网的攻击脆弱性。在以下趋势下，迁移到智能电网电信平台中心的公用事业公司的首要安全问题：
o Integration of distributed energy resources
o 分布式能源的集成
o Proliferation of digital devices to enable management, automation, protection, and control
o 支持管理、自动化、保护和控制的数字设备激增
o Regulatory mandates to comply with standards for critical infrastructure protection
o 遵守关键基础设施保护标准的法规要求
o Migration to new systems for outage management, distribution automation, condition-based maintenance, load forecasting, and smart metering
o 迁移到新系统，用于大修管理、配电自动化、基于状态的维护、负荷预测和智能计量
o Demand for new levels of customer service and energy management
o 对新级别客户服务和能源管理的需求
This development of a diverse set of networks to support the integration of microgrids, open-access energy competition, and the use of network-controlled devices is driving the need for a converged security infrastructure for all participants in the smart grid, including utilities, energy service providers, large commercial and industrial customers, and residential customers. Securing the assets of electric power delivery systems (from the control center to the substation, to the feeders and down to customer meters) requires an end-to-end security infrastructure that protects the myriad of telecommunications assets used to operate, monitor, and control power flow and measurement.
为支持微电网集成、开放获取能源竞争和网络控制设备的使用而开发的各种网络正推动着智能电网所有参与者（包括公用事业、能源服务提供商、，大型商业和工业客户以及住宅客户。保护电力输送系统的资产（从控制中心到变电站，到馈线，再到用户电表）需要一个端到端的安全基础设施，以保护用于操作、监控和控制潮流和测量的无数电信资产。
"Cybersecurity" refers to all the security issues in automation and telecommunications that affect any functions related to the operation of the electric power systems. Specifically, it involves the concepts of:
“网络安全”是指自动化和电信中影响电力系统运行相关功能的所有安全问题。具体而言，它涉及以下概念：
o Integrity: data cannot be altered undetectably
o 完整性：无法检测到数据的更改
o Authenticity (data origin authentication): the telecommunications parties involved must be validated as genuine
o 真实性（数据来源认证）：涉及的电信方必须验证为真实
o Authorization: only requests and commands from authorized users can be accepted by the system
o 授权：系统只能接受授权用户的请求和命令
o Confidentiality: data must not be accessible to any unauthenticated users
o 保密性：未经验证的用户不得访问数据
When designing and deploying new smart-grid devices and telecommunications systems, it is imperative to understand the various impacts of these new components under a variety of attack situations on the power grid. The consequences of a cyber attack on the grid telecommunications network can be catastrophic. This is why security for the smart grid is not just an ad hoc feature or product; it's a complete framework integrating both physical and cybersecurity requirements and covering the entire smart-grid networks from generation to distribution. Security has therefore become one of the main foundations of the utility telecom network architecture and must be considered at every layer with a defense-in-depth approach.
在设计和部署新的智能电网设备和电信系统时，必须了解这些新组件在各种攻击情况下对电网的各种影响。电网电信网络遭受网络攻击的后果可能是灾难性的。这就是为什么智能电网的安全不仅仅是一个特殊的功能或产品；它是一个综合物理和网络安全要求的完整框架，涵盖从发电到配电的整个智能电网网络。因此，安全性已成为公用电信网络体系结构的主要基础之一，必须在每一层采用纵深防御方法加以考虑。
Migrating to IP-based protocols is key to addressing these challenges for two reasons:
迁移到基于IP的协议是解决这些挑战的关键，原因有两个：
o IP enables a rich set of features and capabilities to enhance the security posture.
o IP支持一组丰富的特性和功能，以增强安全态势。
o IP is based on open standards; this allows interoperability between different vendors and products, driving down the costs associated with implementing security solutions in OT networks.
o 知识产权基于开放标准；这允许不同供应商和产品之间的互操作性，降低了在OT网络中实施安全解决方案的相关成本。
Securing OT telecommunications over packet-switched IP networks follows the same principles that are foundational for securing the IT infrastructure, i.e., consideration must be given to (1) enforcing electronic access control for both person-to-machine and machine-to-machine communications and (2) providing the appropriate levels of data privacy, device and platform integrity, and threat detection and mitigation.
通过分组交换IP网络保护OT电信遵循与保护IT基础设施相同的原则，即必须考虑（1）对人-机和机-机通信实施电子访问控制，以及（2）提供适当级别的数据隐私，设备和平台完整性，以及威胁检测和缓解。
o Mixed Layer 2 and Layer 3 topologies
o 混合第2层和第3层拓扑
o Deterministic behavior
o 确定性行为
o Bounded latency and jitter
o 有界延迟和抖动
o Tight feedback intervals
o 紧密的反馈间隔
o High availability, low recovery time
o 高可用性，低恢复时间
o Redundancy, low packet loss
o 冗余，低数据包丢失
o Precise timing
o 精确计时
o Centralized computing of deterministic paths
o 确定性路径的集中计算
o Distributed configuration (may also be useful)
o 分布式配置（也可能有用）
A BAS manages equipment and sensors in a building for improving residents' comfort, reducing energy consumption, and responding to failures and emergencies. For example, the BAS measures the temperature of a room using sensors and then controls the HVAC (heating, ventilating, and air conditioning) to maintain a set temperature and minimize energy consumption.
BAS管理建筑物中的设备和传感器，以提高居民的舒适度，降低能耗，并应对故障和紧急情况。例如，BAS使用传感器测量房间温度，然后控制HVAC（加热、通风和空调），以保持设定温度并将能耗降至最低。
A BAS primarily performs the following functions:
BAS主要执行以下功能：
o Periodically measures states of devices -- for example, humidity and illuminance of rooms, open/close state of doors, fan speed.
o 定期测量设备的状态——例如，房间的湿度和照度、门的打开/关闭状态、风扇转速。
o Stores the measured data.
o 存储测量数据。
o Provides the measured data to BAS operators.
o 向BAS操作员提供测量数据。
o Generates alarms for abnormal state of devices.
o 为设备的异常状态生成警报。
o Controls devices (e.g., turns room lights off at 10:00 PM).
o 控制设备（例如，在晚上10:00关闭房间灯）。
A typical present-day BAS architecture is shown in Figure 4.
图4显示了当今典型的BAS体系结构。
+----------------------------+
| |
| BMS HMI |
| | | |
| +----------------------+ |
| | Management Network | |
| +----------------------+ |
| | | |
| LC LC |
| | | |
| +----------------------+ |
| | Field Network | |
| +----------------------+ |
| | | | | |
| Dev Dev Dev Dev |
| |
+----------------------------+
+----------------------------+
| |
| BMS HMI |
| | | |
| +----------------------+ |
| | Management Network | |
| +----------------------+ |
| | | |
| LC LC |
| | | |
| +----------------------+ |
| | Field Network | |
| +----------------------+ |
| | | | | |
| Dev Dev Dev Dev |
| |
+----------------------------+
BMS: Building Management Server HMI: Human-Machine Interface LC: Local Controller
BMS：楼宇管理服务器HMI：人机界面LC：本地控制器
Figure 4: BAS Architecture
图4:BAS体系结构
There are typically two layers of a network in a BAS. The upper layer is called the management network, and the lower layer is called the field network. In management networks, an IP-based communication protocol is used, while in field networks, non-IP-based communication
BAS中通常有两层网络。上层称为管理网络，下层称为现场网络。在管理网络中，使用基于IP的通信协议，而在现场网络中，使用非基于IP的通信协议
protocols ("field protocols") are mainly used. Field networks have specific timing requirements, whereas management networks can be best effort.
主要使用协议（“现场协议”）。现场网络有特定的时间要求，而管理网络可以是最好的。
An HMI is typically a desktop PC used by operators to monitor and display device states, send device control commands to Local Controllers (LCs), and configure building schedules (for example, "turn off all room lights in the building at 10:00 PM").
HMI通常是操作员使用的台式PC，用于监控和显示设备状态，向本地控制器（LCs）发送设备控制命令，并配置建筑物时间表（例如，“在晚上10:00关闭建筑物内的所有房间灯”）。
A building management server (BMS) performs the following operations.
楼宇管理服务器（BMS）执行以下操作。
o Collects and stores device states from LCs at regular intervals.
o 定期从LCs收集和存储设备状态。
o Sends control values to LCs according to a building schedule.
o 根据建筑明细表将控制值发送到LCs。
o Sends an alarm signal to operators if it detects abnormal device states.
o 如果检测到设备状态异常，则向操作员发送报警信号。
The BMS and HMI communicate with LCs via IP-based "management protocols" (see standards [BACnet-IP] and [KNX]).
BMS和HMI通过基于IP的“管理协议”与LCs通信（参见标准[BACnet IP]和[KNX]）。
An LC is typically a Programmable Logic Controller (PLC) that is connected to several tens or hundreds of devices using "field protocols". An LC performs the following kinds of operations:
LC通常是一个可编程逻辑控制器（PLC），它使用“现场协议”连接到数十个或数百个设备。LC执行以下类型的操作：
o Measures device states and provides the information to a BMS or HMI.
o 测量设备状态并向BMS或HMI提供信息。
o Sends control values to devices, unilaterally or as part of a feedback control loop.
o 单方面或作为反馈控制回路的一部分，向设备发送控制值。
At the time of this writing, many field protocols are in use; some are standards-based protocols, and others are proprietary (see standards [LonTalk], [MODBUS], [PROFIBUS], and [FL-net]). The result is that BASs have multiple MAC/PHY modules and interfaces. This makes BASs more expensive and slower to develop and can result in "vendor lock-in" with multiple types of management applications.
在撰写本文时，许多现场协议正在使用中；一些是基于标准的协议，另一些是专有的（参见标准[LonTalk]、[MODBUS]、[PROFIBUS]和[FL net]）。结果是BASs具有多个MAC/PHY模块和接口。这使得BASs的开发成本更高、速度更慢，并可能导致对多种类型的管理应用程序的“供应商锁定”。
An example BAS for medium or large buildings is shown in Figure 5. The physical layout spans multiple floors and includes a monitoring room where the BAS management entities are located. Each floor will have one or more LCs, depending on the number of devices connected to the field network.
中型或大型建筑的BAS示例如图5所示。物理布局跨越多个楼层，包括BAS管理实体所在的监控室。根据连接到现场网络的设备数量，每个楼层将有一个或多个LCs。
+--------------------------------------------------+
| Floor 3 |
| +----LC~~~~+~~~~~+~~~~~+ |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 2 |
| +----LC~~~~+~~~~~+~~~~~+ Field Network |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 1 |
| +----LC~~~~+~~~~~+~~~~~+ +-----------------|
| | | | | | Monitoring Room |
| | Dev Dev Dev | |
| | | BMS HMI |
| | Management Network | | | |
| +--------------------------------+-----+ |
| | |
+--------------------------------------------------+
+--------------------------------------------------+
| Floor 3 |
| +----LC~~~~+~~~~~+~~~~~+ |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 2 |
| +----LC~~~~+~~~~~+~~~~~+ Field Network |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 1 |
| +----LC~~~~+~~~~~+~~~~~+ +-----------------|
| | | | | | Monitoring Room |
| | Dev Dev Dev | |
| | | BMS HMI |
| | Management Network | | | |
| +--------------------------------+-----+ |
| | |
+--------------------------------------------------+
Figure 5: BAS Deployment Model for Medium/Large Buildings
图5：中型/大型建筑的BAS部署模型
Each LC is connected to the monitoring room via the management network, and the management functions are performed within the building. In most cases, Fast Ethernet (e.g., 100BASE-T) is used for the management network. Since the management network is not a real-time network, the use of Ethernet without QoS is sufficient for today's deployments.
每个LC通过管理网络连接到监控室，管理功能在建筑物内执行。在大多数情况下，管理网络使用快速以太网（如100BASE-T）。由于管理网络不是实时网络，因此在今天的部署中使用没有QoS的以太网就足够了。
Many physical interfaces used in field networks have specific timing requirements -- for example, RS232C and RS485. Thus, if a field network is to be replaced with an Ethernet or wireless network, such networks must support time-critical deterministic flows.
现场网络中使用的许多物理接口都有特定的定时要求，例如RS232C和RS485。因此，如果要用以太网或无线网络替换现场网络，则此类网络必须支持时间关键的确定性流。
Figure 6 shows another deployment model, in which the management system is hosted remotely. This model is becoming popular for small offices and residential buildings, in which a standalone monitoring system is not cost effective.
图6显示了另一个部署模型，其中管理系统是远程托管的。这种模式在小型办公室和住宅建筑中越来越流行，因为在这些建筑中，独立的监控系统并不具有成本效益。
+---------------+
| Remote Center |
| |
| BMS HMI |
+------------------------------------+ | | | |
| Floor 2 | | +---+---+ |
| +----LC~~~~+~~~~~+ Field Network| | | |
| | | | | | Router |
| | Dev Dev | +-------|-------+
| | | |
|--- | ------------------------------| |
| | Floor 1 | |
| +----LC~~~~+~~~~~+ | |
| | | | | |
| | Dev Dev | |
| | | |
| | Management Network | WAN |
| +------------------------Router-------------+
| |
+------------------------------------+
+---------------+
| Remote Center |
| |
| BMS HMI |
+------------------------------------+ | | | |
| Floor 2 | | +---+---+ |
| +----LC~~~~+~~~~~+ Field Network| | | |
| | | | | | Router |
| | Dev Dev | +-------|-------+
| | | |
|--- | ------------------------------| |
| | Floor 1 | |
| +----LC~~~~+~~~~~+ | |
| | | | | |
| | Dev Dev | |
| | | |
| | Management Network | WAN |
| +------------------------Router-------------+
| |
+------------------------------------+
Figure 6: Deployment Model for Small Buildings
图6：小型建筑的部署模型
Some interoperability is possible in today's management networks but is not possible in today's field networks due to their non-IP-based design.
某些互操作性在今天的管理网络中是可能的，但在今天的现场网络中由于其非基于IP的设计而不可能实现。
Below are use cases for environmental monitoring, fire detection, and feedback control, and their implications for field network performance.
以下是环境监测、火灾探测和反馈控制的用例及其对现场网络性能的影响。
The BMS polls each LC at a maximum measurement interval of 100 ms (for example, to draw a historical chart of 1-second granularity with a 10x sampling interval) and then performs the operations as specified by the operator. Each LC needs to measure each of its several hundred sensors once per measurement interval. Latency is not critical in this scenario as long as all sensor value measurements are completed within the measurement interval. Availability is expected to be 99.999%.
BMS以100 ms的最大测量间隔轮询每个LC（例如，以10倍的采样间隔绘制1秒粒度的历史图表），然后执行操作员指定的操作。每个LC需要在每个测量间隔内测量其数百个传感器中的每一个。在这种情况下，只要在测量间隔内完成所有传感器值测量，延迟就不重要。预计可用率为99.999%。
On detection of a fire, the BMS must stop the HVAC, close the fire shutters, turn on the fire sprinklers, send an alarm, etc. There are typically tens of fire sensors per LC that the BMS needs to manage. In this scenario, the measurement interval is 10-50 ms, the communication delay is 10 ms, and the availability must be 99.9999%.
在检测到火灾时，BMS必须停止HVAC、关闭防火百叶窗、打开消防喷头、发出警报等。BMS需要管理的每个LC通常有数十个火灾传感器。在这种情况下，测量间隔为10-50毫秒，通信延迟为10毫秒，可用性必须为99.9999%。
BASs utilize feedback control in various ways; the most time-critical is control of DC motors, which require a short feedback interval (1-5 ms) with low communication delay (10 ms) and jitter (1 ms). The feedback interval depends on the characteristics of the device and on the requirements for the control values. There are typically tens of feedback sensors per LC.
低音以各种方式利用反馈控制；最关键的时间是控制直流电机，这需要一个短的反馈间隔（1-5毫秒），通信延迟（10毫秒）和抖动（1毫秒）。反馈间隔取决于装置的特性和对控制值的要求。每个LC通常有数十个反馈传感器。
Communication delay is expected to be less than 10 ms and jitter less than 1 ms, while the availability must be 99.9999%.
通信延迟预计小于10ms，抖动小于1ms，而可用性必须为99.9999%。
When BAS field networks were developed, it was assumed that the field
networks would always be physically isolated from external networks;
therefore, security was not a concern. In today's world, many BASs
are managed remotely and are thus connected to shared IP networks;
therefore, security is a definite concern. Note, however, that
security features are not currently available in the majority of BAS
field network deployments.
When BAS field networks were developed, it was assumed that the field
networks would always be physically isolated from external networks;
therefore, security was not a concern. In today's world, many BASs
are managed remotely and are thus connected to shared IP networks;
therefore, security is a definite concern. Note, however, that
security features are not currently available in the majority of BAS
field network deployments.
The management network, being an IP-based network, has the protocols available to enable network security, but in practice many BASs do not implement even such available security features as device authentication or encryption for data in transit.
管理网络是基于IP的网络，具有可用于实现网络安全的协议，但在实践中，许多BAS甚至没有实现设备身份验证或传输数据加密等可用的安全功能。
In the future, lower energy consumption and environmental monitoring that is more fine-grained will emerge; these will require more sensors and devices, thus requiring larger and more-complex building networks.
未来，将出现更精细的低能耗和环境监测；这些将需要更多的传感器和设备，因此需要更大、更复杂的建筑网络。
Building networks will be connected to or converged with other networks (enterprise networks, home networks, and the Internet).
建筑网络将与其他网络（企业网络、家庭网络和互联网）连接或聚合。
Therefore, better facilities for network management, control, reliability, and security are critical in order to improve resident and operator convenience and comfort. For example, the ability to
因此，更好的网络管理、控制、可靠性和安全设施对于提高居民和运营商的便利性和舒适性至关重要。例如，能够
monitor and control building devices via the Internet would enable (for example) control of room lights or HVAC from a resident's desktop PC or phone application.
通过互联网监控建筑设备可以（例如）从住户的台式PC或电话应用程序控制室内灯光或HVAC。
The community would like to see an interoperable protocol specification that can satisfy the timing, security, availability, and QoS constraints described above, such that the resulting converged network can replace the disparate field networks. Ideally, this connectivity could extend to the open Internet.
社区希望看到一个可互操作的协议规范，该规范能够满足上述时间、安全性、可用性和QoS约束，从而产生的聚合网络可以取代不同的现场网络。理想情况下，这种连接可以扩展到开放互联网。
This would imply an architecture that can guarantee
这意味着一个架构可以保证
o Low communication delays (from <10 ms to 100 ms in a network of several hundred devices)
o 低通信延迟（在数百台设备组成的网络中，从<10 ms到100 ms）
o Low jitter (<1 ms)
o 低抖动（<1毫秒）
o Tight feedback intervals (1-10 ms)
o 紧密的反馈间隔（1-10毫秒）
o High network availability (up to 99.9999%)
o 高网络可用性（高达99.9999%）
o Availability of network data in disaster scenarios
o 灾难场景中网络数据的可用性
o Authentication between management devices and field devices (both local and remote)
o 管理设备和现场设备（本地和远程）之间的身份验证
o Integrity and data origin authentication of communication data between management devices and field devices
o 管理设备和现场设备之间通信数据的完整性和数据源验证
o Confidentiality of data when communicated to a remote device
o 与远程设备通信时的数据保密性
Wireless networks are useful for industrial applications -- for example, (1) when portable, fast-moving, or rotating objects are involved and (2) for the resource-constrained devices found in the Internet of Things (IoT).
无线网络对于工业应用非常有用——例如，（1）当涉及便携式、快速移动或旋转物体时，（2）对于物联网（IoT）中资源受限的设备。
Such network-connected sensors, actuators, control loops, etc. typically require that the underlying network support real-time QoS, as well as such specific network properties as reliability, redundancy, and security.
此类网络连接的传感器、执行器、控制回路等通常要求底层网络支持实时QoS，以及可靠性、冗余和安全性等特定网络属性。
These networks may also contain very large numbers of devices -- for example, for factories, "big data" acquisition, and the IoT. Given the large numbers of devices installed and the potential pervasiveness of the IoT, this is a huge and very cost-sensitive market such that small cost reductions can save large amounts of money.
这些网络也可能包含大量设备——例如，工厂、“大数据”采集和物联网。考虑到大量设备的安装和物联网的潜在普及性，这是一个巨大且对成本非常敏感的市场，因此小幅度降低成本可以节省大量资金。
Some wireless network technologies support real-time QoS and are thus useful for these kinds of networks, but others do not.
一些无线网络技术支持实时QoS，因此对这类网络很有用，但其他技术则不支持。
This use case focuses on one specific wireless network technology that provides the required deterministic QoS: "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH, where "TSCH" stands for "Time-Slotted Channel Hopping"; see [Arch-for-6TiSCH], [IEEE-802154], and [RFC7554]).
本用例集中于提供所需确定性QoS的一种特定无线网络技术：“IEEE 802.15.4e的TSCH模式上的IPv6”（6TiSCH，其中“TSCH”表示“时隙信道跳频”；请参见[Arch-for-6TiSCH]、[IEEE-802154]和[RFC7554]）。
There are other deterministic wireless buses and networks available today; however, they are incompatible with each other and with IP traffic (for example, see [ISA100] and [WirelessHART]).
今天还有其他确定性无线总线和网络可用；但是，它们彼此不兼容，并且与IP流量不兼容（例如，请参见[ISA100]和[WirelessHART]）。
Thus, the primary goal of this use case is to apply 6TiSCH as a converged IP-based and standards-based wireless network for industrial applications, i.e., to replace multiple proprietary and/or incompatible wireless networking and wireless network management standards.
因此，本用例的主要目标是将6TiSCH应用为工业应用中基于IP和基于标准的融合无线网络，即，取代多个专有和/或不兼容的无线网络和无线网络管理标准。
Today, there are a number of protocols required by 6TiSCH that are still in development. Another goal of this use case is to highlight the ways in which these "missing" protocols share goals in common with DetNet. Thus, it is possible that some of the protocol technology developed for DetNet will also be applicable to 6TiSCH.
今天，6TiSCH需要的许多协议仍在开发中。本用例的另一个目标是强调这些“缺失”协议与DetNet共享目标的方式。因此，为DetNet开发的一些协议技术也可能适用于6DISCH。
These protocol goals are identified here, along with their relationship to DetNet. It is likely that ultimately the resulting protocols will not be identical but will share design principles that contribute to the efficiency of enabling both DetNet and 6TiSCH.
此处确定了这些协议目标及其与DetNet的关系。最终产生的协议可能不完全相同，但将共享有助于实现DetNet和6Disch的效率的设计原则。
One such commonality is that -- although on a different time scale -- in both TSN [IEEE-8021TSNTG] and TSCH, a packet that crosses the network from node to node follows a precise schedule, as does a train that leaves intermediate stations at precise times along its path. This kind of operation reduces collisions, saves energy, and enables engineering of the network for deterministic properties.
其中一个共同点是——尽管在不同的时间尺度上——在TSN[IEEE-8021TSNTG]和TSCH中，从一个节点到另一个节点穿越网络的数据包遵循一个精确的时间表，就像在其路径上的精确时间离开中间站的列车一样。这种操作减少了冲突，节约了能源，并使网络工程具有确定性特性。
Another commonality is remote monitoring and scheduling management of a TSCH network by a Path Computation Element (PCE) and Network Management Entity (NME). The PCE and NME manage timeslots and device resources in a manner that minimizes the interaction with, and the load placed on, resource-constrained devices. For example, a tiny IoT device may have just enough buffers to store one or a few IPv6 packets; it will have limited bandwidth between peers such that it can maintain only a small amount of peer information, and it will not be able to store many packets waiting to be forwarded. It is advantageous, then, for the IoT device to only be required to carry out the specific behavior assigned to it by the PCE and NME (as opposed to maintaining its own IP stack, for example).
另一个共同点是通过路径计算元件（PCE）和网络管理实体（NME）对TSCH网络进行远程监控和调度管理。PCE和NME以最小化与资源受限设备的交互和施加在资源受限设备上的负载的方式管理时隙和设备资源。例如，一个微小的物联网设备可能只有足够的缓冲区来存储一个或几个IPv6数据包；它在节点之间的带宽有限，因此只能维护少量的节点信息，并且不能存储许多等待转发的数据包。因此，仅要求IoT设备执行由PCE和NME分配给它的特定行为是有利的（例如，与维护其自己的IP堆栈相反）。
It is possible that there will be some peer-to-peer communication; for example, the PCE may communicate only indirectly with some devices in order to enable hierarchical configuration of the system.
可能会有一些点对点通信；例如，PCE可以仅间接地与一些设备通信，以便启用系统的分层配置。
6TiSCH depends on [PCE] and [DetNet-Arch].
6Disch取决于[PCE]和[DetNet Arch]。
6TiSCH also depends on the fact that DetNet will maintain consistency with [IEEE-8021TSNTG].
6TiSCH还取决于DetNet将保持与[IEEE-8021TSNTG]的一致性这一事实。
Today, industrial wireless technology ("wireless industrial") is accomplished using multiple deterministic wireless networks that are incompatible with each other and with IP traffic.
今天，工业无线技术（“无线工业”）是通过使用相互不兼容且与IP通信量不兼容的多个确定性无线网络来实现的。
6TiSCH is not yet fully specified, so it cannot be used in today's applications.
6Disch尚未完全指定，因此无法在今天的应用程序中使用。
DetNet and 6TiSCH together can enable converged transport of deterministic and best-effort traffic flows between real-time industrial devices and WANs via IP routing. A high-level view of this type of basic network is shown in Figure 7.
DetNet和6TiSCH可以通过IP路由在实时工业设备和WAN之间实现确定性和尽力而为的流量流的融合传输。这种基本网络的高级视图如图7所示。
---+-------- ............ ------------
| External Network |
| +-----+
+-----+ | NME |
| | LLN Border | |
| | Router +-----+
+-----+
o o o
o o o o
o o LLN o o o
o o o o
o
---+-------- ............ ------------
| External Network |
| +-----+
+-----+ | NME |
| | LLN Border | |
| | Router +-----+
+-----+
o o o
o o o o
o o LLN o o o
o o o o
o
LLN: Low-Power and Lossy Network
LLN：低功耗有损网络
Figure 7: Basic 6TiSCH Network
图7：基本6Disch网络
Figure 8 shows a backbone router federating multiple synchronized 6TiSCH subnets into a single subnet connected to the external network.
图8显示了一个主干路由器，它将多个同步的6Disch子网联合到一个连接到外部网络的子网中。
---+-------- ............ ------------
| External Network |
| +-----+
| +-----+ | NME |
+-----+ | +-----+ | |
| | Router | | PCE | +-----+
| | +--| |
+-----+ +-----+
| |
| Subnet Backbone |
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
o | | Router | | Router | | Router
+-----+ +-----+ +-----+
o o o o o
o o o o o o o o o o o
o o o LLN o o o o
o o o o o o o o o o o o
---+-------- ............ ------------
| External Network |
| +-----+
| +-----+ | NME |
+-----+ | +-----+ | |
| | Router | | PCE | +-----+
| | +--| |
+-----+ +-----+
| |
| Subnet Backbone |
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
o | | Router | | Router | | Router
+-----+ +-----+ +-----+
o o o o o
o o o o o o o o o o o
o o o LLN o o o o
o o o o o o o o o o o o
Figure 8: Extended 6TiSCH Network
图8：扩展的6Disch网络
The backbone router must ensure end-to-end deterministic behavior between the LLN and the backbone. This should be accomplished in conformance with the work done in [DetNet-Arch] with respect to Layer 3 aspects of deterministic networks that span multiple Layer 2 domains.
主干路由器必须确保LLN和主干之间的端到端确定性行为。这应按照[DetNet Arch]中关于跨越多个第2层域的确定性网络的第3层方面所做的工作来完成。
The PCE must compute a deterministic path end to end across the TSCH network and IEEE 802.1 TSN Ethernet backbone, and DetNet protocols are expected to enable end-to-end deterministic forwarding.
PCE必须通过TSCH网络和IEEE 802.1 TSN以太网主干计算端到端的确定性路径，预计DetNet协议将支持端到端的确定性转发。
6TiSCH uses the Automatic Repeat reQuest (ARQ) mechanism [IEEE-802154] to provide higher reliability of packet delivery. ARQ is related to Packet Replication and Elimination (PRE) because there are two independent paths for packets to arrive at the destination. If an expected packet does not arrive on one path, then it checks for the packet on the second path.
6TiSCH使用自动重复请求（ARQ）机制[IEEE-802154]提供更高的数据包传输可靠性。ARQ与数据包复制和消除（PRE）相关，因为数据包到达目的地有两条独立的路径。如果预期的数据包没有到达一条路径，那么它会检查第二条路径上的数据包。
Although to date this mechanism is only used by wireless networks, this technique might be appropriate for DetNet, and aspects of the enabling protocol could therefore be co-developed.
尽管到目前为止，该机制仅用于无线网络，但该技术可能适用于DetNet，因此可以共同开发启用协议的各个方面。
For example, in Figure 9, a track is laid out from a field device in a 6TiSCH network to an IoT gateway that is located on an IEEE 802.1 TSN backbone.
例如，在图9中，从6Disch网络中的现场设备到位于IEEE 802.1 TSN主干上的IoT网关布置轨道。
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track Branch | |
+-------+ +--------+ Subnet Backbone
| |
+--|--+ +--|--+
| | | Backbone | | | Backbone
o | | | Router | | | Router
+--/--+ +--|--+
o / o o---o----/ o
o o---o--/ o o o o o
o \ / o o LLN o
o v <---- Replication
o
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track Branch | |
+-------+ +--------+ Subnet Backbone
| |
+--|--+ +--|--+
| | | Backbone | | | Backbone
o | | | Router | | | Router
+--/--+ +--|--+
o / o o---o----/ o
o o---o--/ o o o o o
o \ / o o LLN o
o v <---- Replication
o
Figure 9: 6TiSCH Network with PRE
图9:6Disch网络与预处理
In ARQ, the replication function in the field device sends a copy of each packet over two different branches, and the PCE schedules each hop of both branches so that the two copies arrive in due time at the gateway. In the case of a loss on one branch, one hopes that the other copy of the packet will still arrive within the allocated time. If two copies make it to the IoT gateway, the elimination function in the gateway ignores the extra packet and presents only one copy to upper layers.
在ARQ中，现场设备中的复制功能通过两个不同的分支发送每个分组的副本，并且PCE调度两个分支的每个跃点，以便两个副本在适当的时间到达网关。在一个分支丢失的情况下，我们希望数据包的另一个副本仍能在分配的时间内到达。如果两个副本到达物联网网关，网关中的消除功能将忽略额外的数据包，并仅向上层提供一个副本。
At each 6TiSCH hop along the track, the PCE may schedule more than one timeslot for a packet, so as to support Layer 2 retries (ARQ).
在沿着轨道的每6跳，PCE可以为分组调度多个时隙，以便支持第2层重试（ARQ）。
At the time of this writing, a deployment's TSCH track does not necessarily support PRE but is systematically multipath. This means that a track is scheduled so as to ensure that each hop has at least two forwarding solutions. The forwarding decision will be to try the preferred solution and use the other solution in the case of Layer 2 transmission failure as detected by ARQ.
在撰写本文时，部署的TSCH跟踪不一定支持PRE，而是系统地支持多路径。这意味着安排一个跟踪，以确保每个跃点至少有两个转发解决方案。转发决策将是在ARQ检测到第2层传输失败的情况下，尝试首选解决方案并使用其他解决方案。
A common feature of 6TiSCH and DetNet is actions taken by a PCE when configuring paths through the network. Specifically, what is needed is a protocol and data model that the PCE will use to get/set the relevant configuration from/to the devices, as well as perform operations on the devices. Specifically, both DetNet and 6TiSCH need to develop a protocol (and associated data model) that the PCE can use to (1) get/set the relevant configuration from/to the devices and (2) perform operations on the devices. These could be initially developed by DetNet, with consideration for their reuse by 6TiSCH. The remainder of this section provides a bit more context from the 6TiSCH side.
6Disch和DetNet的一个共同特征是PCE在配置网络路径时采取的操作。具体而言，需要的是协议和数据模型，PCE将使用该协议和数据模型从设备获取/设置相关配置，以及在设备上执行操作。具体而言，DetNet和6Disch都需要开发协议（和相关数据模型），PCE可以使用该协议（1）从设备获取/设置相关配置，以及（2）在设备上执行操作。这些可由DetNet最初开发，并考虑到6TiSCH的重用。本节的其余部分从第6节提供了更多的上下文。
The 6TiSCH device does not expect to place the request for bandwidth between itself and another device in the network. Rather, an operation control system invoked through a human interface specifies the traffic requirements and the end nodes (in terms of latency and reliability). Based on this information, the PCE must compute a path between the end nodes and provision the network with per-flow state that describes the per-hop operation for a given packet, the corresponding timeslots, the flow identification that enables recognizing that a certain packet belongs to a certain path, etc.
6Disch设备不希望在其自身和网络中的另一个设备之间发出带宽请求。相反，通过人机界面调用的操作控制系统指定了流量需求和终端节点（在延迟和可靠性方面）。基于该信息，PCE必须计算终端节点之间的路径，并向网络提供描述给定分组的每跳操作的每流状态、对应的时隙、能够识别特定分组属于特定路径的流标识等。
For a static configuration that serves a certain purpose for a long period of time, it is expected that a node will be provisioned in one shot with a full schedule, i.e., a schedule that defines the behavior
对于长期服务于特定目的的静态配置，预期节点将以完整的时间表（即定义行为的时间表）一次性供应
of the node with respect to all data flows through that node. 6TiSCH expects that the programming of the schedule will be done over the Constrained Application Protocol (CoAP) as discussed in [CoAP-6TiSCH].
与通过该节点的所有数据流相关的节点。6TiSCH预计该计划的编程将在[CoAP-6TiSCH]中讨论的受限应用协议（CoAP）上完成。
6TiSCH expects that the PCE commands will be mapped back and forth into CoAP by a gateway function at the edge of the 6TiSCH network. For instance, it is possible that a mapping entity on the backbone transforms a non-CoAP protocol such as the Path Computation Element Communication Protocol (PCEP) into the RESTful interfaces that the 6TiSCH devices support. This architecture will be refined to comply with DetNet [DetNet-Arch] when the work is formalized. Related information about 6TiSCH can be found in [Interface-6TiSCH-6top] and [RFC6550] ("RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks").
6TiSCH期望PCE命令通过6TiSCH网络边缘的网关功能前后映射到CoAP中。例如，主干上的映射实体可能将非CoAP协议（如路径计算元素通信协议（PCEP））转换为6TiSCH设备支持的RESTful接口。当工作正式化时，将对该体系结构进行改进，以符合DetNet[DetNet Arch]。有关6TiSCH的相关信息可在[Interface-6TiSCH-6top]和[RFC6550]（“RPL:IPv6低功耗和有损网络路由协议”）中找到。
A protocol may be used to update the state in the devices during runtime -- for example, if it appears that a path through the network has ceased to perform as expected, but in 6TiSCH that flow was not designed and no protocol was selected. DetNet should define the appropriate end-to-end protocols to be used in that case. The implication is that these state updates take place once the system is configured and running, i.e., they are not limited to the initial communication of the configuration of the system.
协议可用于在运行时更新设备中的状态——例如，如果通过网络的路径似乎已停止按预期运行，但在第6节中，未设计流且未选择协议。DetNet应定义在这种情况下使用的适当端到端协议。这意味着一旦系统配置并运行，这些状态更新就会发生，即，它们不限于系统配置的初始通信。
A "slotFrame" is the base object that a PCE would manipulate to program a schedule into an LLN node [Arch-for-6TiSCH].
“slotFrame”是PCE将操纵的基本对象，用于将计划编程到LLN节点[Arch-for-6TiSCH]中。
The PCE should read energy data from devices and compute paths that will implement policies on how energy in devices is consumed -- for instance, to ensure that the spent energy does not exceed the available energy over a period of time. Note that this statement implies that an extensible protocol for communicating device information to the PCE and enabling the PCE to act on it will be part of the DetNet architecture; however, for subnets with specific protocols (e.g., CoAP), a gateway may be required.
PCE应从设备中读取能量数据，并计算路径，以实施有关设备中能量消耗方式的策略，例如，确保在一段时间内，消耗的能量不会超过可用能量。注意，该语句意味着用于将设备信息传送到PCE并使PCE能够对其进行操作的可扩展协议将是DetNet架构的一部分；但是，对于具有特定协议（如CoAP）的子网，可能需要网关。
6TiSCH devices can discover their neighbors over the radio using a mechanism such as beacons, but even though the neighbor information is available in the 6TiSCH interface data model, 6TiSCH does not describe a protocol to proactively push the neighbor information to a PCE. DetNet should define such a protocol; one possible design alternative is that it could operate over CoAP. Alternatively, it could be converted to/from CoAP by a gateway. Such a protocol could carry multiple metrics -- for example, metrics similar to those used for RPL operations [RFC6551].
6TiSCH设备可以使用诸如信标之类的机制通过无线电发现它们的邻居，但是即使邻居信息在6TiSCH接口数据模型中可用，6TiSCH也没有描述将邻居信息主动推送到PCE的协议。DetNet应该定义这样一个协议；一种可能的设计方案是，它可以在CoAP上运行。或者，它可以通过网关转换为CoAP或从CoAP转换为CoAP。这样的协议可以携带多个度量——例如，与RPL操作使用的度量相似的度量[RFC6551]。
Protocol translation between the TSCH MAC layer and IP is accomplished via the "6top" sublayer [Sublayer-6TiSCH-6top]. The 6top data model and management interfaces are further discussed in [Interface-6TiSCH-6top] and [CoAP-6TiSCH].
TSCH MAC层和IP之间的协议转换通过“6top”子层[sublayer-6TiSCH-6top]完成。[Interface-6TiSCH-6top]和[CoAP-6TiSCH]进一步讨论了6top数据模型和管理接口。
An IP packet that is sent along a 6TiSCH path uses a differentiated services Per-Hop Behavior Group (PHB) called "deterministic forwarding", as described in [Det-Fwd-PHB].
沿6Disch路径发送的IP数据包使用称为“确定性转发”的每跳区分服务行为组（PHB），如[Det Fwd PHB]中所述。
In addition to the classical requirements for protection of control signaling, it must be noted that 6TiSCH networks operate on limited resources that can be depleted rapidly in a DoS attack on the system -- for instance, by placing a rogue device in the network or by obtaining management control and setting up unexpected additional paths.
除了保护控制信令的经典要求外，必须注意的是，6Disk网络在有限的资源上运行，这些资源在系统遭受DoS攻击时会迅速耗尽，例如，通过在网络中放置恶意设备，或通过获得管理控制和设置意外的额外路径。
6TiSCH depends on DetNet to define:
6Disch依赖DetNet来定义：
o Configuration (state) and operations for deterministic paths
o 确定性路径的配置（状态）和操作
o End-to-end protocols for deterministic forwarding (tagging, IP)
o 用于确定性转发的端到端协议（标签、IP）
o A protocol for PRE
o 预处理协议
This use case describes the application of deterministic networking in the context of cellular telecom transport networks. Important elements include time synchronization, clock distribution, and ways to establish time-sensitive streams for both Layer 2 and Layer 3 user-plane traffic.
本用例描述了确定性网络在蜂窝电信传输网络环境中的应用。重要的元素包括时间同步、时钟分布以及为第2层和第3层用户平面流量建立时间敏感流的方法。
Figure 10 illustrates a 3GPP-defined cellular network architecture typical at the time of this writing. The architecture includes "Fronthaul", "Midhaul", and "Backhaul" network segments. The "Fronthaul" is the network connecting base stations (Baseband Units (BBUs)) to the Remote Radio Heads (RRHs) (also referred to here as "antennas"). The "Midhaul" is the network that interconnects base
图10说明了撰写本文时典型的3GPP定义的蜂窝网络架构。该体系结构包括“前程”、“中程”和“回程”网段。“Fronthaul”是将基站（基带单元（BBU））连接到远程无线电头（RRH）（这里也称为“天线”）的网络。“中程”是一个连接基础设施的网络
stations (or small-cell sites). The "Backhaul" is the network or links connecting the radio base station sites to the network controller/gateway sites (i.e., the core of the 3GPP cellular network).
站点（或小蜂窝站点）。“回程”是将无线基站站点连接到网络控制器/网关站点（即，3GPP蜂窝网络的核心）的网络或链路。
Y (RRHs (antennas))
\
Y__ \.--. .--. +------+
\_( `. +---+ _( `. | 3GPP |
Y------( Front- )----|eNB|----( Back- )------| core |
( ` .haul ) +---+ ( ` .haul) ) | netw |
/`--(___.-' \ `--(___.-' +------+
Y_/ / \.--. \
Y_/ _(Mid-`. \
( haul ) \
( ` . ) ) \
`--(___.-'\_____+---+ (small-cell sites)
\ |SCe|__Y
+---+ +---+
Y__|eNB|__Y
+---+
Y_/ \_Y ("local" radios)
Y (RRHs (antennas))
\
Y__ \.--. .--. +------+
\_( `. +---+ _( `. | 3GPP |
Y------( Front- )----|eNB|----( Back- )------| core |
( ` .haul ) +---+ ( ` .haul) ) | netw |
/`--(___.-' \ `--(___.-' +------+
Y_/ / \.--. \
Y_/ _(Mid-`. \
( haul ) \
( ` . ) ) \
`--(___.-'\_____+---+ (small-cell sites)
\ |SCe|__Y
+---+ +---+
Y__|eNB|__Y
+---+
Y_/ \_Y ("local" radios)
Figure 10: Generic 3GPP-Based Cellular Network Architecture
图10：基于3GPP的通用蜂窝网络架构
In Figure 10, "eNB" ("E-UTRAN Node B") is the hardware that is connected to the mobile phone network and enables the mobile phone network to communicate with mobile handsets [TS36300]. ("E-UTRAN" stands for "Evolved Universal Terrestrial Radio Access Network".)
在图10中，“eNB”（“E-UTRAN节点B”）是连接到移动电话网络并使移动电话网络能够与移动电话通信的硬件[TS36300]。（“E-UTRAN”代表“演进的通用地面无线电接入网络”。）
The available processing time for Fronthaul networking overhead is limited to the available time after the baseband processing of the radio frame has completed. For example, in Long Term Evolution (LTE) radio, 3 ms is allocated for the processing of a radio frame, but typically the baseband processing uses most of it, allowing only a small fraction to be used by the Fronthaul network. In this example, out of 3 ms, the maximum time allocated to the Fronthaul network for one-way delay is 250 us, and the existing specification [NGMN-Fronth] specifies a maximum delay of only 100 us. This ultimately determines the distance the RRHs can be located from the base stations (e.g., 100 us equals roughly 20 km of optical fiber-based transport). Allocation options regarding the available time budget between processing and transport are currently undergoing heavy discussion in the mobile industry.
Fronthaul网络开销的可用处理时间限于无线电帧的基带处理完成后的可用时间。例如，在长期演进（LTE）无线电中，3ms被分配用于无线电帧的处理，但通常基带处理使用其中的大部分，仅允许一小部分被前长途网络使用。在此示例中，在3 ms中，分配给Fronthaul网络的单向延迟的最大时间为250 us，而现有规范[NGMN Fronth]规定的最大延迟仅为100 us。这最终决定了RRH与基站之间的距离（例如，100 us相当于大约20 km的光纤传输）。关于处理和传输之间可用时间预算的分配选项目前正在移动行业中进行大量讨论。
For packet-based transport, the allocated transport time between the RRH and the BBU is consumed by node processing, buffering, and distance-incurred delay. An example of the allocated transport time is 100 us (from the Common Public Radio Interface [CPRI]).
对于基于分组的传输，RRH和BBU之间分配的传输时间由节点处理、缓冲和距离延迟消耗。分配的传输时间的示例为100 us（来自公共无线电接口[CPRI]）。
The baseband processing time and the available "delay budget" for the Fronthaul is likely to change in the forthcoming "5G" due to reduced radio round-trip times and other architectural and service requirements [NGMN].
由于无线电往返时间减少以及其他架构和服务要求[NGMN]，在即将到来的“5G”中，前端传输的基带处理时间和可用的“延迟预算”可能会发生变化。
The transport time budget, as noted above, places limitations on the distance that RRHs can be located from base stations (i.e., the link length). In the above analysis, it is assumed that the entire transport time budget is available for link propagation delay. However, the transport time budget can be broken down into three components: scheduling/queuing delay, transmission delay, and link propagation delay. Using today's Fronthaul networking technology, the queuing, scheduling, and transmission components might become the dominant factors in the total transport time, rather than the link propagation delay. This is especially true in cases where the Fronthaul link is relatively short and is shared among multiple Fronthaul flows -- for example, in indoor and small-cell networks, massive Multiple Input Multiple Output (MIMO) antenna networks, and split Fronthaul architectures.
如上所述，传输时间预算限制了RRH与基站之间的距离（即链路长度）。在上述分析中，假设整个传输时间预算可用于链路传播延迟。然而，传输时间预算可分为三个部分：调度/排队延迟、传输延迟和链路传播延迟。使用当今的前端网络技术，排队、调度和传输组件可能成为总传输时间的主要因素，而不是链路传播延迟。这尤其适用于前端链路相对较短且在多个前端流之间共享的情况——例如，在室内和小蜂窝网络、大规模多输入多输出（MIMO）天线网络和分体式前端结构中。
DetNet technology can improve Fronthaul networks by controlling and reducing the time required for the queuing, scheduling, and transmission operations by properly assigning network resources, thus (1) leaving more of the transport time budget available for link propagation and (2) enabling longer link lengths. However, link length is usually a predetermined parameter and is not a controllable network parameter, since RRH and BBU sites are usually located in predetermined locations. However, the number of antennas in an RRH site might increase -- for example, by adding more antennas, increasing the MIMO capability of the network, or adding support for massive MIMO. This means increasing the number of Fronthaul flows sharing the same Fronthaul link. DetNet can now control the bandwidth assignment of the Fronthaul link and the scheduling of Fronthaul packets over this link and can provide adequate buffer provisioning for each flow to reduce the packet loss rate.
DetNet技术可以通过适当分配网络资源来控制和减少排队、调度和传输操作所需的时间，从而改善前线运输网络，从而（1）为链路传播留出更多的传输时间预算；（2）实现更长的链路长度。然而，链路长度通常是预定参数，并且不是可控网络参数，因为RRH和BBU站点通常位于预定位置。然而，RRH站点中的天线数量可能会增加——例如，通过添加更多天线、增加网络的MIMO能力或增加对大规模MIMO的支持。这意味着增加共享同一Fronthaul链接的Fronthaul流的数量。DetNet现在可以控制Fronthaul链路的带宽分配和该链路上Fronthaul数据包的调度，并且可以为每个流提供足够的缓冲区以降低数据包丢失率。
Another way in which DetNet technology can aid Fronthaul networks is by providing effective isolation between flows -- for example, between flows originating in different slices within a network-sliced 5G network. Note, however, that this isolation applies to DetNet flows for which resources have been preallocated, i.e., it does not apply to best-effort flows within a DetNet. DetNet technology can also dynamically control the bandwidth-assignment, scheduling, and
DetNet技术可以帮助Fronthaul网络的另一种方式是在流之间提供有效的隔离——例如，在网络切片5G网络中源自不同切片的流之间。但是，请注意，这种隔离适用于已预分配资源的DetNet流，即，它不适用于DetNet内的尽力而为流。DetNet技术还可以动态控制带宽分配、调度和分配
packet-forwarding decisions, as well as the buffer provisioning of the Fronthaul flows to guarantee the end-to-end delay of the Fronthaul packets and minimize the packet loss rate.
数据包转发决策，以及前端传输流的缓冲区供应，以保证前端传输数据包的端到端延迟，并将数据包丢失率降至最低。
[METIS] documents the fundamental challenges as well as overall technical goals of the future 5G mobile and wireless systems as the starting point. These future systems should support much higher data volumes and rates and significantly lower end-to-end latency for 100x more connected devices (at cost and energy-consumption levels similar to today's systems).
[METIS]记录了未来5G移动和无线系统的基本挑战和总体技术目标，作为起点。这些未来的系统应支持更高的数据量和速率，并大大降低100倍以上连接设备的端到端延迟（成本和能耗水平与今天的系统类似）。
For Midhaul connections, delay constraints are driven by inter-site radio functions such as Coordinated Multi-Point (CoMP) processing (see [CoMP]). CoMP reception and transmission constitute a framework in which multiple geographically distributed antenna nodes cooperate to improve performance for the users served in the common cooperation area. The design principle of CoMP is to extend single-cell-to-multi-UE (User Equipment) transmission to a multi-cell-to-multi-UE transmission via cooperation among base stations.
对于长途连接，延迟约束由站点间无线电功能驱动，如协调多点（CoMP）处理（参见[CoMP]）。CoMP接收和传输构成了一个框架，在该框架中，多个地理上分布的天线节点协作以提高在公共协作区域中服务的用户的性能。CoMP的设计原理是通过基站间的协作，将单小区到多UE（用户设备）的传输扩展到多小区到多UE的传输。
CoMP has delay-sensitive performance parameters: "Midhaul latency" and "CSI (Channel State Information) reporting and accuracy". The essential feature of CoMP is signaling between eNBs, so Midhaul latency is the dominating limitation of CoMP performance. Generally, CoMP can benefit from coordinated scheduling (either distributed or centralized) of different cells if the signaling delay between eNBs is within 1-10 ms. This delay requirement is both rigid and absolute, because any uncertainty in delay will degrade performance significantly.
CoMP具有对延迟敏感的性能参数：“长途延迟”和“CSI（信道状态信息）报告和准确性”。CoMP的基本特征是enb之间的信令，因此中程延迟是CoMP性能的主要限制。通常，如果enb之间的信令延迟在1-10ms内，CoMP可以从不同小区的协调调度（分布式或集中式）中获益。这种延迟要求既严格又绝对，因为延迟中的任何不确定性都会显著降低性能。
Inter-site CoMP is one of the key requirements for 5G and is also a goal for 4.5G network architectures.
站点间CoMP是5G的关键要求之一，也是4.5G网络架构的目标。
Fronthaul time-synchronization requirements are given by [TS25104], [TS36104], [TS36211], and [TS36133]. These can be summarized for the 3GPP LTE-based networks as:
[TS25104]、[TS36104]、[TS36211]和[TS36133]给出了前方运输时间同步要求。对于基于3GPP LTE的网络，这些可以概括为：
Delay accuracy: +-8 ns (i.e., +-1/32 Tc, where Tc is the Universal Mobile Telecommunications System (UMTS) Chip time of 1/3.84 MHz), resulting in a round-trip accuracy of +-16 ns. The value is this low in order to meet the 3GPP Timing Alignment Error (TAE) measurement requirements. Note that performance guarantees of low-nanosecond values such as these are considered to be below the DetNet layer -- it is assumed that the underlying implementation (e.g., the hardware) will provide sufficient support (e.g.,
延迟精度：+-8纳秒（即+-1/32 Tc，其中Tc是通用移动通信系统（UMTS）芯片时间的1/3.84 MHz），因此往返精度为+-16纳秒。该值如此低，以满足3GPP定时对准误差（TAE）测量要求。请注意，低纳秒值的性能保证（如这些）被视为低于DetNet层——假定底层实现（如硬件）将提供足够的支持（如：。，
buffering) to enable this level of accuracy. These values are maintained in the use case to give an indication of the overall application.
缓冲）以实现此精度级别。这些值在用例中保持，以给出整个应用的指示。
TAE: TAE is problematic for Fronthaul networks and must be minimized. If the transport network cannot guarantee TAE levels that are low enough, then additional buffering has to be introduced at the edges of the network to buffer out the jitter. Buffering is not desirable, as it reduces the total available delay budget.
TAE:TAE对于前线运输网络是有问题的，必须最小化。如果传输网络不能保证TAE水平足够低，那么必须在网络边缘引入额外的缓冲来缓冲抖动。缓冲是不可取的，因为它会减少总的可用延迟预算。
Packet Delay Variation (PDV) requirements can be derived from TAE measurements for packet-based Fronthaul networks.
数据包延迟变化（PDV）要求可以从基于数据包的长途网络的TAE测量中得出。
* For MIMO or TX diversity transmissions, at each carrier frequency, TAE measurements shall not exceed 65 ns (i.e., 1/4 Tc).
* 对于MIMO或TX分集传输，在每个载波频率下，TAE测量值不得超过65 ns（即1/4 Tc）。
* For intra-band contiguous carrier aggregation, with or without MIMO or TX diversity, TAE measurements shall not exceed 130 ns (i.e., 1/2 Tc).
* 对于带内连续载波聚合，无论有无MIMO或TX分集，TAE测量值不得超过130 ns（即1/2 Tc）。
* For intra-band non-contiguous carrier aggregation, with or without MIMO or TX diversity, TAE measurements shall not exceed 260 ns (i.e., 1 Tc).
* 对于带内非连续载波聚合，无论有无MIMO或TX分集，TAE测量值不得超过260 ns（即1 Tc）。
* For inter-band carrier aggregation, with or without MIMO or TX diversity, TAE measurements shall not exceed 260 ns.
* 对于带间载波聚合，无论有无MIMO或TX分集，TAE测量值不得超过260 ns。
Transport link contribution to radio frequency errors: +-2 PPB. This value is considered to be "available" for the Fronthaul link out of the total 50 PPB budget reserved for the radio interface. Note that the transport link contributes to radio frequency errors for the following reason: at the time of this writing, Fronthaul communication is direct communication from the radio unit to the RRH. The RRH is essentially a passive device (e.g., without buffering). The transport drives the antenna directly by feeding it with samples, and everything the transport adds will be introduced to the radio "as is". So, if the transport causes any additional frequency errors, the errors will show up immediately on the radio as well. Note that performance guarantees of low-nanosecond values such as these are considered to be below the DetNet layer -- it is assumed that the underlying implementation (e.g., the hardware) will provide sufficient support to enable this level of performance. These values are maintained in the use case to give an indication of the overall application.
传输链路对射频错误的影响：+-2 PPB。在为无线电接口预留的总50 PPB预算中，该值被视为“可用”用于前长途链路。请注意，传输链路导致射频错误的原因如下：在撰写本文时，Fronthaul通信是从无线电单元到RRH的直接通信。RRH本质上是一个无源设备（例如，没有缓冲）。传输装置通过向天线馈送样本直接驱动天线，传输装置添加的所有内容都将“按原样”引入无线电。因此，如果传输导致任何额外的频率错误，这些错误也会立即出现在收音机上。请注意，低纳秒值（如这些）的性能保证被视为低于DetNet层——假定底层实现（如硬件）将提供足够的支持，以实现此级别的性能。这些值在用例中保持，以给出整个应用的指示。
The above-listed time-synchronization requirements are difficult to meet with point-to-point connected networks and are more difficult to meet when the network includes multiple hops. It is expected that networks must include buffering at the ends of the connections as imposed by the jitter requirements, since trying to meet the jitter requirements in every intermediate node is likely to be too costly. However, every measure to reduce jitter and delay on the path makes it easier to meet the end-to-end requirements.
以上列出的时间同步要求在点到点连接的网络中很难满足，并且在网络包括多个跃点时更难满足。预计网络必须包括由抖动要求施加的连接端的缓冲，因为在每个中间节点中尝试满足抖动要求可能代价太高。然而，每一种减少路径抖动和延迟的措施都使其更容易满足端到端的要求。
In order to meet the timing requirements, both senders and receivers must remain time synchronized, demanding very accurate clock distribution -- for example, support for IEEE 1588 transparent clocks or boundary clocks in every intermediate node.
为了满足定时要求，发送方和接收方必须保持时间同步，要求非常精确的时钟分布——例如，在每个中间节点中支持IEEE 1588透明时钟或边界时钟。
In cellular networks from the LTE radio era onward, phase synchronization is needed in addition to frequency synchronization [TS36300] [TS23401]. Time constraints are also important due to their impact on packet loss. If a packet is delivered too late, then the packet may be dropped by the host.
在LTE无线电时代以后的蜂窝网络中，除了频率同步之外，还需要相位同步[TS36300][TS23401]。时间限制也很重要，因为它们会影响数据包丢失。如果数据包传递太晚，则主机可能会丢弃该数据包。
Fronthaul and Midhaul networks assume that transport is almost error free. Errors can cause a reset of the radio interfaces, in turn causing reduced throughput or broken radio connectivity for mobile customers.
前端和中端网络假定传输几乎没有错误。错误可能导致无线电接口重置，进而导致移动客户的吞吐量降低或无线电连接中断。
For packetized Fronthaul and Midhaul connections, packet loss may be caused by BER, congestion, or network failure scenarios. Different Fronthaul "functional splits" are being considered by 3GPP, requiring strict Frame Loss Ratio (FLR) guarantees. As one example (referring to the legacy CPRI split, which is option 8 in 3GPP), lower-layer splits may imply an FLR of less than 10^-7 for data traffic and less than 10^-6 for control and management traffic.
对于分组化的前长途和中长途连接，分组丢失可能是由误码率、拥塞或网络故障情况引起的。3GPP正在考虑不同的前向传输“功能分割”，需要严格的帧丢失率（FLR）保证。作为一个示例（参考传统CPRI分割，它是3GPP中的选项8），较低层分割可能意味着对于数据业务小于10^-7，对于控制和管理业务小于10^-6的FLR。
Many of the tools available for eliminating packet loss for Fronthaul and Midhaul networks have serious challenges; for example, retransmitting lost packets or using FEC to circumvent bit errors (or both) is practically impossible, due to the additional delay incurred. Using redundant streams for better guarantees of delivery is also practically impossible in many cases, due to high bandwidth requirements for Fronthaul and Midhaul networks. Protection switching is also a candidate, but at the time of this writing, available technologies for the path switch are too slow to avoid a reset of mobile interfaces.
许多可用于消除前端和中端网络丢包的工具都面临着严峻的挑战；例如，由于产生的额外延迟，重新传输丢失的数据包或使用FEC规避位错误（或两者）实际上是不可能的。由于前端和中端网络的高带宽要求，在许多情况下，使用冗余流来更好地保证传输几乎是不可能的。保护切换也是一个候选，但在撰写本文时，路径切换的可用技术太慢，无法避免移动接口的重置。
It is assumed that Fronthaul links are symmetric. All Fronthaul streams (i.e., those carrying radio data) have equal priority and cannot delay or preempt each other.
假定前向调土连接是对称的。所有前端传输流（即，承载无线电数据的流）具有相同的优先级，不能相互延迟或抢占。
All of this implies that it is up to the network to guarantee that each time-sensitive flow meets its schedule.
所有这一切都意味着，由网络来保证每个时间敏感流满足其时间表。
Establishing time-sensitive streams in the network entails reserving networking resources for long periods of time. It is important that these reservation requests be authenticated to prevent malicious reservation attempts from hostile nodes (or accidental misconfiguration). This is particularly important in the case where the reservation requests span administrative domains. Furthermore, the reservation information itself should be digitally signed to reduce the risk of a legitimate node pushing a stale or hostile configuration into another networking node.
在网络中建立时间敏感流需要长时间保留网络资源。必须对这些保留请求进行身份验证，以防止恶意节点的恶意保留尝试（或意外错误配置）。这在保留请求跨越管理域的情况下尤为重要。此外，应该对保留信息本身进行数字签名，以降低合法节点将过时或恶意配置推入另一个网络节点的风险。
Note: This is considered important for the security policy of the network but does not affect the core DetNet architecture and design.
注：这对网络安全策略很重要，但不影响核心DetNet架构和设计。
Today's Fronthaul networks typically consist of:
今天的前端运输网络通常包括：
o Dedicated point-to-point fiber connection (common)
o 专用点对点光纤连接（通用）
o Proprietary protocols and framings
o 专有协议和框架
o Custom equipment and no real networking
o 定制设备，没有真正的网络
At the time of this writing, solutions for Fronthaul are direct optical cables or Wavelength-Division Multiplexing (WDM) connections.
在撰写本文时，Fronthaul的解决方案是直接光缆或波分复用（WDM）连接。
Today's Midhaul and Backhaul networks typically consist of:
今天的中长途和回程网络通常包括：
o Mostly normal IP networks, MPLS-TP, etc.
o 主要是普通IP网络、MPLS-TP等。
o Clock distribution and synchronization using IEEE 1588 and syncE
o 使用IEEE 1588和syncE的时钟分配和同步
Telecommunications networks in the Midhaul and Backhaul are already heading towards transport networks where precise time-synchronization support is one of the basic building blocks. In order to meet
中长途和回程的电信网络已经朝着传输网络的方向发展，在传输网络中，精确的时间同步支持是基本的构建模块之一。为了满足
bandwidth and cost requirements, most transport networks have already transitioned to all-IP packet-based networks; however, highly accurate clock distribution has become a challenge.
由于带宽和成本的要求，大多数传输网络已经过渡到所有基于IP分组的网络；然而，高精度的时钟分配已经成为一个挑战。
In the past, Midhaul and Backhaul connections were typically based on TDM and provided frequency-synchronization capabilities as a part of the transport media. More recently, other technologies such as GPS or syncE [syncE] have been used.
过去，中程和回程连接通常基于TDM，并作为传输介质的一部分提供频率同步功能。最近，还使用了其他技术，如GPS或syncE[syncE]。
Ethernet, IP/MPLS [RFC3031], and pseudowires (as described in
[RFC3985] ("Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture")
for legacy transport support)) have become popular tools for building
and managing new all-IP Radio Access Networks (RANs)
[SR-IP-RAN-Use-Case]. Although various timing and synchronization
optimizations have already been proposed and implemented, including
PTP enhancements [IEEE-1588] (see also [Timing-over-MPLS] and
[RFC8169]), these solutions are not necessarily sufficient for the
forthcoming RAN architectures, nor do they guarantee the more
stringent time-synchronization requirements such as [CPRI].
Ethernet, IP/MPLS [RFC3031], and pseudowires (as described in
[RFC3985] ("Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture")
for legacy transport support)) have become popular tools for building
and managing new all-IP Radio Access Networks (RANs)
[SR-IP-RAN-Use-Case]. Although various timing and synchronization
optimizations have already been proposed and implemented, including
PTP enhancements [IEEE-1588] (see also [Timing-over-MPLS] and
[RFC8169]), these solutions are not necessarily sufficient for the
forthcoming RAN architectures, nor do they guarantee the more
stringent time-synchronization requirements such as [CPRI].
Existing solutions for TDM over IP include those discussed in [RFC4553], [RFC5086], and [RFC5087]; [MEF8] addresses TDM over Ethernet transports.
现有的IP TDM解决方案包括[RFC4553]、[RFC5086]和[RFC5087]中讨论的解决方案；[MEF8]通过以太网传输解决TDM问题。
Future cellular radio networks will be based on a mix of different xHaul networks (xHaul = Fronthaul, Midhaul, and Backhaul), and future transport networks should be able to support all of them simultaneously. It is already envisioned today that:
未来的蜂窝无线网络将基于不同的xHaul网络（xHaul=前程、中程和回程）的混合，未来的传输网络应该能够同时支持所有这些网络。今天已经预见到：
o Not all "cellular radio network" traffic will be IP; for example, some will remain at Layer 2 (e.g., Ethernet based). DetNet solutions must address all traffic types (Layer 2 and Layer 3) with the same tools and allow their transport simultaneously.
o 并非所有的“蜂窝无线网络”通信都是IP；例如，一些将保留在第2层（例如，基于以太网）。DetNet解决方案必须使用相同的工具处理所有流量类型（第2层和第3层），并允许其同时传输。
o All types of xHaul networks will need some types of DetNet solutions. For example, with the advent of 5G, some Backhaul traffic will also have DetNet requirements (for example, traffic belonging to time-critical 5G applications).
o 所有类型的xHaul网络都需要某些类型的DetNet解决方案。例如，随着5G的出现，一些回程流量也将有DetNet要求（例如，属于时间关键型5G应用的流量）。
o Different functional splits between the base stations and the on-site units could coexist on the same Fronthaul and Backhaul network.
o 基站和现场设备之间的不同功能划分可以在同一前程和回程网络上共存。
Future cellular radio networks should contain the following:
未来的蜂窝无线网络应包含以下内容：
o Unified standards-based transport protocols and standard networking equipment that can make use of underlying deterministic link-layer services
o 基于统一标准的传输协议和标准网络设备，可利用底层确定性链路层服务
o Unified and standards-based network management systems and protocols in all parts of the network (including Fronthaul)
o 网络所有部分（包括Fronthaul）的统一和基于标准的网络管理系统和协议
New RAN deployment models and architectures may require TSN services with strict requirements on other parts of the network that previously were not considered to be packetized at all. Time and synchronization support are already topical for Backhaul and Midhaul packet networks [MEF22.1.1] and are also becoming a real issue for Fronthaul networks. Specifically, in Fronthaul networks, the timing and synchronization requirements can be extreme for packet-based technologies -- for example, on the order of a PDV of +-20 ns or less and frequency accuracy of +-0.002 PPM [Fronthaul].
新的RAN部署模型和体系结构可能需要TSN服务，对网络的其他部分有严格的要求，这些部分以前根本不被认为是打包的。时间和同步支持已经成为回程和中程分组网络[MEF22.1.1]的热门话题，并且也正在成为前程网络的一个实际问题。具体地说，在Fronthaul网络中，基于分组的技术的定时和同步要求可能是极端的——例如，PDV为+-20 ns或更小，频率精度为+-0.002 PPM[Fronthaul]。
The actual transport protocols and/or solutions for establishing required transport "circuits" (pinned-down paths) for Fronthaul traffic are still undefined. Those protocols are likely to include (but are not limited to) solutions directly over Ethernet, over IP, and using MPLS/pseudowire transport.
为前线运输建立所需运输“线路”（固定路径）的实际运输协议和/或解决方案仍不明确。这些协议可能包括（但不限于）直接通过以太网、IP和使用MPLS/伪线传输的解决方案。
Interesting and important work for TSN has been done for Ethernet [IEEE-8021TSNTG]; this work specifies the use of PTP [IEEE-1588] in the context of IEEE 802.1D and IEEE 802.1Q. [IEEE-8021AS] specifies a Layer 2 time-synchronizing service, and other specifications such as IEEE 1722 [IEEE-1722] specify Ethernet-based Layer 2 transport for time-sensitive streams.
针对以太网[IEEE-8021TSNTG]的TSN已经完成了有趣而重要的工作；本工作规定了PTP[IEEE-1588]在IEEE 802.1D和IEEE 802.1Q上下文中的使用。[IEEE-8021AS]指定了第2层时间同步服务，而其他规范，如IEEE 1722[IEEE-1722]指定了基于以太网的时间敏感流第2层传输。
However, even these Ethernet TSN features may not be sufficient for Fronthaul traffic. Therefore, having specific profiles that take Fronthaul requirements into account is desirable [IEEE-8021CM].
然而，即使这些以太网TSN功能也可能不足以满足前端长途通信。因此，需要考虑到前端运输要求的特定剖面[IEEE-8021CM]。
New promising work seeks to enable the transport of time-sensitive Fronthaul streams in Ethernet bridged networks [IEEE-8021CM]. Analogous to IEEE 1722, standardization efforts in the IEEE 1914.3 Task Force [IEEE-19143] to define the Layer 2 transport encapsulation format for transporting Radio over Ethernet (RoE) are ongoing.
新的有希望的工作寻求在以太网桥接网络中实现对时间敏感的前端传输流[IEEE-8021CM]。与IEEE 1722类似，IEEE 1914.3工作组[IEEE-19143]正在进行标准化工作，以定义通过以太网传输无线电（RoE）的第2层传输封装格式。
As mentioned in Section 6.1.2, 5G communications will provide one of the most challenging cases for delay-sensitive networking. In order to meet the challenges of ultra-low latency and ultra-high throughput, 3GPP has studied various functional splits for 5G, i.e., physical decomposition of the 5G "gNodeB" base station and deployment of its functional blocks in different locations [TR38801].
如第6.1.2节所述，5G通信将成为延迟敏感网络最具挑战性的案例之一。为了应对超低延迟和超高吞吐量的挑战，3GPP研究了5G的各种功能划分，即5G“gNodeB”基站的物理分解及其功能块在不同位置的部署[TR38801]。
These splits are numbered from split option 1 (dual connectivity, a split in which the radio resource control is centralized and other radio stack layers are in distributed units) to split option 8 (a PHY-RF split in which RF functionality is in a distributed unit and the rest of the radio stack is in the centralized unit), with each intermediate split having its own data-rate and delay requirements. Packetized versions of different splits have been proposed, including enhanced CPRI (eCPRI) [eCPRI] and RoE (as previously noted). Both provide Ethernet encapsulations, and eCPRI is also capable of IP encapsulation.
这些拆分从拆分选项1（双连接，其中无线电资源控制集中，其他无线电堆栈层位于分布式单元中的拆分）到拆分选项8（其中射频功能位于分布式单元中，其余无线电堆栈位于集中单元中的PHY-RF拆分）进行编号，每个中间拆分都有自己的数据速率和延迟要求。已经提出了不同拆分的打包版本，包括增强型CPRI（eCPRI）[eCPRI]和RoE（如前所述）。两者都提供以太网封装，eCPRI也能够进行IP封装。
All-IP RANs and xHaul networks would benefit from time synchronization and time-sensitive transport services. Although Ethernet appears to be the unifying technology for the transport, there is still a disconnect when it comes to providing Layer 3 services. The protocol stack typically has a number of layers below Ethernet Layer 2 that might be "visible" to Layer 3. In a fairly common scenario, on top of the lowest-layer (optical) transport is the first (lowest) Ethernet layer, then one or more layers of MPLS, pseudowires, and/or other tunneling protocols, and finally one or more Ethernet layers that are visible to Layer 3.
所有IP RAN和xHaul网络都将受益于时间同步和时间敏感的传输服务。尽管以太网似乎是统一的传输技术，但在提供第3层服务时，仍然存在脱节。协议栈通常在以太网第2层下面有许多层，第3层可能“可见”。在一个相当常见的场景中，在最低层（光）传输的顶部是第一（最低）以太网层，然后是一个或多个MPLS、伪线和/或其他隧道协议层，最后是一个或多个对第3层可见的以太网层。
Although there exist technologies for establishing circuits through the routed and switched networks (especially in the MPLS/PWE space), there is still no way to signal the time-synchronization and time-sensitive stream requirements/reservations for Layer 3 flows in a way that addresses the entire transport stack, including the Ethernet layers that need to be configured.
尽管存在通过路由和交换网络（特别是在MPLS/PWE空间中）建立电路的技术，但仍然无法以解决整个传输堆栈的方式发出第3层流的时间同步和时间敏感流要求/保留的信号，包括需要配置的以太网层。
Furthermore, not all "user-plane" traffic will be IP. Therefore, the solution in question also must address the use cases where the user-plane traffic is on a different layer (for example, Ethernet frames).
此外，并非所有“用户平面”流量都是IP。因此，所讨论的解决方案还必须解决用户平面流量位于不同层（例如，以太网帧）的用例。
A standard for data-plane transport specifications that is:
数据平面传输规范的标准，即：
o Unified among all xHauls (meaning that different flows with diverse DetNet requirements can coexist in the same network and traverse the same nodes without interfering with each other)
o 在所有xHauls之间统一（意味着具有不同DetNet需求的不同流可以共存于同一网络中，并在不相互干扰的情况下穿越相同节点）
o Deployed in a highly deterministic network environment
o 部署在高度确定性的网络环境中
o Capable of supporting multiple functional splits simultaneously, including existing Backhaul and CPRI Fronthaul, and (potentially) new modes as defined, for example, in 3GPP; these goals can be supported by the existing DetNet use case "common themes" (Section 11); of special note are Sections 11.1.8 ("Mix of Deterministic and Best-Effort Traffic"), 11.3.1 ("Bounded Latency"), 11.3.2 ("Low Latency"), 11.3.4 ("Symmetrical Path Delays"), and 11.6 ("Deterministic Flows")
o 能够同时支持多个功能拆分，包括现有回程和CPRI前程，以及（可能）如3GPP中定义的新模式；这些目标可以由现有的DetNet用例“公共主题”（第11节）支持；特别注意的是第11.1.8节（“确定性和尽力而为流量的混合”）、第11.3.1节（“有界延迟”）、第11.3.2节（“低延迟”）、第11.3.4节（“对称路径延迟”）和第11.6节（“确定性流”）
o Capable of supporting network slicing and multi-tenancy; these goals can be supported by the same DetNet themes noted above
o 支持网络切片和多租户；上述DetNet主题可以支持这些目标
o Capable of transporting both in-band and out-of-band control traffic (e.g., Operations, Administration, and Maintenance (OAM) information)
o 能够传输带内和带外控制流量（例如，操作、管理和维护（OAM）信息）
o Deployable over multiple data-link technologies (e.g., IEEE 802.3, mmWave)
o 可通过多种数据链路技术（如IEEE 802.3、mmWave）部署
A standard for data-flow information models that is:
数据流信息模型的标准是：
o Aware of the time sensitivity and constraints of the target networking environment
o 了解目标网络环境的时间敏感性和限制
o Aware of underlying deterministic networking services (e.g., on the Ethernet layer)
o 了解底层确定性网络服务（例如，在以太网层上）
"Industrial automation" in general refers to automation of manufacturing, quality control, and material processing. This M2M use case focuses on machine units on a plant floor that periodically exchange data with upstream or downstream machine modules and/or a supervisory controller within a LAN.
“工业自动化”一般指制造、质量控制和材料加工的自动化。本M2M用例主要关注工厂地板上的机器单元，这些机器单元定期与LAN内的上游或下游机器模块和/或监控控制器交换数据。
PLCs are the "actors" in M2M communications. Communication between PLCs, and between PLCs and the supervisory PLC (S-PLC), is achieved via critical control/data streams (Figure 11).
PLC是M2M通信中的“参与者”。PLC之间以及PLC与监控PLC（S-PLC）之间的通信通过关键控制/数据流实现（图11）。
S (Sensor)
\ +-----+
PLC__ \.--. .--. ---| MES |
\_( `. _( `./ +-----+
A------( Local )-------------( L2 )
( Net ) ( Net ) +-------+
/`--(___.-' `--(___.-' ----| S-PLC |
S_/ / PLC .--. / +-------+
A_/ \_( `.
(Actuator) ( Local )
( Net )
/`--(___.-'\
/ \ A
S A
S (Sensor)
\ +-----+
PLC__ \.--. .--. ---| MES |
\_( `. _( `./ +-----+
A------( Local )-------------( L2 )
( Net ) ( Net ) +-------+
/`--(___.-' `--(___.-' ----| S-PLC |
S_/ / PLC .--. / +-------+
A_/ \_( `.
(Actuator) ( Local )
( Net )
/`--(___.-'\
/ \ A
S A
Figure 11: Current Generic Industrial M2M Network Architecture
图11：当前通用工业M2M网络架构
This use case focuses on PLC-related communications; communication to Manufacturing Execution Systems (MESs) are not addressed.
本用例主要关注PLC相关的通信；未解决与制造执行系统（MESs）的通信问题。
This use case covers only critical control/data streams; non-critical traffic between industrial automation applications (such as communication of state, configuration, setup, and database communication) is adequately served by prioritizing techniques available at the time of this writing. Such traffic can use up to 80% of the total bandwidth required. There is also a subset of non-time-critical traffic that must be reliable even though it is not time sensitive.
该用例仅涵盖关键控制/数据流；工业自动化应用程序之间的非关键通信（如状态通信、配置、设置和数据库通信）通过撰写本文时可用的优先技术得到充分的服务。这种通信量最多可以使用所需总带宽的80%。还有一部分非时间关键流量必须是可靠的，即使它对时间不敏感。
In this use case, deterministic networking is primarily needed to provide end-to-end delivery of M2M messages within specific timing constraints -- for example, in closed-loop automation control. Today, this level of determinism is provided by proprietary networking technologies. In addition, standard networking technologies are used to connect the local network to remote industrial automation sites, e.g., over an enterprise or metro network that also carries other types of traffic. Therefore, flows that should be forwarded with deterministic guarantees need to be sustained, regardless of the amount of other flows in those networks.
在这个用例中，确定性网络主要需要在特定的时间限制内提供M2M消息的端到端传递——例如，在闭环自动化控制中。今天，专有网络技术提供了这种程度的决定论。此外，标准网络技术用于将本地网络连接到远程工业自动化站点，例如，通过也承载其他类型流量的企业或城域网络。因此，无论这些网络中的其他流的数量如何，都需要维持应该以确定性保证转发的流。
Today, proprietary networks fulfill the needed timing and availability for M2M networks.
如今，专有网络满足了M2M网络所需的时间和可用性。
The network topologies used today by industrial automation are similar to those used by telecom networks: daisy chain, ring, hub-and-spoke, and "comb" (a subset of daisy chain).
如今工业自动化所使用的网络拓扑与电信网络所使用的网络拓扑相似：菊花链、环、轮毂辐和“梳”（菊花链的子集）。
PLC-related control/data streams are transmitted periodically and carry either a preconfigured payload or a payload configured during runtime.
PLC相关的控制/数据流定期传输，并携带预配置的有效负载或运行时配置的有效负载。
Some industrial applications require time synchronization at the end nodes. For such time-coordinated PLCs, accuracy of 1 us is required. Even in the case of "non-time-coordinated" PLCs, time synchronization may be needed, e.g., for timestamping of sensor data.
一些工业应用需要在终端节点进行时间同步。对于这种时间协调的PLC，精度要求为1us。即使在“非时间协调”PLC的情况下，也可能需要时间同步，例如，用于传感器数据的时间戳。
Industrial-network scenarios require advanced security solutions. At the time of this writing, many industrial production networks are physically separated. Filtering policies that are typically enforced in firewalls are used to prevent critical flows from being leaked outside a domain.
工业网络场景需要高级安全解决方案。在撰写本文时，许多工业生产网络在物理上是分离的。通常在防火墙中强制实施的过滤策略用于防止关键流泄漏到域外。
The cycle time defines the frequency of message(s) between industrial actors. The cycle time is application dependent, in the range of 1-100 ms for critical control/data streams.
周期时间定义了工业参与者之间的消息频率。关键控制/数据流的循环时间取决于应用程序，范围为1-100 ms。
Because industrial applications assume that deterministic transport will be used for critical control-data-stream parameters (instead of having to define latency and delay-variation parameters), it is sufficient to fulfill requirements regarding the upper bound of latency (maximum latency). The underlying networking infrastructure must ensure a maximum end-to-end message delivery time in the range of 100 us to 50 ms, depending on the control-loop application.
由于工业应用假定确定性传输将用于关键控制数据流参数（而不必定义延迟和延迟变化参数），因此足以满足关于延迟上限（最大延迟）的要求。底层网络基础设施必须确保最大端到端消息传递时间在100 us到50 ms之间，具体取决于控制回路应用程序。
The bandwidth requirements of control/data streams are usually calculated directly from the bytes-per-cycle parameter of the control loop. For PLC-to-PLC communication, one can expect 2-32 streams with packet sizes in the range of 100-700 bytes. For S-PLC-to-PLC communication, the number of streams is higher -- up to 256 streams. Usually, no more than 20% of available bandwidth is used for critical control/data streams. In today's networks, 1 Gbps links are commonly used.
控制/数据流的带宽要求通常直接从控制回路的每周期字节数参数计算。对于PLC到PLC的通信，可以预期2-32个数据流，数据包大小在100-700字节范围内。对于S-PLC-to-PLC通信，流的数量更高——最多256个流。通常，用于关键控制/数据流的可用带宽不超过20%。在今天的网络中，通常使用1 Gbps链路。
Most PLC control loops are rather tolerant of packet loss; however, critical control/data streams accept a loss of no more than one packet per consecutive communication cycle (i.e., if a packet gets lost in cycle "n", then the next cycle ("n+1") must be lossless). After the loss of two or more consecutive packets, the network may be considered to be "down" by the application.
大多数PLC控制回路对丢包有相当大的容忍度；然而，关键控制/数据流接受每个连续通信周期不超过一个分组的丢失（即，如果分组在周期“n”中丢失，则下一个周期（“n+1”）必须是无损的）。在丢失两个或多个连续分组之后，应用程序可以认为网络“关闭”。
As network downtime may impact the whole production system, the required network availability is rather high (99.999%).
由于网络停机可能会影响整个生产系统，因此所需的网络可用性相当高（99.999%）。
Based on the above parameters, some form of redundancy will be required for M2M communications; however, any individual solution depends on several parameters, including cycle time and delivery time.
基于上述参数，M2M通信需要某种形式的冗余；然而，任何单独的解决方案都取决于几个参数，包括周期时间和交付时间。
In an industrial environment, critical control/data streams are created rather infrequently, on the order of ~10 times per day/week/month. Most of these critical control/data streams get created at machine startup; however, flexibility is also needed during runtime -- for example, when adding or removing a machine. As production systems become more flexible going forward, there will be a significant increase in the rate at which streams are created, changed, and destroyed.
在工业环境中，创建关键控制/数据流的频率相当低，每天/每周/每月约10次。大多数这些关键控制/数据流是在机器启动时创建的；然而，在运行时也需要灵活性——例如，在添加或删除机器时。随着生产系统变得更加灵活，流的创建、更改和销毁速度将显著提高。
We foresee a converged IP-standards-based network with deterministic properties that can satisfy the timing, security, and reliability constraints described above. Today's proprietary networks could then be interfaced to such a network via gateways; alternatively, in the case of new installations, devices could be connected directly to the converged network.
我们预见了一个融合的基于IP标准的网络，该网络具有确定性特性，能够满足上述时间、安全性和可靠性约束。今天的专有网络可以通过网关与这样的网络连接；或者，在新安装的情况下，设备可以直接连接到聚合网络。
For this use case, time-synchronization accuracy on the order of 1 us is expected.
对于该用例，时间同步精度预计为1us。
o Converged IP-based network
o 基于IP的融合网络
o Deterministic behavior (bounded latency and jitter)
o 确定性行为（有界延迟和抖动）
o High availability (presumably through redundancy) (99.999%)
o 高可用性（可能通过冗余实现）（99.999%）
o Low message delivery time (100 us to 50 ms)
o 低消息传递时间（100 us到50 ms）
o Low packet loss (with a bounded number of consecutive lost packets)
o 低数据包丢失（连续丢失的数据包数量有限）
o Security (e.g., preventing critical flows from being leaked between physically separated networks)
o 安全性（例如，防止物理隔离网络之间的关键流泄漏）
The mining industry is highly dependent on networks to monitor and control their systems, in both open-pit and underground extraction as well as in transport and refining processes. In order to reduce risks and increase operational efficiency in mining operations, the location of operators has been relocated (as much as possible) from the extraction site to remote control and monitoring sites.
采矿业高度依赖网络来监测和控制其系统，包括露天和地下开采以及运输和精炼过程。为了降低采矿作业中的风险并提高作业效率，已将操作员的位置（尽可能）从开采现场转移到远程控制和监测现场。
In the case of open-pit mining, autonomous trucks are used to transport the raw materials from the open pit to the refining factory where the final product (e.g., copper) is obtained. Although the operation is autonomous, the tracks are remotely monitored from a central facility.
在露天采矿的情况下，使用自动卡车将原材料从露天矿运输到精炼厂，在那里获得最终产品（如铜）。虽然操作是自主的，但轨道是由中央设施远程监控的。
In pit mines, the monitoring of the tailings or mine dumps is critical in order to minimize environmental pollution. In the past, monitoring was conducted through manual inspection of preinstalled dataloggers. Cabling is not typically used in such scenarios, due to its high cost and complex deployment requirements. At the time of this writing, wireless technologies are being employed to monitor these cases permanently. Slopes are also monitored in order to anticipate possible mine collapse. Due to the unstable terrain, cable maintenance is costly and complex; hence, wireless technologies are employed.
在露天矿中，为了最大限度地减少环境污染，对尾矿或尾矿堆的监测至关重要。过去，监测是通过手动检查预安装的数据记录器进行的。由于布线成本高且部署要求复杂，因此通常不在此类场景中使用。在撰写本文时，无线技术正被用于永久监测这些病例。还对边坡进行监测，以预测可能发生的矿山坍塌。由于地形不稳定，电缆维护成本高且复杂；因此，采用了无线技术。
In the case of underground monitoring, autonomous vehicles with extraction tools travel independently through the tunnels, but their operational tasks (such as excavation, stone-breaking, and transport) are controlled remotely from a central facility. This generates upstream video and feedback traffic plus downstream actuator-control traffic.
在地下监控的情况下，配备提取工具的自动车辆独立通过隧道，但其操作任务（如挖掘、碎石和运输）由中央设施远程控制。这将生成上游视频和反馈流量加上下游执行器控制流量。
At the time of this writing, the mining industry uses a packet-switched architecture supported by high-speed Ethernet. However, in order to comply with requirements regarding delay and packet loss, the network bandwidth is overestimated. This results in very low efficiency in terms of resource usage.
在撰写本文时，采矿业使用高速以太网支持的分组交换体系结构。然而，为了符合关于延迟和分组丢失的要求，网络带宽被高估。这导致资源使用效率极低。
QoS is implemented at the routers to separate video, management, monitoring, and process-control traffic for each stream.
QoS在路由器上实现，以分离每个流的视频、管理、监视和过程控制流量。
Since mobility is involved in this process, the connections between the backbone and the mobile devices (e.g., trucks, trains, and excavators) are implemented using a wireless link. These links are based on IEEE 802.11 [IEEE-80211] for open-pit mining and "leaky feeder" communications for underground mining. (A "leaky feeder" communication system consists of a coaxial cable, run along tunnels, that emits and receives radio waves, functioning as an extended antenna. The cable is "leaky" in that it has gaps or slots in its outer conductor to allow the radio signal to leak into or out of the cable along its entire length.)
由于此过程涉及到移动性，因此主干网和移动设备（例如卡车、火车和挖掘机）之间的连接使用无线链路实现。这些链路基于用于露天采矿的IEEE 802.11[IEEE-80211]和用于地下采矿的“泄漏馈线”通信。（一个“漏泄馈线”通信系统由一根沿隧道敷设的同轴电缆组成，该电缆发射和接收无线电波，起到延伸天线的作用。该电缆“漏泄”是因为其外部导体中有间隙或槽，允许无线信号沿其整个长度漏出或进入电缆。）
Lately, in pit mines the use of Low-Power WAN (LPWAN) technologies has been extended: tailings, slopes, and mine dumps are monitored by battery-powered dataloggers that make use of robust long-range radio technologies. Reliability is usually ensured through retransmissions at Layer 2. Gateways or concentrators act as bridges, forwarding the data to the backbone Ethernet network. Deterministic requirements are biased towards reliability rather than latency, as events are triggered slowly or can be anticipated in advance.
最近，在矿井中，低功率广域网（LPWAN）技术的使用得到了扩展：尾矿、边坡和矿山倾倒区由电池供电的数据记录器进行监测，该记录器利用了可靠的远程无线电技术。可靠性通常通过第2层的重传来保证。网关或集中器充当网桥，将数据转发到骨干以太网。确定性需求倾向于可靠性而不是延迟，因为事件触发缓慢或可以提前预测。
At the mineral-processing stage, conveyor belts and refining processes are controlled by a SCADA system that provides an in-factory delay-constrained networking environment.
在矿物加工阶段，传送带和精炼过程由SCADA系统控制，该系统提供了一个厂内延迟受限的网络环境。
At the time of this writing, voice communications are served by a redundant trunking infrastructure, independent from data networks.
在撰写本文时，语音通信由独立于数据网络的冗余中继基础设施提供服务。
Mining operations and management are converging towards a combination of autonomous operation and teleoperation of transport and extraction machines. This means that video, audio, monitoring, and process-control traffic will increase dramatically. Ideally, all activities at the mine will rely on network infrastructure.
采矿作业和管理正在向运输和开采机械的自主操作和远程操作相结合的方向发展。这意味着视频、音频、监控和过程控制流量将大幅增加。理想情况下，矿山的所有活动都将依赖于网络基础设施。
Wireless for open-pit mining is already a reality with LPWAN technologies; it is expected to evolve to more-advanced LPWAN technologies, such as those based on LTE, to increase last-hop reliability or novel LPWAN flavors with deterministic access.
利用LPWAN技术，露天采矿的无线通信已经成为现实；预计它将发展到更先进的LPWAN技术，如基于LTE的技术，以提高最后一跳的可靠性或具有确定性接入的新型LPWAN风格。
One area in which DetNet can improve this use case is in the wired networks that make up the "backbone network" of the system. These networks connect many wireless Access Points (APs) together. The mobile machines (which are connected to the network via wireless)
DetNet可以改进该用例的一个领域是构成系统“骨干网络”的有线网络。这些网络将许多无线接入点（AP）连接在一起。移动机器（通过无线连接到网络）
transition from one AP to the next as they move about. A deterministic, reliable, low-latency backbone can enable these transitions to be more reliable.
移动时从一个AP切换到下一个AP。确定性的、可靠的、低延迟的主干网可以使这些转换更加可靠。
Connections that extend all the way from the base stations to the machinery via a mix of wired and wireless hops would also be beneficial -- for example, to improve the responsiveness of digging machines to remote control. However, to guarantee deterministic performance of a DetNet, the end-to-end underlying network must be deterministic. Thus, for this use case, if a deterministic wireless transport is integrated with a wire-based DetNet network, it could create the desired wired plus wireless end-to-end deterministic network.
通过有线和无线跳数的混合从基站一直延伸到机器的连接也将是有益的——例如，提高挖土机对远程控制的响应能力。然而，为了保证DetNet的确定性性能，端到端基础网络必须是确定性的。因此，对于这个用例，如果确定性无线传输与基于有线的DetNet网络集成，它可以创建所需的有线加无线端到端确定性网络。
o Improved bandwidth efficiency
o 提高带宽效率
o Very low delay, to enable machine teleoperation
o 极低延迟，可实现机器远程操作
o Dedicated bandwidth usage for high-resolution video streams
o 高分辨率视频流的专用带宽使用
o Predictable delay, to enable real-time monitoring
o 可预测的延迟，以实现实时监控
o Potential for constructing a unified DetNet network over a combination of wired and deterministic wireless links
o 通过有线和确定性无线链路组合构建统一的DetNet网络的可能性
Blockchain was created with Bitcoin as a "public" blockchain on the open Internet; however, blockchain has also spread far beyond its original host into various industries, such as smart manufacturing, logistics, security, legal rights, and others. In these industries, blockchain runs in designated and carefully managed networks in which deterministic networking requirements could be addressed by DetNet. Such implementations are referred to as "private" blockchain.
区块链是以比特币作为开放互联网上的“公共”区块链创建的；然而，区块链也已远远超出其原始宿主，扩展到各个行业，如智能制造、物流、安全、合法权益等。在这些行业中，区块链在指定和精心管理的网络中运行，其中确定性网络需求可由DetNet解决。此类实施被称为“私有”区块链。
The sole distinction between public and private blockchain is defined by who is allowed to participate in the network, execute the consensus protocol, and maintain the shared ledger.
公共区块链和私有区块链之间的唯一区别由允许参与网络、执行共识协议和维护共享账本的人来定义。
Today's networks manage the traffic from blockchain on a best-effort basis, but blockchain operation could be made much more efficient if deterministic networking services were available to minimize latency and packet loss in the network.
今天的网络在尽最大努力的基础上管理来自区块链的流量，但如果确定性网络服务可用于最小化网络中的延迟和数据包丢失，则区块链操作可以变得更加高效。
A "block" runs as a container of a batch of primary items (e.g., transactions, property records). The blocks are chained in such a way that the hash of the previous block works as the pointer to the header of the new block. Confirmation of each block requires a consensus mechanism. When an item arrives at a blockchain node, the latter broadcasts this item to the rest of the nodes, which receive it, verify it, and put it in the ongoing block. The block confirmation process begins as the number of items reaches the predefined block capacity, at which time the node broadcasts its proved block to the rest of the nodes, to be verified and chained. The result is that block N+1 of each chain transitively vouches for blocks N and previous of that chain.
“块”作为一批主要项目（例如事务、属性记录）的容器运行。这些块以这样一种方式链接，即前一个块的散列作为指向新块头的指针。每个区块的确认都需要一个共识机制。当项目到达区块链节点时，区块链节点将该项目广播给其余节点，其余节点接收、验证该项目并将其放入正在进行的区块中。当项目数量达到预定义的块容量时，块确认过程开始，此时节点将其已验证的块广播给其余待验证和链接的节点。结果是每个链的块N+1可传递地为该链的块N和上一个块提供担保。
Blockchain node communication and coordination are achieved mainly through frequent point-to-multipoint communication; however, persistent point-to-point connections are used to transport both the items and the blocks to the other nodes. For example, consider the following implementation.
区块链节点通信和协调主要通过频繁的点对多点通信实现；但是，持久的点到点连接用于将项目和块传输到其他节点。例如，考虑下面的实现。
When a node is initiated, it first requests the other nodes' addresses from a specific entity, such as DNS. The node then creates persistent connections with each of the other nodes. If a node confirms an item, it sends the item to the other nodes via these persistent connections.
当一个节点启动时，它首先从特定实体（如DNS）请求其他节点的地址。然后，该节点创建与其他每个节点的持久连接。如果一个节点确认一个项目，它将通过这些持久连接将该项目发送到其他节点。
As a new block in a node is completed and is proven by the surrounding nodes, it propagates towards its neighbor nodes. When node A receives a block, it verifies it and then sends an invite message to its neighbor B. Neighbor B checks to see if the designated block is available and responds to A if it is unavailable; A then sends the complete block to B. B repeats the process (as was done by A) to start the next round of block propagation.
当节点中的新块完成并被周围节点验证时，它会向其邻居节点传播。当节点A接收到一个块时，它对其进行验证，然后向其邻居B发送invite消息。邻居B检查指定的块是否可用，如果不可用，则响应A；然后A将完整的块发送给B。B重复该过程（正如A所做的那样）以开始下一轮块传播。
The challenge of blockchain network operation is not overall data rates, since the volume from both the block and the item stays between hundreds of bytes and a couple of megabytes per second; rather, the challenge is in transporting the blocks with minimum latency to maximize the efficiency of the blockchain consensus process. The efficiency of differing implementations of the consensus process may be affected to a differing degree by the latency (and variation of latency) of the network.
区块链网络运营的挑战不是总体数据速率，因为区块和项目的容量保持在每秒数百字节到几兆字节之间；相反，挑战在于以最小延迟传输块，以最大限度地提高区块链共识过程的效率。协商一致过程的不同实现的效率可能在不同程度上受到网络延迟（以及延迟的变化）的影响。
Security is crucial to blockchain applications; at the time of this writing, blockchain systems address security issues mainly at the application level, where cryptography as well as hash-based consensus play a leading role in preventing both double-spending and malicious service attacks. However, there is concern that in the proposed use case for a private blockchain network that is dependent on deterministic properties the network could be vulnerable to delays and other specific attacks against determinism, as these delays and attacks could interrupt service.
安全性对于区块链应用至关重要；在撰写本文时，区块链系统主要在应用程序层面解决安全问题，其中加密技术以及基于散列的共识在防止双重支出和恶意服务攻击方面发挥着主导作用。然而，有人担心，在依赖于确定性属性的私有区块链网络的拟议用例中，网络可能容易受到延迟和其他针对确定性的特定攻击，因为这些延迟和攻击可能中断服务。
Today, private blockchain runs in Layer 2 or Layer 3 VPNs, generally without guaranteed determinism. The industry players are starting to realize that improving determinism in their blockchain networks could improve the performance of their service, but at present these goals are not being met.
如今，私有区块链在第2层或第3层VPN中运行，通常不保证确定性。行业参与者开始意识到，改善区块链网络中的决定论可以提高其服务的性能，但目前这些目标尚未实现。
Blockchain system performance can be greatly improved through deterministic networking services, primarily because low latency would accelerate the consensus process. It would be valuable to be able to design a private blockchain network with the following properties:
通过确定性网络服务，区块链系统性能可以大大提高，这主要是因为低延迟将加速共识过程。能够设计具有以下属性的私有区块链网络是很有价值的：
o Transport of point-to-multipoint traffic in a coordinated network architecture rather than at the application layer (which typically uses point-to-point connections)
o 在协调网络体系结构中传输点对多点流量，而不是在应用层（通常使用点对点连接）
o Guaranteed transport latency
o 保证传输延迟
o Reduced packet loss (to the point where delay incurred by packet retransmissions would be negligible)
o 减少数据包丢失（数据包重传产生的延迟可以忽略不计）
o Layer 2 and Layer 3 multicast of blockchain traffic
o 区块链流量的第2层和第3层组播
o Item and block delivery with bounded, low latency and negligible packet loss
o 具有有限、低延迟和可忽略的数据包丢失的项和块传递
o Coexistence of blockchain and IT traffic in a single network
o 区块链和IT流量在单个网络中共存
o Ability to scale the network by distributing the centralized control of the network across multiple control entities
o 通过在多个控制实体之间分配对网络的集中控制来扩展网络的能力
Network slicing divides one physical network infrastructure into multiple logical networks. Each slice, which corresponds to a logical network, uses resources and network functions independently from each other. Network slicing provides flexibility of resource allocation and service quality customization.
网络切片将一个物理网络基础设施划分为多个逻辑网络。每个片对应于一个逻辑网络，使用彼此独立的资源和网络功能。网络切片提供了资源分配和服务质量定制的灵活性。
Future services will demand network performance with a wide variety of characteristics such as high data rate, low latency, low loss rate, security, and many other parameters. Ideally, every service would have its own physical network satisfying its particular performance requirements; however, that would be prohibitively expensive. Network slicing can provide a customized slice for a single service, and multiple slices can share the same physical network. This method can optimize performance for the service at lower cost, and the flexibility of setting up and releasing the slices also allows the user to allocate network resources dynamically.
未来的服务将要求具有多种特性的网络性能，如高数据速率、低延迟、低丢失率、安全性和许多其他参数。理想情况下，每个服务都有自己的物理网络，以满足其特定的性能要求；然而，这将是令人望而却步的昂贵。网络切片可以为单个服务提供自定义切片，多个切片可以共享同一物理网络。这种方法可以以较低的成本优化服务的性能，并且设置和释放片的灵活性还允许用户动态分配网络资源。
Unlike the other use cases presented here, network slicing is not a specific application that depends on specific deterministic properties; rather, it is introduced as an area of networking to which DetNet might be applicable.
与这里介绍的其他用例不同，网络切片不是依赖于特定确定性属性的特定应用程序；相反，它是作为一个可能适用DetNet的网络领域引入的。
One of the requirements discussed for network slicing is the "hard" separation of various users' deterministic performance. That is, it should be impossible for activity, lack of activity, or changes in activity of one or more users to have any appreciable effect on the deterministic performance parameters of any other slices. Typical techniques used today, which share a physical network among users, do not offer this level of isolation. DetNet can supply point-to-point or point-to-multipoint paths that offer a user bandwidth and latency guarantees that cannot be affected by other users' data traffic. Thus, DetNet is a powerful tool when reliability and low latency are required in network slicing.
讨论的网络切片需求之一是各种用户确定性性能的“硬”分离。也就是说，一个或多个用户的活动、缺少活动或活动的变化不可能对任何其他片的确定性性能参数产生任何明显的影响。今天使用的典型技术在用户之间共享一个物理网络，不提供这种隔离级别。DetNet可以提供点对点或点对多点路径，提供不受其他用户数据流量影响的用户带宽和延迟保证。因此，当网络切片需要可靠性和低延迟时，DetNet是一个强大的工具。
Slices may need to provide services with DetNet-type performance guarantees; note, however, that a system can be implemented to provide such services in more than one way. For example, the slice itself might be implemented using DetNet, and thus the slice can provide service guarantees and isolation to its users without any particular DetNet awareness on the part of the users' applications. Alternatively, a "non-DetNet-aware" slice may host an application that itself implements DetNet services and thus can enjoy similar service guarantees.
Slices可能需要提供具有DetNet类型性能保证的服务；但是，请注意，可以实现一个系统以多种方式提供此类服务。例如，slice本身可以使用DetNet实现，因此slice可以为其用户提供服务保证和隔离，而不需要用户应用程序的任何特定DetNet感知。或者，“非DetNet感知”片可以承载一个应用程序，该应用程序本身实现DetNet服务，因此可以享受类似的服务保证。
Network slicing is a core feature of 5G as defined in 3GPP. The system architecture for 5G is under development at the time of this writing [TS23501]. A network slice in a mobile network is a complete logical network, including RANs and Core Networks (CNs). It provides telecommunications services and network capabilities, which may vary from slice to slice. A 5G bearer network is a typical use case for network slicing; for example, consider three 5G service scenarios: eMBB, URLLC, and mMTC.
网络分层是3GPP中定义的5G的核心功能。撰写本文时，5G的系统架构正在开发中[TS23501]。移动网络中的网络片是一个完整的逻辑网络，包括RAN和核心网络（CNs）。它提供电信服务和网络能力，这可能因片而异。5G承载网络是网络切片的典型用例；例如，考虑三个5G服务场景：EMBB、URLLC和MMTC。
o eMBB (Enhanced Mobile Broadband) focuses on services characterized by high data rates, such as high-definition video, Virtual Reality (VR), augmented reality, and fixed mobile convergence.
o eMBB（增强移动宽带）专注于以高数据速率为特征的服务，如高清视频、虚拟现实（VR）、增强现实和固定移动融合。
o URLLC (Ultra-Reliable and Low Latency Communications) focuses on latency-sensitive services, such as self-driving vehicles, remote surgery, or drone control.
o URLLC（超可靠低延迟通信）专注于对延迟敏感的服务，如自动驾驶车辆、远程手术或无人机控制。
o mMTC (massive Machine Type Communications) focuses on services that have high connection-density requirements, such as those typically used in smart-city and smart-agriculture scenarios.
o mMTC（大规模机器型通信）专注于具有高连接密度要求的服务，如智能城市和智能农业场景中通常使用的服务。
A 5G bearer network could use DetNet to provide hard resource isolation across slices and within a given slice. For example, consider Slice-A and Slice-B, with DetNet used to transit services URLLC-A and URLLC-B over them. Without DetNet, URLLC-A and URLLC-B would compete for bandwidth resources, and latency and reliability requirements would not be guaranteed. With DetNet, URLLC-A and URLLC-B have separate bandwidth reservations; there is no resource conflict between them, as though they were in different physical networks.
5G承载网络可以使用DetNet在片间和给定片内提供硬资源隔离。例如，考虑SLICE-A和SLICE-B，DTENT用于在它们上面传输服务URLC-A和URLC-B。如果没有DetNet，URLLC-A和URLLC-B将争夺带宽资源，延迟和可靠性要求将得不到保证。对于DetNet，URLLC-A和URLLC-B有单独的带宽预留；它们之间没有资源冲突，就好像它们在不同的物理网络中一样。
Although the operation of services not related to 5G is not part of the 5G network slicing definition and scope, network slicing is likely to become a preferred approach for providing various services across a shared physical infrastructure. Examples include providing services for electrical utilities and pro audio via slices. Use cases like these could become more common once the work for the 5G CN evolves to include wired as well as wireless access.
尽管与5G无关的服务的操作不是5G网络切片定义和范围的一部分，但网络切片可能成为跨共享物理基础设施提供各种服务的首选方法。示例包括通过切片为电力设施和专业音频提供服务。一旦5G CN的工作发展到包括有线和无线接入，这样的用例可能会变得更加常见。
DetNet cannot cover every network slicing use case. One issue is that DetNet is a point-to-point or point-to-multipoint technology; however, network slicing ultimately needs multipoint-to-multipoint guarantees. Another issue is that the number of flows that can be carried by DetNet is limited by DetNet scalability; flow aggregation and queuing management modification may help address this issue. Additional work and discussion are needed to address these topics.
DetNet无法覆盖所有网络切片用例。一个问题是DetNet是一种点对点或点对多点技术；然而，网络切片最终需要多点对多点的保证。另一个问题是，DetNet可承载的流量数量受到DetNet可伸缩性的限制；流聚合和队列管理修改可能有助于解决此问题。需要进行更多的工作和讨论来解决这些问题。
Network slicing has promise in terms of satisfying many requirements of future network deployment scenarios, but it is still a collection of ideas and analyses without a specific technical solution. DetNet is one of various technologies that could potentially be used in network slicing, along with, for example, Flex-E and segment routing. For more information, please see the IETF 99 Network Slicing BoF session agenda and materials as provided in [IETF99-netslicing-BoF].
网络切片有望满足未来网络部署场景的许多需求，但它仍然是一个想法和分析的集合，没有具体的技术解决方案。DetNet是可能用于网络切片的各种技术之一，例如，Flex-E和段路由。有关更多信息，请参阅[IETF99 Netlicing BoF]中提供的IETF 99网络切片BoF会话议程和材料。
o Isolation from other flows through queuing management
o 通过队列管理与其他流隔离
o Service quality customization and guarantees
o 服务质量定制与保障
o Security
o 安全
This section summarizes the expected properties of a DetNet network, based on the use cases as described in this document.
本节根据本文档中描述的用例总结了DetNet网络的预期属性。
A DetNet network is not "a new kind of network" -- it is based on extensions to existing Ethernet standards, including elements of IEEE 802.1 TSN and related standards. Presumably, it will be possible to run DetNet over other underlying transports besides Ethernet, but Ethernet is explicitly supported.
DetNet网络不是“一种新的网络”——它基于对现有以太网标准的扩展，包括IEEE 802.1 TSN和相关标准的元素。据推测，除了以太网，还可以在其他底层传输上运行DetNet，但以太网是明确支持的。
In general, a DetNet network is not expected to be "plug and play"; rather, some type of centralized network configuration and control system is expected. Such a system may be in a single central location, or it may be distributed across multiple control entities that function together as a unified control system for the network. However, the ability to "hot swap" components (e.g., due to malfunction) is similar enough to "plug and play" that this kind of behavior may be expected in DetNet networks, depending on the implementation.
一般来说，DetNet网络不需要“即插即用”；相反，需要某种类型的集中式网络配置和控制系统。这样的系统可以位于单个中心位置，或者可以分布在多个控制实体之间，这些控制实体一起作为网络的统一控制系统运行。然而，“热插拔”组件的能力（例如，由于故障）与“即插即用”的能力非常相似，因此这种行为可能会在DetNet网络中出现，具体取决于实现情况。
Data-flow information models to be used with DetNet networks are to be specified by DetNet.
DetNet网络使用的数据流信息模型由DetNet指定。
A DetNet network is intended to integrate between Layer 2 (bridged) network(s) (e.g., an AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g., using IP-based protocols). One example of this is making AVB/TSN-type deterministic performance available from Layer 3 applications, e.g., using RTP. Another example is connecting two AVB/TSN LANs ("islands") together through a standard router.
DetNet网络旨在集成第2层（桥接）网络（例如，AVB/TSN LAN）和第3层（路由）网络（例如，使用基于IP的协议）。这方面的一个例子是使AVB/TSN类型的确定性性能可从第3层应用程序获得，例如，使用RTP。另一个例子是通过标准路由器将两个AVB/TSN LAN（“岛”）连接在一起。
This document explicitly does not specify any particular implementation or protocol; however, it has been observed that various use cases (and their associated industries) described herein are explicitly based on IPv4 (as opposed to IPv6), and it is not considered practical to expect such implementations to migrate to
本文件未明确规定任何特定实施或协议；然而，已经观察到，本文描述的各种用例（及其相关行业）明确地基于IPv4（与IPv6相反），并且期望这种实现迁移到IPv4是不实际的
IPv6 in order to use DetNet. Thus, the expectation is that even if not every feature of DetNet is available in an IPv4 context, at least some of the significant benefits (such as guaranteed end-to-end delivery and low latency) will be available.
IPv6以使用DetNet。因此，我们的期望是，即使不是每个DetNet功能在IPv4上下文中都可用，至少一些重要的好处（如有保证的端到端交付和低延迟）将可用。
Packets in a DetNet flow are guaranteed not to be dropped by the network due to congestion. However, the network may drop packets for intended reasons, e.g., per security measures. Similarly, best-effort traffic on a DetNet is subject to being dropped (as on a non-DetNet IP network). Also note that this guarantee applies to actions taken by DetNet protocol software and does not provide any guarantee against lower-level errors such as media errors or checksum errors.
DetNet流中的数据包保证不会因拥塞而被网络丢弃。然而，网络可能出于预期的原因（例如，根据安全措施）丢弃分组。类似地，DetNet上的尽力而为流量可能会被丢弃（如在非DetNet IP网络上）。还请注意，此保证适用于DetNet协议软件采取的操作，不提供任何针对较低级别错误（如媒体错误或校验和错误）的保证。
There are many proprietary non-interoperable deterministic Ethernet-based networks available; DetNet is intended to provide an open-standards-based alternative to such networks.
有许多基于以太网的专有非互操作确定性网络可用；DetNet旨在为此类网络提供一种基于开放标准的替代方案。
DetNet is intended to support the coexistence of time-sensitive operational (OT) traffic and informational (IT) traffic on the same ("unified") network.
DetNet旨在支持同一（“统一”）网络上的时间敏感操作（OT）流量和信息（IT）流量共存。
11.1.9. Unused Reserved Bandwidth to Be Available to Best-Effort Traffic
11.1.9. 最大努力流量可用的未使用保留带宽
If bandwidth reservations are made for a stream but the associated bandwidth is not used at any point in time, that bandwidth is made available on the network for best-effort traffic. If the owner of the reserved stream then starts transmitting again, the bandwidth is no longer available for best-effort traffic; this occurs on a moment-to-moment basis. Note that such "temporarily available" bandwidth is not available for time-sensitive traffic, which must have its own reservation.
如果为流预留了带宽，但在任何时间点都没有使用相关的带宽，则该带宽在网络上可用于尽力而为的流量。如果保留流的所有者随后再次开始传输，则带宽不再可用于尽力而为的业务；这是在时刻对时刻的基础上发生的。请注意，这种“临时可用”带宽不适用于时间敏感的流量，这些流量必须有自己的保留。
The DetNet network specifications are intended to enable an ecosystem in which multiple vendors can create interoperable products, thus promoting device diversity and potentially higher numbers of each device manufactured, promoting cost reduction and cost competition
DetNet网络规范旨在实现一个生态系统，在这个生态系统中，多个供应商可以创建可互操作的产品，从而促进设备多样性和可能制造的每个设备的数量增加，促进成本降低和成本竞争
among vendors. In other words, vendors should be able to create DetNet networks at lower cost and with greater diversity of available devices than existing proprietary networks.
在供应商之间。换句话说，供应商应该能够以较低的成本创建DetNet网络，并且比现有的专有网络具有更大的可用设备多样性。
DetNet networks range in size from very small (e.g., inside a single industrial machine) to very large (e.g., a utility-grid network spanning a whole country and involving many "hops" over various kinds of links -- for example, radio repeaters, microwave links, or fiber optic links). However, recall that the scope of DetNet is confined to networks that are centrally administered and thereby explicitly excludes unbounded decentralized networks such as the Internet.
DetNet网络的规模从非常小（例如，在一台工业机器内）到非常大（例如，横跨整个国家的公用电网网络，涉及各种链路上的许多“跃点”——例如，无线电中继器、微波链路或光纤链路）。然而，回想一下，DetNet的范围仅限于集中管理的网络，因此明确排除了无限分散的网络，如互联网。
The number of flows in a given network application can potentially be large and can potentially grow faster than the number of nodes and hops, so the network should provide a sufficient (perhaps configurable) maximum number of flows for any given application.
给定网络应用程序中的流的数量可能很大，并且可能比节点和跃点的数量增长得更快，因此网络应该为任何给定应用程序提供足够（可能可配置）的最大流数量。
DetNet data-flow information models are expected to provide means to configure the network that include parameters for querying network path latency, requesting bounded latency for a given stream, requesting worst-case maximum and/or minimum latency for a given path or stream, and so on. It is expected that the network may not be able to provide a given requested service level; if this is indeed the case, the network control system should reply that the requested services are not available (as opposed to accepting the parameter but then not delivering the desired behavior).
DetNet数据流信息模型有望提供配置网络的方法，包括查询网络路径延迟、请求给定流的有界延迟、请求给定路径或流的最坏情况最大和/或最小延迟等参数。预计网络可能无法提供给定的请求服务级别；如果确实如此，网络控制系统应回复请求的服务不可用（与接受参数但随后不提供所需行为相反）。
Various applications may state that they require "extremely low latency"; however, depending on the application, "extremely low" may imply very different latency bounds. For example, "low latency" across a utility-grid network is a different order of magnitude of latency values compared to "low latency" in a motor control loop in a small machine. It is intended that the mechanisms for specifying desired latency include wide ranges and that architecturally there is nothing to prevent arbitrarily low latencies from being implemented in a given network.
各种应用程序可能会声明它们需要“极低的延迟”；但是，根据应用程序的不同，“极低”可能意味着非常不同的延迟界限。例如，与小型机器的电机控制回路中的“低延迟”相比，公用电网网络中的“低延迟”是不同数量级的延迟值。其意图是，用于指定期望延迟的机制包括宽范围，并且在架构上没有任何东西可以防止在给定网络中实现任意低延迟。
As with the other latency-related elements noted above, parameters that can determine or request permitted variations in latency should be available.
和上面提到的其他延迟相关元素一样，可以确定或请求允许的延迟变化的参数应该是可用的。
Some applications would like to specify that the transit delay time values be equal for both the transmit path and the return path.
一些应用程序希望指定传输路径和返回路径的传输延迟时间值相等。
Reliability is of critical importance to many DetNet applications, because the consequences of failure can be extraordinarily high in terms of cost and even human life. DetNet-based systems are expected to be implemented with essentially arbitrarily high availability -- for example, 99.9999% uptime (where 99.9999 means "six nines") or even 12 nines. DetNet designs should not make any assumptions about the level of reliability and availability that may be required of a given system and should define parameters for communicating these kinds of metrics within the network.
可靠性对于许多DetNet应用程序来说至关重要，因为故障的后果在成本甚至人的生命方面可能非常高。基于DetNet的系统预计将实现基本上任意的高可用性——例如，99.9999%的正常运行时间（其中99.9999表示“六个9”），甚至12个9。DetNet设计不应对给定系统可能需要的可靠性和可用性水平进行任何假设，并应定义用于在网络内传达此类指标的参数。
A strategy used by DetNet for providing such extraordinarily high levels of reliability is to provide redundant paths so that a system can seamlessly switch between the paths while maintaining its required level of performance.
DetNet为提供如此高水平的可靠性而使用的一种策略是提供冗余路径，以便系统能够在路径之间无缝切换，同时保持其所需的性能水平。
Security is of critical importance to many DetNet applications. A DetNet network must have the ability to be made secure against device failures, attackers, misbehaving devices, and so on. In a DetNet network, the data traffic is expected to be time sensitive; thus, in addition to arriving with the data content as intended, the data must also arrive at the expected time. This may present "new" security challenges to implementers and must be addressed accordingly. There are other security implications, including (but not limited to) the change in attack surface presented by PRE.
安全性对于许多DetNet应用程序至关重要。DetNet网络必须能够针对设备故障、攻击者、行为不端的设备等进行安全防护。在DetNet网络中，数据流量预计是时间敏感的；因此，除了按照预期到达数据内容外，数据还必须在预期时间到达。这可能会给实现者带来“新的”安全挑战，必须相应地加以解决。还有其他安全影响，包括（但不限于）PRE提出的攻击面变化。
Reserved-bandwidth data flows must be isolated from each other and from best-effort traffic, so that even if the network is saturated with best-effort (and/or reserved-bandwidth) traffic, the configured flows are not adversely affected.
预留带宽数据流必须相互隔离，并与尽力而为的流量隔离，以便即使网络被尽力而为（和/或预留带宽）流量饱和，配置的流量也不会受到不利影响。
This document covers a number of representative applications and network scenarios that are expected to make use of DetNet technologies. Each of the potential DetNet use cases will have security considerations from both the use-specific perspective and the DetNet technology perspective. While some use-specific security considerations are discussed above, a more comprehensive discussion of such considerations is captured in [DetNet-Security] ("Deterministic Networking (DetNet) Security Considerations"). Readers are encouraged to review [DetNet-Security] to gain a more complete understanding of DetNet-related security considerations.
本文档涵盖了预计将使用DetNet技术的许多代表性应用程序和网络场景。每个潜在的DetNet用例都将从特定于使用的角度和DetNet技术的角度考虑安全问题。虽然上面讨论了一些特定于使用的安全注意事项，但[DetNet security]（“确定性网络（Detnistic Networking，DetNet）安全注意事项”）中对这些注意事项进行了更全面的讨论。鼓励读者阅读[DetNet Security]，以更全面地了解DetNet相关的安全注意事项。
This document has no IANA actions.
本文档没有IANA操作。
[Ahm14] Ahmed, M. and R. Kim, "Communication Network Architectures for Smart-Wind Power Farms", Energies 2014, pp. 3900-3921, DOI 10.3390/en7063900, June 2014.
[Ahmed，M.和R.Kim，“智能风电场的通信网络架构”，能源2014，第3900-3921页，DOI 10.3390/en7063900，2014年6月。
[Arch-for-6TiSCH] Thubert, P., Ed., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-20, March 2019.
[Arch-for-6TiSCH]Thubert，P.，Ed.“基于IEEE 802.15.4 TSCH模式的IPv6架构”，正在进行的工作，草案-ietf-6TiSCH-Architecture-20，2019年3月。
[BACnet-IP] ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP", January 1999, <http://www.bacnet.org/Addenda/ Add-1995-135a.pdf>.
[BACnet IP]ASHRAE，“ANSI/ASHRAE 135-1995附录J-BACnet/IP”，1999年1月<http://www.bacnet.org/Addenda/ Add-1995-135a.pdf>。
[BAS-DetNet] Kaneko, Y. and S. Das, "Building Automation Use Cases and Requirements for Deterministic Networking", Work in Progress, draft-bas-usecase-detnet-00, October 2015.
[BAS DetNet]Kaneko，Y.和S.Das，“确定性网络的楼宇自动化用例和要求”，在建工程，草稿-BAS-usecase-DetNet-00，2015年10月。
[CoAP-6TiSCH] Sudhaakar, R., Ed. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", Work in Progress, draft-ietf-6tisch-coap-03, March 2015.
[CoAP-6TiSCH]Sudhaakar，R.，Ed.和P.Zand，“使用CoAP的6TiSCH资源管理和交互”，正在进行的工作，草案-ietf-6TiSCH-CoAP-032015年3月。
[CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND ENHANCEMENT", VERSION 2.0, NGMN Alliance, March 2015, <https://www.ngmn.org/fileadmin/user_upload/ NGMN_RANEV_D3_CoMP_Evaluation_and_Enhancement_v2.0.pdf>.
[CoMP]NGMN联盟，“RAN演进项目CoMP评估和增强”，版本2.0，NGMN联盟，2015年3月<https://www.ngmn.org/fileadmin/user_upload/ NGMN_RANEV_D3_CoMP_Evaluation_和_Enhancement_v2.0.pdf>。
[Content_Protection] Olsen, D., "1722a Content Protection", April 2012, <http://grouper.ieee.org/groups/1722/contributions/2012/ avtp_dolsen_1722a_content_protection.pdf>.
[内容保护]Olsen，D.，“172A内容保护”，2012年4月<http://grouper.ieee.org/groups/1722/contributions/2012/ avtp_dolsen_1722a_content_protection.pdf>。
[CPRI] CPRI Cooperation, "Common Public Radio Interface (CPRI); Interface Specification", CPRI Specification V6.1, July 2014, <http://www.cpri.info/downloads/ CPRI_v_6_1_2014-07-01.pdf>.
[CPRI]CPRI合作，“公共无线电接口（CPRI）；接口规范”，CPRI规范V6.12014年7月<http://www.cpri.info/downloads/ CPRI_v_6_1_2014-07-01.pdf>。
[DCI] Digital Cinema Initiatives, LLC, "DCI Specification, Version 1.3", June 2018, <https://www.dcimovies.com/>.
[DCI]数字电影倡议有限责任公司，“DCI规范，版本1.3”，2018年6月<https://www.dcimovies.com/>.
[Det-Fwd-PHB] Shah, S. and P. Thubert, "Deterministic Forwarding PHB", Work in Progress, draft-svshah-tsvwg-deterministic-forwarding-04, August 2015.
[Det Fwd PHB]Shah，S.和P.Thubert，“确定性转发PHB”，正在进行的工作，草稿-svshah-tsvwg-Deterministic-Forwarding-042015年8月。
[DetNet-6TiSCH] Thubert, P., Ed., "6TiSCH requirements for DetNet", Work in Progress, draft-thubert-6tisch-4detnet-01, June 2015.
[DetNet-6Disch]Thubert，P.，Ed.“DetNet的6Disch要求”，在建工程，草稿-Thubert-6Disch-4detnet-012015年6月。
[DetNet-Arch] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", Work in Progress, draft-ietf-detnet-architecture-13, May 2019.
[DetNet Arch]Finn，N.，Thubert，P.，Varga，B.，和J.Farkas，“确定性网络架构”，正在进行的工作，草案-ietf-DetNet-Architecture-13，2019年5月。
[DetNet-Audio-Reqs] Gunther, C., Ed. and E. Grossman, Ed., "Deterministic Networking Professional Audio Requirements", Work in Progress, draft-gunther-detnet-proaudio-req-01, March 2015.
[DetNet音频要求]Gunther，C.，Ed.和E.Grossman，Ed.，“确定性网络专业音频要求”，正在进行的工作，草稿-Gunther-DetNet-proaudio-req-01，2015年3月。
[DetNet-Mobile] Zha, Y., "Deterministic Networking Use Case in Mobile Network", Work in Progress, draft-zha-detnet-use-case-00, July 2015.
[DetNet Mobile]Zha，Y.“移动网络中的确定性网络用例”，正在进行的工作，草稿-Zha-DetNet-Use-Case-00，2015年7月。
[DetNet-RAN] Korhonen, J., "Deterministic networking for radio access networks", Work in Progress, draft-korhonen-detnet-telreq-00, May 2015.
[DetNet RAN]Korhonen，J.，“无线接入网络的确定性网络”，正在进行的工作，草稿-Korhonen-DetNet-telreq-00，2015年5月。
[DetNet-Security] Mizrahi, T., Grossman, E., Ed., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, draft-ietf-detnet-security-04, March 2019.
[DetNet Security]Mizrahi，T.，Grossman，E.，Ed.，Hacker，A.，Das，S.，Dowdell，J.，Austad，H.，Stanton，K.，和N.Finn，“确定性网络（DetNet）安全注意事项”，正在进行中，草案-ietf-DetNet-Security-042019年3月。
[DetNet-Util-Reqs] Wetterwald, P. and J. Raymond, "Deterministic Networking Uitilities requirements", Work in Progress, draft-wetterwald-detnet-utilities-reqs-02, June 2015.
[DetNet utilities Reqs]Wetterwald，P.和J.Raymond，“确定性网络设施要求”，在建工程，草稿-Wetterwald-DetNet-utilities-Reqs-022015年6月。
[eCPRI] IEEE Standards Association, "Common Public Radio Interface: eCPRI Interface Specification V1.2", June 2018, <http://www.cpri.info/>.
[eCPRI]IEEE标准协会，“公共无线电接口：eCPRI接口规范V1.2”，2018年6月<http://www.cpri.info/>.
[ESPN_DC2] Daley, D., "ESPN's DC2 Scales AVB Large", SVG News, June 2014, <https://sportsvideo.org/main/blog/2014/06/ espns-dc2-scales-avb-large>.
[ESPN_DC2]Daley，D.，“ESPN的DC2大规模AVB”，SVG新闻，2014年6月<https://sportsvideo.org/main/blog/2014/06/ espns-dc2-scales-avb-large>。
[EtherCAT] "EtherCAT Technology Group", <https://www.ethercat.org/default.htm>.
[以太猫]“以太猫科技集团”<https://www.ethercat.org/default.htm>.
[FL-net] Japan Electrical Manufacturers Association, "JEMA 1479 - English Edition", September 2012, <https://www.jema-net.or.jp/Japanese/standard/opcn/pdf/ JEM_1479e(20120927).pdf>.
[FL net]日本电气制造商协会，“JEMA 1479-英文版”，2012年9月<https://www.jema-net.or.jp/Japanese/standard/opcn/pdf/ JEM_1479e（20120927）.pdf>。
[Fronthaul] Chen, D. and T. Mustala, "Ethernet Fronthaul Considerations", IEEE 1904.3, February 2015, <http://www.ieee1904.org/3/meeting_archive/2015/02/ tf3_1502_chen_1.pdf>.
[Fronthaul]Chen，D.和T.Mustala，“以太网Fronthaul考虑”，IEEE 1904.3，2015年2月<http://www.ieee1904.org/3/meeting_archive/2015/02/ tf3_1502_chen_1.pdf>。
[IEC-60834] International Electrotechnical Commission, "Teleprotection equipment of power systems - Performance and testing", IEC 60834, October 1999.
[IEC-60834]国际电工委员会，“电力系统远程保护设备-性能和测试”，IEC 60834，1999年10月。
[IEC-60870-5-104] International Electrotechnical Commission, "Telecontrol equipment and systems - Part 5-104: Transmission protocols - Network access for IEC 60870-5-101 using standard transport profiles", IEC 60870-5-104, June 2006.
[IEC-60870-5-104]国际电工委员会，“遥控设备和系统-第5-104部分：传输协议-使用标准传输模式的IEC 60870-5-101网络接入”，IEC 60870-5-104，2006年6月。
[IEC-61400-25] International Electrotechnical Commission, "Communications for monitoring and control of wind power plants", IEC 61400-25, June 2013.
[IEC-61400-25]国际电工委员会，“风力发电厂监控通信”，IEC 61400-252013年6月。
[IEC-61850-5:2013] International Electrotechnical Commission, "Communication networks and systems for power utility automation - Part 5: Communication requirements for functions and device models", IEC 61850-5, January 2013.
[IEC-61850-5:2013]国际电工委员会，“电力设施自动化用通信网络和系统-第5部分：功能和设备型号的通信要求”，IEC 61850-52013年1月。
[IEC-61850-9-2:2011] International Electrotechnical Commission, "Communication networks and systems for power utility automation - Part 9-2: Specific communication service mapping (SCSM) - Sampled values over ISO/IEC 8802-3", IEC 61850-9-2, September 2011.
[IEC-61850-9-2:2011]国际电工委员会，“电力设施自动化用通信网络和系统-第9-2部分：特定通信服务映射（SCSM）-ISO/IEC 8802-3上的采样值”，IEC 61850-9-22011年9月。
[IEC-61850-90-12:2015] International Electrotechnical Commission, "Communication networks and systems for power utility automation - Part 90-12: Wide area network engineering guidelines", IEC TR 61850-90-12, July 2015.
[IEC-61850-90-12:2015]国际电工委员会，“电力设施自动化用通信网络和系统-第90-12部分：广域网工程指南”，IEC TR 61850-90-12，2015年7月。
[IEC-62357-200:2015] International Electrotechnical Commission, "Power systems management and associated information exchange - Part 200: Guidelines for migration from Internet Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6)", IEC 62357-200:2015, July 2015.
[IEC-62357-200:2015]国际电工委员会，“电力系统管理和相关信息交换-第200部分：从互联网协议版本4（IPv4）到互联网协议版本6（IPv6）的迁移指南”，IEC 62357-200:2015，2015年7月。
[IEC-62439-3:2016] International Electrotechnical Commission, "Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)", March 2016.
[IEC-62439-3:2016]国际电工委员会，“工业通信网络-高可用性自动化网络-第3部分：并行冗余协议（PRP）和高可用性无缝冗余（HSR）”，2016年3月。
[IEC-IEEE-61850-9-3:2016] International Electrotechnical Commission, "Communication networks and systems for power utility automation - Part 9-3: Precision time protocol profile for power utility automation", IEC 61850-9-3, May 2016.
[IEC-IEEE-61850-9-3:2016]国际电工委员会，“电力设施自动化的通信网络和系统-第9-3部分：电力设施自动化的精确时间协议概要”，IEC 61850-9-3，2016年5月。
[IEEE-1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, <https://standards.ieee.org/findstds/ standard/1588-2008.html>.
[IEEE-1588]IEEE，“网络测量和控制系统精密时钟同步协议的IEEE标准”，IEEE标准1588<https://standards.ieee.org/findstds/ 标准/1588-2008.html>。
[IEEE-1646] IEEE, "IEEE Standard Communication Delivery Time Performance Requirements for Electric Power Substation Automation", IEEE Standard 1646, <https://standards.ieee.org/standard/1646-2004.html>.
[IEEE-1646]IEEE，“电力变电站自动化的IEEE标准通信交付时间性能要求”，IEEE标准1646<https://standards.ieee.org/standard/1646-2004.html>.
[IEEE-1722] IEEE, "IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks", IEEE Standard 1722, <https://standards.ieee.org/findstds/ standard/1722-2016.html>.
[IEEE-1722]IEEE，“桥接局域网中时间敏感应用传输协议的IEEE标准”，IEEE标准1722<https://standards.ieee.org/findstds/ 标准/1722-2016.html>。
[IEEE-1815] IEEE Standards Association, "IEEE Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3)", IEEE Standard 1815, <https://ieeexplore.ieee.org/ servlet/opac?punumber=6327576>.
[IEEE-1815]IEEE标准协会，“电力系统通信分布式网络协议（DNP3）的IEEE标准”，IEEE标准1815<https://ieeexplore.ieee.org/ servlet/opac？punumber=6327576>。
[IEEE-19143] IEEE Standards Association, "IEEE Standard for Radio over Ethernet Encapsulations and Mappings", IEEE 1914.3, <https://standards.ieee.org/develop/project/1914.3.html>.
[IEEE-19143]IEEE标准协会，“以太网无线电封装和映射的IEEE标准”，IEEE 1914.3<https://standards.ieee.org/develop/project/1914.3.html>.
[IEEE-80211] IEEE Standard for Information technology, "IEEE Std. 802.11, 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", <https://standards.ieee.org/standard/802_11-2016.html>.
[IEEE-80211]IEEE信息技术标准，“IEEE标准802.11，系统间电信和信息交换——局域网和城域网——特殊要求——第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”<https://standards.ieee.org/standard/802_11-2016.html>.
[IEEE-802154] IEEE Standard for Information technology, "IEEE Std. 802.15.4, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs)", <https://standards.ieee.org/standard/802_15_4-2015.html>.
[IEEE-802154]IEEE信息技术标准，“IEEE标准802.15.4，第15.4部分：低速无线个人区域网络（WPAN）的无线媒体访问控制（MAC）和物理层（PHY）规范”<https://standards.ieee.org/standard/802_15_4-2015.html>.
[IEEE-8021AS] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE 802.1AS, <http://www.ieee802.org/1/pages/802.1as.html>.
[IEEE-8021AS]IEEE，“局域网和城域网的IEEE标准-桥接局域网中时间敏感应用的定时和同步”，IEEE 802.1AS<http://www.ieee802.org/1/pages/802.1as.html>.
[IEEE-8021CM] "IEEE Standard for Local and metropolitan area networks - Time-Sensitive Networking for Fronthaul", IEEE Standard 802.1CM, <https://standards.ieee.org/standard/802_1CM-2018.html>.
[IEEE-8021CM]“局域网和城域网的IEEE标准-前线运输的时间敏感网络”，IEEE标准802.1CM<https://standards.ieee.org/standard/802_1CM-2018.html>.
[IEEE-8021TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networking Task Group", <http://www.ieee802.org/1/pages/avbridges.html>.
[IEEE-8021TSNTG]IEEE标准协会，“IEEE 802.1时间敏感网络任务组”<http://www.ieee802.org/1/pages/avbridges.html>.
[IETF99-netslicing-BoF] "Network Slicing (netslicing) BoF", IETF 99, Prague, July 2017, <https://datatracker.ietf.org/meeting/99/ materials/slides-99-netslicing-chairs-netslicing-bof-04>.
[IETF99 Netlicing BoF]“网络切片（Netlicing）BoF”，IETF 99，布拉格，2017年7月<https://datatracker.ietf.org/meeting/99/ 材料/幻灯片-99-netslicing-chairs-netslicing-bof-04>。
[Interface-6TiSCH-6top] Wang, Q., Ed. and X. Vilajosana, "6TiSCH Operation Sublayer (6top) Interface", Work in Progress, draft-ietf-6tisch-6top-interface-04, July 2015.
[Interface-6TiSCH-6top]Wang，Q.，Ed.和X.Vilajosana，“6TiSCH操作子层（6top）接口”，正在进行的工作，草稿-ietf-6TiSCH-6top-Interface-042015年7月。
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", <https://www.isa.org/isa100/>.
[ISA100]ISA/ANSI，“ISA100，自动化无线系统”<https://www.isa.org/isa100/>.
[KNX] KNX Association, "ISO/IEC 14543-3 - KNX", November 2006.
[KNX]KNX协会，“ISO/IEC 14543-3-KNX”，2006年11月。
[LonTalk] Echelon Corp., "LonTalk(R) Protocol Specification Version 3.0", 1994, <http://www.enerlon.com/JobAids/ Lontalk%20Protocol%20Spec.pdf>.
[LonTalk]Echelon公司，“LonTalk（R）协议规范3.0版”，1994年<http://www.enerlon.com/JobAids/ Lontalk%20Protocol%20Spec.pdf>。
[MailingList-6TiSCH] IETF, "6TiSCH Mailing List", <https://mailarchive.ietf.org/arch/browse/6tisch/>.
[MailingList-6Disch]IETF，“6Disch邮件列表”<https://mailarchive.ietf.org/arch/browse/6tisch/>.
[MEF22.1.1] Metro Ethernet Forum, "Mobile Backhaul Phase 2 Amendment 1 -- Small Cells", MEF 22.1.1, July 2014, <http://www.mef.net/Assets/Technical_Specifications/PDF/ MEF_22.1.1.pdf>.
[MEF22.1.1]城域以太网论坛，“移动回程第2阶段修正案1——小小区”，MEF 22.1.12014年7月<http://www.mef.net/Assets/Technical_Specifications/PDF/ MEF_22.1.1.pdf>。
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", MEF 8, October 2004, <https://www.mef.net/ Assets/Technical_Specifications/PDF/MEF_8.pdf>.
[MEF8]城域以太网论坛，“城域以太网上PDH电路仿真的实施协议”，MEF 8，2004年10月<https://www.mef.net/ 资产/技术规范/PDF/MEF_8.PDF>。
[METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and wireless system", Document Number ICT-317669-METIS/D1.1, April 2013, <https://metis2020.com/wp-content/ uploads/deliverables/METIS_D1.1_v1.pdf>.
[METIS]METIS，“5G移动和无线系统的场景、要求和KPI”，文件编号ICT-317669-METIS/D1.11913年4月<https://metis2020.com/wp-content/ 上传/Deliveries/METIS_D1.1_v1.pdf>。
[MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol Specification", April 2012, <http://www.modbus.org/specs.php>.
[MODBUS]MODBUS组织有限公司，“MODBUS应用协议规范”，2012年4月<http://www.modbus.org/specs.php>.
[NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0, February 2015, <https://www.ngmn.org/fileadmin/ngmn/ content/downloads/Technical/2015/ NGMN_5G_White_Paper_V1_0.pdf>.
[NGMN]NGMN联盟，“5G白皮书”，NGMN 5G白皮书v1.0，2015年2月<https://www.ngmn.org/fileadmin/ngmn/ content/downloads/Technical/2015/NGMN_5G_白皮书_V1_0.pdf>。
[NGMN-Fronth] NGMN Alliance, "Fronthaul Requirements for C-RAN", March 2015, <https://www.ngmn.org/fileadmin/user_upload/ NGMN_RANEV_D1_C-RAN_Fronthaul_Requirements_v1.0.pdf>.
[NGMN Fronth]NGMN联盟，“C-RAN的前端运输要求”，2015年3月<https://www.ngmn.org/fileadmin/user_upload/ NGMN_RANEV_D1_C-RAN_Fronthaul_要求_v1.0.pdf>。
[OPCXML] OPC Foundation, "OPC Data Access (OPC DA) Specification", <http://www.opcti.com/opc-da-specification.aspx>.
[OPCXML ] OPC基金会，“OPC数据访问（OPC DA）规范”，<http://www.opcti.com/opc-da-specification.aspx>.
[PCE] IETF, "Path Computation Element", <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[PCE]IETF，“路径计算元素”<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[PROFIBUS] IEC, "PROFIBUS Standard - DP Specification (IEC 61158 Type 3)", <https://www.profibus.com/>.
[PROFIBUS]IEC，“PROFIBUS标准-DP规范（IEC 61158第3类）”<https://www.profibus.com/>.
[PROFINET] "PROFINET Technology", <https://us.profinet.com/technology/profinet/>.
[PROFINET]“PROFINET技术”<https://us.profinet.com/technology/profinet/>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，DOI 10.17487/RFC34112002年12月<https://www.rfc-editor.org/info/rfc3411>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，DOI 10.17487/RFC3985，2005年3月<https://www.rfc-editor.org/info/rfc3985>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, <https://www.rfc-editor.org/info/rfc4553>.
[RFC4553]Vainstein，A.，Ed.和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC 4553，DOI 10.17487/RFC4553，2006年6月<https://www.rfc-editor.org/info/rfc4553>.
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, <https://www.rfc-editor.org/info/rfc5086>.
[RFC5086]Vainstein，A.，Ed.，Sasson，I.，Metz，E.，Frost，T.，和P.Pate，“分组交换网络上的结构感知时分多路复用（TDM）电路仿真服务（CESoPSN）”，RFC 5086，DOI 10.17487/RFC5086，2007年12月<https://www.rfc-editor.org/info/rfc5086>.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, <https://www.rfc-editor.org/info/rfc5087>.
[RFC5087]Stein，Y（J.），Shashoua，R.，Insler，R.，和M.Anavi，“IP时分多路复用（TDMoIP）”，RFC 5087，DOI 10.17487/RFC5087，2007年12月<https://www.rfc-editor.org/info/rfc5087>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<https://www.rfc-editor.org/info/rfc5905>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 6550，DOI 10.17487/RFC6550，2012年3月<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <https://www.rfc-editor.org/info/rfc6551>.
[RFC6551]Vasseur，JP.，Ed.，Kim，M.，Ed.，Pister，K.，Dejean，N.，和D.Barthel，“低功率和有损网络中用于路径计算的路由度量”，RFC 6551，DOI 10.17487/RFC6551，2012年3月<https://www.rfc-editor.org/info/rfc6551>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>.
[RFC7554]Watteyne，T.，Ed.，Palatella，M.，和L.Grieco，“在物联网（IoT）中使用IEEE 802.15.4e时隙信道跳频（TSCH）：问题陈述”，RFC 7554，DOI 10.17487/RFC7554，2015年5月<https://www.rfc-editor.org/info/rfc7554>.
[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., and A. Vainshtein, "Residence Time Measurement in MPLS Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, <https://www.rfc-editor.org/info/rfc8169>.
[RFC8169]Mirsky，G.，Ruffini，S.，Gray，E.，Drake，J.，Bryant，S.，和A.Vainstein，“MPLS网络中的停留时间测量”，RFC 8169，DOI 10.17487/RFC8169，2017年5月<https://www.rfc-editor.org/info/rfc8169>.
[Spe09] Barbosa, R., Sadre, R., and A. Pras, "A First Look into SCADA Network Traffic", IP Network Operations and Management Symposium, DOI 10.1109/NOMS.2012.6211945, June 2012, <https://ieeexplore.ieee.org/document/6211945>.
[Spe09]Barbosa，R.，Sadre，R.，和A.Pras，“SCADA网络流量的首次研究”，IP网络运营和管理研讨会，DOI 10.1109/NOMS.2012.62119452012年6月<https://ieeexplore.ieee.org/document/6211945>.
[SR-IP-RAN-Use-Case] Khasnabish, B., Hu, F., and L. Contreras, "Segment Routing in IP RAN use case", Work in Progress, draft-kh-spring-ip-ran-use-case-02, November 2014.
[SR IP RAN用例]Khasnabish，B.，Hu，F.，和L.Contreras，“IP RAN用例中的段路由”，正在进行的工作，草稿-kh-spring-IP-RAN-用例-022014年11月。
[SRP_LATENCY] Gunther, C., "Specifying SRP Acceptable Latency", March 2014, <http://www.ieee802.org/1/files/public/ docs2014/cc-cgunther-acceptable-latency-0314-v01.pdf>.
[SRP_延迟]Gunther，C.“指定SRP可接受延迟”，2014年3月<http://www.ieee802.org/1/files/public/ docs2014/cc-cgunther-acceptable-latency-0314-v01.pdf>。
[Sublayer-6TiSCH-6top] Wang, Q., Ed. and X. Vilajosana, "6TiSCH Operation Sublayer (6top)", Work in Progress, draft-wang-6tisch-6top-sublayer-04, November 2015.
[子层-6TiSCH-6top]Wang，Q.，Ed.和X.Vilajosana，“6TiSCH操作子层（6top）”，正在进行的工作，草稿-Wang-6TiSCH-6top-Sublayer-042015年11月。
[syncE] International Telecommunication Union, "Timing and synchronization aspects in packet networks", ITU-T Recommendation G.8261, August 2013, <https://www.itu.int/rec/T-REC-G.8261>.
[syncE]国际电信联盟，“分组网络中的定时和同步方面”，ITU-T建议G.82612013年8月<https://www.itu.int/rec/T-REC-G.8261>.
[Timing-over-MPLS] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS Networks", Work in Progress, draft-ietf-tictoc-1588overmpls-07, October 2015.
[MPLS上的定时]Davari，S.，Oren，A.，Bhatia，M.，Roberts，P.，和L.Montini，“通过MPLS网络传输定时消息”，正在进行的工作，草案-ietf-tictoc-1588overmpls-072015年10月。
[TR38801] 3GPP, "Study on new radio access technology: Radio access architecture and interfaces (Release 14)", 3GPP TR 38.801, April 2017, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3056>.
[TR38801]3GPP，“新无线接入技术研究：无线接入体系结构和接口（第14版）”，3GPP TR 38.801，2017年4月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=3056>。
[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)", 3GPP TS 23.401, March 2019, <https://portal.3gpp.org/ desktopmodules/ Specifications/ SpecificationDetails.aspx?specificationId=849>.
[TS23401]3GPP，“通用分组无线业务（GPRS）对演进型通用地面无线接入网（E-UTRAN）接入的增强（第16版）”，3GPP TS 23.4012019年3月<https://portal.3gpp.org/ desktopmodules/Specifications/SpecificationDetails.aspx？specificationId=849>。
[TS23501] 3GPP, "System architecture for the 5G System (5GS) (Release 15)", 3GPP TS 23.501, March 2019, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3144>.
[TS23501]3GPP，“5G系统（5GS）的系统架构（第15版）”，3GPP TS 23.5012019年3月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=3144>。
[TS25104] 3GPP, "Base Station (BS) radio transmission and reception (FDD) (Release 16)", 3GPP TS 25.104, January 2019, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=1154>.
[TS25104]3GPP，“基站（BS）无线传输和接收（FDD）（第16版）”，3GPP TS 25.104，2019年1月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=1154>。
[TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio transmission and reception (Release 16)", 3GPP TS 36.104, January 2019, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=2412>.
[TS36104]3GPP，“演进式通用地面无线接入（E-UTRA）；基站（BS）无线传输和接收（第16版）”，3GPP TS 36.104，2019年1月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=2412>。
[TS36133] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of radio resource management (Release 16)", 3GPP TS 36.133, January 2019, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=2420>.
[TS36133]3GPP，“演进式通用地面无线接入（E-UTRA）；支持无线资源管理的要求（第16版）”，3GPP TS 36.133，2019年1月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=2420>。
[TS36211] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation (Release 15)", 3GPP TS 36.211, January 2019, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=2425>.
[TS36211]3GPP，“演进式通用地面无线接入（E-UTRA）；物理信道和调制（第15版）”，3GPP TS 36.211，2019年1月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=2425>。
[TS36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 15)", 3GPP TS 36.300, January 2019, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=2430>.
[TS36300]3GPP，“演进通用地面无线接入（E-UTRA）和演进通用地面无线接入网络（E-UTRAN）；总体描述；第2阶段（第15版）”，3GPP TS 36.300，2019年1月<https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx？specificationId=2430>。
[WirelessHART] International Electrotechnical Commission, "Industrial networks - Wireless communication network and communication profiles - WirelessHART(TM)", IEC 62591:2016, March 2016.
[WirelessHART]国际电工委员会，“工业网络-无线通信网络和通信配置文件-WirelessHART（TM）”，IEC 62591:2016，2016年3月。
This appendix contains text regarding use cases that have been determined to be outside the scope of the present DetNet work.
本附录包含关于已确定不在本DetNet工作范围内的用例的文本。
The scope of DetNet is deliberately limited to specific use cases that are consistent with the WG charter, subject to the interpretation of the WG. At the time that the DetNet use cases were solicited and provided by the authors, the scope of DetNet was not clearly defined. As the scope has been clarified, certain use cases have been determined to be outside the scope of the present DetNet work. Text regarding these use cases was moved to this appendix to clarify that they will not be supported by the DetNet work.
DetNet的范围被有意地限制在符合工作组章程的特定用例中，但须服从工作组的解释。在作者征求并提供DetNet用例时，DetNet的范围没有明确定义。由于范围已明确，某些用例已被确定为不在当前DetNet工作的范围内。有关这些用例的文本已移至本附录，以澄清DetNet工作将不支持这些用例。
The text was moved to this appendix based on the following "exclusion" principles. Please note that as an alternative to moving all such text to this appendix some text has been modified in situ to reflect these same principles.
根据以下“排除”原则，将文本移至本附录。请注意，作为将所有此类文本移至本附录的替代方案，一些文本已进行了现场修改，以反映这些相同的原则。
The following principles have been established to clarify the scope of the present DetNet work.
为明确目前DetNet工作的范围，制定了以下原则。
o The scope of networks addressed by DetNet is limited to networks that can be centrally controlled, i.e., an "enterprise" (aka "corporate") network. This explicitly excludes "the open Internet".
o DetNet处理的网络范围仅限于可集中控制的网络，即“企业”（又名“公司”）网络。这明确排除了“开放互联网”。
o Maintaining time synchronization across a DetNet network is crucial to its operation; however, DetNet assumes that time is to be maintained using other means. One example would be PTP [IEEE-1588]. A use case may state the accuracy and reliability that it expects from the DetNet network as part of a whole system; however, it is understood that such timing properties are not guaranteed by DetNet itself. At the time of this writing, two open questions remain: (1) whether DetNet protocols will include a way for an application to communicate expectations regarding such timing properties to the network and (2) if so, whether those properties would likely have a material effect on network performance as a result.
o 在DetNet网络上保持时间同步对其运行至关重要；然而，DetNet假设时间是通过其他方式维持的。一个例子是PTP[IEEE-1588]。用例可以说明它期望从作为整个系统一部分的DetNet网络获得的准确性和可靠性；然而，据了解，DetNet本身并不保证此类定时特性。在撰写本文时，还有两个悬而未决的问题：（1）DetNet协议是否包括应用程序向网络传达有关此类定时特性的期望的方式；（2）如果是，这些特性是否可能因此对网络性能产生重大影响。
There are many applications that communicate over the open Internet that could benefit from guaranteed delivery and bounded latency. However, as noted above, all such applications, when run over the open Internet, are out of scope for DetNet. These same applications
有许多通过开放互联网进行通信的应用程序可以受益于有保证的交付和有限的延迟。然而，如上所述，所有此类应用程序在开放互联网上运行时，都超出了DetNet的范围。这些应用程序
may be in scope when run in constrained environments, i.e., within a centrally controlled DetNet network. The following are some examples of such applications.
在受限环境中运行时，可能在范围内，即在集中控制的DetNet网络内。以下是此类应用的一些示例。
Media content delivery continues to be an important use of the Internet, yet users often experience poor-quality audio and video due to the delay and jitter inherent in today's Internet.
媒体内容交付仍然是互联网的一个重要用途，但由于当今互联网固有的延迟和抖动，用户经常会体验到低质量的音频和视频。
Online gaming is a significant part of the gaming market; however, latency can degrade the end user's experience. For example, "First Person Shooter" (FPS) games are highly delay sensitive.
在线游戏是游戏市场的重要组成部分；但是，延迟会降低最终用户的体验。例如，“第一人称射击”（FPS）游戏对延迟非常敏感。
VR has many commercial applications, including real estate presentations, remote medical procedures, and so on. Low latency is critical to interacting with the virtual world, because perceptual delays can cause motion sickness.
虚拟现实有许多商业应用，包括房地产演示、远程医疗程序等。低延迟对于与虚拟世界交互至关重要，因为感知延迟会导致运动病。
Internet service today is by definition "best effort", with no guarantees regarding delivery or bandwidth.
根据定义，今天的互联网服务是“尽力而为”，对于交付或带宽没有任何保证。
One should be able to play Internet videos without glitches and play Internet games without lag.
一个人应该能够在没有故障的情况下播放网络视频，在没有延迟的情况下玩网络游戏。
For online gaming, the desired maximum allowance for round-trip delay is typically 100 ms. However, it may be less for specific types of games; for example, for FPS games, the maximum delay should be 50 ms. Transport delay is the dominant part, with a budget of 5-20 ms.
对于在线游戏，往返延迟的期望最大容差通常为100 ms。但是，对于特定类型的游戏，其可能更小；例如，对于FPS游戏，最大延迟应为50毫秒。交通延迟是主要部分，预算为5-20毫秒。
For VR, a maximum delay of 1-10 ms is needed; if doing remote VR, the total network delay budget is 1-5 ms.
对于VR，需要1-10 ms的最大延迟；如果进行远程虚拟现实，总网络延迟预算为1-5毫秒。
Flow identification can be used for gaming and VR, i.e., it can recognize a critical flow and provide appropriate latency bounds.
流标识可用于游戏和虚拟现实，即，它可以识别关键流并提供适当的延迟边界。
o Unified control and management protocols that handle time-critical data flows
o 处理时间关键型数据流的统一控制和管理协议
o An application-aware flow-filtering mechanism that recognizes time-critical flows without doing 5-tuple matching
o 一种支持应用程序的流过滤机制，无需进行5元组匹配即可识别时间关键流
o A unified control plane that provides low-latency service on Layer 3 without changing the data plane
o 在第3层上提供低延迟服务的统一控制平面，无需更改数据平面
o An OAM system and protocols that can help provide service provisioning that is sensitive to end-to-end delays
o 可以帮助提供对端到端延迟敏感的服务供应的OAM系统和协议
The following text was moved to this appendix because this information is considered a link-layer topic for which DetNet is not directly responsible.
由于该信息被视为链接层主题，DetNet不直接负责，因此将以下文本移至本附录。
Digital Rights Management (DRM) is very important to the audio and video industries. Whenever protected content is introduced into a network, there are DRM concerns that must be taken into account (see [Content_Protection]). Many aspects of DRM are outside the scope of network technology; however, there are cases when a secure link supporting authentication and encryption is required by content owners to carry their audio or video content when it is outside their own secure environment (for example, see [DCI]).
数字版权管理（DRM）对音频和视频行业非常重要。无论何时将受保护的内容引入网络，都必须考虑DRM问题（请参见[内容保护]）。DRM的许多方面超出了网络技术的范围；但是，在某些情况下，当音频或视频内容超出其自身的安全环境（例如，请参见[DCI]）时，内容所有者需要支持身份验证和加密的安全链接来承载其音频或视频内容。
As an example, two such techniques are Digital Transmission Content Protection (DTCP) and High-bandwidth Digital Content Protection (HDCP). HDCP content is not approved for retransmission within any other type of DRM, while DTCP content may be retransmitted under HDCP. Therefore, if the source of a stream is outside of the network and it uses HDCP, it is only allowed to be placed on the network with that same type of protection (i.e., HDCP).
例如，两种这样的技术是数字传输内容保护（DTCP）和高带宽数字内容保护（HDCP）。HDCP内容不允许在任何其他类型的DRM中重新传输，而DTCP内容可以在HDCP下重新传输。因此，如果流的源在网络之外并且它使用HDCP，则只允许将其放置在具有相同类型保护（即HDCP）的网络上。
Note: The term "link aggregation" is used here as defined by the text in the following paragraph, i.e., not following a more common network-industry definition.
注：此处使用的术语“链路聚合”由以下段落中的文本定义，即，不遵循更常见的网络行业定义。
For transmitting streams that require more bandwidth than a single link in the target network can support, link aggregation is a technique for combining (aggregating) the bandwidth available on multiple physical links to create a single logical link that provides
对于传输需要比目标网络中单个链路所能支持的带宽更多的流，链路聚合是一种组合（聚合）多个物理链路上可用带宽以创建单个逻辑链路的技术，该链路提供
the required bandwidth. However, if aggregation is to be used, the network controller (or equivalent) must be able to determine the maximum latency of any path through the aggregate link.
所需的带宽。但是，如果要使用聚合，网络控制器（或等效设备）必须能够确定通过聚合链路的任何路径的最大延迟。
The DetNet WG decided that guidelines for establishing a deterministic time to establish stream startup are not within the scope of DetNet. If the bounded timing for establishing or re-establishing streams is required in a given use case, it is up to the application/system to achieve it.
DetNet工作组决定，确定确定流启动时间的指南不在DetNet的范围内。如果在给定用例中需要建立或重新建立流的有界定时，则由应用程序/系统来实现。
Acknowledgments
致谢
Pro audio (Section 2)
专业音频（第2节）
As also acknowledged in [DetNet-Audio-Reqs], the editor would like to acknowledge the help of the following individuals and the companies they represent.
正如[DetNet Audio Reqs]中所述，编辑希望感谢以下个人及其代表的公司的帮助。
Jeff Koftinoff, Meyer Sound Jouni Korhonen, Associate Technical Director, Broadcom Pascal Thubert, CTAO, Cisco Kieran Tyrrell, Sienda New Media Technologies GmbH
Jeff Koftinoff，Meyer Sound Jouni Korhonen，Broadcom Pascal Thubert，CTAO，Cisco Kieran Tyrrell，Sienda新媒体技术有限公司副技术总监
Utility telecom (Section 3)
公用电信（第3节）
Information regarding utility telecom was derived from [DetNet-Util-Reqs]. As in that document, the following individuals are acknowledged here.
有关公用电信的信息来源于[DetNet Util Reqs]。与该文件一样，在此确认以下个人。
Faramarz Maghsoodlou, Ph.D., IoT Connected Industries and Energy Practice, Cisco Pascal Thubert, CTAO, Cisco
Faramarz Maghsoodlou博士，物联网产业和能源实践，思科帕斯卡·苏伯特，CTAO，思科
The wind power generation use case has been extracted from the study of wind parks conducted within the 5GPPP VirtuWind Project. The project is funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 671648 (VirtuWind).
风力发电用例摘自5GPP VirtuWind项目内进行的风力发电场研究。该项目由欧盟地平线2020研究和创新计划资助，协议号为671648（VirtuWind）。
Building automation systems (Section 4)
楼宇自动化系统（第4节）
Please see [BAS-DetNet].
请参阅[BAS DetNet]。
Wireless for industrial applications (Section 5)
工业无线应用（第5节）
See [DetNet-6TiSCH].
见[DetNet-6Disch]。
[DetNet-6TiSCH] derives from the 6TiSCH architecture, which is the result of multiple interactions -- in particular, during the 6TiSCH (bi)weekly interim call, relayed through the 6TiSCH mailing list at the IETF [MailingList-6TiSCH].
[DetNet-6TiSCH]源自6TiSCH体系结构，它是多种交互的结果——特别是在6TiSCH（每两周）临时呼叫期间，通过IETF[MailingList-6TiSCH]上的6TiSCH邮件列表中继。
As also acknowledged in [DetNet-6TiSCH], the editor wishes to thank Kris Pister, Thomas Watteyne, Xavier Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon, Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey, Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation and various contributions.
正如[DetNet-6TiSCH]中所述，编辑希望感谢克里斯·皮斯特、托马斯·瓦特因、泽维尔·维拉戈萨纳、秦旺、汤姆·菲尼、罗伯特·阿西米蒂、迈克尔·理查森、卓晨、玛丽莎·武奇尼奇、阿尔弗雷多·格里奥、马丁·图隆、多米尼克·巴瑟尔、埃尔维斯·沃格利、纪尧姆·盖拉德、赫尔曼·斯托里、玛丽亚·丽塔·巴拉泰拉、尼古拉·阿克图拉、，Patrick Wetterwald、Pouria Zand、Raghuram Sudhaakar和Shitanshu Shah感谢他们的参与和各种贡献。
Cellular radio (Section 6)
蜂窝无线电（第6节）
See [DetNet-RAN].
见[DetNet RAN]。
Internet applications and CoMP (Section 6)
互联网应用和CoMP（第6节）
As also acknowledged in [DetNet-Mobile], authored by Yiyong Zha, the editor would like to thank the following people for their reviews, suggestions, comments, and proposed text: Jing Huang, Junru Lin, Lehong Niu, and Oliver Huang.
正如查一勇（Yiyong Zha）所著的[DetNet Mobile]所承认的，编辑要感谢以下人士的评论、建议、评论和建议文本：黄晶、林俊如、牛乐宏和黄立伟。
Industrial Machine to Machine (M2M) (Section 7)
工业机器对机器（M2M）（第7节）
The editor would like to thank Feng Chen and Marcel Kiessling for their comments and suggestions.
编辑要感谢陈峰和基斯林的评论和建议。
Mining industry (Section 8)
采矿业（第8节）
This text was written by Diego Dujovne, who worked in conjunction with Xavier Vilajosana.
本文由迭戈·杜乔夫内（Diego Dujovne）撰写，他与泽维尔·维拉乔萨纳（Xavier Vilajosana）合作。
Private blockchain (Section 9)
私有区块链（第9节）
This text was written by Daniel Huang.
这篇课文是丹尼尔·黄写的。
Network slicing (Section 10)
网络切片（第10节）
This text was written by Xuesong Geng, who would like to acknowledge Norm Finn and Mach Chen for their useful comments.
这篇文章是由耿学松写的，他想感谢范姆·芬恩和马赫·陈的有用评论。
Contributors
贡献者
RFC 7322 ("RFC Style Guide") generally limits the number of authors listed on the front page of a document to five individuals -- far fewer than the 19 individuals listed below, who also made important contributions to this document. The editor wishes to thank and acknowledge each of the following authors for contributing text to this document. See also the Acknowledgments section.
RFC 7322（“RFC风格指南”）通常将文件首页上列出的作者人数限制为5人，远远少于下面列出的19人，他们也对本文件做出了重要贡献。编辑希望感谢并感谢以下每一位作者为本文件提供文本。另请参见“确认”部分。
Craig Gunther (Harman International) 10653 South River Front Parkway South Jordan, UT 84095 United States of America Phone: +1 801 568 7675 Email: craig.gunther@harman.com
克雷格·冈瑟（哈曼国际）10653南河畔公园路南约旦，UT 84095美利坚合众国电话：+1801 568 7675电子邮件：克雷格。gunther@harman.com
Pascal Thubert (Cisco Systems, Inc.) Building D, 45 Allee des Ormes - BP1200 Mougins - Sophia Antipolis 06254 France Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com
Pascal Thubert（思科系统公司）D栋45 Allee des Ormes-BP1200 Mougins-Sophia Antipolis 06254法国电话：+33 4 97 23 26 34电子邮件：pthubert@cisco.com
Patrick Wetterwald (Cisco Systems) 45 Allee des Ormes Mougins 06250 France Phone: +33 4 97 23 26 36 Email: pwetterw@cisco.com
Patrick Wetterwald（思科系统）45 Allee des Ormes Mougins 06250法国电话：+33 4 97 23 26 36电子邮件：pwetterw@cisco.com
Jean Raymond (Hydro-Quebec) 1500 University Montreal, Quebec H3A 3S7 Canada Phone: +1 514 840 3000 Email: raymond.jean@hydro.qc.ca
Jean Raymond（魁北克水电）1500大学魁北克蒙特利尔H3A 3S7加拿大电话：+1 514 840 3000电子邮件：Raymond。jean@hydro.qc.ca
Jouni Korhonen (Broadcom Corporation) 3151 Zanker Road San Jose, CA 95134 United States of America Email: jouni.nospam@gmail.com
Jouni Korhonen（Broadcom Corporation）美国加利福尼亚州圣何塞市赞克路3151号，邮编95134电子邮件：Jouni。nospam@gmail.com
Yu Kaneko (Toshiba) 1 Komukai-Toshiba-cho Saiwai-ku, Kasasaki-shi, Kanagawa Japan Email: yu1.kaneko@toshiba.co.jp
Yu Kaneko（东芝）1 Komukai Toshiba cho Saiwai ku，Kasasaki shi，神奈川日本电子邮件：yu1。kaneko@toshiba.co.jp
Subir Das (Vencore Labs) 150 Mount Airy Road Basking Ridge, NJ 07920 United States of America Email: sdas@appcomsci.com
Subir Das（Vencore实验室）150 Mount Airy Road Basking Ridge，NJ 07920美利坚合众国电子邮件：sdas@appcomsci.com
Balazs Varga (Ericsson) Konyves Kalman krt. 11/B Budapest 1097 Hungary Email: balazs.a.varga@ericsson.com
Balazs Varga（爱立信）Konyves Kalman krt。11/B布达佩斯1097匈牙利电子邮件：balazs.a。varga@ericsson.com
Janos Farkas (Ericsson) Konyves Kalman krt. 11/B Budapest 1097 Hungary Email: janos.farkas@ericsson.com
雅诺斯·法卡斯（爱立信）科尼维斯·卡尔曼·克尔特。11/B布达佩斯1097匈牙利电子邮件：janos。farkas@ericsson.com
Franz-Josef Goetz (Siemens) Gleiwitzerstr. 555 Nurnberg 90475 Germany Email: franz-josef.goetz@siemens.com
Franz Josef Goetz（西门子）Gleiwizerstr。555纽伦堡90475德国电子邮件：franz josef。goetz@siemens.com
Juergen Schmitt (Siemens) Gleiwitzerstr. 555 Nurnberg 90475 Germany Email: juergen.jues.schmitt@siemens.com
Juergen Schmitt（西门子）Gleiwizerstr。555纽伦堡90475德国电子邮件：juergen.jues。schmitt@siemens.com
Xavier Vilajosana (Worldsensing) 483 Arago Barcelona, Catalonia 08013 Spain Email: xvilajosana@worldsensing.com
Xavier Vilajosana（世界感应）483加泰罗尼亚巴塞罗那阿拉戈08013西班牙电子邮件：xvilajosana@worldsensing.com
Toktam Mahmoodi (King's College London) Strand, London WC2R 2LS United Kingdom Email: toktam.mahmoodi@kcl.ac.uk
Toktam Mahmoodi（伦敦国王学院）Strand，伦敦WC2R 2LS英国电子邮件：Toktam。mahmoodi@kcl.ac.uk
Spiros Spirou (Intracom Telecom) 19.7 km Markopoulou Ave. Peania, Attiki 19002 Greece Email: spiros.spirou@gmail.com
Spiros Spirou（Inracom Telecom）19.7公里，地址：希腊阿提基市皮亚尼亚马科普鲁大道19002号电子邮件：Spiros。spirou@gmail.com
Petra Vizarreta (Technical University of Munich) Maxvorstadt, Arcisstrasse 21 Munich 80333 Germany Email: petra.stojsavljevic@tum.de
Petra Vizarreta（慕尼黑工业大学）Max VistaDt，ARCISSTRASE 21慕尼黑80333德国电子邮件：PeTRA.stojsavljevic@tum.de
Daniel Huang (ZTE Corporation, Inc.) No. 50 Software Avenue Nanjing, Jiangsu 210012 China Email: huang.guangping@zte.com.cn
Daniel Huang（中兴通讯股份有限公司）江苏南京软件大道50号210012中国电子邮件：Huang。guangping@zte.com.cn
Xuesong Geng (Huawei Technologies) Email: gengxuesong@huawei.com
耿学松（华为技术）电子邮件：gengxuesong@huawei.com
Diego Dujovne (Universidad Diego Portales) Email: diego.dujovne@mail.udp.cl
Diego Dujovne（Diego Portales大学）电子邮件：Diego。dujovne@mail.udp.cl
Maik Seewald (Cisco Systems) Email: maseewal@cisco.com
Maik Seewald（思科系统）电子邮件：maseewal@cisco.com
Author's Address
作者地址
Ethan Grossman (editor) Dolby Laboratories, Inc. 1275 Market Street San Francisco, CA 94103 United States of America
Ethan Grossman（编辑）杜比实验室，公司1275市场街旧金山，CA 94103美利坚合众国
Phone: +1 415 645 4726
Email: ethan.grossman@dolby.com
URI: http://www.dolby.com
Phone: +1 415 645 4726
Email: ethan.grossman@dolby.com
URI: http://www.dolby.com