CORECONF, NETCONF, and RESTCONF: Benchmarking Network Orchestration in Constrained IIoT Devices

Industry 4.0 promises to unlock the new capabilities for Industrial Internet of Things (IIoT) by transforming a rigid hierarchical automation pyramid into a flatter networked system. IEEE Time-Sensitive Networking, chosen as one of the Industry 4.0 pillars on the network level, offers mechanisms for deterministic data exchange and high reliability for such systems. Yet, to ensure a flexible and reliable service, a flat networked system requires a more sophisticated orchestration. Consecutively, such orchestration requires certain memory and CPU capacity from the IIoT devices, and the state of the art discusses the three candidate protocols, namely: 1) NETCONF; 2) RESTCONF; and 3) CORECONF. This article analyzes these protocols with a focus on resource-constrained IIoT devices. To compare the parameters a prototype implementation of CORECONF is developed, and extensively benchmarked against other protocols. Results suggest that CORECONF could be an ideal candidate in terms of time, power, and memory characteristics for resource-constrained devices.

Future cyber-physical systems require a more deterministic communication to ensure Quality of Service (QoS) guarantees of bounded latency, low jitter, and a high reliability [4].Traditional Ethernet struggles to accommodate these service requirements [4], [5], even though some proprietary Ethernet-based solutions, such as Profinet Isochronous Real Time (IRT), Ethercat, or CC-link have been reporting impressive performance [6], [7].The IEEE 802.1 Time-Sensitive Networking (TSN) Task Group (TG) was formed to address such essential mechanisms for deterministic Ethernet in a set of 802.1 substandards [8].
Industrial automation systems of today are often managed statically and have no room for dynamic device orchestration.Manual configuration of multidevice systems can be expensive in deployment and could incur costly system shutdowns in various cases [9].These issues can be addressed in various ways, among which concepts of software-defined networking (SDN) have gained traction in the network orchestration community [10].TSN, in its turn, addresses dynamic network management in IEEE 802.1Qcc substandard [11], introducing control and resource management mechanisms for dynamic network configuration.This enables a combination of IEEE 802.1 standards and configuration agents in line with the continuously running system.
The simple network management protocol (SNMP) [12] was developed to cater to the needs of computer networks that have evolved to a point of needing a dedicated network management protocol.However, since the development of SNMP networks has become more complex and capable, automation networks have imposed ever more strict requirements, on the management level as well.With regard to network management concepts, the most advances were made by Internet Engineering Task Force (IETF) community that proposed several enhanced protocols, superseding SNMP.Such protocols exchange data structures that are often described using data modeling languages, such as yet another next generation (YANG) [13].IETF introduced NETCONF [14], a YANGbased successor to SNMP [12] that uses extensible markup language (XML) data encoding format.IETF proposes further options associated with YANG, including RESTCONF built on hypertext transfer protocol (HTTP) [15] and CORECONF on concise binary object representation (CBOR) [16].These protocols use a similar stack, but each has its own strengths and weaknesses.
One important aspect of adopting IoT concepts in industrial automation is cost-many today's devices are extremely limited in memory and CPU, and upgrading such devices is not a simple and cheap task [17].The constrained devices [18] can be found in many applications, but a constrained device in motion control could be considered a high-performance unit in process automation.One way to identify the real constraints is to follow technology limitations, as the ones, for instance, established in Ethernet-advanced physical layer (Ethernet-APL) [19].APL mandates the overall field device power consumption as low as 500 mW, which limits the CPU power and other performance-related aspects.This in itself is not the most constraining of all possible requirements.However, if we consider that this power feeds the device itself, the CPU which runs an embedded OS, and the automation application, it can be considered sufficiently constrained.
IEC/IEEE 60802 [20] (60802), is a joint project of the IEC and IEEE 802 Group that defines TSN profiles for industrial automation.60802 has recently instituted NETCONF as the main network management protocol candidate for industrial TSN.We have already [21] touched upon enabling IIoT applications to utilize TSN and discussed the design challenges in deterministic networking applied to future bindings of OPC unified architecture (UA) [22] and NETCONF.However, for constrained devices in industrial automation, researchers seek a lightweight alternative.A qualitative study of features supported by IoT management protocols is given in [23], however, a quantitative validation is missing.
Given a growing number of IIoT frameworks under the industrial umbrella, it is of essence to address the protocol selection and shed light on the critical aspects of a universally accepted solution.On that account, we analyze the following three candidate protocols, i.e., 1) NETCONF; 2) RESTCONF; and 3) CORECONF, exploring their applicability to TSN orchestration for industrial automation.The comparison assesses key performance metrics like provisioning time, processing time, CPU, memory usage, and code size.To the best of our knowledge, this is the first work that evaluates CORECONF and benchmarks it against the aforementioned protocols.
The main contributions of this article are summarized as follows.
1) We introduce a comparative analysis of the three mentioned network management protocols.2) We propose a concrete system architecture and its proof of concept.3) We validate the sustainability of the proposed framework via an extensive performance evaluation.4) We deliver results that show CORECONF clearly outperforms conventional protocols.5) We propose CORECONF as the best candidate to embrace resource-constrained devices application scenarios over TSN infrastructure.The remainder of this article is structured as follows.Section II overviews the related work and main challenges.Section III introduces the system architecture.Section IV contains the experimental setup and performance evaluation results.Section V concludes our findings.

