5. IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)
This section preserves the RFC text for RAW technologies, including Wi-Fi 6/7, IEEE 802.11, TSCH, 6TiSCH, 5G NR, TSN/TSC integration, UE, gNB, RAN, UPF, PDU sessions, LDACS, PHY/MAC terms, figures, tables, and security considerations.
Original RFC Text
5. IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)
IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed
directly at industrial IoT applications, for use in process control
loops and monitoring. It was used as a base for the major industrial
wireless process control standards, Wireless Highway Addressable
Remote Transducer Protocol (HART) and ISA100.11a.
While the MAC/PHY standards enable the relatively slow rates used in
process control (typically in the order of 4-5 per second), the
technology is not suited for the faster periods used in factory
automation and motion control (1 to 10 ms).
5.1. Provenance and Documents
The IEEE 802.15.4 Task Group has been driving the development of low-
power, low-cost radio technology. The IEEE 802.15.4 Physical (PHY)
layer has been designed to support demanding low-power scenarios
targeting the use of unlicensed bands, both the 2.4 GHz and sub-GHz
Industrial, Scientific and Medical (ISM) bands. This has imposed
requirements in terms of frame size, data 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. IEEE 802.15.4 uses spread spectrum
modulation such as the Direct Sequence Spread Spectrum (DSSS).
The Time-Slotted Channel Hopping (TSCH) mode was added to the 2015
revision of the IEEE 802.15.4 standard [IEEE802.15.4]. TSCH is
targeted at the embedded and industrial world, where reliability,
energy consumption, and cost drive the application space.
Building on IEEE 802.15.4, TSN on low-power constrained wireless
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 capabilities [RFC8200] with a 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 [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 6TiSCH Operation (6top) sublayer and the
Scheduling Functions (SFs), to enable the management plane operation
while ensuring IPv6 is supported.
* The 6top Protocol (6P) is defined in [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 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, 6TiSCH can establish Layer 2 links between
neighboring nodes and support best-effort traffic. The Routing
Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] provides
the routing structure, enabling the 6TiSCH devices to establish
the links with well-connected neighbors, thus forming the acyclic
network graphs.
In 6TiSCH, a Track is the concept of a recovery graph in the RAW
architecture applied to wireless. A Track can follow a simple
sequence of relay nodes, or it can be structured as a more complex
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 forwarding
schemes, reducing the overhead of making routing decisions at Layer
3.
The 6TiSCH architecture [RFC9030] identifies different models to
schedule resources along so-called Tracks (see Section 5.2.1),
exploiting the TSCH schedule structure; however, the focus in 6TiSCH
is on best-effort traffic, and the group was never chartered to
produce standards work related to Tracks.
There are several works that can be used to complement the overview
provided in this document. For example, [vilajosana21] provides a
detailed description of the 6TiSCH protocols, how they are linked
together, and how they are integrated with other standards like RPL
and 6Lo.
5.2. General Characteristics
As a core technique in 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,
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 (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 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 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 timeSlot).
Channel hopping provides increased reliability to multipath fading
and external interference. It is handled by TSCH through a channel-
hopping sequence referred to as macHopSeq in the 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 IEEE 802.15.4
standard [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, and ARIB impose duty cycle regulations to limit the use of the
bands, but interference may still constrain the probability of
delivering a packet. Part of these reliability challenges are
addressed at the MAC layer by introducing redundancy and diversity,
thanks to channel hopping, 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
In the 6TiSCH architecture [RFC9030], a Track is the concept of a
DetNet architecture protection path applied to 6TiSCH networks. A
Track can be structured as a 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 forwarding schemes, reducing the
overhead of making routing decisions at 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; 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 concepts like replication and
elimination can be exploited. Spatial redundancy increases the
overall energy consumption in the network but 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 so-called
Packet Replication and Elimination (PRE), over non-congruent
branches. PRE may be used to complement Layer 2 ARQ and receiver-end
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 recovery graph described in the RAW 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
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 Track
In Figure 1, a Track is laid out from a field device in a 6TiSCH
network to an IoT gateway that is located on an IEEE 802.1 TSN
backbone.
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 retries (ARQ).
It is also possible for the field device to only 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 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 transmission failure as detected
by ARQ.
Methods to implement complex Tracks are described in [RFC9914] and
complemented by extensions to the RPL routing protocol in [NSA-EXT]
for 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 4.4 of the 6TiSCH architecture [RFC9030] describes four
approaches to manage the TSCH schedule of the Low-Power and Lossy
Network (LLN) nodes: static scheduling, neighbor-to-neighbor
scheduling, remote monitoring and scheduling management, and 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
In the 6TiSCH architecture [RFC9030], forwarding is the per-packet
operation that allows a packet to be delivered to a next hop or an
upper layer in a node. Forwarding is based on 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
models: GMPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding
(FF), and IPv6 Forwarding (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 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 IEEE 802.15.4 ARQ usually
happens, though the acknowledgment may be omitted in some cases, for
instance, if there is no scheduled cell for a retry.
Track Forwarding is the simplest and fastest operation. 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
forwarding state that can be used regardless of the network-layer
protocol. This model can effectively be seen as a Generalized
Multiprotocol Label Switching (GMPLS) operation in that the
information used to switch a frame is not an explicit label but is
rather related to other properties about the way the packet was
received (a particular cell, in the case of 6TiSCH). As a result, as
long as the TSCH MAC (and 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 a multicast
address, depending on MAC support). This way, the MAC layer in the
intermediate nodes accepts the incoming frame, and 6top switches it
without incurring a change in the MAC header. In the case of IEEE
802.15.4, this effectively means that the address is broadcast, so
that the short address for the destination of the frame is set to
0xFFFF along the Track.
A Track is thus formed end to end as a succession of paired bundles:
a receive bundle from the previous hop and a transmit bundle to the
next hop along the Track. A cell in such a bundle belongs to one
Track at most. For a given iteration of the device schedule, the
effective channel of the cell is obtained by adding a 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 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 frames that were received for a given Track
are effectively transmitted, any available TX-cell for that Track can
be reused for 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. As a
result, a frame that is received in 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, 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 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. As a result, a
frame that is received over a 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.
However, with 6TiSCH, since the use of the Layer 3 bundle may be due
to transmission failures, it makes sense for the receiver to
recognize a frame that should be re-Tracked and to place it back on
the appropriate bundle if possible. A frame should be re-Tracked if
the per-hop-behavior group indicated in the Differentiated Services
field in the IPv6 header is set to 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 Bit Index
Explicit Replication (BIER) [RFC8279] and, more specifically, BIER
Traffic Engineering (BIER-TE) [RFC9262].
5.3. Applicability to Deterministic Flows
In the RAW context, low-power reliable networks should address non-
critical control scenarios such as Class 2 and monitoring scenarios
such as Class 4, as defined by [RFC5673]. As a low-power technology
targeting industrial scenarios, radio transducers provide low data
rates (typically between 50 kbps to 250 kbps) and robust modulations
to trade off performance for 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, 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), resource blocks can be chained so nodes in
previous hops transmit their data before the next packet comes. This
provides a tight control of latency along a Track. Collision loss is
avoided for 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 Interface (HMI) provides the
traffic specification (in particular, in terms of latency,
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 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 expects that
the programming of the schedule is done over the Constrained
Application Protocol (CoAP) as discussed in [CoAP-6TiSCH].
However, a Hybrid mode may be required as well, whereby a single
Track is added, modified, or removed (for instance, if it appears
that a Track does not perform as expected). For that case, the
expectation is that a protocol that flows along a Track, 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, and it is expected that DetNet will determine the
appropriate end-to-end protocols to be used in that case.
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 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 are tagged to uniquely
identify the Track and associated transmit bundle of timeSlots.
As a result, the tagging that is used for a DetNet flow outside the
6TiSCH 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, and Elimination
The 6TiSCH 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
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 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. In the
figure below, S transmits the same data packet twice: once to its
Destination Parent (DP) (A) and once to its Alternate Parent (AP)
(B).
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 4: Packet Replication
By employing a packet elimination function once it receives the first
copy of a data packet, 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 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 the transmission.
6TiSCH expects elimination and replication of packets along a complex
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
the same packet along a Track are correlated by configuration, so
processing the sequence numbers is not needed.
The semantics of the configuration must enable correlated timeSlots
to be grouped for transmit (and receive, respectively) with 'OR'
relations, and then an 'AND' relation must be configurable between
groups. The semantics are such that if the transmit (and 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 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. As a result, a node
will maintain only a small amount of peering 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 mechanisms such as
enhanced beacons, but although the neighbor information is available
in the 6TiSCH interface data model, 6TiSCH does not describe a
protocol to 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, the
same metrics that are used for RPL operations [RFC6551].
The energy that the device consumes in sleep, transmit, and receive
modes can be evaluated and reported, and so can the amount of energy
that is stored in the device and the power that 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,
policies that balance between nodes and ensure that the spent energy
does not 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, for example, be computed by an
entity such as a PCE [PCE]. Distributed routes are computed by RPL
[RFC6550].
Both methods may inject routes in the 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 the
same topology. 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
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 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 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 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, which may take up to a few
milliseconds on some device architectures. The matrix represents the
overall 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 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, 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's
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 4.3.5 of [RFC9030], and Figures 17
and 18 of [RFC9030] illustrate that projection.