IEC 63448:2025
(Main)Low and ultra-low latency communication and control systems
Low and ultra-low latency communication and control systems
IEC 63448:2025 specifies the low and ultra-low latency communication and control system (ULCCS) technology to address the communication and control challenges of multimedia-centric applications. It describes the medium access control (MAC) layer specifications:
- MAC frame design for control-centric scheduling.
- Message types and packet formats for MAC layer operation.
- System management aspects at the MAC layer for multiple control domains and multi-hop operation.
General Information
Standards Content (Sample)
IEC 63448 ®
Edition 1.0 2025-11
INTERNATIONAL
STANDARD
Low and ultra-low latency communication and control systems
ICS 33.160.60 ISBN 978-2-8327-0816-3
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.
IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a
publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms. 9
4 General . 10
5 System-level design aspects of ULCCS technology . 12
5.1 Examples of PHY layers for ULCCS . 12
5.2 MAC layer aspects . 12
5.3 Management aspects . 13
6 Medium access control (MAC) layer . 13
6.1 General MAC framework . 13
6.2 Frame formats . 14
6.2.1 General. 14
6.2.2 Signaling frame. 14
6.2.3 Downlink frame . 15
6.2.4 Uplink frame . 15
6.2.5 Retransmission frame . 15
6.2.6 Slot structure . 15
6.3 Message types . 15
6.4 Message structure . 15
6.5 MAC functions . 18
6.5.1 General. 18
6.5.2 Schedule generation . 18
6.5.3 Data transmissions. 21
6.5.4 Retransmission handling . 22
6.5.5 Frequency hopping . 25
6.6 MAC parameters. 25
6.7 Logical channels . 26
7 System management. 28
7.1 Time synchronization . 28
7.1.1 General. 28
7.1.2 Multi-hop time synchronization based on synchronous flooding . 28
7.1.3 Multi-hop time synchronization based on timestamping . 29
7.1.4 Single-hop time synchronization based on IEEE 802.11-2012 . 30
7.2 Multi-hop operation . 30
7.2.1 General. 30
7.2.2 Topology generation by the network layer . 31
7.2.3 Topology generation by the MAC layer . 32
7.3 Parallel operation of multiple domains. 33
7.3.1 General. 33
7.3.2 Synchronous operation of multiple domains . 33
7.3.3 Asynchronous operation of multiple domains . 34
7.4 Parallel operation over multiple radios . 35
7.5 Security . 35
Annex A (informative) Use-cases and reference scenarios . 37
A.1 Use-case 1: Multi-sensory wireless teleoperation . 37
A.2 Use-case 2: Multi-user VR environment . 37 ®
A.3 ULCCS operation over Bluetooth 5.0 PHY layers . 38
Bibliography . 40
Figure 1 – System model for multimedia-centric communication and control in local
environments . 10
Figure 2 – Logical view of the protocol layer model for ULCCS technology . 11 ®
Figure 3 – Packet format of ULCCS technology over uncoded Bluetooth 5.0 PHY
layer . 12
Figure 4 – MAC layer operation of ULCCS technology and its different phases . 13
Figure 5 – Reference example for ULCCS operation . 13
Figure 6 – Illustration of the signaling frame . 14
Figure 7 – RFR message structure . 17
Figure 8 – ASG message structure . 17
Figure 9 – DLS message structure for distributed scheduling . 18
Figure 10 – DLS message structure for centralized scheduling . 18
Figure 11 – Exchange of signaling messages for schedule generation . 19
Figure 12 – Structure of retransmitted DLS message for distributed scheduling . 21
Figure 13 – Data message structure . 21
Figure 14 – Schedule duplication technique . 22
Figure 15 – Schedule extrapolation technique . 22
Figure 16 – G-NACK message structure . 23
Figure 17 – Reference example for illustrating schedule extrapolation . 23
Figure 18 – Illustration of schedule extrapolation (Scenario A) . 24
Figure 19 – Illustration of schedule extrapolation (Scenario B) . 24
Figure 20 – Illustration of the logical channels for ULCCS . 26
Figure 21 – Illustration of schedule translation functionality. 27
Figure 22 – Illustration of time synchronization via synchronous flooding . 28
Figure 23 – Illustration of time synchronization via synchronous flooding . 29
Figure 24 – W-DREQ message structure . 29
Figure 25 – W-DRES message structure . 30
Figure 26 – RC message structure . 30
Figure 27 – Illustration of topology generation by network layer . 31
Figure 28 – RC-ACK message structure . 31
Figure 29 – Illustration of advertising and scanning procedures . 32
Figure 30 – Illustration of topology generation via managed flooding. 33
Figure 31 – Illustration of synchronous operation of multiple domains . 33
Figure 32 – Illustration of the two-tier schedule . 34
Figure 33 – Illustration of asynchronous operation of multiple domains . 34
Figure 34 – Illustration of multi-radio operation . 35
Figure 35 – ASG-MR message structure . 35
Figure 36 – Illustration of data message with signature . 36
Figure A.1 – Wireless teleoperation use-case for ULCCS . 37
Figure A.2 – Multi-user VR use-case for ULCCS (enterprise scenario) . 38
Figure A.3 – Multi-user VR use-case for ULCCS (edge rendering scenario) . 38
Figure A.4 – Multi-hop topology for illustration of ULCCS operation over LE 2M PHY . 39
Table 1 – Message types for ULCCS operation . 16
Table 2 – MAC layer parameters for ULCCS . 25
Table 3 – Logical channel mapping for ULCCS over DECT-2020 NR PHY . 27
Table A.1 – Key parameters for illustration of ULCCS operation of LE 2M PHY . 39
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Low and ultra-low latency communication and control system
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 63448 has been prepared by IEC technical committee TC 100: Audio, video and multimedia
systems and equipment. It is an International Standard.
The text of this International Standard is based on the following documents:
Draft Report on voting
100/4293/CDV 100/4364/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
INTRODUCTION
The focus of this document is low and ultra-low latency communication and control system
(ULCCS) technology to address the challenges of communication and control for multimedia-
centric applications in local environments. State-of-the-art wireless systems targeting
multimedia delivery do not adequately fulfil the stringent performance requirements of emerging
control-centric applications. Hence, there is a need to develop a new protocol which can satisfy
the stringent requirements of such applications.
1 Scope
This document specifies the low and ultra-low latency communication and control system
(ULCCS) technology to address the communication and control challenges of multimedia-
centric applications. It describes the medium access control (MAC) layer specifications:
– MAC frame design for control-centric scheduling.
– Message types and packet formats for MAC layer operation.
– System management aspects at the MAC layer for multiple control domains and multi-hop
operation.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://www.iso.org/obp
3.1 Terms and definitions
3.1.1
closed-loop control
type of control which uses feedback to control the output or state of a dynamic process or
system
3.1.2
closed-loop control system
spatially distributed system comprising a controller and a plurality of sensors and actuators for
feedback control
3.1.3
channel
resource allocated for a fixed duration for communication
3.1.4
controlled domain
secondary domain
domain comprising one or more devices that receives or generates command or feedback
messages from or toward the master domain
3.1.5
controller
device which handles closed-loop control in ULCCS, i.e., using feedback to control the state or
output of a dynamic process or system
3.1.6
cycle time
cumulative time of successfully transmitting command messages from the controller to all the
devices and successfully receiving response from each device in the system
3.1.7
device
sensor or actuator in ULCCS
3.1.8
downlink
communication in ULCCS from the controller to the devices
3.1.9
initiator
node in ULCCS which initiates the time synchronization process
3.1.10
master controller
controller which handles the operation of other controllers in the case of parallel operation of
multiple domains
3.1.11
master domain
primary domain
domain comprising one or more controllers that generate or receive command or feedback
messages for or from the secondary domain
3.1.12
multicast
one-to-many transmission between a sender and a group of receivers
3.1.13
node
device or controller in ULCCS
3.1.14
phase
duration of the signaling phase or data communication phase in ULCCS
3.1.15
relay
device in ULCCS that participates in cooperative transmissions for a device with failed
transmissions
3.1.16
unicast
one-to-one transmission between a sender and a receiver
3.1.17
uplink
communication in ULCCS from the devices to the controller
3.2 Abbreviated terms
AES Advanced encryption standard
AFN Absolute frame number
AR Augmented reality
ASG Assignment
ASN Absolute slot number
BAN Body area network
®1
BLE Bluetooth low energy
CSMA/CA Carrier sense multiple access with collision avoidance
CMAC Cipher-based message authentication code
DECT Digital enhanced cordless telecommunications
DLS Downlink signaling
G-NACK Group negative acknowledgement
HSI Human system interface
LE Low energy
MAC Medium access control
MIC Message integrity check
NIN Non-IP networking
MR Mixed reality
NR New radio
OFDMA Orthogonal frequency division multiple access
PDU Protocol data unit
PHY Physical
PTP Precision time protocol
RC Route construction
RFR Request for resources
RFU Reserved for future use
SIFS Short interframe space
SNR Signal-to-noise ratio
TA Timing advertisement
TM Timing measurement
TSF Timing synchronization function
ULCCS Ultra-low latency communication and control system
VR Virtual reality
WLAN Wireless local area network
___________
Bluetooth is the trademark of a product supplied by Bluetooth SIG, Inc. This information is given for the convenience
of users of this document and does not constitute an endorsement by IEC of the product named. Equivalent
products may be used if they can be shown to lead to the same results.
4 General
Over the last few years, the data rate and latency requirements of multimedia communication
have become more stringent, mainly due the emergence of new applications such as
augmented reality (AR), virtual reality (VR), and mixed reality (MR). Multimedia technologies
are increasingly being used in control-centric applications across industrial as well as consumer
sectors.
Control-centric communication (e.g., closed-loop control) often takes place in cycles of fixed
duration. A cycle of communication involves exchange of command and feedback signals
between a master or primary domain and a controlled or secondary domain of a closed-loop
control system. To ensure stability of control application, reliability, latency, and timeliness
(guaranteed latency with minimal cyclic variation or jitter) requirements become crucial. Control-
centric communication typically occurs in local environments (factories, warehouses, retail
stores, gaming arcades, etc.).
Figure 1 – System model for multimedia-centric communication
and control in local environments
The generic architecture of multimedia-centric communication and control is shown in Figure 1
which illustrates three different applications: teleoperation of robots, multi-user AR, VR, or MR
system, and studio lighting control with device management. These use cases depict closed-
loop control, involving bi-directional exchange of command and feedback messages over a
communication network in local environments.
Existing wireless standards do not completely fulfil the stringent performance requirements of
multimedia-centric control applications. This document specifies ULCCS technology which
focuses on ultra-low latency, guaranteed cyclic latency or timeliness, and reliability aspects.
European Telecommunications Standards Institute (ETSI) non-IP networking (NIN) Industry
Specification Group (ISG) is standardizing a technology aiming to provide low latency and
guaranteed service for emerging control applications. NIN defines flows, control-plane protocols
for flow management, and associated packet formats. The ULCCS technology will be developed
such that NIN flows are adequately supported at the MAC layer for control-centric
communication.
ULCCS technology is primarily focused on enabling communication and control in local
environments which are often characterized by a lean protocol stack compared to their global
counterparts (e.g., communication over the Internet). The logical view of the protocol stack
model for ULCCS technology is shown in Figure 2.
Figure 2 – Logical view of the protocol layer model for ULCCS technology
The physical (PHY) layer of ULCCS technology includes the necessary PHY layer and air-
interface mechanisms including (but not limited to) radio frequencies, antenna aspects, packet
formats, modulation, and coding.
The medium access control (MAC) layer of ULCCS technology handles control-aware
scheduling, time and frequency division duplexing, bi-directional information exchange,
retransmissions, etc.
The network layer in ULCCS technology includes functions for providing connectivity
information for a spatially distributed system of controllers and devices pertaining to master or
primary and controlled or secondary domains.
The application layer of ULCCS represents control applications which directly reside over the
network or MAC layers.
The system management layer defines system-level management functionality which is spread
across different layers of the protocol stack. System management includes (but is not limited
to) signaling for scheduling, time synchronization, device discovery mechanisms, authentication,
encryption, and parallel operation of multiple control domains.
5 System-level design aspects of ULCCS technology
5.1 Examples of PHY layers for ULCCS
ULCCS technology is agnostic to the PHY layer. Therefore, any commercial off-the-shelf
wireless chipset can be adopted for implementing ULCCS, provided the requirements described
in this document are fulfilled. The PHY-agnostic feature also ensures that the appropriate PHY
layer is selected to fulfil the data rate requirements of a specific use-case. Prominent examples
of PHY layers for ULCCS technology include the following. ®
– Uncoded Bluetooth 5.0 PHY layers [2], i.e., low energy (LE) 2M PHY (2 Mbps data rate)
and LE 1M PHY (1 Mbps data rate). ®
– Coded Bluetooth 5.0 PHY layers [2], i.e., LE Coded PHYs supporting 500 kbps and
125 kbps data rates.
– PHY layers of legacy wireless local area network (WLAN) standards (IEEE 802.11n™, IEEE
802.11ac™, etc.) [3].
®2
– PHY layers of new Wi-Fi standards (IEEE 802.11ax™ [4], IEEE 802.11be™ [5], etc.).
– PHY layers of IEEE 802.15.4™-2020 standard [6] and its z and ab amendments.
– PHY layer of ETSI DECT-2020 New Radio (NR) standard [7].
– PHY layer of ETSI TS 103 326 Smart Body Area Network (BAN) standard [8].
Underpinned by a range of PHY layers, the ULCCS technology can operate in unlicensed as ®
well as licensed spectrums. The packet format of ULCCS technology based on a Bluetooth 5.0
uncoded PHY layer is shown in Figure 3.
®
Figure 3 – Packet format of ULCCS technology over uncoded Bluetooth 5.0 PHY layer
5.2 MAC layer aspects
The MAC layer of the ULCCS technology is based on the principles of ‘control-aware scheduled
communication’ for providing strict latency guarantees and meeting stringent latency, timeliness,
and reliability requirements. The scheduled communication is realized through either
centralized or distributed techniques.
The MAC layer considers a cycle of communication between a controller and multiple devices
as part of a single control domain. It defines different types of frames, message types, duplexing
modes, and retransmission handling techniques underpinned by one or more diversity
techniques for achieving ultra-grade reliability. It also supports single-hop and multi-hop
operation.
___________
Wi-Fi is the trademark of a product supplied by Wi-Fi Alliance. This information is given for the convenience of
users of this document and does not constitute an endorsement by IEC of the product named. Equivalent products
may be used if they can be shown to lead to the same results.
5.3 Management aspects
The management aspects of ULCCS technology span different layers of the stack. At the MAC
layer, ULCCS technology handles time and frequency synchronization functionality, parallel
operation of multiple control domains, and parallel operation over multiple radios. At the network
layer, ULCCS technology handles connectivity information for a spatially distributed system of
controllers and devices. At the application (or other layers), it handles security-related functions.
Figure 4 – MAC layer operation of ULCCS technology and its different phases
6 Medium access control (MAC) layer
6.1 General MAC framework
The MAC layer operation of ULCCS technology, which is illustrated in Figure 4, is broadly split
into a signaling phase and a data communication phase. The signaling phase is mainly used
for disseminating a schedule (in the case of centralized approaches) or for building a schedule
(in the case of distributed approaches). The data communication phase handles bi-directional
information exchange, as per the constructed control-aware schedule, between master and
controlled domains. The data communication phase consists of a downlink transmission phase,
an uplink transmission phase, and a retransmissions phase. The duration of the data
communication phase is defined as per the cycle time of the control application.
Figure 5 – Reference example for ULCCS operation
Figure 5 depicts a reference example for ULCCS operation where control-centric
communication takes place between a controller and five devices which form a multi-hop
network. The controller sends a single command message to all the devices in the downlink
whereas each device transmits a distinct feedback message to the controller in the uplink. The
control-aware schedule is also shown in Figure 5. The control-aware schedule consists of a
downlink transmission phase and an uplink transmission phase. The downlink frame consists
of three slots. The schedule follows a sequential approach such that the controller transmits
the command message to its directly connected devices, i.e., devices 1 and 2, in the first slot,
i.e., t . This is followed by downlink transmission by device 1, to devices 3 and 4, in t and by
0 1
device 2, to device 5, in t , respectively. The uplink frame consists of six slots. In the first slot
(t ), device 3 and device 5 simultaneously transmit to their parent devices, i.e., device 1 and
device 2, respectively. This parallel communication is possible when the receiving devices
cannot overhear each other at the MAC layer. In the second slot (t ), device 4 and device 2
transmit to their parent devices, i.e., device 1 and the controller, respectively. Note that device 2
requires two transmissions in the uplink, one for its own feedback and the other for relaying the
feedback from device 5. Therefore, in the third slot (t ), device 2 transmits again to the controller.
The subsequent three slots, i.e., t to t , are used by device 1 to transmit the required three
3 5
messages to the controller.
The schedule generation function is discussed later in this document (see 6.5.2).
NOTE Sequential scheduling ensures minimal latency for cyclic information exchange between the controller and
the devices.
6.2 Frame formats
6.2.1 General
A frame in ULCCS technology is defined as a collection of timeslots on one or more frequency
channels. Different types of frames are defined, including a signaling frame, a downlink frame,
an uplink frame, and a retransmission frame.
6.2.2 Signaling frame
The signaling frame handles: a) information related to schedule dissemination (for centralized
scheduling) or b) information exchange for building a schedule (for distributed scheduling).
The signaling frame consists of a repetitive pattern of three different types of slots as shown in
Figure 6.
The first slot is the DLS slot which is used for transmission of the DLS message. The second
slot is the RFR slot which is used for transmission of the RFR message. The third slot is the
ASG slot which is used for transmission of the ASG message.
The DLS, RFR, and ASG messages are discussed later (see 6.4).
Figure 6 – Illustration of the signaling frame
6.2.3 Downlink frame
The downlink frame handles control information from the controller (in the master domain) to
the devices (in the controlled domain).
6.2.4 Uplink frame
The uplink frame handles feedback information from the devices (in the controlled domain) to
the controller (in the master domain).
6.2.5 Retransmission frame
The retransmission frame handles retransmissions for transmission failures in the downlink and
uplink frames.
6.2.6 Slot structure
A slot in the ULCCS is long enough to transmit a single message. Signaling slots and data
transmission slots can be of different durations. The duration of a signaling slot is given by
T = T + T
SLOT_SIG SIG GUARD
where T is the transmission time of a signaling message and T is the guard interval.
SIG GUARD
The duration of a data slot is given by
T = T + T
SLOT_DATA DATA GUARD
where T is the transmission time of a data message and T is the guard interval.
DATA GUARD
6.3 Message types
The ULCCS technology defines different types of messages.
The request-for-resources (RFR) message is used by a device to request resources from
another node. Separate RFR messages are defined for downlink and uplink, i.e., RFR-D and
RFR-U, respectively.
The assignment (ASG) message is used by a device to allocate resources to a node requesting
resources via an RFR message.
The downlink signaling (DLS) message is used by a node to disseminate schedule information
(in case of centralized techniques) or to assist neighboring nodes in building a conflict-free
schedule (in the case of distributed techniques).
The group negative acknowledgement (G-NACK) message is used by a node to indicate failed
transmissions for a set of directly connected neighboring nodes.
6.4 Message structure
The ULCCS technology uses different types of messages. Each message has a unique structure
with some fields common to all messages and some distinct fields. The common fields in all
messages include the message type, the source ID, and reserved fields. The destination ID
field is also common to some messages.
The message type field is one octet in length and defines the type of signaling or data message.
The key message types defined for ULCCS operation are as follows.
– Data
– DLS for distributed scheduling
– DLS retransmission for distributed scheduling
– DLS for centralized scheduling
– RFR-D
– RFR-D retransmission
– RFR-U
– RFR-U retransmission
– ASG
– ASG retransmission
– G-NACK
– RC
– RC-ACK
– W-SYNC
– W-DREQ
– W-DRES
– RFR-C
– ASG-C
– RFR-MR
– ASG-MR
Table 1 defines the message type values for different ULCCS messages. Some message type
values are reserved for future use (RFU).
Table 1 – Message types for ULCCS operation
Value Message
11010001 DLS (distributed scheduling)
11010010 DLS (centralized scheduling)
11010011 DLS retransmission (distributed)
11010100 DLS retransmission (centralized)
11010110 RFU (DLS)
11011100 G-NACK
11011101 G-NACK (retransmission)
11011110 RFU (G-NACK)
10010001 RFR-D
10010010 RFR-U
10010011 RFR-D (retransmission)
10010100 RFR-U (retransmission)
10010111 RFR-MR
10010101 RFR-MR (retransmission)
10011001 RFR-C
10011010 RFR-C (retransmission)
Value Message
10011011 RFU (RFR)
01011001 ASG
01011010 ASG (retransmission)
01011011 ASG-MR
01011101 ASG-MR (retransmission)
01011110 ASG-C
01011100 RFU (ASG)
01101001 Data
01100101 Data-C
11110001 W-SYNC
11110010 W-DREQ
11110011 W-DRES
11110100 RFU (time synchronization)
11110110 RFU (time synchronization)
00011001 RC
00011011 RC-ACK
00011010 RFU (topology generation)
The source and destination ID fields are one to eight octets in length and capture the unique
identifier of the source and destination nodes, respectively. The unique identifier of a node can
be its MAC address or a hash function of the MAC address. The destination ID can be a group
or multicast address as well (see 6.5.3).
The structure of different messages is described as follows. Figure 7 shows the structure of the
RFR message. In addition to the common fields, it contains fields for requested resources for
downlink or uplink communication. These include the requested slot start, the requested slot
end, and the requested channel fields. The slots and channels for data transmission are
numbered. The request slot start and end fields are one to two octets whereas the requested
channel is one octet in length.
Figure 7 – RFR message structure
Figure 8 shows the structure of the ASG message. In addition to the common fields, it contains
fields for allocated resources for downlink or uplink communication. These include the allocated
slot start, the allocated slot end, and the allocated channel fields, all of which have the same
length as their counterparts in the RFR message.
Figure 8 – ASG message structure
Figure 9 shows the DLS message structure for distributed scheduling. In addition to the
common fields, it contains the DLS type, the number of nodes, the slot index, and the priority
information fields. The DLS type field indicates whether the DLS message is original or
retransmitted, and the sequence number if it is the latter. The DLS message carries priority
information for multiple nodes as indicated by the number of nodes field. The slot index field
contains the index of the next available RFR slot. The priority information field sequentially
carries the priority of associated child nodes in the form of their unique identifiers. A child node
determines its priority based on the offset of its unique identifier in the DLS message.
Figure 9 – DLS message structure for distributed scheduling
Figure 10 shows the DLS message structure for centralized scheduling. It has a similar structure
as the DLS message for distributed scheduling with the exception of priority information. The
schedule for each node is included in the DLS message. The Node ID field contains the unique
identifier of a node. This is followed by fields for the allocated schedule, i.e., the allocated slot
start, the allocated slot end, and the allocated channel fields. These four fields are repeated as
per the number of nodes in the DLS message.
Figure 10 – DLS message structure for centralized scheduling
6.5 MAC functions
6.5.1 General
In the ULCCS, the MAC layer is responsible for schedule generation, data transmissions, and
handling retransmissions.
6.5.2 Schedule generation
The ULCCS implements a distributed scheduling functionality where schedule generation takes
place via local overhearing, information exchange, and negotiation. Such information exchange
takes place during the signaling phase over the signaling frame using different message types
described earlier (see 6.3). Distributed scheduling operates on a single-hop or a multi-hop
network topology for the spatially distributed system of controllers and devices exchanging
control-centric information. The network topology provides a parent-child relationship between
different devices and the controller. A parent node has at least one child node associated with
it at the network layer. A node with no child nodes is the leaf node. A parent node is aware of
its child nodes based on the network layer information. Creation of network topology is
discussed later.
The parent nodes (including the controller) implement a downlink signaling policy for schedule
construction. Any parent node assigns priorities to its child nodes using the DLS message. The
priority information is used by the child nodes for conflict-free access to the signaling frame.
The DLS message is also used for conveying the information regarding the next available RFR
slot. Prioritization of child nodes can be based on any unique parameter (e.g., its MAC identifier
or its rank at the network layer), and it does not affect the schedule generation process. Any
child node computes the index of its RFR slot as
I + P − 1
RFR_SLOT
where
I is the index of the RFR slot as in the DLS message;
RFR_SLOT
P is the priority of the node.
The schedule generation process also implements a parent-child handshake policy for conflict-
free resource allocation. The handshake starts with the child node requesting earliest available
timeslot(s) on a data channel, through the RFR message, where it finds no conflict as per its
local knowledge. Upon reception of an RFR message, a parent node confirms the requested
allocation, through an ASG message, if it finds no conflict based on its local knowledge. If a
parent node detects a conflict in requested allocation, it responds with an updated allocation as
per its local knowledge of earliest available timeslots on a data channel.
The uplink signaling policy dictates schedule generation in the uplink. It follows a sequential
approach like the downlink. The schedule generation process starts at the leaf nodes which
request resources via the signaling frame. A parent node requests resources for uplink
transmission only if all its child nodes have been scheduled in the uplink. The number of
timeslots requested by a parent node is the sum of the total number of slots requested by its
child nodes and those required for its own transmission(s).
The exchange of signaling messages for schedule generation, for the multi-hop topology in
Figure 5, is shown in Figure 11.
Figure 11 – Exchange of signaling messages for schedule generation
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...