A. IEEE 802.1 Time-Sensitive Networking
TSN is a set of IEEE 802.1 substandards that enable realtime deterministic communication over Ethernet.On the data plane, physical and link layer techniques, such as traffic scheduling (IEEE 802.1Qbv), frame preemption (802.1Qbu), and time-synchronization (IEEE 802.1AS), provide guaranteed delivery of data with bounded low latency and low delay variation (jitter) over Ethernet.A comprehensive survey covering an overview of each of the IEEE 802.1 substandards is presented in [24].IEEE 802.1Qbv defines how critical traffic can be handled by TSN bridges.It facilitates deterministic communication via the temporal isolation of critical and noncritical traffic.It does so by introducing a transmission gate operation called timeaware shaper (TAS) for each queue of an egress interface.Essentially, the transmission gates are either open or closed according to a time schedule called the gate control list (GCL), executed periodically.The synthesis of GCLs, based on various data plane approaches, is a well-researched topic [25], [26], [27], [28].However, this article focuses on the control and management of TSN bridges using already generated GCLs.
In a TSN configuration and management key elements include talkers, listeners, bridges, and the user/network interface (UNI).The end stations that produce and consume data streams are called talkers and listeners, respectively.Talkers and listeners form the user end of the UNI, and the bridges that transfer the data frames of a stream between the talkers and listeners form the network side of it.Here, a stream is defined as a unidirectional, one-to-one, or one-to-many, periodical flow of data.A user specifies the requirements for the streams while being agnostic of the network.The network analyzes the topology and capacity of the network elements and, if the stream requirements can be accommodated by the network, configures them accordingly.The success or failure of a request is returned to the user by the network provisioning entity.In this context, IEEE 802.1Qcc specifies three configuration models.
1) Fully Distributed: In this model, a distributed protocol (e.g., P802.1Qdd) propagates end stations' requirements through the active topology.A central networkprovisioning entity does not exist, hence each network element is only aware of its own capabilities.The requirements are propagated over UNI between the end stations and the edge switches.2) Centralized Network/Distributed User: This model, also known as the hybrid model, introduces a key element called the centralized network entity (CNC) which performs resource allocation decisions centrally.The CNC is aware of the network topology and stream requests, it configures the TSN features in bridges using a network management protocol.In this model, UNI exists between the end stations and the bridges they are connected to, within the topology.3) Fully Centralized: This model introduces an applicationspecific entity, the centralized user configuration (CUC), responsible for the discovery of end stations, retrieval of end station capabilities, and configuration of TSN features in the end stations.The difference from the previous model is that the CUC retrieves the requirements from the end stations and exchanges this information with the CNC, i.e., the UNI exists between CUC and CNC as seen in Fig. 1.The CNC in this model, configures the TSN features in bridges using a network management protocol.This article utilizes this model for configuration and management in the experimental setup.While IEEE 802.1Qcc provides a framework for end-toend configuration and management for TSN-enabled networks, there are several other substandards and amendments required.For instance, the network management protocol between the CNC and the bridges is not standardized, even though the associated managed objects (YANG models) are in the process of being standardized under substandards such as IEEE P802.1Qcw and IEEE P802.1Qdj.The focus of this article is to provide a comparative analysis of the possible network management protocols that could be used in an IEEE 802.1Qcc framework, specifically for a TSN-enabled network comprising constrained devices.

