RAW
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Internet-Draft
Intended status:
Request for Comments: 9913
Category: Informational D. Cavalcanti
Expires: 17 October 2025
ISSN: 2070-1721 Intel
X. Vilajosana
Universitat Oberta de Catalunya
C. Schmitt
Research Institute CODE, UniBw M
J. Farkas
Ericsson
15 April 2025
February 2026
Reliable and Available Wireless (RAW) Technologies
draft-ietf-raw-technologies-17
Abstract
This document surveys the short short- and middle range middle-range radio technologies
that are suitable to provide
over which providing a Deterministic Networking (DetNet) / Reliable
and Available Wireless (RAW) service over, is suitable, presents the
characteristics that RAW may leverage, and explores the applicability
of the technologies to carry deterministic flows, as of its the time of
publication. The studied technologies are Wi-Fi 6/7, TimeSlotted Time-Slotted
Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical
Communications System (LDACS).
Status of This Memo
This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents valid
approved by the IESG are candidates for a maximum any level of six months Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 October 2025.
https://www.rfc-editor.org/info/rfc9913.
Copyright Notice
Copyright (c) 2025 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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 Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Towards Reliable and Available Wireless Networks . . . . . . 5
3.1. Scheduling for Reliability . . . . . . . . . . . . . . . 5
3.2. Diversity for Availability . . . . . . . . . . . . . . . 5
3.3. Benefits of Scheduling . . . . . . . . . . . . . . . . . 6
4. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Provenance and Documents . . . . . . . . . . . . . . . . 8
4.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . . . 10
4.2.1. General Characteristics . . . . . . . . . . . . . . . 10
4.2.2. Applicability to Deterministic Flows . . . . . . . . 11
4.3. 802.11be Extreme High Throughput (EHT) . . . . . . . . . 13
4.3.1. General Characteristics . . . . . . . . . . . . . . . 13
4.3.2. Applicability to Deterministic Flows . . . . . . . . 14
4.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . . . 15 Operation)
4.4.1. General Characteristics . . . . . . . . . . . . . . . 15
4.4.2. Applicability to deterministic flows . . . . . . . . 15 Deterministic Flows
5. IEEE 802.15.4 Timeslotted Time-Slotted Channel Hopping . . . . . . . . . . 16 (TSCH)
5.1. Provenance and Documents . . . . . . . . . . . . . . . . 16
5.2. General Characteristics . . . . . . . . . . . . . . . . . 18
5.2.1. 6TiSCH Tracks . . . . . . . . . . . . . . . . . . . . 19
5.3. Applicability to Deterministic Flows . . . . . . . . . . 23
5.3.1. Centralized Path Computation . . . . . . . . . . . . 24
6. 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Provenance and Documents . . . . . . . . . . . . . . . . 29
6.2. General Characteristics . . . . . . . . . . . . . . . . . 31
6.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 33
6.4. Applicability to Deterministic Flows . . . . . . . . . . 34
6.4.1. System Architecture . . . . . . . . . . . . . . . . . 34
6.4.2. Overview of The the Radio Protocol Stack . . . . . . . . 36
6.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 37
6.4.4. Scheduling and QoS (MAC) . . . . . . . . . . . . . . 39
6.4.5. Time-Sensitive Communications (TSC) . . . . . . . . . 41
7. L-band L-Band Digital Aeronautical Communications System . . . . . . 46 (LDACS)
7.1. Provenance and Documents . . . . . . . . . . . . . . . . 46
7.2. General Characteristics . . . . . . . . . . . . . . . . . 47
7.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 48
7.4. Applicability to Deterministic Flows . . . . . . . . . . 49
7.4.1. System Architecture . . . . . . . . . . . . . . . . . 49
7.4.2. Overview of the Radio Protocol Stack . . . . . . . . 49
7.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 51
7.4.4. Scheduling, Frame Structure Structure, and QoS (MAC) . . . . . . 52
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9. Security Considerations . . . . . . . . . . . . . . . . . . . 55
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
12. References
10.1. Normative References . . . . . . . . . . . . . . . . . . . . 55
13.
10.2. Informative References . . . . . . . . . . . . . . . . . . . 56
Acknowledgments
Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction
Deterministic Networking (DetNet) [RFC8557] provides a capability to
carry specified unicast or multicast data flows for real-time
applications with extremely low data loss rates and bounded latency
within a network domain. Techniques that might be used include (1)
reserving data-plane data plane resources for individual (or aggregated) DetNet
flows in some or all of the intermediate nodes along the path of the
flow, (2) providing explicit routes for DetNet flows that do not
immediately change with the network topology, and (3) distributing
data from DetNet flow packets over time and/or space (e.g., different
frequencies,
frequencies or non-Shared Risk Links) non-shared risk links) to ensure delivery of each
packet in spite of the unavailability of a path.
DetNet operates at the IP layer and typically delivers service over
wired lower-layer technologies such as Time-Sensitive Networking
(TSN) as defined by IEEE 802.1 and IEEE 802.3.
The Reliable and Available Wireless (RAW) Architecture
[I-D.ietf-raw-architecture] architecture [RFC9912]
extends the DetNet Architecture architecture [RFC8655] to adapt to the specific
challenges of the wireless medium, in
particular particular, intermittently
lossy connectivity, by optimizing the use of diversity and
multipathing. [I-D.ietf-raw-architecture] [RFC9912] defines the concepts of Reliability reliability and Availability
availability that are used in this document. In turn, this document
presents wireless technologies with
capabilities capabilities, such as time
synchronization and scheduling of transmission, that would make RAW/DetNet RAW/
DetNet operations possible over such media. The technologies studied
in this document were identified in the charter during the RAW WG
Working Group (WG) formation and inherited by DetNet (when the WG
picked up the work on RAW).
Making wireless reliable and available is even more challenging than
it is with wires, due to the numerous causes of radio transmission
losses that add up to the congestion losses and the delays caused by
overbooked shared resources.
RAW, like DetNet, needs and leverages lower-layer capabilities such
as time synchronization and traffic shapers. To balance the adverse
effects of the radio transmission losses, RAW leverages additional
lower-layer capabilities, some of which may be specific or at least
more typically applied to wireless. Such lower-layer techniques
include:
* per-hop retransmissions (aka (also known as Automatic Repeat Request or ARQ),
(ARQ)),
* variation of the modulation Modulation and coding scheme Coding Scheme (MCS),
* short range short-range broadcast,
* Multiple User Multi-User - Multiple Input Multiple Output (MU-MIMO),
* constructive interference, and
* overhearing whereby multiple receivers are scheduled to receive
the same transmission, which saves both energy on the sender and
spectrum.
These capabilities may be offered by the lower layer and may be
controlled by RAW, separately or in combination.
RAW defines a network-layer control loop that optimizes the use of
links with constrained spectrum and energy while maintaining the
expected connectivity properties, typically reliability and latency.
The control loop involves communication monitoring through
Operations, Administration Administration, and Maintenance (OAM), (OAM); path control
through a Path computation Computation Element (PCE) and a runtime distributed
Path Selection Engine (PSE) (PSE); and extended packet replication,
elimination, Packet Replication,
Elimination, and ordering functions Ordering Functions (PREOF).
This document surveys the short short- and middle range middle-range radio technologies
that are suitable to provide
over which providing a DetNet/RAW service over, is suitable, presents the
characteristics that RAW may leverage, and explores the applicability
of the technologies to carry deterministic flows. The studied
technologies are Wi-Fi 6/7, TimeSlotted Time-Slotted Channel Hopping (TSCH), 3GPP
5G, and L-band Digital Aeronautical Communications System (LDACS).
The purpose of this document is to support and enable work on the
these (and possibly other similar compatible technologies) at the
IETF
IETF, specifically in the DetNet working group Working Group working on RAW.
This document surveys existing networking technology and defines no technology; it does not
define protocol behaviors or operational practices. The IETF
specifications referenced herein each provide their own Security Considerations, security
considerations, and
lower layer lower-layer technologies provide their own
security at Layer-2; Layer 2; a security study of the technologies is
explicitly not in scope.
2. Terminology
This document uses the terminology and acronyms defined in Section 2
of [RFC8655] and Section 2 3 of [I-D.ietf-raw-architecture]. [RFC9912].
3. Towards Reliable and Available Wireless Networks
3.1. Scheduling for Reliability
A packet network is reliable for critical (e.g., time-sensitive)
packets when the undesirable statistical effects that affect the
transmission of those packets, e.g., packets (e.g., delay or loss, loss) are eliminated.
The reliability of a Deterministic Network deterministic network [RFC8655] often relies on
precisely applying a tight schedule that controls the use of time-
shared resources such as CPUs and buffers, and maintains at all time times
the amount number of the critical packets within the available resources of
the communication hardware (e.g.; (e.g., buffers) and that of the transmission
medium (e.g.; (e.g., bandwidth, transmission slots). The schedule can also
be used to shape the flows by controlling the time of transmission of
the packets that compose the flow at every hop.
To achieve this, there must be a shared sense of time throughout the
network. The sense of time is usually provided by the lower layer
and is not in scope for RAW. As an example, the Precision Time
Protocol,
Protocol (PTP), standardized as IEEE 1588 and IEC 61588, has mapping
through profiles to Ethernet, industrial and SmartGrid protocols, and
Wi-Fi with IEEE Std 802.1AS.
3.2. Diversity for Availability
Equipment (e.g., node) failure, for instance a broken switch or an
access point rebooting, a broken wire or radio adapter, or a fixed
obstacle to the transmission, failure can be the cause of multiple packets
being lost in a row before the flows are rerouted or the system may
recover.
This
recovers. Examples of equipment failure include a broken switch, an
access point rebooting, a broken wire or radio adapter, or a fixed
obstacle to the transmission.
Equipment failure is not acceptable for critical applications such as
those related to safety. A typical process control loop will
tolerate an occasional packet loss, but a loss of several packets in
a row will cause an emergency stop. In an amusement ride (e.g., at
Disneyland,
Universal, Universal Studios, or MGM Studios parks) parks), a continuous
loss of packet packets for a few 100ms 100 ms may trigger an automatic
interruption of the ride and cause the evacuation of the attraction
floor to restart it.
Network Availability availability is obtained by making the transmission resilient
against hardware failures and radio transmission losses due to
uncontrolled events such as co-channel interferers, multipath fading fading,
or moving obstacles. The best results are typically achieved by
pseudo-randomly
pseudorandomly cumulating all forms of diversity, diversity -- in the spatial
domain with replication and elimination, in the time domain with ARQ
and diverse scheduled transmissions, and in the frequency domain with
frequency hopping or channel hopping between frames.
3.3. Benefits of Scheduling
Scheduling redundant transmissions of the critical packets on diverse
paths improves the resiliency against breakages and statistical
transmission loss, such as those due to cosmic particles on wires, wires and
interferences on wireless. While transmission losses are orders of
magnitude more frequent on wireless, redundancy and diversity are
needed in all cases for life- and mission-critical applications.
When required, the worst case worst-case time of delivery can be guaranteed as
part of the end-to-end schedule, and the sense of time that must be
shared throughout the network can be exposed to and leveraged by
other applications.
In addition, scheduling provides specific value over the wireless
medium:
* Scheduling allows a time-sharing operation, where every
transmission is assigned its own time/frequency resource. Sender The
sender and receiver are synchronized and scheduled to talk on a
given frequency resource at a given time and for a given duration.
This way, scheduling can avoid collisions between scheduled
transmissions and enable a high ratio of critical traffic (think
60
60% or 70% of high priority high-priority traffic with ultra low loss) compared
to statistical priority-based schemes.
* Scheduling can be used as a technique for both time and frequency
diversity (e.g., between transmission retries), allowing the next
transmission to happen on a different frequency as programmed in
both the sender and the receiver. This is useful to defeat co-
channel interference from un-controlled uncontrolled transmitters as well as
multipath fading.
* Transmissions can be also scheduled on multiple channels in
parallel, which enables using the use of the full available spectrum
while avoiding the hidden terminal problem, e.g., when the next
packet in a same flow interferes on a same channel with the
previous one that progressed a few hops farther.
* On the other hand, scheduling Scheduling optimizes the bandwidth usage:
compared usage. Compared to classical Collision Avoidance
collision avoidance techniques, there is no blank time related to inter-frame space
Interframe Space (IFS) and exponential back-off in scheduled
operations. A minimal Clear Channel
Assessment clear channel assessment may be needed to
comply with the local regulations such as ETSI 300-328, but that
will not detect a collision when the senders are synchronized.
* Finally, scheduling Scheduling plays a critical role to save in saving energy. In IoT, the
Internet of Things (IoT), energy is the foremost concern, and
synchronizing the sender and listener enables always maintaining
them in deep sleep when there is no scheduled transmission. This
avoids idle listening and long
preambles preambles, and it enables long
sleep periods between traffic and resynchronization, allowing
battery-operated nodes to operate in a mesh topology for multiple
years.
4. IEEE 802.11
In the recent years, the evolution of the IEEE Std 802.11 standard has
taken a new direction, emphasizing improved reliability and reduced
latency in addition to minor improvements in speed, to enable new
fields of application such as Industrial industrial IoT and Virtual Reality. Reality
(VR).
Leveraging IEEE Std 802.11, the Wi-Fi Alliance [WFA] delivered Wi-Fi
6, 7, and now 8 with more capabilities to schedule and deliver frames
in due time at fast rates. Still, as with any radio technology, Wi-Fi Wi-
Fi is sensitive to frame loss, which can only be combated with the
maximum use of diversity, diversity in space, time, channel, and even
technology.
In parallel, the Avnu Alliance [Avnu], which focuses on applications
of TSN for real time real-time data, formed a workgroup for uses case with TSN
capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11
standards.
To achieve the latter, the reliability must be handled at an upper
layer that can select Wi-Fi and other wired or wireless technologies
for parallel transmissions. This is where RAW comes into play.
This section surveys the IEEE 802.11 features that are most relevant
to RAW, noting that there are a great many more in the specification,
some of which may also possibly be of interest as well for a RAW solution.
For instance, frame fragmentation reduces the impact of a very
transient transmission loss, both on latency and energy consumption.
4.1. Provenance and Documents
The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains
networking standards and recommended practices for local,
metropolitan, and other area networks, networks using an open and accredited
process, and it advocates them on a global basis. The most widely
used standards are for Ethernet, Bridging and Virtual Bridged LANs LAN,
Wireless LAN, Wireless PAN, Personal Area Network (PAN), Wireless MAN,
Wireless Coexistence, Media Independent Handover Services, and
Wireless RAN. Radio Access Network (RAN). An individual
Working Group working group
provides the focus for each area.
The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying
MAC
Medium Access Control (MAC) and PHY Physical (PHY) layers for the Wi-Fi
technology. While previous 802.11 generations, such as 802.11n and
802.11ac, have focused mainly on improving peak throughput, more recent
generations are also considering other performance vectors, such as
efficiency enhancements for dense environments in IEEEE Std 802.11ax [IEEE Std
802.11ax]
[IEEE802.11ax] (approved in 2021), 2021) and throughput, latency, and
reliability enhancements in P802.11be [IEEE 802.11be] IEEE Std 802.11be [IEEE802.11be]
(approved in 2024).
IEEE Std 802.11-2012 includes support for TSN time synchronization
based on IEEE 802.1AS over the 802.11 Timing Measurement protocol.
IEEE Std 802.11-2016 additionally includes an extension to the
802.1AS operation over 802.11 for Fine Timing Measurement (FTM), as
well as the Stream Reservation Protocol (IEEE 802.1Qat). 802.11 WLANs
can also be part of a 802.1Q bridged networks with enhancements enabled
by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020.
Traffic classification based on 802.1Q VLAN tags is also supported in
802.11. Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB,
which are media agnostic, can already operate over 802.11. The IEEE
Std 802.11ax-2021 defines additional scheduling capabilities that can
enhance the timeliness performance in the 802.11 MAC and achieve
lower bounded
lower-bounded latency. The IEEE 802.11be has introduced introduces features to enhance
the support for 802.1 TSN capabilities capabilities, especially those related to
worst-case latency, reliability reliability, and availability.
The IEEE 802.11 working group Working Group has been working in collaboration with
the IEEE 802.1 working group Working Group for several years years, extending some 802.1
features over 802.11. As with any wireless media, 802.11 imposes new
constraints and restrictions to TSN-grade QoS, and tradeoffs trade-offs between
latency and reliability guarantees must be considered as well as
managed deployment requirements. An overview of 802.1 TSN
capabilities and challenges for their extensions to 802.11 are
discussed in [Cavalcanti_2019].
The Wi-Fi Alliance is the worldwide network of companies that drives
global Wi-Fi adoption and evolution through thought leadership,
spectrum advocacy, and industry-wide collaboration. The WFA work
helps ensure that Wi-Fi devices and networks provide users the
interoperability, security, and reliability they have come to expect.
The Avnu Alliance is also a global industry forum developing
interoperability testing for TSN capable TSN-capable devices across multiple
media including Ethernet, Wi-Fi, and 5G.
The following [IEEE IEEE Std 802.11] 802.11 specifications/certifications
[IEEE802.11] are relevant in the context of reliable and available
wireless services and support for time-sensitive networking TSN capabilities:
* Time Synchronization: IEEE802.11-2016 synchronization: IEEE Std 802.11-2016 with IEEE802.1AS; IEEE Std 802.1AS;
WFA TimeSync
Certification. Certification
* Congestion Control: control: IEEE Std 802.11-2016 Admission Control; WFA
Admission Control. Control
* Security: WFA Wi-Fi Protected Access, WPA2 WPA2, and WPA3. WPA3
* Interoperating with IEEE802.1Q IEEE 802.1Q bridges: IEEE Std 802.11-2020
incorporating 802.11ak. 802.11ak
* Stream Reservation Protocol (part of [IEEE Std 802.1Qat]): [IEEE802.1Qat]):
AIEEE802.11-2016
* Scheduled channel access: IEEE802.11ad Enhancements IEEE 802.11ad enhancements for very high
throughput in the 60 GHz band [IEEE Std 802.11ad]. [IEEE802.11ad]
* 802.11 Real-Time Applications: Topic Interest Group (TIG)
ReportDoc
[IEEE_doc_11-18-2009-06]. [IEEE_doc_11-18-2009-06]
In addition, major amendments being developed by the IEEE802.11 IEEE 802.11
Working Group include capabilities that can be used as the basis for
providing more reliable and predictable wireless connectivity and
support time-sensitive applications:
IEEE 802.11ax:
* [IEEE802.11ax]: Enhancements for High Efficiency (HE). [IEEE Std
802.11ax]
IEEE 802.11be (HE)
* [IEEE802.11be]: Extreme High Throughput (EHT). [IEEE 802.11be]
IEE 802.11ay (EHT)
* [IEEE802.11ay]: Enhanced throughput for operation in license-exempt license-
exempt bands above 45 GHz. [IEEE Std 802.11ay] GHz
The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and
their relevance to RAW are discussed in the remainder of this
section. As P802.11bn is still in early stages of development, its
capabilities are not included in this document.
4.2. 802.11ax High Efficiency (HE)
4.2.1. General Characteristics
The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax
amendment [IEEE IEEE Std 802.11ax], 802.11ax
amendment [IEEE802.11ax], which includes specific capabilities to
increase efficiency, control and reduce latency. Some of these
features include higher order higher-order 1024-QAM modulation, support for uplink
multiple user (MU) multiple input multiple output (MIMO), orthogonal
frequency-division multiple access
Multi-User - Multiple Input Multiple Output (MU-MIMO), Orthogonal
Frequency-Division Multiple Access (OFDMA), trigger-based access access, and
Target Wake time Time (TWT) for enhanced power savings. The OFDMA mode
and trigger-based access enable the AP, Access Point (AP), after
reserving the channel using the clear channel assessment procedure
for a given duration, to schedule multi-user transmissions, which is
a key capability required to increase latency predictability and
reliability for time-sensitive flows. 802.11ax can operate in up to
160 MHz channels channels, and it includes support for operation in the new 6
GHz band, which has been open to unlicensed use by the FCC Federal
Communications Commission (FCC) and other regulatory agencies
worldwide.
4.2.1.1. Multi-User OFDMA and Trigger-based Trigger-Based Scheduled Access
802.11ax introduced an OFDMA mode in which multiple users can be
scheduled across the frequency domain. In this mode, the Access
Point (AP) can initiate multi-user (MU) Uplink uplink (UL) transmissions in the
same PHY Protocol Data Unit (PPDU) by sending a trigger frame. This
centralized scheduling capability gives the AP much more control of
the channel in its Basic Service Set (BSS) (BSS), and it can remove
contention between associated stations for uplink transmissions,
therefore reducing the randomness caused by CSMA-based access based on Carrier
Sense Multiple Access (CSMA) between stations within the same BSS.
The AP can also transmit simultaneously to multiple users in the
downlink direction by using a
Downlink downlink (DL) MU OFDMA PPDU. In order
to initiate a contention free contention-free Transmission Opportunity (TXOP) using
the OFDMA mode, the AP still follows the typical listen before talk listen-before-talk
procedure to acquire the medium, which ensures interoperability and
compliance with unlicensed band access rules. However, 802.11ax also
includes a multi-user Multi-User Enhanced Distributed Channel Access (MU-EDCA)
capability, which allows the AP to get higher channel access priority
than other devices in its BSS.
4.2.1.2. Traffic Isolation via OFDMA Resource Management and Resource
Unit Allocation
802.11ax relies on the notion of an OFDMA Resource Unit (RU) to
allocate frequency chunks to different STAs stations over time. RUs
provide a way to allow for multiple stations to transmit simultaneously,
starting and ending at the same time. The way this is achieved is
via padding, where extra bits are transmitted with the same power
level. The current RU allocation algorithms provide a way to achieve
traffic isolation per station which while per se station. While this does not support time-aware
scheduling, time-
aware scheduling per se, it is a key aspect to assist reliability, as
it provides traffic isolation in a shared medium.
4.2.1.3. Improved PHY Robustness
The 802.11ax PHY can operate with a 0.8, 1.6 1.6, or 3.2 microsecond guard
interval
Guard Interval (GI). The larger GI options provide better protection
against multipath, which is expected to be a challenge in industrial
environments. The possibility to operate of operating with smaller resource units
(e.g. RUs (e.g., 2
MHz) enabled by OFDMA also helps reduce noise power and improve SNR,
Signal-to-Noise Ratio (SNR), leading to better packet error rate Packet Error Rate
(PER) performance.
802.11ax supports beamforming as in 802.11ac, 802.11ac but introduces UL MU MU-
MIMO, which helps improve reliability. The UL MU MIMO MU-MIMO capability is
also enabled by the trigger based trigger-based access operation in 802.11ax.
4.2.1.4. Support for 6GHz 6 GHz Band
The 802.11ax specification [IEEE Std 802.11ax] [IEEE802.11ax] includes support for
operation in the 6 GHz band. Given the amount of new spectrum
available
available, as well as the fact that no legacy 802.11 device (prior
802.11ax) will be able to operate in this band, 802.11ax operation in
this new band can be even more efficient.
4.2.2. Applicability to Deterministic Flows
TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide
the underlying mechanism for supporting deterministic flows in a
Local Area Network (LAN). The IEEE 802.11 working group Working Group has
incorporated support for absolute time synchronization to extend the
TSN 802.1AS protocol so that time-sensitive flow flows can experience
precise time synchronization when operating over 802.11 links. As
IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802
architecture, 802.11 devices can directly implement some TSN
capabilities without the need for a gateway/translation protocol.
Basic features required for operation in a 802.1Q LAN are already
enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can
already operate over the existing 802.11 MAC SAP [Sudhakaran2021].
Implementation and experimental results of TSN capabilities (802.1AS,
802.1Qbv, and 802.1CB) extended over standard Ethernet and Wi-Fi
devices have also been described in [Fang_2021]. Nevertheless, the
IEEE 802.11 MAC/PHY could be extended to improve the operation of
IEEE 802.1 TSN features and achieve better performance metrics
[Cavalcanti1287].
TSN capabilities supported over 802.11 (which also extends to
802.11ax),
802.11ax) include:
1. 802.1AS based Time Synchronization 802.1AS-based time synchronization (other time synchronization
techniques may also be used)
2. Interoperating with IEEE802.1Q IEEE 802.1Q bridges
3. Time-sensitive Traffic Stream Classification traffic stream classification
The existing 802.11 TSN capabilities listed above, and the 802.11ax
OFDMA and AP-controlled access within a BSS BSS, provide a new set of
tools to better serve time-sensitive flows. However, it is important
to understand the tradeoffs trade-offs and constraints associated with such
capabilities, as well as redundancy and diversity mechanisms that can
be used to provide more predictable and reliable performance.
4.2.2.1. 802.11 Managed Network Operation and Admission Control
Time-sensitive applications and TSN standards are expected to operate
in a managed network (e.g. (e.g., an industrial/enterprise network). This
enables to carefully manage careful management and integrate integration of the Wi-Fi operation
with the overall TSN management framework, as defined in the
[IEEE802.1Qcc] specification.
[IEEE802.1Qcc].
Some of the random-access latency and interference from legacy/
unmanaged devices can be reduced under a centralized management mode
as defined in [IEEE802.1Qcc].
Existing traffic stream identification, configuration configuration, and admission
control procedures defined in [IEEE Std 802.11] the QoS mechanism in [IEEE802.11] can
be
re-used. reused. However, given the high degree of determinism required by
many time-sensitive applications, additional capabilities to manage
interference and legacy devices within tight time-constraints time constraints need to
be explored.
4.2.2.2. Scheduling for Bounded Latency and Diversity
As discussed earlier, the [IEEE Std 802.11ax] OFDMA mode in [IEEE802.11ax] introduces the
possibility of assigning different RUs (time/frequency resources) to
users within a PPDU. Several RU sizes are defined in the
specification (26, 52, 106, 242, 484, and 996 subcarriers). In
addition, the AP can also decide on MCS (Modulation a Modulation and Coding Scheme) Scheme
(MCS) and grouping of users within a given OFMDA PPDU. Such
flexibility can be leveraged to support time-sensitive applications
with bounded latency, especially in a managed network where stations
can be configured to operate under the control of the AP, in a
controlled environment (which contains only devices operating on the
unlicensed band installed by the facility owner and where unexpected
interference from other systems and/or radio access technologies only
sporadically happens), or in a deployment where channel/link channel and link
redundancy is used to reduce the impact of unmanaged devices/ devices and
interference.
When the network is lightly loaded, it is possible to achieve
latencies under 1 msec when Wi-Fi is operated in a contention-based
mode (i.e., without OFDMA) mode. OFDMA). It is also has been shown that it is
possible to achieve 1 msec latencies in a controlled environment with
higher efficiency when multi-user transmissions are used (enabled by
OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency,
reliability
reliability, and capacity tradeoffs trade-offs to be considered. For instance,
smaller RUs result in longer transmission durations, which may impact
the minimal latency that can be achieved, but the contention latency
and randomness elimination in an interference-free environment due to
multi-user transmission is a major benefit of the OFDMA mode.
The flexibility to dynamically assign RUs to each transmission also
enables the AP to provide frequency diversity, which can help
increase reliability.
4.3. 802.11be Extreme High Throughput (EHT)
4.3.1. General Characteristics
The [IEEE 802.11be] ammendment
[IEEE802.11be] was the next major 802.11 amendment (after IEEE Std
802.11ax-2021) for operation in the 2.4, 5 5, and 6 GHz bands. 802.11be
includes new PHY and MAC features features, and it is targeting extremely high
throughput (at least 30 Gbps), as well as enhancements to worst case worst-case
latency and jitter. It is also expected to improve the integration
with 802.1 TSN to support time-sensitive applications over Ethernet
and Wireless LANs.
The 802.11be main features of 802.11be that are relevant to this document
include:
1. 320MHz 320 MHz bandwidth and more efficient utilization of non-contiguous
spectrum. non-
contiguous spectrum
2. Multi-link operation. Multi-Link Operation (MLO)
3. QoS enhancements to reduce latency and increase reliability. reliability
4.3.2. Applicability to Deterministic Flows
The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
provided detailed information on use cases, issues issues, and potential
solution directions to improve support for time-sensitive
applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06]
was used as input to the 802.11be project scope.
Improvements for worst-case latency, jitter jitter, and reliability were the
main topics identified in the RTA report, which were motivated by
applications in gaming, industrial automation, robotics, etc. The
RTA report also highlighted the need to support additional TSN
capabilities, such as time-aware (802.1Qbv) shaping and packet
replication and elimination as defined in 802.1CB.
IEEE Std 802.11be builds on and enhances 802.11ax capabilities to
improve worst case latency and jitter. Some of the enhancement areas
are discussed next.
4.3.2.1. Enhanced Scheduled Operation for Bounded Latency
In addition to the throughput enhancements, 802.11be leverages the
trigger-based scheduled operation enabled by 802.11ax to provide
efficient and more predictable medium access.
802.11be introduced QoS signaling enhancements, such as an additional
QoS characteristics element, that enables STAs stations to provide
detailed information about deterministic traffic stream to the AP.
This capability helps AP implementations to better support scheduling
for deterministic flows.
4.3.2.2. Multi-link operation Multi-Link Operation
802.11be introduces new features to improve operation over multiple
links and channels. By leveraging multiple links/channels, links and channels,
802.11be can isolate time-sensitive traffic from network congestion,
one of the main causes of large latency variations. In a managed
802.11be network, it should be possible to steer traffic to certain links/
links and channels to isolate time-sensitive traffic from other
traffic and help achieve bounded latency. The multi-link operation Multi-Link Operation
(MLO) is a major feature in the 802.11be amendment that can enhance
latency and reliability by enabling data frames to be duplicated
across links.
4.4. 802.11ad and 802.11ay (mmWave operation) Operation)
4.4.1. General Characteristics
The IEEE 802.11ad amendment defines PHY and MAC capabilities to
enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave)
band. The standard addresses the adverse mmWave signal propagation
characteristics and provides directional communication capabilities
that take advantage of beamforming to cope with increased
attenuation. An overview of the 802.11ad standard can be found in
[Nitsche_2015].
The IEEE 802.11ay is currently developing enhancements to the
802.11ad standard to enable the next generation mmWave operation
targeting 100 Gbps throughput. Some of the main enhancements in
802.11ay include MIMO, channel bonding, improved channel access access, and
beamforming training. An overview of the 802.11ay capabilities can
be found in [Ghasempour_2017].
4.4.2. Applicability to deterministic flows Deterministic Flows
The high data high-data rates achievable with 802.11ad and 802.11ay can
significantly reduce latency down to microsecond levels. Limited
interference from legacy and other unlicensed devices in 60 GHz is
also a benefit. However, the directionality and short range typical
in mmWave operation impose new challenges such as the overhead
required for beam training and blockage issues, which impact both
latency and reliability. Therefore, it is important to understand
the use case and deployment conditions in order to properly apply and
configure 802.11ad/ay networks for time sensitive time-sensitive applications.
The 802.11ad standard includes a scheduled access mode in which the
central controller, after contending and reserving the channel for a
dedicated period, can allocate to stations contention-free service
periods. This scheduling capability is also available in 802.11ay,
and it is one of the mechanisms that can be used to provide bounded
latency to time-sensitive data flows in interference-free scenarios.
An analysis of the theoretical latency bounds that can be achieved
with 802.11ad service periods is provided in [Cavalcanti_2019].
5. IEEE 802.15.4 Timeslotted Time-Slotted Channel Hopping (TSCH)
IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed
directly at Industrial industrial IoT applications, for use in Process Control process control
loops and monitoring. It was used as a base for the major industrial
wireless process control standards, Wireless HART Highway Addressable
Remote Transducer Protocol (HART) and ISA100.11a.
While the MAC/PHY standards enable the relatively slow rates used in
Process Control
process control (typically in the order of 4-5 per second), the
technology is not suited for the faster periods (1 to 10ms) used in
Factory Automation factory
automation and motion control. control (1 to 10 ms).
5.1. Provenance and Documents
The IEEE802.15.4 IEEE 802.15.4 Task Group has been driving the development of low-
power
power, low-cost radio technology. The IEEE802.15.4 IEEE 802.15.4 physical layer
has been designed to support demanding low-power scenarios targeting
the use of unlicensed bands, both the 2.4 GHz and sub GHz sub-GHz Industrial,
Scientific and Medical (ISM) bands. This has imposed requirements in
terms of frame size, data rate rate, and bandwidth to achieve reduced
collision probability, reduced packet error rate, and acceptable
range with limited transmission power. The PHY layer supports frames
of up to 127 bytes. The Medium Access Control (MAC) sublayer
overhead is in the order of 10-20 bytes, leaving about 100 bytes to
the upper layers. IEEE802.15.4 IEEE 802.15.4 uses spread spectrum modulation such
as the Direct Sequence Spread Spectrum (DSSS).
The Timeslotted Time-Slotted Channel Hopping (TSCH) mode was added to the 2015
revision of the IEEE802.15.4 IEEE 802.15.4 standard [IEEE Std 802.15.4]. [IEEE802.15.4]. TSCH is
targeted at the embedded and industrial world, where reliability,
energy consumption consumption, and cost drive the application space.
Time sensitive networking
Building on low power IEEE 802.15.4, TSN on low-power constrained wireless networks,
building on IEEE802.15.4, have
networks has been partially addressed by ISA100.11a [ISA100.11a] and
WirelessHART [WirelessHART]. Both technologies involve a central
controller that computes redundant paths for industrial process
control traffic over a TSCH mesh. Moreover, ISA100.11a introduces
IPv6 [RFC8200] capabilities [RFC8200] with a Link-Local
Address link-local address for the join
process and a global unicast address for later exchanges, but the
IPv6 traffic typically ends at a local application gateway and the
full power of IPv6 for end-to-end communication is not enabled.
At the IETF, the 6TiSCH working group Working Group [TiSCH] has enabled distributed
routing and scheduling to exploit the deterministic access
capabilities provided by TSCH for IPv6. The group designed the
essential mechanisms, the 6top layer 6TiSCH Operation (6top) sublayer and the
Scheduling Functions (SFs), to enable the management plane operation
while ensuring IPv6 is supported: supported.
* The 6top Protocol (6P) is defined in [RFC8480]. The 6P Protocol [RFC8480] and provides a
pairwise negotiation mechanism to the control plane operation.
The protocol supports agreement on a schedule between neighbors,
enabling distributed scheduling.
* 6P goes hand-in-hand hand in hand with an SF, the policy that decides how to
maintain cells and trigger 6P transactions. The Minimal
Scheduling Function (MSF) [RFC9033] is the default SF defined by
the 6TiSCH WG.
* With these mechanisms mechanisms, 6TiSCH can establish layer Layer 2 links between
neighbouring
neighboring nodes and support best effort best-effort traffic. RPL The Routing
Protocol for Low-Power and Lossy Networks (RPL) [RFC8480] provides
the routing structure, enabling the 6TiSCH devices to establish
the links with well connected neighbours and well-connected neighbors, thus forming the acyclic
network graphs.
A Track at 6TiSCH is the application to wireless of the concept of a
Recovery Graph
recovery graph in the RAW architecture. A Track can follow a simple
sequence of relay nodes nodes, or it can be structured as a more complex
Destination Oriented
Destination-Oriented Directed Acyclic Graph (DODAG) to a unicast
destination. Along a Track, 6TiSCH nodes reserve the resources to
enable the efficient transmission of packets while aiming to optimize
certain properties such as reliability and ensure small jitter or
bounded latency. The Track structure enables Layer-2 Layer 2 forwarding
schemes, reducing the overhead of taking making routing decisions at the
Layer-3. Layer
3.
The 6TiSCH architecture [RFC9030] identifies different models to
schedule resources along so-called Tracks (see Section 5.2.1) 5.2.1),
exploiting the TSCH schedule structure however structure; however, the focus at in 6TiSCH
is on best effort traffic best-effort traffic, and the group was never chartered to
produce
standard standards work related to Tracks.
There are several works that can be used to complement the overview
provided in this document. For example example, [vilajosana21] provides a
detailed description of the 6TiSCH protocols, how they are linked
together
together, and how they are integrated with other standards like RPL
and 6Lo.
5.2. General Characteristics
As a core technique in IEEE802.15.4, IEEE 802.15.4, TSCH splits time in multiple
time slots that repeat over time. Each device has its own
perspective of when the send or receive occurs and on which channel
the transmission happens. This constitutes the device's Slotframe Slotframe,
where the channel and destination of a transmission by this device
are a function of time. The overall aggregation of all the
Slotframes of all the devices constitutes a time/frequency matrix
with at most one transmission in each cell of the matrix (more (see more in
Section 5.3.1.4).
The IEEE 802.15.4 TSCH standard does not define any scheduling
mechanism but only provides the architecture that establishes a
slotted structure that can be managed by a proper schedule. This
schedule represents the possible communications of a node with its
neighbors,
neighbors and is managed by a Scheduling Function such as the Minimal
Scheduling Function (MSF) [RFC9033]. In MSF, each cell in the
schedule is identified by its slotoffset and channeloffset
coordinates. A cell's timeslot offset indicates its position in
time, relative to the beginning of the slotframe. A cell's channel
offset is an index which that maps to a frequency at each iteration of the
slotframe. Each packet exchanged between neighbors happens within
one cell. The size of a cell is a timeslot duration, between 10 to
15 milliseconds. An Absolute Slot Number (ASN) indicates the number
of slots elapsed since the network started. It increments at every
slot. This is a 5-byte counter that can support networks running for
more than 300 years without wrapping (assuming a 10-ms 10 ms timeslot).
Channel hopping provides increased reliability to multi-path multipath fading
and external interference. It is handled by TSCH through a channel channel-
hopping sequence referred to as macHopSeq in the IEEE802.15.4 IEEE 802.15.4
specification.
The Time-Frequency Division Multiple Access provided by TSCH enables
the orchestration of traffic flows, spreading them in time and
frequency, and hence enabling an efficient management of the
bandwidth utilization. Such efficient bandwidth utilization can be
combined with OFDM modulations also supported by the IEEE802.15.4 IEEE 802.15.4
standard [IEEE Std 802.15.4] [IEEE802.15.4] since the 2015 version.
TSCH networks operate in ISM bands in which the spectrum is shared by
different coexisting technologies. Regulations such as the FCC, ETSI
ETSI, and ARIB impose duty cycle regulations to limit the use of the bands
bands, but
yet interference may constraint still constrain the probability to deliver of
delivering a packet. Part of these reliability challenges are
addressed at the MAC introducing redundancy and diversity, thanks to
channel hopping,
scheduling scheduling, and ARQ policies. Yet, the MAC layer
operates with a 1-hop vision, being limited to local actions to
mitigate underperforming links.
5.2.1. 6TiSCH Tracks
A Track in the 6TiSCH Architecture architecture [RFC9030] is the application to
6TiSCH networks of the concept of a protection path in the "Detnet
architecture" DetNet
architecture [RFC8655]. A Track can be structured as a Destination Destination-
Oriented Directed Acyclic Graph (DODAG) to a destination for unicast
traffic. Along a Track, 6TiSCH nodes reserve the resources to enable
the efficient transmission of packets while aiming to optimize
certain properties such as reliability and ensure small jitter or
bounded latency. The Track structure enables Layer-2 Layer 2 forwarding
schemes, reducing the overhead of taking making routing decisions at the
Layer-3. Layer
3.
Serial Tracks can be understood as the concatenation of cells or
bundles along a routing path from a source towards a destination.
The serial Track concept is analogous to the circuit concept where
resources are chained into a multi-hop topology, topology; see more in
Section 5.2.1.2 on how that is used in the data plane to forward
packets.
Whereas scheduling ensures reliable delivery in bounded time along
any Track, high availability requires the application of PREOF
functions along a more complex DODAG Track structure. A DODAG has
forking and joining nodes where the concepts such as Replication like replication and
Elimination
elimination can be exploited. Spatial redundancy increases the
overall energy consumption in the network but improves significantly improves
the availability of the network as well as the packet delivery ratio.
A Track may also branch off and rejoin, for the purpose of the so-
called so-called
Packet Replication and Elimination (PRE), over non congruent non-congruent
branches. PRE may be used to complement layer-2 Layer 2 ARQ and receiver-end
Ordering
ordering to complete/extend the PREOF functions. This enables
meeting industrial expectations of packet delivery within bounded
delay over a Track that includes wireless links, even when the Track
extends beyond the 6TiSCH network.
The RAW Track described in the RAW Architecture
[I-D.ietf-raw-architecture] architecture [RFC9912] inherits
directly from that model. RAW extends the graph beyond a DODAG as
long as a given packet cannot loop within the Track.
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track branch | |
+-------+ +--------+ Subnet Backbone 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 1: End-to-End deterministic Deterministic Track
In the example above (see Figure 1), 1, a Track is laid out from a field device in a 6TiSCH
network to an IoT gateway that is located on a
IEEE802.1 an IEEE 802.1 TSN
backbone.
The Replication function in the field device sends a copy of each
packet over two different branches, and a PCE schedules each hop of
both branches so that the two copies arrive in due time at the
gateway. In case of a loss on one branch, hopefully the other copy
of the packet still makes it in due 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.
At each 6TiSCH hop along the Track, the PCE may schedule more than
one timeSlot for a packet, so as to support Layer-2 Layer 2 retries (ARQ).
It is also possible that for the field device to only uses use the second
branch if sending over the first branch fails.
In current deployments, a TSCH Track does not necessarily support PRE
but is systematically multi-path. multipath. This means that a Track is
scheduled so as to ensure that each hop has at least two forwarding
solutions, and the forwarding decision is to try the preferred one
and use the other in case of Layer-2 Layer 2 transmission failure as detected
by ARQ.
Methods to implement complex Tracks are described in
[I-D.ietf-roll-dao-projection] [RFC9914] and
complemented by extensions to the RPL routing protocol in [I-D.ietf-roll-nsa-extension] [NSA-EXT]
for best effort best-effort traffic, but a centralized routing technique such as
one promoted in DetNet is still missing.
5.2.1.1. Track Scheduling Protocol
Section "Schedule Management Mechanisms" 4.4 of the 6TiSCH architecture [RFC9030] describes 4 four
approaches to manage the TSCH schedule of the LLN Low-Power and Lossy
Network (LLN) nodes:
Static Scheduling, static scheduling, neighbor-to-neighbor Scheduling,
scheduling, remote monitoring and scheduling management, and Hop-by-hop hop-by-
hop scheduling. The Track operation for DetNet corresponds to a
remote monitoring and scheduling management by a PCE.
5.2.1.2. Track Forwarding
By forwarding,
In the 6TiSCH Architecture [RFC9030] means architecture [RFC9030], forwarding is the per-packet
operation that allows delivering a packet to be delivered to a next hop or an
upper layer in this a node. Forwarding is based on pre-existing preexisting state that
was installed as a result of the routing computation of a Track by a
PCE. The 6TiSCH architecture supports three different forwarding
model, G-MPLS
models: GMPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF)
(FF), and IPv6 Forwarding (6F) (6F), which is the classical IP operation
[RFC9030]. The DetNet case relates to the Track Forwarding operation
under the control of a PCE.
A Track is a unidirectional path between a source and a destination.
Time/Frequency
Time and frequency resources called cells (see Section 5.3.1.4) are
allocated to enable the forwarding operation along the Track. In a
Track cell, the normal operation of IEEE802.15.4 IEEE 802.15.4 ARQ usually
happens, though the acknowledgment may be omitted in some cases, for instance
instance, if there is no scheduled cell for a retry.
Track Forwarding is the simplest and fastest. A bundle of cells set
to receive (RX-cells) is uniquely paired to a bundle of cells that
are set to transmit (TX-cells), representing a layer-2 Layer 2 forwarding
state that can be used regardless of the network layer network-layer protocol.
This model can effectively be seen as a Generalized Multi-protocol Multiprotocol
Label Switching (G-MPLS) (GMPLS) operation in that the information used to
switch a frame is not an explicit label, label but is rather related to
other properties of about the way the packet was received, a received (a particular cell
cell, in the case of 6TiSCH. 6TiSCH). As a result, as long as the TSCH MAC
(and
Layer-2 Layer 2 security) accepts a frame, that frame can be switched
regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
fragment, or a frame from an alternate protocol such as WirelessHART
or ISA100.11a.
A data frame that is forwarded along a Track normally has a
destination MAC address that is set to broadcast - or (or a multicast
address
address, depending on MAC support. support). This way, the MAC layer in the
intermediate nodes accepts the incoming frame frame, and 6top switches it
without incurring a change in the MAC header. In the case of
IEEE802.15.4, IEEE
802.15.4, this means effectively broadcast, so that along the
Track the short address
for the destination of the frame is set to
0xFFFF. 0xFFFF along the Track.
A Track is thus formed end-to-end end to end as a succession of paired bundles, bundles:
a receive bundle from the previous hop and a transmit bundle to the
next hop along the Track, and a Track. A cell in such a bundle belongs to at
most one Track.
Track at most. For a given iteration of the device schedule, the
effective channel of the cell is obtained by adding a pseudo-random pseudorandom
number to the channelOffset of the cell, which results in a rotation
of the frequency that was used for transmission. The bundles may be
computed so as to accommodate both variable rates and
retransmissions, so they might not be fully used at a given iteration
of the schedule. The 6TiSCH architecture provides additional means
to avoid waste of cells as well as overflows in the transmit bundle,
as follows:
In described in the following paragraphs.
On one hand, a TX-cell that is not needed for the current iteration
may be reused opportunistically on a per-hop basis for routed
packets. When all of the frame frames that were received for a given Track
are effectively transmitted, any available TX-cell for that Track can
be reused for upper layer upper-layer traffic for which the next-hop router
matches the next hop along the Track. In that case, the cell that is
being used is effectively a TX-cell from the Track, but the short
address for the destination is that of the next-hop router. It
results that a frame that is received in a an RX-cell of a Track with a
destination MAC address set to this node as opposed to broadcast must
be extracted from the Track and delivered to the upper layer (a frame
with an unrecognized MAC address is dropped at the lower MAC layer
and thus is not received at the 6top sublayer).
On the other hand, it might happen that there are not enough TX-cells
in the transmit bundle to accommodate the Track traffic, for instance
instance, if more retransmissions are needed than provisioned. In
that case, the frame can be placed for transmission in the bundle
that is used for layer-3 Layer 3 traffic towards the next hop along the Track
as long as it can be routed by the upper layer, that is, typically,
if the frame transports an IPv6 packet. The MAC address should be
set to the next-hop MAC address to avoid confusion. It results that
a frame that is received over a layer-3 Layer 3 bundle may be in fact
associated with a Track. In a classical IP link such as an Ethernet,
off-Track traffic is typically in excess over reservation to be
routed along the non-reserved path based on its QoS setting. But
However, with 6TiSCH, since the use of the layer-3 Layer 3 bundle may be due
to transmission failures, it makes sense for the receiver to
recognize a frame that should be re-Tracked, re-Tracked and to place it back on
the appropriate bundle if possible. A frame should be re-Tracked if
the Per-Hop-Behavior per-hop-behavior group indicated in the Differentiated Services Field
field in the IPv6 header is set to Deterministic Forwarding, deterministic forwarding, as
discussed in Section 5.3.1.1. A frame is re-Tracked by scheduling it
for transmission over the transmit bundle associated with the Track,
with the destination MAC address set to broadcast.
5.2.1.2.1. OAM
"An Overview of Operations, Administration, and Maintenance (OAM)
Tools" [RFC7276] provides an overview of the existing tooling for OAM
[RFC6291]. Tracks are complex paths and new tooling is necessary to
manage them, with respect to load control, timing, and the Packet
Replication and Elimination Functions (PREF).
An example of such tooling can be found in the context of BIER Bit Index
Explicit Replication (BIER) [RFC8279] and and, more specifically specifically, BIER
Traffic Engineering [RFC9262]
(BIER-TE). (BIER-TE) [RFC9262].
5.3. Applicability to Deterministic Flows
In the RAW context, low power low-power reliable networks should address non-
critical control scenarios such as Class 2 and monitoring scenarios
such as Class 4 4, as defined by the RFC5673 [RFC5673]. As a low power low-power technology
targeting industrial scenarios scenarios, radio transducers provide low data
rates (typically between 50kbps 50 kbps to 250kbps) 250 kbps) and robust modulations
to trade-off performance to reliability. TSCH networks are organized
in mesh topologies and connected to a backbone. Latency in the mesh
network is mainly influenced by propagation aspects such as
interference. ARQ methods and redundancy techniques such as
replication and elimination should be studied to provide the needed
performance to address deterministic scenarios.
Nodes in a TSCH network are tightly synchronized. This enables
building the slotted structure and ensures efficient utilization of
resources thanks to proper scheduling policies. Scheduling is key to
orchestrate the resources that different nodes in a Track or a path
are using. Slotframes can be split in resource blocks blocks, reserving the
needed capacity to certain flows. Periodic and bursty traffic can be
handled independently in the schedule, using active and reactive
policies and taking advantage of overprovisioned cells. Along a
Track (see Section 5.2.1, 5.2.1), resource blocks can be chained so nodes in
previous hops transmit their data before the next packet comes. This
provides a tight control to latency along a Track. Collision loss is
avoided for best effort best-effort traffic by overprovisioning resources, giving
time to the management plane of the network to dedicate more
resources if needed.
5.3.1. Centralized Path Computation
When considering end-to-end communication over TSCH, a 6TiSCH device
usually does not place a request for bandwidth between itself and
another device in the network. Rather, an Operation Control System
(OCS) invoked through a Human/Machine Human-Machine Interface (HMI) provides the
Traffic Specification,
traffic specification, in particular particular, in terms of latency and
reliability, and the end nodes, to a PCE. With this, the PCE
computes a Track between the end nodes and provisions every hop in
the Track with per-flow state that describes the per-hop operation
for a given packet, the corresponding timeSlots, and the flow
identification to recognize which packet is placed in which Track,
sort out duplicates, etc. An example of Operational Control System an OCS and HMI is depicted
in Figure 2.
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, which incorporates the aggregation of its
behavior for multiple Tracks. The 6TiSCH Architecture architecture expects that
the programing programming of the schedule is done over the Constrained
Application Protocol (CoAP) such as discussed in "6TiSCH Resource
Management and Interaction using CoAP" [I-D.ietf-6tisch-coap].
But an [CoAP-6TiSCH].
However, a Hybrid mode may be required as well well, whereby a single
Track is added, modified, or removed, for instance removed (for instance, if it appears
that a Track does not perform as expected. expected). For that case, the
expectation is that a protocol that flows along a Track (to be), in a
fashion similar to classical Traffic Engineering (TE) [CCAMP], may be
used to update the state in the devices. In general, that flow was
not designed designed, and it is expected that DetNet will determine the
appropriate end-to-end protocols to be used in that case.
Stream Management Entity
Operational Control System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \
Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device--
Figure 2: Architectural Layers
5.3.1.1. Packet Marking and Handling
Section "Packet Marking and Handling" 4.7.1 of [RFC9030] describes the packet tagging and marking
that is expected in 6TiSCH networks.
5.3.1.1.1. Tagging Packets for Flow Identification
Packets that are routed by a PCE along a Track, Track are tagged to uniquely
identify the Track and associated transmit bundle of timeSlots.
It results that the tagging that is used for a DetNet flow outside
the 6TiSCH Low Power Low-Power and Lossy Network (LLN) must be swapped into
6TiSCH formats and back as the packet enters and then leaves the
6TiSCH network.
5.3.1.1.2. Replication, Retries Retries, and Elimination
The 6TiSCH Architecture architecture [RFC9030] leverages PREOF over several
alternate paths in a network to provide redundancy and parallel
transmissions to bound the end-to-end delay. Considering the
scenario shown in Figure 3, many different paths are possible for S
to reach R. A simple way to benefit from this topology could be to
use the two independent paths via nodes A, C, E and via B, D, F. But F, but
more complex paths are possible as well.
(A) (C) (E)
source (S) (R) (destination)
(B) (D) (F)
Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward
the Destination
By employing a Packet Replication packet replication function, each node forwards a copy
of each data packet over two different branches. For instance, in
Figure 4, the source node S transmits the data packet to nodes A and
B, in two different timeslots within the same TSCH slotframe. S
transmits twice the same data packet to its Destination Parent (DP)
(A) and to its Alternate Parent (AP) (B).
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 4: Packet Replication: S transmits twice the same data
packet, to its Destination Parent (DP) (A) and to its Alternate
Parent (AP) (B). Replication
By employing Packet Elimination a packet elimination function once a node it receives the first
copy of a data packet, it a node discards the subsequent copies.
Because the first copy that reaches a node is the one that matters,
it is the only copy that will be forwarded upward.
Considering that the wireless medium is broadcast by nature, any
neighbor of a transmitter may overhear a transmission. By employing
the Promiscuous Overhearing promiscuous overhearing function, nodes will have multiple
opportunities to receive a given data packet. For instance, in
Figure 4, when the source node S transmits the data packet to node A,
node B may overhear this the transmission.
6TiSCH expects elimination and replication of packets along a complex
Track,
Track but has no position about how the sequence numbers would be
tagged in the packet.
As it goes, 6TiSCH expects that timeSlots corresponding to copies of
a
the same packet along a Track are correlated by configuration, and
does not need to process the sequence numbers.
The semantics of the configuration must enable correlated timeSlots
to be grouped for transmit (and respectively receive) receive, respectively) with 'OR'
relations, and then an 'AND' relation must be configurable between
groups. The semantics is are such that if the transmit (and respectively
receive) receive,
respectively) operation succeeded in one timeSlot in an 'OR' group,
then all the other timeslots in the group are ignored. Now, if there
are at least two groups, the 'AND' relation between the groups
indicates that one operation must succeed in each of the groups.
Further details can be found in the 6TiSCH Architecture architecture document
[RFC9030].
5.3.1.2. Topology and Capabilities
6TiSCH nodes are usually IoT devices, characterized by a very limited
amount of memory, just enough buffers to store one or a few IPv6
packets, and limited bandwidth between peers. It results that a node
will maintain only a small number amount of peering information, information and will not
be able to store many packets waiting to be forwarded. Peers can be
identified through MAC or IPv6 addresses.
Neighbors can be discovered over the radio using mechanism mechanisms such as
Enhanced Beacons, but, though
enhanced beacons, but although the neighbor information is available
in the 6TiSCH interface data model, 6TiSCH does not describe a
protocol to pro-actively proactively push the neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The
protocol should be able to carry multiple metrics, in particular particular, the
same metrics as that are used for RPL operations [RFC6551].
The energy that the device consumes in sleep, transmit transmit, and receive
modes can be evaluated and reported. So reported, and so can the amount of energy
that is stored in the device and the power that it can be scavenged from
the environment. The PCE should be able to compute Tracks that will
implement policies on how the energy is consumed, for instance instance,
policies that balance between nodes and ensure that the spent energy
does not
exceeded exceed the scavenged energy over a period of time.
5.3.1.3. Schedule Management by a PCE
6TiSCH supports a mixed model of centralized routes and distributed
routes. Centralized routes can can, for example example, be computed by a an
entity such as a PCE [PCE]. Distributed routes are computed by RPL
[RFC6550].
Both methods may inject routes in the Routing Tables routing tables of the 6TiSCH
routers. In either case, each route is associated with a 6TiSCH
topology that can be a RPL Instance topology or a Track. The 6TiSCH
topology is indexed by an Instance ID, in a format that reuses the
RPLInstanceID as defined in RPL.
Both RPL and PCE rely on shared sources such as policies to define
Global and Local RPLInstanceIDs that can be used by either method.
It is possible for centralized and distributed routing to share a the
same topology. Generally Generally, they will operate in different slotFrames,
and centralized routes will be used for scheduled traffic and will
have precedence over distributed routes in case of conflict between
the slotFrames.
5.3.1.4. SlotFrames and Priorities
IEEE802.15.4
IEEE 802.15.4 TSCH avoids contention on the medium by formatting time
and frequencies in cells of transmission of equal duration. In order
to describe that formatting of time and frequencies, the 6TiSCH
architecture defines a global concept that is called a Channel
Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
cells with an a height equal to the number of available channels
(indexed by ChannelOffsets) and a width (in timeSlots) that is the
period of the network scheduling operation (indexed by slotOffsets)
for that CDU matrix.
The CDU Matrix matrix is used by the PCE as the map of all the channel
utilization. This organization depends on the time in the future.
The frequency used by a cell in the matrix rotates in a pseudo-random pseudorandom
fashion, from an initial position at an epoch time, as the CDU matrix
iterates over and over.
The size of a cell is a timeSlot duration, and values of 10 to 15
milliseconds are typical in 802.15.4 TSCH to accommodate for the
transmission of a frame and an acknowledgement, including the
security validation on the receive side side, which may take up to a few
milliseconds on some device architecture. architectures. The matrix represents the
overall utilisation utilization of the spectrum over time by a scheduled network
operation.
A CDU matrix is computed by the PCE, but unallocated timeSlots may be
used opportunistically by the nodes for classical best effort best-effort IP
traffic. The PCE has precedence in the allocation in case of a
conflict. Multiple schedules may coexist, in which case the schedule
adds a dimension to the matrix matrix, and the dimensions are ordered by
priority.
A slotFrame is the base object that a PCE needs to manipulate to
program a schedule into one device. The slotFrame is a device
perspective of a transmission schedule; there can be more than one
with different priorities so in case of a contention the highest
priority applies. In other words, a slotFrame is the projection of a
schedule from the CDU matrix onto one device. Elaboration on that
concept can be found in section "SlotFrames and Priorities" of
[RFC9030], and figures Figures 17 and 18 of in [RFC9030] illustrate that
projection.
6. 5G
5G technology enables deterministic communication. Based on the
centralized admission control and the scheduling of the wireless
resources, licensed or unlicensed, quality Quality of service Service (QoS) such as
latency and reliability can be guaranteed. 5G contains several
features to achieve ultra-reliable and low latency performance, e.g., low-latency performance (e.g.,
support for different OFDM numerologies and slot-durations, slot durations), as well
as fast processing capabilities and redundancy techniques that lead
to achievable latency numbers of below 1ms 1 ms with 99.999% or higher
confidence.
5G also includes features to support Industrial industrial IoT use cases, e.g.,
via the integration of 5G with TSN. This includes 5G capabilities
for each TSN component, latency, resource management, time
synchronization, and reliability. Furthermore, 5G support for TSN
can be leveraged when 5G is used as the subnet technology for DetNet,
in combination with or instead of TSN, which is the primary subnet
for DetNet. In addition, the support for integration with TSN
reliability was added to 5G by making DetNet reliability also
applicable, due to the commonalities between TSN and DetNet
reliability. Moreover, providing IP service is native to 5G 5G, and
3GPP Release 18 adds direct support for DetNet to 5G.
Overall, 5G provides scheduled wireless segments with high
reliability and availability. In addition, 5G includes capabilities
for integration to IP networks. This makes 5G a suitable technology
upon which to apply RAW upon. RAW.
6.1. Provenance and Documents
The 3rd Generation Partnership Project (3GPP) incorporates many
companies whose business is related to cellular network operation as
well as network equipment and device manufacturing. All generations
of 3GPP technologies provide scheduled wireless segments, primarily
in licensed spectrum spectrum, which is beneficial for reliability and
availability.
In 2016, the 3GPP started to design New Radio (NR) technology
belonging to the fifth generation (5G) of cellular networks. NR has
been designed from the beginning to not only address enhanced Mobile
Broadband (eMBB) services for consumer devices such as smart phones
or tablets tablets, but it is also tailored for future Internet of Things (IoT) IoT communication and
connected cyber-physical systems. In addition to eMBB, requirement
categories have been defined on Massive Machine-
Type Machine-Type Communication
(M-MTC) for a large number of connected devices/
sensors, devices/sensors and Ultra-Reliable on Ultra-
Reliable Low-Latency Communication Communications (URLLC) for connected control
systems and critical communication as illustrated in Figure 5. It is
the URLLC capabilities that make 5G a great candidate for reliable
low-latency communication. With these three
corner stones, cornerstones, NR is a
complete solution supporting the connectivity needs of consumers,
enterprises, and the public sector for both wide area wide-area and local area, e.g. indoor local-area
(e.g., indoor) deployments. A general overview of NR can be found in
[TS38300].
enhanced
Mobile Broadband
^
/ \
/ \
/ \
/ \
/ 5G \
/ \
/ \
/ \
+-----------------+
Massive Ultra-Reliable
Machine-Type Low-Latency
Communication Communication
Figure 5: 5G Application Areas
As a result of releasing the first NR specification in 2018 (Release
15), it has been proven by many companies that NR is a URLLC-capable
technology and can deliver data packets at 10^-5 packet error rate
within 1ms a 1 ms latency budget [TR37910]. Those evaluations were
consolidated and forwarded to ITU to be included in the [IMT2020]
work. work on
[IMT2020].
In order to understand communication requirements for automation in
vertical domains, 3GPP studied different use cases [TR22804] and
released a technical specification with reliability, availability availability,
and latency demands for a variety of applications [TS22104].
As an evolution of NR, multiple studies that focus on radio aspects
have been conducted in scope of 3GPP Release 16 16, including the
following two, focusing on radio
aspects: two:
1. Study "Study on physical layer enhancements for NR ultra-reliable and
low latency communication (URLLC) [TR38824]. case (URLLC)" [TR38824]
2. Study "Study on NR industrial Internet of Things (I-IoT) [TR38825].
Resulting (IoT)" [TR38825]
As a result of these studies, further enhancements to NR have been
standardized in 3GPP Release 16, hence, 16 and are available in [TS38300], [TS38300] and
continued in 3GPP Release 17 standardization (according to
[RP210854]).
In addition, several enhancements have been done made on the system
architecture level level, which are reflected in System "System architecture for
the 5G System (5GS) (5GS)" [TS23501]. These enhancements include multiple
features in support of Time-Sensitive Communications (TSC) by Release
16 and Release 17. Further improvements improvements, such as support for DetNet
[TR2370046], are provided in Release 18,
e.g., support for DetNet [TR2370046]. 18.
The adoption and the use of 5G is facilitated by multiple
organizations. For instance, the 5G Alliance for Connected
Industries and Automation (5G-ACIA) brings together widely varying 5G
stakeholders including Information and Communication Technology (ICT)
players and Operational Technology (OT) companies, e.g.: companies (e.g., industrial
automation enterprises, machine builders, and end users. users). Another
example is the 5G Automotive Association (5GAA), which bridges ICT
and automotive technology companies to develop end-to-end solutions
for future mobility and transportation services.
6.2. General Characteristics
The 5G Radio Access Network (5G RAN) with its NR interface includes
several features to achieve Quality of Service (QoS), such as a
guaranteeably low latency or tolerable packet error rates for
selected data flows. Determinism is achieved by centralized
admission control and scheduling of the wireless frequency resources,
which are typically licensed frequency bands assigned to a network
operator.
NR enables short transmission slots in a radio subframe, which
benefits low-latency applications. NR also introduces mini-slots,
where prioritized transmissions can be started without waiting for
slot boundaries, further reducing latency. As part of giving
priority and faster radio access to URLLC traffic, NR introduces
preemption
preemption, where URLLC data transmission can preempt ongoing non-
URLLC transmissions. Additionally, NR applies very fast processing,
enabling retransmissions even within short latency bounds.
NR defines extra-robust transmission modes for increased reliability
both
for both data and control radio channels. Reliability is further
improved by various techniques, such as multi-antenna transmission,
the use of multiple frequency carriers in parallel parallel, and packet
duplication over independent radio links. NR also provides full
mobility support, which is an important reliability aspect not only
for devices that are moving, but also for devices located in a
changing environment.
Network slicing is seen as one of the key features for 5G, allowing
vertical industries to take advantage of 5G networks and services.
Network slicing is about transforming a Public Land Mobile Network
(PLMN) from a single network to a network where logical partitions
are created, with appropriate network isolation, resources, optimized
topology
topology, and specific configuration configurations to serve various service
requirements. An operator can configure and manage the mobile
network to support various types of services enabled by 5G, for
example 5G (e.g.,
eMBB and URLLC, URLLC), depending on the different customers’ needs. needs of customers.
Exposure of capabilities of 5G Systems systems to the network or applications
outside the 3GPP domain have been added to Release 16 [TS23501]. Via
exposure interfaces, applications
Applications can access 5G capabilities, e.g., capabilities like communication service
monitoring and network maintenance. maintenance via exposure interfaces.
For several generations of mobile networks, 3GPP has considered how
the communication system should work on a global scale with billions
of users, taking into account resilience aspects, privacy regulation,
protection of data, encryption, access and core network security, as
well as interconnect. Security requirements evolve as demands on
trustworthiness increase. For example, this has led to the
introduction of enhanced privacy protection features in 5G. 5G also
employs strong security algorithms, encryption of traffic, protection
of signaling signaling, and protection of interfaces.
One particular strength of mobile networks is the authentication,
based on well-proven algorithms and tightly coupled with a global
identity management infrastructure. Since 3G, there is also mutual
authentication, allowing the network to authenticate the device and
the device to authenticate the network. Another strength is secure
solutions for storage and distribution of keys keys, fulfilling regulatory
requirements and allowing international roaming. When connecting to
5G, the user meets the entire communication system, where security is
the result of standardization, product security, deployment,
operations
operations, and management as well as incident handling incident-handling capabilities.
The mobile networks approach the entirety in a rather coordinated
fashion
fashion, which is beneficial for security.
6.3. Deployment and Spectrum
The 5G system allows deployment in a vast spectrum range, addressing
use-cases
use cases in both wide-area as well as local and local-area networks. Furthermore, 5G
can be configured for public and non-public access.
When it comes to spectrum, NR allows combining the merits of many
frequency bands, such as the high bandwidths in millimeter Waves
(mmW) waves
(mmWaves) for extreme capacity locally, as well as locally and the broad coverage when
using mid- and low frequency low-frequency bands to address wide-area scenarios.
URLLC is achievable in all these bands. Spectrum can be either
licensed, which means that the license holder is the only authorized
user of that spectrum range, or unlicensed, which means that anyone
who wants to use the spectrum can do so.
A prerequisite for critical communication is performance
predictability, which can be achieved by the full control of the access to
the spectrum, which 5G provides. Licensed spectrum guarantees
control over spectrum usage by the system, making it a preferable
option for critical communication. However, unlicensed spectrum can
provide an additional resource for scaling non-critical
communications. While NR is was initially developed for usage of
licensed spectrum, the functionality to access also access unlicensed
spectrum was introduced in 3GPP Release 16. Moreover, URLLC features
are enhanced in Release 17 [RP210854] to be better applicable to
unlicensed spectrum.
Licensed spectrum dedicated to mobile communications has been
allocated to mobile service providers, i.e. i.e., issued as longer-term
licenses by national administrations around the world. These
licenses have often been associated with coverage requirements and
issued across whole countries, countries or in large regions. Besides this,
configured as a non-public network (NPN) deployment, 5G can also
provide network services also to a non-operator defined organization and
its premises such as a factory deployment. By With this isolation, quality of
service requirements, QoS
requirements as well as security requirements can be achieved. An
integration with a public network, if required, is also possible.
The non-public (local) network can thus be interconnected with a
public network, allowing devices to roam between the networks.
In an alternative model, some countries are now in the process of
allocating parts of the 5G spectrum for local use to industries.
These non-service providers then have a the choice of applying to apply for a local
license themselves and operating operate their own network or
cooperating to cooperate with
a public network operator or service provider.
6.4. Applicability to Deterministic Flows
6.4.1. System Architecture
The 5G system [TS23501] consists of the User Equipment (UE) at the
terminal side, and the Radio Access Network (RAN) with the gNB gNodeB (gNB)
as radio base station node, as well as and the Core Network (CN), which is
connected to the external Data Network (DN). The core network CN is based on a
service-based architecture with the following central functions:
Access and Mobility Management Function (AMF), Session Management
Function (SMF) (SMF), and User Plane Function (UPF) as illustrated in
Figure 6. "(Note (Note that this document only explains key functions, functions;
however, Figure 6 provides a more detailed view, and [SYSTOVER5G]
summarizes the functions and provides the full definition definitions of the
acronyms used in the figure.)" figure.)
The gNB’s gNB's main responsibility is the radio resource management, including
admission control and scheduling, mobility control control, and radio
measurement handling. The AMF handles the UE’s UE's connection status and
security, while the SMF controls the UE’s UE's data sessions. The UPF
handles the user plane traffic.
The SMF can instantiate various Packet Data Unit (PDU) sessions for
the UE, each associated with a set of QoS flows, i.e., with different
QoS profiles. profiles). Segregation of those sessions is also possible, e.g., possible; for
example, resource isolation in the RAN and in the CN can be defined
(slicing).
+----+ +---+ +---+ +---+ +---+ +---+
|NSSF| |NEF| |NRF| |PCF| |UDM| |AF |
+--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf|
| | | | | |
---+------+-+-----+-+------------+--+-----+-+---
| | | |
Nausf| Nausf| Nsmf| |
| | | |
+--+-+ +-+-+ +-+-+ +-+-+
|AUSF| |AMF| |SMF| |SCP|
+----+ +++-+ +-+-+ +---+
/ | |
/ | |
/ | |
N1 N2 N4
/ | |
/ | |
/ | |
+--+-+ +--+--+ +--+---+ +----+
| UE +---+(R)AN+--N3--+ UPF +--N6--+ DN |
+----+ +-----+ ++----++ +----+
| |
+-N9-+
Figure 6: 5G System Architecture
To allow UE mobility across cells/gNBs, handover mechanisms are
supported in NR. For an established connection, i.e., connection (i.e., connected mode
mobility,
mobility), a gNB can configure a UE to report measurements of
received signal strength and quality of its own and neighbouring neighboring
cells, periodically or event-based. based on events. Based on these measurement
reports, the gNB decides to handover hand over a UE to another target cell/gNB. cell/
gNB. Before triggering the handover, it is hand-shaked handshaked with the
target gNB based on network signalling. signaling. A handover command is then
sent to the UE UE, and the UE switches its connection to the target
cell/gNB. The Packet Data Convergence Protocol (PDCP) of the UE can
be configured to avoid data loss in this procedure, i.e., to handle
retransmissions if needed. Data forwarding is possible between
source and target gNB as well. To improve the mobility performance further, i.e.,
further (i.e., to avoid connection failures, e.g., failures due to too-late handovers,
handovers), the mechanism of conditional handover is introduced in
Release 16 specifications.
Therein Therein, a conditional handover command,
defining a triggering point, can be sent to the UE before the UE
enters a handover situation. A further improvement that has been
introduced in Release 16 is the Dual Active Protocol Stack (DAPS),
where the UE maintains the connection to the source cell while
connecting to the target cell. This way, potential interruptions in
packet delivery can be avoided entirely.
6.4.2. Overview of The the Radio Protocol Stack
The protocol architecture for NR consists of the L1 Layer 1 Physical layer
(PHY) and layer and, as part of the L2, Layer 2, the sublayers of Medium Access
Control (MAC), Radio Link Control (RLC), Packet Data Convergence
Protocol (PDCP), as well as the and Service Data Adaption Protocol (SDAP).
The PHY layer handles signal processing actions related actions, to signal processing, such as
encoding/decoding of data and control bits, modulation, antenna
precoding
precoding, and mapping.
The MAC sub-layer sublayer handles multiplexing and priority handling of
logical channels (associated with QoS flows) to transport blocks for
PHY transmission, as well as scheduling information reporting and
error correction through Hybrid Automated Repeat Request (HARQ).
The RLC sublayer handles sequence numbering of higher layer higher-layer packets,
retransmissions through Automated Repeat Request (ARQ), if
configured, as well as segmentation and reassembly and duplicate
detection.
The PDCP sublayer consists of functionalities for ciphering/
deciphering, integrity protection/verification, re-ordering reordering and in-
order delivery, and duplication and duplicate handling for higher higher-
layer
packets, and packets. This sublayer also acts as the anchor protocol to
support handovers.
The SDAP sublayer provides services to map QoS flows, as established
by the 5G core network, to data radio bearers (associated with
logical channels), as used in the 5G RAN.
Additionally, in RAN, the Radio Resource Control (RRC) protocol, protocol
handles the access control and configuration signalling signaling for the
aforementioned protocol layers. RRC messages are considered L3 Layer 3
and are thus transmitted also transmitted via those radio protocol layers.
To provide low latency and high reliability for one transmission
link, i.e., link
(i.e., to transport data (or or control signaling) signaling of one radio bearer via
one carrier, carrier), several features have been introduced on the user plane
protocols for PHY and L2, Layer 2, as explained in the following. below.
6.4.3. Radio (PHY)
NR is designed with native support of antenna arrays utilizing
benefits from beamforming, transmissions over multiple MIMO layers layers,
and advanced receiver algorithms allowing effective interference
cancellation. Those antenna techniques are the basis for high signal
quality and the effectiveness of spectral usage. Spatial diversity
with up to 4 four MIMO layers in UL and up to 8 eight MIMO layers in DL
is supported. Together with spatial-domain multiplexing, antenna
arrays can focus power in the desired direction to form beams. NR
supports beam management mechanisms to find the best suitable beam
for UE initially and when it is moving. In addition, gNBs can
coordinate their respective DL and UL transmissions over the backhaul network
network, keeping interference reasonably low, and even make
transmissions or receptions from multiple points (multi-TRP). Multi-TRP Multi-
TRP can be used for repetition of a data packet in time, in frequency
frequency, or over multiple MIMO layers layers, which can improve
reliability even further.
Any downlink transmission to a UE starts from resource allocation
signaling over the Physical Downlink Control Channel (PDCCH). If it
is successfully received, the UE will know about the scheduled
transmission and may receive data over the Physical Downlink Shared
Channel (PDSCH). If retransmission is required according to the HARQ
scheme, a signaling of negative acknowledgement (NACK) on the
Physical Uplink Control Channel (PUCCH) is involved involved, and PDCCH
together with PDSCH transmissions (possibly with additional
redundancy bits) are transmitted and soft-combined with previously
received bits. Otherwise, if no valid control signaling for
scheduling data is received, nothing is transmitted on PUCCH
(discontinuous transmission - DTX),and (DTX)), and upon detecting DTX, the base
station upon
detecting DTX will retransmit the initial data.
An uplink transmission normally starts from a Scheduling Request (SR)
–
(SR), a signaling message from the UE to the base station sent via
PUCCH. Once the scheduler is informed about buffer data in UE, e.g., the UE
(e.g., by SR, SR), the UE transmits a data packet on the Physical Uplink
Shared Channel (PUSCH). Pre-scheduling Pre-scheduling, not relying on SR SR, is also
possible (see
following section). Section 6.4.4).
Since transmission of data packets require requires usage of control and data
channels, there are several methods to maintain the needed
reliability. NR uses Low Density Parity Check (LDPC) codes for data
channels, Polar polar codes for PDCCH, as well as orthogonal sequences and
Polar
polar codes for PUCCH. For ultra-reliability of data channels, very
robust (low spectral (low-spectral efficiency) Modulation and Coding Scheme (MCS)
tables are introduced containing very low (down to 1/20) LDPC code
rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support
multiple code rates including very low ones for the channel
robustness.
A connected UE reports downlink (DL) quality to gNB by sending
Channel State Information (CSI) reports via PUCCH while uplink (UL)
quality is measured directly at gNB. For both uplink and downlink,
gNB selects the desired MCS number and signals it to the UE by
Downlink Control Information (DCI) via PDCCH channel. For URLLC
services, the UE can assist the gNB by advising that MCS targeting a
10^-5 Block Error Rate (BLER) are used. Robust link adaptation
algorithms can maintain the needed level of reliability reliability, considering
a given latency bound.
Low latency on the physical layer is provided by short transmission
duration
duration, which is possible by using high Subcarrier Spacing (SCS)
and the allocation of only one or a few Orthogonal Frequency Division
Multiplexing (OFDM) symbols. For example, the shortest latency for
the worst case is 0.23 ms in DL can be 0.23ms and 0.24 ms in UL can be 0.24ms according (according to (section
Section 5.7.1 in [TR37910]). Moreover, if the initial transmission
has failed, HARQ feedback can quickly be provided and an HARQ
retransmission is scheduled.
Dynamic multiplexing of data associated with different services is
highly desirable for efficient use of system resources and to
maximize system capacity. Assignment of resources for eMBB is
usually done with regular (longer) transmission slots, which can lead
to blocking of low latency low-latency services. To overcome the blocking, eMBB
resources can be pre-empted preempted and re-assigned reassigned to URLLC services. In this
way, spectrally efficient assignments for eMBB can be ensured while
providing the flexibility required to ensure a bounded latency for
URLLC services. In downlink, the gNB can notify the eMBB UE about
pre-emption
preemption after it has happened, while in uplink there are two pre-
emption
preemption mechanisms: special signaling to cancel eMBB transmission
and URLLC dynamic power boost to suppress eMBB transmission.
6.4.4. Scheduling and QoS (MAC)
One integral part of the 5G system is the Quality of Service (QoS)
framework [TS23501]. QoS flows are setup set up by the 5G system for
certain IP or Ethernet packet flows, so that packets of each flow
receive the same forwarding treatment, i.e., treatment (i.e., in scheduling and
admission control. control). For example, QoS flows can for example be associated with
different priority level, levels, packet delay budgets budgets, and tolerable packet
error rates. Since radio resources are centrally scheduled in NR,
the admission control function can ensure that only those QoS flows
are admitted for
which QoS targets can be reached. reached are admitted.
NR transmissions in both UL and DL are scheduled by the gNB
[TS38300]. This ensures radio resource efficiency, efficiency and fairness in
resource usage of the users users, and it enables differentiated treatment
of the data flows of the users according to the QoS targets of the
flows. Those QoS flows are handled as data radio bearers or logical
channels in NR RAN scheduling.
The gNB can dynamically assign DL and UL radio resources to users,
indicating the resources as DL assignments or UL grants via control
channel to the UE. Radio resources are defined as blocks of OFDM
symbols in spectral domain and time domain. Different lengths are
supported in time domain, i.e., (multiple) (i.e., multiple slot or mini-slot lengths. lengths).
Resources of multiple frequency carriers can be aggregated and
jointly scheduled to the UE.
Scheduling decisions are based, e.g., on channel quality measured on
reference signals and reported by the UE (cf. periodical CSI reports
for DL channel quality). The transmission reliability can be chosen
in the scheduling algorithm, i.e., chosen by link adaptation where an
appropriate transmission format (e.g., robustness of modulation and
coding scheme, controlled UL power) is selected for the radio channel
condition of the UE. Retransmissions, based on HARQ feedback, are
also controlled by the scheduler. The feedback transmission in HARQ
loop introduces delays, but there are methods to minimize it by using
short transmission formats, sub-slot feedback reporting reporting, and PUCCH
carrier switching. If needed to avoid HARQ round-trip time delays,
repeated transmissions can be also scheduled beforehand, to the cost
of reduced spectral efficiency.
In dynamic DL scheduling, transmission can be initiated immediately
when DL data becomes available in the gNB. However, for dynamic UL
scheduling, when data becomes available but no UL resources are
available yet, the UE indicates the need for UL resources to the gNB
via a (single bit) scheduling request message in the UL control
channel. When thereupon UL resources are scheduled to the UE, the UE
can transmit its data and may include a buffer status report,
indicating report that
indicates the exact amount of data per logical channel still left to
be sent. More UL resources may be scheduled accordingly. To avoid
the latency introduced in the scheduling request loop, UL radio
resources can also be pre-scheduled.
In particular particular, for periodical traffic patterns, the pre-scheduling
can rely on the scheduling features DL Semi-Persistent Scheduling
(SPS) and UL Configured Grant (CG). With these features,
periodically recurring resources can be assigned in DL and UL.
Multiple parallels of those configurations are supported, supported in order to
serve multiple parallel traffic flows of the same UE.
To support QoS enforcement in the case of mixed traffic with
different QoS requirements, several features have recently been
introduced. This way, e.g., different periodical critical QoS flows
can be served served, together with best effort transmissions, best-effort transmissions by the same
UE. Among others, these These features (partly Release 16) are: 1) include the following:
* UL logical channel transmission restrictions restrictions, allowing to map logical
channels of certain QoS to only be mapped to intended UL resources
of a certain frequency carrier, slot-length, slot length, or CG configuration, and 2) configuration.
* intra-UE
pre-emption preemption and multiplexing, allowing critical UL
transmissions to either pre-empt preempt non-critical transmissions or being be
multiplexed with non-critical transmissions keeping different
reliability targets.
When multiple frequency carriers are aggregated, duplicate parallel
transmissions can be employed (beside repeated transmissions on one
carrier). This is possible in the Carrier Aggregation (CA)
architecture where those carriers originate from the same gNB, gNB or in
the Dual Connectivity (DC) architecture where the carriers originate
from different gNBs, i.e., gNBs (i.e., the UE is connected to two gNBs in this
case.
case). In both cases, transmission reliability is improved by this
means of providing frequency diversity.
In addition to licensed spectrum, a 5G system can also utilize
unlicensed spectrum to offload non-critical traffic. This version of
NR is
NR, called NR-U, is part of 3GPP Release 16. The central scheduling
approach applies also applies for unlicensed radio resources, but in addition
also resources and the
mandatory channel access mechanisms for unlicensed spectrum,
e.g., spectrum (e.g.,
Listen Before Talk (LBT) are is supported in NR-U. NR-U). This way, by using
NR, operators have and can control access to both licensed and
unlicensed frequency resources.
6.4.5. Time-Sensitive Communications (TSC)
Recent 3GPP releases have introduced various features to support
multiple aspects of Time-Sensitive Communication (TSC), which
includes Time-Sensitive Networking (TSN) and beyond beyond, as described in
this section.
The main objective of Time-Sensitive Networking (TSN) TSN is to provide guaranteed data delivery
within a guaranteed time window, i.e., window (i.e., bounded low latency. latency). IEEE
802.1 TSN [IEEE802.1TSN] is a set of open standards that provide
features to enable deterministic communication on standard IEEE 802.3
Ethernet [IEEE802.3]. TSN standards can be seen as a toolbox for
traffic shaping, resource management, time synchronization, and
reliability.
A TSN stream is a data flow between one end station (Talker) (talker) to
another end station (Listener). (listener). In the centralized configuration
model, TSN bridges are configured by the Central Network Controller
(CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the
TSN stream through the network. Time-based traffic shaping provided
by Scheduled Traffic scheduled traffic [IEEE802.1Qbv] may be used to achieve bounded
low latency. The TSN tool for time synchronization is the
generalized Precision Time Protocol (gPTP) [IEEE802.1AS]), [IEEE802.1AS], which
provides reliable time synchronization that can be used by end
stations and by other TSN tools, e.g., Scheduled Traffic
[IEEE802.1Qbv]. tools (e.g., scheduled traffic
[IEEE802.1Qbv]). High availability, as a result of ultra-reliability, ultra-
reliability, is provided for data flows by the Frame Replication and
Elimination for Reliability (FRER) [IEEE802.1CB] mechanism. mechanism [IEEE802.1CB].
3GPP Release 16 includes integration of 5G with TSN, i.e., specifies
functions for the 5G System (5GS) to deliver TSN streams such that
the meet their QoS requirements. A key aspect of the integration is
the 5GS appears from the rest of the network as a set of TSN bridges,
in particular, one virtual bridge per User Plane Function (UPF) on
the user plane. The 5GS includes TSN Translator (TT) functionality
for the adaptation of the 5GS to the TSN bridged network and for
hiding the 5GS internal procedures. The 5GS provides the following
components:
1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully
centralized configuration model
2. time synchronization via reception and transmission of gPTP PDUs
[IEEE802.1AS]
3. low latency, hence, can be integrated with Scheduled Traffic scheduled traffic
[IEEE802.1Qbv]
4. reliability, hence, can be integrated with FRER [IEEE802.1CB]
3GPP Release 17 [TS23501] introduced enhancements to generalize
support for Time-Sensitive Communications (TSC) TSC beyond TSN. This includes IP communications to
provide time-sensitive service to,
e.g., services (e.g., to Video, Imaging Imaging, and Audio
for Professional Applications (VIAPA). (VIAPA)). The system model of 5G
acting as a “TSN bridge” "TSN bridge" in Release 16 has been reused to enable the
5GS acting as a “TSC node” "TSC node" in a more generic sense (which includes
TSN bridge and IP node). In the case of TSC that does not involve
TSN, requirements are given via exposure
interface interfaces, and the control
plane provides the service based on QoS and time synchronization
requests from an Application Function (AF).
Figure 7 shows an illustration of 5G-TSN integration where an
industrial controller (Ind Ctrlr) is connected to industrial Input/
Output devices (I/O dev) via 5G. The 5GS can directly transport
Ethernet frames since Release 15, 15; thus, end-to-end Ethernet
connectivity is provided. The 5GS implements the required interfaces
towards the TSN controller functions such as the CNC, thus adapts adapting
to the settings of the TSN network. A 5G user plane virtual bridge
interconnects TSN bridges or connects end stations, e.g., stations (e.g., I/O devices
to the TSN network. TSN Translators (TTs), network). TTs, i.e., the Device-Side TSN Translator (DS-TT) (DS-
TT) at the UE and the Network-Side TSN Translator (NW-
TT) (NW-TT) at the UPF UPF,
have a key role in the interconnection. Note that the introduction
of 5G brings flexibility in various aspects, e.g., a more flexible
network topology because a wireless hop can replace several wireline hops
hops, thus significantly reduce reducing the number of hops end-to- end to end.
[TSN5G] dives more into the integration of 5G with TSN.
+------------------------------+
| 5G System |
| +---+|
| +-+ +-+ +-+ +-+ +-+ |TSN||
| | | | | | | | | | | |AF |......+
| +++ +++ +++ +++ +++ +-+-+| .
| | | | | | | | .
| -+---+---++--+-+-+--+-+- | .
| | | | | | +--+--+
| +++ +++ +++ +++ | | TSN |
| | | | | | | | | | |Ctrlr+.......+
| +++ +++ +++ +++ | +--+--+ .
| | . .
| | . .
| +..........................+ | . .
| . Virtual Bridge . | . .
+---+ | . +--+--+ +---+ +---+--+ . | +--+---+ .
|I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ .
|dev| | . |TT| | | | | |TT| . | |bridge| | .
+---+ | . +--+--+ +---+ +---+--+ . | +------+ | .
| +..........................+ | . +-+-+-+
| | . | Ind |
| +..........................+ | . |Ctrlr|
| . Virtual Bridge . | . +-+---+
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ |
|I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+
|dev| |bridge| | . |TT| | | | | |TT| . | |bridge|
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+
| +..........................+ |
+------------------------------+
<----------------- end-to-end Ethernet ------------------->
Figure 7: 5G - TSN Integration
NR supports accurate reference time synchronization in 1us accuracy
level. Since NR is a scheduled system, an NR UE and a gNB are
tightly synchronized to their OFDM symbol structures. A 5G internal
reference time can be provided to the UE via broadcast or unicast
signaling, associating a known OFDM symbol to this reference clock.
The 5G internal reference time can be shared within the 5G network,
i.e., network
(i.e., radio and core network components. components). Release 16 has introduced
interworking with gPTP for multiple time domains, where the 5GS acts
as a virtual gPTP time-aware system and supports the forwarding of
gPTP time synchronization information between end stations and
bridges through the 5G user plane TTs. These account for the
residence time of the 5GS in the time synchronization procedure. One
special option is when the 5GS internal reference time is not only
used within the 5GS, but also to the rest of the devices in the
deployment, including connected TSN bridges and end stations.
Release 17 includes further improvements, i.e., improvements (i.e., methods for
propagation delay compensation in RAN, RAN), further improving the
accuracy for time synchronization over-the-air, over the air, as well as the
possibility for the TSN grandmaster clock to reside on the UE side.
More extensions and flexibility were added to the time
synchronization service service, making it general for TSC TSC, with additional
support of other types of clocks and time distribution such as
boundary clock, transparent clock peer-
to-peer, peer-to-peer, and transparent clock
end-to-end, aside from the time-aware system used for TSN.
Additionally, it is possible to use internal access stratum signaling
to distribute timing (and not the usual (g)PTP messages), for which
the required accuracy can be provided by the AF [TS23501]. The same
time synchronization service is expected to be further extended and
enhanced in Release 18 to support Timing Resiliency (according to
study item [SP211634]), where the 5G system can provide a back-up backup or
alternative timing source for the failure of the local GNSS source
(or other primary timing source) used by the vertical.
IETF Deterministic Networking (DetNet) DetNet is the technology to support time-sensitive
communications at the IP layer. 3GPP Release 18 includes a study
[TR2370046] on interworking between 5G and DetNet. Along the TSC
framework introduced for Release 17, the 5GS acts as a DetNet node
for the support of DetNet, DetNet; see Figure 7.1-1 in [TR2370046]. The
study provides details on how the 5GS is exposed by the Time
Sensitive Communication and Time Synchronization Function (TSCTSF) to
the DetNet controller as a router on a per UPF per-UPF granularity (similarly (similar
to the per UPF per-UPF Virtual TSN Bridge granularity shown in Figure 11).
In particular, it is listed what lists the parameters that are provided by the
TSCTSF to the DetNet controller. The study also includes how the
TSCTSF maps DetNet flow parameters to 5G QoS parameters. Note that
TSN is the primary subnetwork technology for DetNet. Thus, the work
on DetNet over TSN work, TSN, e.g., [RFC9023], can be leveraged via the TSN
support built in 5G.
Redundancy architectures were specified in order to provide
reliability against any kind of failure on the radio link or nodes in
the RAN and the core network. Redundant user plane paths can be
provided based on the dual connectivity architecture, where the UE
sets up two PDU sessions towards the same data network, and the 5G
system makes the paths of the two PDU sessions independent as
illustrated in Figure 9. There are two PDU sessions involved in the
solution: the The first spans from the UE via gNB1 to UPF1, acting as the
first PDU session anchor, while the second spans from the UE via gNB2
to UPF2, acting as second the PDU session anchor.
The independent paths may continue beyond the 3GPP network.
Redundancy Handling Functions (RHFs) are deployed outside of the 5GS,
i.e., in Host A (the device) and in Host B (the network). RHF can
implement replication and elimination functions as per [IEEE802.1CB]
or the Packet Replication, Elimination, and Ordering Functions
(PREOF) of IETF Deterministic Networking (DetNet) DetNet [RFC8655].
+........+
. Device . +------+ +------+ +------+
. . + gNB1 +--N3--+ UPF1 |--N6--+ |
. ./+------+ +------+ | |
. +----+ / | |
. | |/. | |
. | UE + . | DN |
. | |\. | |
. +----+ \ | |
. .\+------+ +------+ | |
+........+ + gNB2 +--N3--+ UPF2 |--N6--+ |
+------+ +------+ +------+
Figure 8: Reliability with Single UE
An alternative solution is that multiple UEs per device are used for
user plane redundancy as illustrated in Figure 9. Each UE sets up a
PDU session. The 5GS ensures that those the PDU sessions of the different
UEs are handled independently internal to the 5GS. There is no
single point of failure in this solution, which also includes RHF
outside of the 5G system, e.g., as per the FRER or as PREOF
specifications.
+.........+
. Device .
. .
. +----+ . +------+ +------+ +------+
. | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ |
. +----+ . +------+ +------+ | |
. . | DN |
. +----+ . +------+ +------+ | |
. | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ |
. +----+ . +------+ +------+ +------+
. .
+.........+
Figure 9: Reliability with Dual UE
Note that the abstraction provided by the RHF and the location of the
RHF being outside of the 5G system make 5G equally supporting
integration for reliability both with both FRER of TSN and PREOF of DetNet
DetNet, as they both rely on the same concept.
7. L-band L-Band Digital Aeronautical Communications System (LDACS)
One of the main pillars of the modern Air Traffic Management (ATM)
system is the existence of a communication infrastructure that
enables efficient aircraft guidance and safe separation in all phases
of flight. Although current systems are technically mature, they are
suffering
suffer from the VHF band’s band's increasing saturation in high-density
areas and the limitations posed by analogue analog radio. Therefore, aviation globally
(globally and in the European Union (EU) in particular, particular) strives for a
sustainable modernization of the aeronautical communication
infrastructure.
In the long-term, long term, ATM communication shall transition from analogue analog VHF
voice and VDL2 VDL Mode 2 communication to more spectrum efficient spectrum-efficient digital
data communication. The European ATM Master Plan foresees this
transition to be realized for terrestrial communications by the
development and implementation of the L-band Digital Aeronautical
Communications System (LDACS).
LDACS has been designed with applications related to the safety and
regularity of the flight in mind. It has therefore been designed as
a deterministic wireless data link (as far as possible).
It is a secure, scalable scalable, and spectrum efficient spectrum-efficient data link with
embedded navigation capability and capability; thus, it is the first truly
integrated Communications, Navigation, and Surveillance (CNS) system
recognized by the International Civil Aviation Organization (ICAO) (ICAO).
During flight tests tests, the LDACS capabilities have been successfully
demonstrated. A viable roll-out rollout scenario has been developed developed, which
allows gradual introduction of LDACS with immediate use and revenues.
Finally, ICAO is developing LDACS standards to pave the way for the
future.
LDACS shall enable IPv6 based IPv6-based air-ground communication related to the
safety and regularity of the flight. The particular challenge is
that no new frequencies can be made available for terrestrial
aeronautical communication. It was thus necessary to develop
procedures to enable the operation of LDACS in parallel with other
services in the same frequency band, band; see [RFC9372] for more in [RFC9372].
information.
7.1. Provenance and Documents
The development of LDACS has already made substantial progress in the
Single European Sky ATM Research (SESAR) framework, and it is
currently being continued in the follow-up program, SESAR2020
[RIH18]. A key objective of the SESAR activities is to develop, implement
implement, and validate a modern aeronautical data link able to
evolve with aviation needs over long-term. the long term. To this end, an LDACS
specification has been produced [GRA19] and is continuously updated;
transmitter demonstrators were developed to test the spectrum
compatibility of LDACS with legacy systems operating in the L-band [SAJ14];
[SAJ14], and the overall system performance was analyzed by computer
simulations, indicating that LDACS can fulfill the identified
requirements [GRA11].
LDACS standardization within the framework of the ICAO started in
December 2016. The ICAO standardization group has produced an
initial Standards and Recommended Practices (SARPs) document
[ICAO18]. The SARPs document defines the general characteristics of
LDACS.
Up to now now, the LDACS standardization has been focused on the
development of the physical layer and the data link layer, layer; only
recently have higher layers come into the focus of the LDACS
development activities. There is currently no "IPv6 over LDACS"
specification; however, SESAR2020 has started the testing of
IPv6-based LDACS testbeds. The IPv6 architecture for the
aeronautical telecommunication network is called the Future
Communications Infrastructure (FCI). FCI shall support quality of
service, QoS,
diversity, and mobility under the umbrella of the "multi-
link "multi-link
concept". This work is conducted by the ICAO working group WG-I. WG-I Working Group.
In addition to standardization activities activities, several industrial LDACS
prototypes have been built. One set of LDACS prototypes has been
evaluated in flight trials trials, confirming the theoretical results
predicting the system performance [GRA18][BEL22][GRA23] . [GRA18] [BEL22] [GRA23].
7.2. General Characteristics
LDACS will become one of several wireless access networks connecting
aircraft to the Aeronautical Telecommunications Network (ATN). The
LDACS access network contains several ground stations, each of them
providing which
provides one LDACS radio cell. The LDACS air interface is a cellular
data link with a star-topology star topology connecting aircraft to
ground-stations ground stations
with a full duplex radio link. Each ground-station ground station is the
centralized instance controlling all air-ground communications within
its radio cell.
The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the
forward link, link and 294 kbit/s to 1390 kbit/s on the reverse link,
depending on coding and modulation. Due to strong interference from
legacy systems in the L-band, the most robust coding and modulation
should be expected for initial deployment, i.e., 315/294 315 kbit/s on the forward/reverse link, respectively.
forward link and 294 kbit/s on the reverse link.
In addition to the communications capability, LDACS also offers a
navigation capability. Ranging data, similar to DME (Distance
Measuring Equipment), is extracted from the LDACS communication links
between aircraft and LDACS ground stations. This results in LDACS
providing an APNT (Alternative Position, Navigation and Timing)
capability to supplement the existing on-board GNSS (Global
Navigation Satellite System) without the need for additional
bandwidth. Operationally, there will be no difference for pilots
whether the navigation data are provided by LDACS or DME. This
capability was flight tested and proven during the MICONAV flight
trials in 2019 [BAT19].
In previous works and during the MICONAV flight campaign in 2019, it
was also shown, shown that LDACS can be used for surveillance capability.
Filip et al. [FIL19] have shown the passive radar capabilities of LDACS
LDACS, and Automatic Dependence Surveillance – - Contract (ADS-C) was
demonstrated via LDACS during the flight campaign 2019 [SCH19].
Since LDACS has been mainly designed for air traffic management
communication
communication, it supports mutual entity authentication, integrity
and confidentiality capabilities of user data messages messages, and some
control channel protection capabilities [MAE18], [MAE191], [MAE192], [MAE18] [MAE191] [MAE192]
[MAE20].
Overall
Overall, this makes LDACS the world's first truly integrated CNS
system and is the worldwide most mature, secure, and terrestrial long-
range long-range CNS
technology for civil aviation. aviation worldwide.
7.3. Deployment and Spectrum
LDACS has its origin in merging parts of the B-VHF [BRA06], B-AMC
[SCH08], TIA-902 (P34) [HAI09], and WiMAX IEEE 802.16e technologies
[EHA11]. [EHA11]
technologies. In 2007 2007, the spectrum for LDACS was allocated at the
World Radio Conference (WRC).
It was decided to allocate the spectrum next to Distance Measuring
Equipment (DME), resulting in an in-lay approach between the DME
channels for LDAC [SCH14].
LDACS is currently being standardized by ICAO and several roll-out rollout
strategies are discussed: discussed.
The LDACS data link provides enhanced capabilities to existing
Aeronautical
aeronautical communications infrastructure infrastructures, enabling them to better
support user needs and new applications. The deployment scalability
of LDACS allows its implementation to start in areas where it is most
needed to Improve immediately improve the performance of already fielded and already-fielded
infrastructure. Later Later, the deployment is extended based on
operational demand. An attractive scenario for upgrading the
existing VHF communication systems by adding an additional LDACS data
link is described below.
When considering the current VDL Mode 2 infrastructure and user base,
a very attractive win-win situation comes about, about when the
technological advantages of LDACS are combined with the existing VDL
mode
Mode 2 infrastructure. LDACS provides at least 50 time times more
capacity than VDL Mode 2 and is a natural enhancement to the existing
VDL Mode 2 business model. The advantage of this approach is that
the VDL Mode 2 infrastructure can be fully reused. Beyond that, it
opens the way for further enhancements [ICAO19].
7.4. Applicability to Deterministic Flows
As LDACS is a ground-based digital communications system for flight
guidance and communications related to safety and regularity of
flight, time-bounded deterministic arrival times for safety critical
messages are a key feature for its successful deployment and roll-
out. rollout.
7.4.1. System Architecture
Up to 512 Aircraft Station (AS) Stations (ASes) communicate to an LDACS Ground
Station (GS) in the Reverse Link reverse link (RL). A GS communicate communicates to an AS in
the Forward Link (FL). Via an Access-Router (AC-R) (AC-R), GSs connect the
LDACS sub-network subnetwork to the global Aeronautical Telecommunications
Network (ATN) to which the corresponding Air Traffic Services (ATS)
and Aeronautical Operational Control (AOC) end systems are attached.
7.4.2. Overview of the Radio Protocol Stack
The protocol stack of LDACS is implemented in the AS and GS: It GS; it
consists of the Physical Layer physical (PHY) layer with five major functional
blocks above it. Four are placed in the Data Link Layer data link layer (DLL) of the
AS and GS: (1)
1. Medium Access Layer (MAC), (2)
2. Voice Interface (VI),
(3)
3. Data Link Service (DLS), and (4)
4. LDACS Management Entity (LME).
The last entity resides within the Sub-Network Layer: Sub-Network subnetwork layer: the Subnetwork
Protocol (SNP). The LDACS network is externally connected to voice
units, radio control units, and the ATN Network Layer. network layer.
Communications between the MAC and LME layer layers is split into four
distinct control channels: The
1. the Broadcast Control Channel (BCCH) (BCCH), where LDACS ground stations
announce their specific LDACS cell, including physical parameters
and cell identification;
2. the Random Access Channel (RACH) (RACH), where LDACS airborne radios can
request access to an LDACS cell;
3. the Common Control Channel (CCCH) (CCCH), where LDACS ground stations
allocate resources to aircraft radios, enabling the airborne side
to transmit the user payload; and
4. the Dedicated Control Channel (DCCH) (DCCH), where LDACS airborne radios
can request user data resources from the LDACS ground station so
the airborne side can transmit the user payload.
Communications between the MAC and DLS layer layers is handled by the Data
Channel (DCH) where the user payload is handled.
Figure 10 shows the protocol stack of LDACS as implemented in the AS
and GS.
IPv6 Network Layer
|
|
+------------------+ +----+
| SNP |--| | Sub-Network Subnetwork
| | | | Layer
+------------------+ | |
| | LME|
+------------------+ | |
| DLS | | | Logical Link
| | | | Control Layer
+------------------+ +----+
| |
DCH DCCH/CCCH
| RACH/BCCH
| |
+--------------------------+
| MAC | Medium Access
| | Layer
+--------------------------+
|
+--------------------------+
| PHY | Physical Layer
+--------------------------+
|
|
((*))
FL/RL radio channels
separated by
Frequency Division Duplex
frequency division duplex
Figure 10: LDACS protocol stack Protocol Stack in AS and GS
7.4.3. Radio (PHY)
The physical layer provides the means to transfer data over the radio
channel. The LDACS ground-station ground station supports bi-directional bidirectional links to
multiple aircraft under its control. The forward link direction (FL;
ground-to-air)
(which is ground to air) and the reverse link direction (RL; air-to-ground) (which is air
to ground) are separated by frequency division duplex. Forward link
and reverse link use a 500 kHz channel each. The ground-station ground station
transmits a continuous stream of OFDM symbols on the forward link.
In the reverse link link, different aircraft aircrafts are separated in time and
frequency using a combination of Orthogonal Frequency-Division Multiple-Access
Multiple Access (OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus
Thus, aircraft transmit discontinuously on the reverse link with
radio bursts sent in precisely defined transmission opportunities
allocated by the
ground-station. ground station. The most important service on the
PHY layer of LDACS is the PHY time framing service, which indicates
that the PHY layer is ready to transmit in a given slot and to indicate indicates
PHY layer framing and timing to the MAC time framing service. LDACS
does not support beam-forming or Multiple Input Multiple Output
(MIMO).
7.4.4. Scheduling, Frame Structure Structure, and QoS (MAC)
The data-link data link layer provides the necessary protocols to facilitate
concurrent and reliable data transfer for multiple users. The LDACS
data link layer is organized in two sub-layers: The sublayers: the medium access
sub-layer
sublayer and the logical link control sub-layer. sublayer. The medium access
sub-layer
sublayer manages the organization of transmission opportunities in
slots of time and frequency. The logical link control sub-layer sublayer
provides acknowledged point-to-point logical channels between the
aircraft and the ground-station ground station using an automatic repeat request
protocol. LDACS supports also supports unacknowledged point-to-point channels
and ground-to-air broadcast. Before going more into depth about the
LDACS medium access,
Next, the frame structure of LDACS is introduced: introduced, followed by a more
in-depth discussion of the LDACS medium access.
The LDACS framing structure for FL and RL is based on Super-Frames
(SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols.
The FL and RL SF boundaries are aligned in time (from the view of the
GS).
In the FL, an SF contains a Broadcast Frame of broadcast frame with a duration of 6.72
ms (56 OFDM symbols) for the Broadcast Control Channel (BCCH), (BCCH) and
four Multi-Frames (MF), each of with a duration of 58.32 ms (486 OFDM
symbols).
In the RL, each SF starts with a Random Access (RA) slot of with a
length of 6.72 ms with two opportunities for sending RL random access
frames for the Random Access Channel (RACH), followed by four MFs.
These MFs have the same fixed duration of 58.32 ms as in the FL, FL but a
different internal structure
Figure structure.
Figures 11 and Figure 12 illustrate the LDACS frame structure. This fixed
frame structure allows for the reliable and dependable transmission
of data.
^
| +------+------------+------------+------------+------------+
| FL | BCCH | MF | MF | MF | MF |
F +------+------------+------------+------------+------------+
r <---------------- Super-Frame (SF) - 240ms ----------------> 240 ms --------------->
e
q +------+------------+------------+------------+------------+
u RL | RACH | MF | MF | MF | MF |
e +------+------------+------------+------------+------------+
n <---------------- Super-Frame (SF) - 240ms ----------------> 240 ms --------------->
c
y
|
----------------------------- Time ------------------------------>
|
Figure 11: SF structure Structure for LDACS
^
| +-------------+------+-------------+
| FL | DCH | CCCH | DCH |
F +-------------+------+-------------+
r <---- <--- Multi-Frame (MF) - 58.32ms 58.32 ms -->
e
q +------+---------------------------+
u RL | DCCH | DCH |
e +------+---------------------------+
n <---- <--- Multi-Frame (MF) - 58.32ms 58.32 ms -->
c
y
|
-------------------- Time ------------------>
|
Figure 12: MF Structure for LDACS
This fixed frame structure allows for a reliable and dependable
transmission of data.
Next, the LDACS medium access layer is
introduced: introduced.
LDACS medium access is always under the control of the ground-station ground station
of a radio cell. Any medium access for the transmission of user data
has to be requested with a resource request message stating the
requested amount of resources and class of service. The ground- ground
station performs resource scheduling on the basis of these requests
and grants resources with resource allocation messages. Resource
request and allocation messages are exchanged over dedicated
contention-free control channels.
LDACS has two mechanisms to request resources from the scheduler in
the ground-station. ground station. Resources can either be requested "on demand", demand" or
permanently allocated by a LDACS ground station, station with a given class of
service. On the forward link, this is done locally in the
ground-station, ground
station; on the reverse link link, a dedicated contention-free control
channel is used (Dedicated (the Dedicated Control Channel (DCCH); roughly 83
bit
bits every 60 ms). A resource allocation is always announced in the
control channel of the forward link (Common Control Channel (CCCH);
variable sized). Due to the spacing of the reverse link control
channels of every 60 ms, a medium access delay in the same order of
magnitude is to be expected.
Resources can also be requested "permanently". The permanent
resource request mechanism supports requesting recurring resources in at
given time intervals. A permanent resource request has to be
canceled by the user (or by the ground-station, ground station, which is always in
control). User data transmissions over LDACS are therefore always
scheduled by the ground-station, ground station, while control data uses statically
(i.e.
(i.e., at net entry) allocated recurring resources (DCCH and CCCH).
The current specification documents specify no scheduling algorithm.
However
However, performance evaluations so far have used strict priority
scheduling and round robin for equal priorities for simplicity. In
the current prototype implementations implementations, LDACS classes of service are
thus realized as priorities of medium access and not as flows. Note
that this can starve out low priority low-priority flows. However, this is not
seen as a big problem since safety related message safety-related messages always go first
in any case. Scheduling of reverse link resources is done in
physical Protocol Data Units (PDU) of 112 bit bits (or larger if more
aggressive coding and modulation is used). Scheduling on the forward
link is done Byte-wise byte wise since the forward link is transmitted
continuously by the ground-station. ground station.
In order to support diversity, LDACS supports handovers to other
ground-stations
ground stations on different channels. Handovers may be initiated by
the aircraft (break-before-make) (break before make) or by the ground-station (make-
before-break). ground station (make
before break). Beyond this, FCI diversity shall be implemented by
the multi-link concept.
8. IANA Considerations
This specification does not require document has no IANA action. actions.
9. Security Considerations
Most RAW technologies integrate some authentication or encryption
mechanisms that were are defined outside the IETF. The IETF
specifications referenced herein each provide their own Security
Considerations, security
considerations, and the lower layer lower-layer technologies used provide their
own security at Layer-2.
12. Layer 2.
10. References
10.1. Normative References
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <https://www.rfc-editor.org/info/rfc5673>.
[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
<https://www.rfc-editor.org/info/rfc8557>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[I-D.ietf-raw-architecture]
[RFC9912] Thubert, P., Ed., "Reliable and Available Wireless (RAW)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-raw-architecture-24, 28 RFC 9912, DOI 10.17487/RFC9912, February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-
architecture-24>.
13.
2026, <https://www.rfc-editor.org/info/rfc9912>.
10.2. Informative References
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>.
[RFC9372] Mäurer, N., Ed., Gräupl, T., Ed., and C. Schmitt, Ed.,
"L-Band Digital Aeronautical Communications System
(LDACS)", RFC 9372, DOI 10.17487/RFC9372, March 2023,
<https://www.rfc-editor.org/info/rfc9372>.
[RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy,
S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
(MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
<https://www.rfc-editor.org/info/rfc9033>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
[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>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
"Deterministic Networking (DetNet) Data Plane: IP over
IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023,
DOI 10.17487/RFC9023, June 2021,
<https://www.rfc-editor.org/info/rfc9023>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>.
[I-D.ietf-roll-nsa-extension]
[NSA-EXT] Koutsiamanis, R., Ed., Papadopoulos, G. Z., Montavont, N.,
and P. Thubert, "Common Ancestor Objective Function and
Parent Set DAG Metric Container Extension", Work in
Progress,
November 2023, Internet-Draft, draft-ietf-roll-nsa-extension-
13, 7 July 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-roll-nsa-extension-12>.
[I-D.ietf-roll-dao-projection]
draft-ietf-roll-nsa-extension-13>.
[RFC9914] Thubert, P., Ed., Jadhav, R., R.A., and M. Richardson, "Root-
initiated
Initiated Routing State in RPL", Work in Progress,
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-roll-dao-projection-40>.
[I-D.ietf-6tisch-coap] the Routing Protocol for Low-
Power and Lossy Networks (RPL)", RFC 9914,
DOI 10.17487/RFC9914, February 2026,
<https://www.rfc-editor.org/info/rfc9914>.
[CoAP-6TiSCH]
Sudhaakar, R. S. S., Ed. and P. Zand, "6TiSCH Resource
Management and Interaction using CoAP", Work in Progress, Internet-
Draft,
Internet-Draft, draft-ietf-6tisch-coap-03, 9 March 2015,
<https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
coap-03>.
[IEEE Std 802.15.4]
[IEEE802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE standard
Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
<https://doi.org/10.1109/IEEESTD.2016.7460875>.
[IEEE802.11]
IEEE, "IEEE Standard for Information Technology, "IEEE Std
802.15.4, Part. 15.4: Technology --
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks".
[IEEE Std 802.11] Specifications", IEEE standard for Information Technology,
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 2020,
<https://ieeexplore.ieee.org/document/9363693>.
[IEEE802.11ax]
IEEE, "IEEE Standard
802.11 - IEEE Standard for Information Technology - --
Telecommunications and information exchange Information Exchange between
systems
Systems Local and metropolitan area networks - Metropolitan Area Networks -- Specific
requirements -
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications.",
<https://ieeexplore.ieee.org/document/9363693>.
[IEEE Std 802.11ax]
IEEE standard for Information Technology, "802.11ax: Specifications Amendment 1:
Enhancements for High Efficiency High-Efficiency WLAN", IEEE Std 802.11ax-
2021, DOI 10.1109/IEEESTD.2021.9442429, 2021,
<https://ieeexplore.ieee.org/document/9442429>.
[IEEE Std 802.11ay]
IEEE standard
[IEEE802.11ay]
IEEE, "IEEE Standard for Information Technology, "802.11ay: Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 2:
Enhanced throughput Throughput for operation Operation in license-exempt bands License-exempt Bands
above 45 GHz", IEEE Std 802.11ay-2021,
DOI 10.1109/IEEESTD.2021.9502046, 2021,
<https://ieeexplore.ieee.org/document/9502046/>.
[IEEE Std 802.11ad]
"802.11ad:
[IEEE802.11ad]
IEEE, "IEEE Standard for Information technology --
Telecommunications and information exchange between
systems -- Local and metropolitan area networks --
Specific requirements-Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications
Amendment 3: Enhancements for very high throughput Very High Throughput in the
60 GHz band", Band", IEEE Std 802.11ad-2012,
DOI 10.1109/IEEESTD.2012.6392842, 2012,
<https://ieeexplore.ieee.org/document/6392842/>.
[IEEE 802.11be]
IEEE standard
[IEEE802.11be]
IEEE, "IEEE Standard for Information Technology, "802.11be:
Extreme technology --
Telecommunications and information exchange between
systems Local and metropolitan area networks -- Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 2:
Enhancements for Extremely High Throughput PAR",
<https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eht-
eht-draft-proposed-par.docx>.
[IEEE (EHT)", IEEE
Std 802.1Qat]
"802.1Qat: 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080,
<https://ieeexplore.ieee.org/document/11090080>.
[IEEE802.1Qat]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Virtual Bridged Local Area Networks Amendment
14: Stream Reservation Protocol". Protocol (SRP)", IEEE Std 802.1Qat-
2010, DOI 10.1109/IEEESTD.2010.5594972,
<https://doi.org/10.1109/IEEESTD.2010.5594972>.
[Cavalcanti_2019]
Dave Cavalcanti et al.,
Cavalcanti, D., Perez-Ramirez, J., Rashid, M. M., Fang,
J., Galeev, M., and K. B. Stanton, "Extending Accurate
Time Distribution and Timeliness Capabilities over Over the Air
to Enable Future Wireless Industrial Automation Systems, the Systems",
Proceedings of
IEEE", the IEEE, vol. 107, no. 6, pp. 1132-1152,
DOI 10.1109/JPROC.2019.2903414, June 2019. 2019,
<https://doi.org/10.1109/JPROC.2019.2903414>.
[Nitsche_2015]
Thomas Nitsche et al.,
Nitsche, T., Cordeiro, C., Flores, A. B., Knightly, E. W.,
Perahia, E., and J. C. Widmer, "IEEE 802.11ad: directional
60 GHz communication for multi-Gigabit-per-second Wi-Fi",
IEEE Communications Magazine, vol. 52, no. 12, pp.
132-141, DOI 10.1109/MCOM.2014.6979964, December 2014. 2014,
<https://doi.org/10.1109/MCOM.2014.6979964>.
[Ghasempour_2017]
Yasaman Ghasempour et al.,
Ghasempour, Y., Silva, C. R. C. M. D., Cordeiro, C., and
E. W. Knightly, "802.11ay: Next-Generation 60 GHz
Communications for 100 Gb/s Wi-Fi", IEEE Communications
Magazine, vol. 55, no. 12, pp. 186-192,
DOI 10.1109/MCOM.2017.1700393, December 2017. 2017,
<https://doi.org/10.1109/MCOM.2017.1700393>.
[IEEE_doc_11-18-2009-06]
IEEE standard for Information Technology,
IEEE, "802.11 Real-
Time Real-Time Applications (RTA) Topic Interest
Group (TIG) Report", November 2018. 2018,
<https://mentor.ieee.org/802.11/dcn/18/11-18-2009-06-0rta-
rta-report-draft.docx>.
[vilajosana21]
Xavier Vilajosana et al.,
Vilajosana, X., Watteyne, T., Chang, T., Vucinic, M.,
Duquennoy, S., and P. Thubert, "IETF 6TiSCH: A Tutorial", March
2021,
Communications Surveys and Tutorials, IEEE Communications
Society, HAL ID: hal-02420974,
DOI 10.1109/COMST.2019.2939407, December 2019,
<https://inria.hal.science/hal-02420974/file/
IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf>.
[ISA100.11a]
ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
also IEC 62734", 2011, <http://www.isa100wci.org/en-
US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-
WEB-ETSI.aspx>.
ISA, "ISA100 Wireless", ANSI/ISA-100.11a-2011 (IEC 26743),
<https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo
*_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS*
czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw>.
[WirelessHART]
www.hartcomm.org, "Industrial Communication Networks -
Wireless Communication Network and Communication Profiles
- WirelessHART - IEC 62591", 2010.
FieldComm Group, "WirelessHART",
<https://www.fieldcommgroup.org/technologies/
wirelesshart>.
[WFA] www.wi-fi.org, "Wi-Fi Alliance". Alliance", <https://www.wi-fi.org>.
[Avnu] avnu.org, "Avnu Alliance". Alliance", <https://www.avnu.org>.
[PCE] IETF, "Path Computation Element",
<https://dataTracker.ietf.org/doc/charter-ietf-pce/>.
<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[CCAMP] IETF, "Common Control and Measurement Plane",
<https://dataTracker.ietf.org/doc/charter-ietf-ccamp/>.
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4",
<https://dataTracker.ietf.org/doc/charter-ietf-6tisch/>. 802.15.4e",
<https://datatracker.ietf.org/doc/charter-ietf-6tisch/>.
[RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S.,
Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital
Aeronautical Communications System (LDACS) Activities in
SESAR2020", Proceedings of the 2018 Integrated Communications
Navigation and Communications, Navigation,
Surveillance Conference (ICNS) Herndon, VA,
USA, (ICNS), pp. 4A1-1-4A1-8,
DOI 10.1109/ICNSURV.2018.8384880, April 2018. 2018,
<https://doi.org/10.1109/ICNSURV.2018.8384880>.
[GRA19] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G
Specification", SESAR2020 B., and Q. Parrod,
"SESAR2020 - PJ14-02-01 D3.3.010, February
2019. - LDACS A/G SPECIFICATION",
EDITION 00.02.02, 16 August 2019, <https://www.ldacs.com/
wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_A
G_Specification_00_02_02-1_0.pdf>.
[SAJ14] al, B. H. A., Haindl, B., Meser, J., Sajatovic, M., Muller, S.,
Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1
conformance and compatibility assessment", 2014 IEEE/AIAA
33rd Digital Avionics Systems Conference (DASC) (DASC), pp.
3B3-1-3B3-11, DOI 10.1109/DASC.2014.6979447, October
2014. 2014,
<https://doi.org/10.1109/DASC.2014.6979447>.
[GRA11] Gräupl, T. and M. Ehammer, "L-DACS1 T., "LDACS1 Data Link Layer Evolution of ATN/IPS", Proceedings of the 30th
IEEE/AIAA 30th Digital Avionics Systems Conference (DASC) Seattle, WA,
USA, Conference, pp.
1-28, DOI 10.1109/DASC.2011.6096230, October 2011. 2011,
<https://doi.org/10.1109/DASC.2011.6096230>.
[ICAO18] International Civil Aviation Organization (ICAO), "L-Band
Digital Aeronautical Communication System (LDACS)",
International Standards and Recommended Practices Practices, Annex
10 - Aeronautical Telecommunications, Vol. III -
Communication Systems, July 2018. 2018,
<https://elibrary.icao.int/product/279816>.
[GRA18] al., T. Gräupl, T., Schneckenburger, N., Jost, T., Schnell, M.,
Filip, A., Bellido-Manganell, M. A., Mielke, D. M.,
Mäurer, N., Kumar, R., Osechas, O., and G. E., Battista,
"L-band Digital Aeronautical Communications System (LDACS)
flight trials in the national German project MICONAV", Proceedings of the
2018 Integrated Communications, Navigation, Surveillance
Conference
(ICNS) Herndon, VA, USA, (ICNS), pp. 4A2-1-4A2-7,
DOI 10.1109/ICNSURV.2018.8384881, April 2018. 2018,
<https://doi.org/10.1109/ICNSURV.2018.8384881>.
[BEL22] al, B. Bellido-Manganell, M. A., Gräupl, T., Heirich, O., Mäurer,
N., Filip-Dhaubhadel, A., Mielke, D. M., Schalk, L. M.,
Becker, D., Schneckenburger, N., and M. Schnell, "LDACS
Flight Trials: Demonstration of ATS-
B2, IPS, and Seamless Mobility", Performance Analysis of
the Future Aeronautical Communications System", IEEE
Transactions on Aerospace and Electronic Systems, vol. 58 58,
no. 1, pp. 615-634, DOI 10.1109/TAES.2021.3111722, 2022.
February 2022,
<https://doi.org/10.1109/TAES.2021.3111722>.
[GRA23] al, G. T. Gräupl, T., Mielke, D. M., Bellido-Manganell, M. A.,
Jansen, L. J., Mäurer, N., Gürbüz, A., Filip-Dhaubhadel,
A., Schalk, L., Becker, D., Skorepa, M., Wrobel, F.,
Morioka, K., Kurz, S., and J. Meser, "LDACS Flight Trials:
Demonstration of ATS-
B2, ATS-B2, IPS, and Seamless Mobility", Proceedings of the 2023
Integrated Communication, Navigation and Surveillance
Conference (ICNS), Herndon, VA, USA pp. 1-13,
DOI 10.1109/ICNS58246.2023.10124329, 2023. 2023,
<https://doi.org/10.1109/ICNS58246.2023.10124329>.
[TR37910] 3GPP, "Study on self evaluation towards IMT-2020
submission", 3GPP TR 37.910,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3190>.
[TR38824] 3GPP, "Study on physical layer enhancements for NR ultra-
reliable and low latency case (URLLC)", 3GPP TR 38.824,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3498>.
[TR38825] 3GPP, "Study on NR industrial Internet of Things (IoT)",
3GPP TR 38.825,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3492>.
[TS22104] 3GPP, "Service requirements for cyber-physical control
applications in vertical domains", 3GPP TS 22.104,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3528>.
[TR22804] 3GPP, "Study on Communication for Automation in Vertical
domains (CAV)", 3GPP TS 22.804,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3187>.
[TS23501] 3GPP, "System architecture for the 5G System (5GS)",
3GPP TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS38300] 3GPP, "NR "NR; NR and NG-RAN Overall description", description; Stage-2",
3GPP TS 38.300,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3191>.
[SYSTOVER5G]
3GPP, "5G system overview", System Overview", 8 August 2022,
<https://www.3gpp.org/technologies/5g-system-overview>.
[RP210854] 3GPP, "Revised WID: Enhanced Industrial Internet of Things
(IoT) and ultra-reliable and low latency communication
(URLLC) support for NR", 3GPP RP-210854, March 2021,
<https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Docs/
RP-210854.zip>.
[TR2370046]
3GPP, "Study on 5GS DetNet Deterministic Networking (DetNet)
interworking", 3GPP TR23.700-46, August 2022, TR 23.700-46,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3994>.
[SP211634] 3GPP, "Study on 5G Timing Resiliency, TSC, and URLLC
enhancements", 3GPP SP-211634, December 2021,
<https://www.3gpp.org/ftp/tsg_sa/TSG_SA/
TSGS_94E_Electronic_2021_12/Docs/SP-211634.zip>.
[IMT2020] "ITU towards IMT for 2020 and beyond",
<https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-
2020/Pages/default.aspx>. ITU, "IMT-2020 (a.k.a. "5G")", <https://www.itu.int/en/
ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/
default.aspx>.
[IEEE802.1TSN]
IEEE 802.1, 802.1 Working Group, "Time-Sensitive Networking (TSN) Task
Group", <http://www.ieee802.org/1/pages/tsn.html>.
[IEEE802.1AS]
IEEE, "IEEE Standard for Local and metropolitan area
networks Metropolitan Area
Networks -- Timing and Synchronization for Time-Sensitive
Applications", IEEE Std 802.1AS-2020,
<https://standards.ieee.org/content/ieee-standards/en/
standard/802_1AS-2020.html>.
DOI 10.1109/IEEESTD.2020.9121845,
<https://doi.org/10.1109/IEEESTD.2020.9121845>.
[IEEE802.1CB]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Frame Replication and Elimination for
Reliability", DOI 10.1109/IEEEStd2017.8091139, IEEE Std 802.1CB-2017,
DOI 10.1109/IEEEStd2017.8091139, 2017,
<https://ieeexplore.ieee.org/document/8091139>.
[IEEE802.1Qbv]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- - Amendment 25:
Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015,
<https://ieeexplore.ieee.org/document/7440741>. Std 802.1Qbv-
2015, DOI 10.1109/IEEESTD.2016.8613095, 2016,
<https://doi.org/10.1109/IEEESTD.2016.8613095>.
[IEEE802.1Qcc]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- Amendment 31:
Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements", IEEE Std 802.1Qcc-2018,
DOI 10.1109/IEEESTD.2018.8514112,
<https://ieeexplore.ieee.org/document/8514112>.
[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018,
DOI 10.1109/IEEESTD.2018.8457469,
<https://ieeexplore.ieee.org/document/8457469>.
[TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking
for Industrial Communications", 5G-ACIA whitepaper, White Paper,
<https://5g-acia.org/whitepapers/integration-of-5g-with-
time-sensitive-networking-for-industrial-communications>.
[MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity
Architecture for the L-band Digital Aeronautical
Communications System (LDACS)", IEEE 2018 IEEE/AIAA 37th
Digital Avionics Systems Conference (DASC), pp. 1-10, London, UK , 2017.
DOI 10.1109/DASC.2018.8569878, 2018,
<https://doi.org/10.1109/DASC.2018.8569878>.
[MAE191] Maeurer, N. and C. Schmitt, "Towards Successful
Realization of the LDACS Cybersecurity Architecture: An
Updated Datalink Security Threat- and Risk Analysis", IEEE
Integrated Communications, Navigation and Surveillance
Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019.
DOI 10.1109/ICNSURV.2019.8735139, 2019,
<https://doi.org/10.1109/ICNSURV.2019.8735139>.
[ICAO19] International Civil Aviation Organization (ICAO), "TLDACS
White Paper–A Paper - A Roll-out Scenario", Communications Panel -
Data Communications Infrastructure Working Paper
COMMUNICATIONS PANEL–DATA COMMUNICATIONS INFRASTRUCTURE
WORKING GROUP, Montreal, Canada , Group, October 2019.
2019, <https://www.ldacs.com/wp-content/uploads/2013/12/
ACP-DCIWG-IP01-LDACS-White-Paper.pdf>.
[MAE192] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
the LDACS Cybersecurity Implementation", IEEE IEEE/AIAA 38th
Digital Avionics Systems Conference (DACS), (DASC), pp. 1-10, San Diego,
CA, USA ,
DOI 10.1109/DASC43569.2019.9081786, September 2019. 2019,
<https://doi.org/10.1109/DASC43569.2019.9081786>.
[MAE20] Maeurer, N., Graeupl, T., Gentsch, C., and C. Schmitt,
"Comparing Different Diffie-Hellman Key Exchange Flavors
for LDACS",
IEEE AIAA/IEEE 39th Digital Avionics Systems
Conference (DACS), (DASC), pp. 1-10, San Diego, CA, USA , October 2019.
DOI 10.1109/DASC50938.2020.9256746, 2020,
<https://doi.org/10.1109/DASC50938.2020.9256746>.
[FIL19] Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non-
Cooperative Surveillance Multistatic Radar Design and
Detection Coverage Assessment", IEEE IEEE/AIAA 38th Digital
Avionics Systems Conference (DACS), (DASC), pp. 1-10, San Diego, CA, USA ,
September 2019.
DOI 10.1109/DASC43569.2019.9081714, 2019,
<https://doi.org/10.1109/DASC43569.2019.9081714>.
[BAT19] Battista, G., Osechas, O., Narayanan, S., Crespillo, O.G.,
Gerbeth, D., Maeurer, N., Mielke, D., and T. Graeupl,
"Real-Time Demonstration of Integrated Communication and
Navigation Services Using LDACS", IEEE Integrated
Communications, Navigation and Surveillance Conference
(ICNS), pp. 1-12, Herndon, VA, USA , 2019. i-xii, DOI 10.1109/ICNSURV.2019.8735195, 2019,
<https://elib.dlr.de/134475/1/08735195.pdf>.
[BRA06] Brandes, S., Schnell, M., Rokitansky, C.H., C.-h., Ehammer, M.,
Graeupl, T., Steendam, H., Guenach, M., Rihacek, C., and
B. Haindl, "B-VHF -Selected - Selected Simulation Results and Final
Assessment", IEEE 25th Digital Avionics Systems Conference
(DACS), pp. 1-12, New York, NY, USA , September 2019. DOI 10.1109/DASC.2006.313670, 2006,
<https://doi.org/10.1109/DASC.2006.313670>.
[SCH08] Schnell, M., Brandes, S., Gligorevic, S., Rokitansky,
C.H., C.-
H., Ehammer, M., Graeupl, T., Rihacek, C., and M.
Sajatovic, "B-AMC - Broadband Aeronautical Multi-carrier
Communications", IEEE 8th 2008 Integrated Communications,
Navigation and Surveillance Conference (ICNS), Conference, pp. 1-13,
New York, NY, USA , April 2008. 1-12,
DOI 10.1109/ICNSURV.2008.4559173, 2008,
<https://doi.org/10.1109/ICNSURV.2008.4559173>.
[SCH19] Schnell, M., German Aerospace Center (DLR), "DLR tests digital
communications technologies combined with additional
navigation functions for the first time", 3 27 March 2019,
<https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-
10081/151_read-32951/#/gallery/33877>.
<https://www.dlr.de/en/latest/
news/2019/01/20190327_modern-technology-for-the-flight-
deck>.
[HAI09] Haindl, B., Rihacek, C., Sajatovic, M., Phillips, B.,
Budinger, J., Schnell, M., Kamiano, D., and W. Wilson,
"Improvement of L-DACS1 Design by Combining B-AMC with P34
and WiMAX Technologies", IEEE 9th 2009 Integrated Communications,
Navigation and Surveillance Conference
(ICNS), Conference, pp. 1-8, New York, NY, USA ,
DOI 10.1109/ICNSURV.2009.5172873, May 2009. 2009,
<https://doi.org/10.1109/ICNSURV.2009.5172873>.
[EHA11] Ehammer, M. M., Pschernig, E., and T. Graeupl, "AeroMACS - An
Airport Communications System", IEEE 2011 IEEE/AIAA 30th
Digital Avionics Systems
Conference (DACS), Conference, pp. 1-16, New York, NY, USA , September
2011. 4C1-1-4C1-16,
DOI 10.1109/DASC.2011.6095903, 2011,
<https://doi.org/10.1109/DASC.2011.6095903>.
[SCH14] Schnell, M., Epple, U., Shutin, D., and N.
Schneckenburger, "LDACS: Future Aeronautical
Communications for Air- Traffic Management", IEEE
Communications Magazine, 52(5), 104-110 , 2017. vol. 52, no. 5, pp. 104-110,
DOI 10.1109/MCOM.2014.6815900, May 2014,
<https://doi.org/10.1109/MCOM.2014.6815900>.
[Cavalcanti1287]
Cavalcanti, D., Venkatesan, G., Cariou, L., and C.
Cordeiro, "TSN support in 802.11 and potential extensions
for TGbe", 10 September 2019,
<https://mentor.ieee.org/802.11/dcn/19/11-19-1287>.
[Sudhakaran2021]
Sudhakaran, S., Montgomery, K., Kashef, M., Cavalcanti,
D., and R. Candell, "Wireless Time Sensitive Networking
for Industrial Collaborative Robotic Workcells", 2021 17th
IEEE International Conference on Factory Communication
Systems
(WFCS) , (WFCS), pp. 91-94,
DOI 10.1109/WFCS46889.2021.9483447, 2021,
<https://ieeexplore.ieee.org/abstract/document/9483447>.
[Fang_2021]
Fang, J., Sudhakaran, S., Cavalcanti, D., Cordeiro, C.,
and C. Cheng, Chen, "Wireless TSN with Multi-Radio Wi-Fi", 2021
IEEE International Conference on Standards for Communications and Networking,
December 2021. , 2021.
11.
Networking (CSCN), pp. 105-110,
DOI 10.1109/CSCN53733.2021.9686180, 2021,
<https://doi.org/10.1109/CSCN53733.2021.9686180>.
Acknowledgments
Many thanks to the participants of the RAW WG WG, where a lot of the
work discussed here in this document happened, and to Malcolm Smith for
his review of the
802.11 section. section on IEEE 802.11. Special thanks for post
directorate and IESG
reviewers, reviewers Roman Danyliw, Victoria Pritchard,
Donald Eastlake, Mohamed Boucadair, Jiankang Yao, Shivan Kaul Sahib,
Mallory Knodel, Ron Bonica, Ketan Talaulikar, Eric Éric Vyncke, and Carlos Jesus Bernardos
Cano.
10.
J. Bernardos.
Contributors
This document aggregates articles from authors specialized in each
technologies.
technology. Beyond the main authors listed in on the front page, the
following contributors proposed additional text and refinement refinements that
improved the document.
* Georgios Z. Papadopoulos: Contributed Papadopoulos contributed to the TSCH section.
* Nils Maeurer: Contributed to the LDACS section. Maeurer and Thomas Graeupl: Contributed Graeupl contributed to the LDACS section.
* Torsten Dudda, Alexey Shapin, and Sara Sandberg: Contributed Sandberg contributed to the
5G section.
* Rocco Di Taranto: Contributed Taranto contributed to the Wi-Fi section section.
* Rute Sofia: Contributed Sofia contributed to the Introduction and Terminology sections
sections.
Authors' Addresses
Pascal Thubert (editor)
06330 Roquefort-les-Pins
France
Email: pascal.thubert@gmail.com
Dave Cavalcanti
Intel Corporation
2111 NE 25th Ave
Hillsboro, OR, OR 97124
United States of America
Phone: 503 712 5566
Email: dave.cavalcanti@intel.com
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
08018 Barcelona Catalonia
Spain
Email: xvilajosana@uoc.edu
Corinna Schmitt
Research Institute CODE, UniBw M
Werner-Heisenberg-Weg 39
85577 Neubiberg
Germany
Email: corinna.schmitt@unibw.de
Janos Farkas
Ericsson
Budapest
Magyar tudosok korutja 11
1117
Hungary
Email: janos.farkas@ericsson.com