B. Network Management Protocols
A network management protocol is a suite of protocols that provides mechanisms and policies for managing, monitoring, and configuring any network of interconnected devices.These protocols require a common data modeling language in order to express the structure and semantics of configuration information.In the direction of interoperability, IETF developed the YANG-data modeling language to have a standardized, structured, and human-readable way to model configuration data for the management of complex network configurations.
1) Data Modeling Language: Originally developed to be used in conjunction with NETCONF, YANG is a modulebased flexible data modeling language.The RFC for YANG [13] describes the semantics and syntax for modeling and representing the data tree in the form of YANG modules.A YANG module defines a data hierarchy that can be used for protocol operations, including modeling of configuration and state data, remote procedure calls (RPCs), and notifications.This article focuses on three vendor-independent protocols that use YANG modules.
2) NETCONF: It is a session-oriented, stateful configuration and management protocol standardized by the IETF [14].It uses RPCs encoded in XML for messaging.The configurations are based on structured models created using the YANG data modeling language.Although flexibility in terms of the transport layer is mentioned, [29] explains the need for secure shell (SSH) transport protocol mapping.Support for transport layer security (TLS) was included by [30].It supports create, read, update, and delete (CRUD) and server management operations.Additional operations can be appended based on the capabilities advertised by the device.NETCONF defines using one or more configuration data stores that allow CRUD operations.In network management, a data store is the complete set of configuration data required to get a device from its original state to a desired operational state.A protocol can operate with several optional data stores (startup, candidate, and operational), but a running data store is mandatory [31].
3) RESTCONF: With the rising popularity of Web applications, there was a need for mechanisms in several applications to access and modify configuration data, event notification, and perform RPC operations of NETCONF in a modular manner.To cater to these needs, which use RESTful methods, [15] proposed an HTTP-based protocol for configuring YANG-based data stores.The original purpose of RESTCONF was not to replace NETCONF but to provide a RESTful interface to the NETCONF datastore.It implements only a part of the operations supported by NETCONF, mainly just the CRUD operations using HTTP methods.Optionally, other NETCONF operations can be supported by the POST method.Transmission control protocol (TCP) is the underlying transport layer protocol for HTTP, and TLS is used to secure communication.As opposed to NETCONF, RESTCONF uses a less complex message encoding format in javascript object notation (JSON), but the XML format is also supported.
Network management protocols are rapidly becoming a necessity considering the increase in the number of connected devices.In the context of TSN configuration, Bhattacharjee et al. [32] used NETCONF as the network management protocol between the CNC and the bridges.However, the authors conclude that NETCONF consumes most of the end-to-end provisioning time and suggest the need for a lightweight alternative.Hedstrom et al. [33] provided a comparative efficiency analysis between NETCONF and the legacy SNMP in a communication service provider (CSP) network.This study set a precedent for using NETCONF in industrial networks.However, [34] provides insight into system requirements and performance of NETCONF in a resourceconstrained environment and concluded that NETCONF is not suitable for such environments.The specific requirements for such constrained nodes and their use cases in an industrial network are presented in [35], [36], and [37].Using this as a reference, Schönwälder et al. [38] drafted a lighter, constrained, device-specific version of NETCONF called NETCONF light.However, Mavromatis et al. [39] evaluated NETCONF light and indicated that both in terms of Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
CPU/energy consumption and device provisioning time, it is not suitable for resource-constrained IoT devices.Additionally, they conclude that it is unsuitable for many heterogeneous constrained devices because of its complexity.
While a detailed summary of several management protocols, architecture, and qualitative analysis is presented in [23] and [40], a quantitative study presenting a numerical comparison of the YANG-based protocols currently does not exist, to the best of our knowledge.Hence, in this article, we first present a proof-of-concept implementation of CORECONF to address the immediate need for a network management protocol usable with constrained industrial devices.Following this, we present a comparative quantitative analysis of the performance of CORECONF against the commonly used NETCONF and RESTCONF protocols in a large-scale industrial network comprising constrained devices.

A. Architecture
The increasing use of constrained devices in industrial installations is challenging traditional network management approaches.These devices have limited memory and processing resources, making it difficult to deploy the conventional TCP/IP protocol suite.To enable end-to-end IP connectivity, the IETF is developing a network stack that is designed to run on devices with tight memory constraints (e.g., up to ≈ 50-kB RAM and up to ≈ 250-kB flash memory) [18].This IoT network stack is based on 6LoWPAN [41], which is a lightweight adaptation layer that converges IPv6 to low-power link layers.The constrained application protocol (CoAP) [42] is a lightweight implementation of RESTful methods tailored to machine-to-machine (M2M) applications.Its stateless client-server communication reduces the management of state space on embedded devices to a minimum, thus enabling greater scalability.It further makes it a promising candidate for low-power networks, where spurious packet drops and node disappearances are more prevalent than in general-purpose networks.
CORECONF which is introduced by IETF [16] as the suitable protocol candidate for low-power network management builds on top of CoAP functionalities.CoAP supports multiple transports, but CORECONF encourages using the user datagram protocol (UDP) due to its lesser protocol complexity.Corrective actions are then performed on the application layer using CoAP confirmable messages.datagram TLS (DTLS) provides a secured end-to-end communication.However, the IETF draft states that DTLS or object security for constrained RESTful environments (OSCOREs) [43] could be used for security.Since DTLS is more predominantly used and has a wider deployment, in this work, we opt for DTLS.CORECONF uses CBOR [44] as the message encoding format to create data trees based on YANG modules.Encoding follows the rules defined in [44] to produce compact data for constrained nodes.CBOR is based on the JSON data model and follows the key-value notation, but contrary to JSON, it directly represents data in binary objects, thereby eliminating the need for base64 conversion, which is often performed with JSON.The encoding provides two formats for encoding  keys in an array: names (string) or YANG schema identifiers (SIDs) [45].SIDs are unique 63-bit identifiers that are used to identify YANG tree nodes.This enables further compactness by replacing long YANG node keys in a CBOR array with a short numerical identifier, which minimizes packet payload and uniform resource identifier (URI) lengths.
A comparative visual depiction of NETCONF, RESTCONF, and CORECONF across various layers is presented in Fig. 2.

B. Implementation
CORECONF consists of six components: 1) YANG specification relevant to named and versioned YANG modules; 2) CoAP server-client architecture that provides the requestresponse communication; 3) datastore component to store and retrieve configuration data; 4) secure communication employing client authentication and verification of authorization; 5) event stream to get real-time notifications of the server status; and 6) optional SMIv2 [46] specification pertaining to a named module of variables and conceptual tables.This work focuses on a minimal implementation of CORECONF; the event stream and SMIv2 components are part of our future work.
The implemented architecture is shown in Fig. 3.The following open-source libraries provide the tools for each component of the architecture.
1) Libyang [47] is a C language-based library and API by CESNET that implements parsing and validation of YANG schemas and data models.It is used as a YANG specification provider.2) Sysrepo [48] is a YANG-based datastore for Unix/Linux applications.Sysrepo implements all four data stores specified by the network management datastore architecture (NMDA) [31].It provides an integrative library and a standalone API to read, write, and manage data stores.The current implementation follows a single unified data store concept, i.e., only the running data store is utilized.3) Libcoap [49] provides the request, indication, response, and confirm processes performed by the CORECONF clients and servers.It is a lightweight C implementation of the CoAP protocol.It supports several TLS libraries and blockwise transfers in CoAP.Both of these are essential to the client-server processes.4) Tinydtls [50] is a C-based library providing DTLS that supports a minimal set of cipher suites for UDP-based IoT protocols.In our implementation, we use Tinycbor [51], Intel's opensource CBOR library, which has a low memory footprint.The CBOR-to-JSON conversion is inline in the application.This is because Sysrepo only supports data operations in JSON, XML, and custom Libyang binary (LYB).
The libcoap library verifies each resource and subresource of the uniform resource locator (URL).This requires the creation of several resources for every YANG module.In order to avoid this, the libcoap library is augmented to support a wildcard mechanism, to verify just the root directory and forward the remainder of the URL directly to the CORECONF application for validation.

A. Experimental Setup
The objective of this work is to evaluate CORECONF and benchmark it against NETCONF and RESTCONF.To this end, we implement CORECONF in accordance with the architecture explained in Section III.Additionally, we also implement NETCONF and RESTCONF using open-source tools to provide a comparative evaluation of the three protocols.We consider the following open-source tools for each protocol.
1) For NETCONF, Netopeer2 [52], an application created by the association CESNET is used.It uses the following: a) libnetconf2 library for the NETCONF features; b) Sysrepo as the datastore; and c) libyang for the YANG All communication uses TLS. 2) For RESTCONF, a simple application is implemented which runs on Sysrepo provided by Netopeer2.
The HTTP interface is created using the microhttpd library [53].TLS secures all communication.3) For CORECONF, the custom implementation described in Section III is used.For evaluation, we use Containernet [54], an extension of Mininet [55], a popular SDN emulation framework.It provides containerized end stations and the option to attach existing containers as end stations in real time.Containernet emulates the TSN-enabled bridges with the same root filesystem but different network namespaces, which are then linked using virtual Ethernet devices (veth pairs).For a clear separation, all standard libraries to support configuration management are running within the container.To this end, docker containerization is utilized for isolation.Effectively, a single Mininet bridge is emulated inside a docker container, and one container per bridge is created.The bridges are connected to each other by employing a generic routing encapsulation (GRE) tunnel.The bridges connected to end stations utilize a dockerin-docker implementation, i.e., the end station containers are created from within the containers of the bridge and linked to the bridge via Open vSwitch (OVS) [56] links.All bridges are connected to a central controller, Ryu [57].Ryu is an open-source python-based SDN controller that supports software link layer discovery for dynamic topology discovery and provides OpenFlow [58] for SDN features.The experimental setup can be seen in Fig. 4. We use the Fully Centralized model of IEEE 802.1Qcc in our experiments, keeping in line with the ongoing standardization activities.In this context, the docker containers running the servers are the bridges, and the Ryu controller, coupled with the protocol clients, acts as the CNC.
For the evaluation experiments, we use a two-bridge topology.Each bridge running in a docker container consists of a server instance of all three protocols writing to the same datastore provided by Sysrepo, as shown in Fig. 4.Each bridge is equipped with eight ports with eight queues per port.Since we use an IEEE 802.1Qbv network, the input data for the test cases are the GCLs catering to the YANG specification of the ietf-interfaces module augmented by the ieee802-dot1q-schedbridge module in accordance with the IEEE P802.1Qcw.In our experiments, we evaluate for increasing number of GCL entries ranging from 1 to 128 entries (2 0 to 2 7 ), i.e., increasing input data size.For each protocol, a datastore write operation is used as the basis, i.e., PUT in RESTCONF and CORECONF, <edit> with replace in NETCONF.All tests are sampled over 100 runs.Note that all results provided consider the independent performance of the RESTCONF interface only, i.e., standalone RESTCONF without the NETCONF datastore (minimalistic).
The emulated network and the controller are hosted in separate virtual machines (VMs), both running Ubuntu 20.04.The emulated containers also run Ubuntu 20.04.They are connected via the virtual internal network adapter.Both the

B. Evaluation Results
In order to validate the viability of our implementation of CORECONF and to compare the three protocols in the context of a real-time industrial network comprising low-power, constrained devices, we evaluate their performance mainly in terms of provisioning time, power consumption, and memory consumption.
In the first set of experiments, we were interested in determining the end-to-end provisioning time.Provisioning time here is the time taken from a client (CNC) request to the reception of acknowledgment of a successful datastore write from the server (bridge).Fig. 5(a) shows the average provisioning time for the given inputs.NETCONF takes the highest time owing to its session-based communication.Between RESTCONF and CORECONF, CORECONF is faster for smaller inputs but gradually worsens.This is due to the block transfer mechanism (with a maximum allowed block size of 1024 B), which fragments data into more packets in CoAP compared to the underlying TCP in RESTCONF, as shown in Table I.The time taken at the server is split between the time taken to accumulate the data by an application handler and the time taken to decode and write to the datastore (edit operation), as presented in Fig. 5(b).It can be seen that for protocol, the decode and write edit operations take a similar time, but with the increase in the input size, there is a significant increase in time required by the handler for data accumulation in CORECONF.
In the second set of experiments, in order to evaluate the viability of each protocol in low-power, constrained devices, we evaluated the average power consumed by each server.We measure the power consumption using PowerTop, a Linux tool.The power consumption for each input includes both an active period and a sleep period.The results are presented in Fig. 6.Because of the difference in magnitudes of the power consumption values, the y-axis is scaled to a logarithmic (base 10) scale.Note that we do not scale the values (power consumption) themselves.We notice that RESTCONF consumes the least power because it has the least number of wake cycles owing to fewer packets, as shown in Table I.For smaller inputs, the power consumption of CORECONF and RESTCONF are nearly equal, but CORECONF gradually worsens owing to more packets and hence more wake time.NETCONF is easily the most power-consuming protocol owing to its stateful nature and, thus, the need for being awake throughout the session.NETCONF also uses a multithreading model which attempts to parallelize some operations while trading off the power.Nevertheless, currently, in order to use a datastore, RESTCONF is proposed to coexist with NETCONF as explained in [23].So the actual power consumption of RESTCONF would be higher due to the influence of active polling of a coexisting NETCONF server, which would mean that CORECONF effectively consumes the least power out of the three protocols.
In the third set of experiments, we measure memory consumption.This is split into two sections: 1) static and 2) dynamic memory consumption.With regards to static memory, three important sections are considered: 1) .textsection pertains to the code, vector tables, and constants; 2) .datasection consists of memory allocated to initialized variables; and 3) .bsssection pertains to the uninitialized variables.The sizes of .text,.data,and .bsssections of the protocols are shown in Table II.NETCONF has an extensive .textsection due to its complex implementation involving extensive filtering, multithreading, and XPath handling.CORECONF,  without JSON decoding, has the smallest .textsection ideal for constrained devices.However, CORECONF, with JSON decoding, has a larger .textsection owing to the decoding functions of the open-source CBOR library (Tinycbor).The static memory consumption of RESTCONF is better than NETCONF and CORECONF with JSON decoding due to the lightweight microhttpd and minimalistic implementation.
Using Heaptrack, a memory profiler for Linux, we generate statistics related to the dynamic memory consumed by the management server.The peak dynamic memory allocation per message for each protocol is plotted in Fig. 7.During the datastore write in CORECONF, the CBOR is decoded to JSON effectively, making it similar to RESTCONF; hence both the protocols consume similar dynamic memory, but CORECONF is marginally better as seen in the zoomed view.This is due to the different message sizes for the same GCL input, a result of the compact encoding mechanism of CBOR.
For low-powered constrained devices in particular, while peak average heap consumption is essential, some of the memory is freed over the duration of a transaction, enabling reusability.Therefore, we further break down the total heap consumption and focus on the number of heap allocations for large sizes (greater than 1 kB).Fig. 8 provides insight into the total number of allocations greater than 1 kB requested by the protocols per transaction, which is an indicator of the number of memory blocks or pages required by the processes.It is evident that CORECONF requires fewer allocations in the range greater than 1 kB, making it a good fit for constrained devices requiring minimal memory footprint.Finally, we take a look at the message size for each of these protocols.The actual size post encoding into the relevant messaging formats is shown in Fig. 9(a).It is evident that the compactness of CBOR encoding enables a much smaller message size for CORECONF in comparison to XML and JSON for NETCONF and RESTCONF, respectively.However, if we consider the size of an individual packet, Fig. 9(b) shows that both NETCONF and RESTCONF utilize the maximum transmission unit (MTU) for Ethernet, but CORECONF owing to the underlying CoAP's block transfer mechanism underutilizes the packet size.Also, in RESTCONF, due to TCP/TLS, which can transmit much larger frames and rely on the physical interface to handle the fragmentation, the number of acknowledgments can be further reduced.This leads to lower provisioning time for RESTCONF compared to CORECONF, which uses CoAP, for larger input data sizes.This is evident in Table I and Fig. 5  convergence of IT and OT in Industry 4.0.We developed a prototype implementation of CORECONF and benchmarked its performance against two other YANG-based configuration management protocols, namely, NETCONF and RESTCONF.Through an extensive comparative analysis under resourceconstrained scenarios, we demonstrated that CORECONF surpassed both NETCONF and RESTCONF in terms of power, and memory consumption.With regards to end-to-end provisioning time, CORECONF is the fastest for small input sizes that are favorable to a resource-constrained environment, and fares second only to RESTCONF for larger input sizes.In our future work, we plan to include enhancements to CORECONF, like implementing a native CBOR datastore and YANG SIDs.We also plan to investigate the effects of object security on the protocol performance of CORECONF using OSCORE.These enhancements and modifications could potentially further amplify CORECONF's performance.

Fig. 5 .
Fig. 5. End-to-end provisioning time.(a) Provisioning time.(b) Distribution of time consumed at the server.

Fig. 6 .
Fig. 6.Power consumed by the server per message in logarithmic scale.
(a).V. CONCLUSION AND FUTURE WORKIn this study, we successfully addressed the challenges of device configuration within the IIoT context, driven by the Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 9 .
Fig. 9. Comparison of message and packet size.(a) Message size for input (GCL entries) per respective protocols.(b) Composition of a single packet per respective protocols.

TABLE II STATIC
MEMORY SECTION SIZES (KB)