Enhancing Scalability in Wi-Fi IoT Networks with Logical Data Plane

Segregation Using SDN Principles

Gabriel Vieira

, Ana Rita Ortigoso

, Daniel Fuentes

, Luis Fraz

, Nuno Costa

and

Ant

onio Pereira

Computer Science and Communication Research Centre, Polytechnic University of Leiria, Portugal

{gabriel.m.vieira, ana.l.ortigoso, daniel.fuentes, luis.frazao, nuno.costa, apereira}@ipleiria.pt

Keywords:

Data Plane Segregation, IoT, Wi-Fi 6, ESP-NOW, SDN, Scalability.

Abstract:

The increasing demand for wireless connectivity, with IoT devices projected to exceed 20 billion by 2025,

reinforces Wi-Fi as the dominant technology. However, the standard star topology limits coverage for widely

dispersed IoT devices. While mesh networking extends coverage, most IoT endpoints lack native mesh sup-

port, posing scalability and security challenges. This study proposes an IoT architecture leveraging a dual-

stack and dual logical data plane approach based on SDN principles. It separates control and data trafﬁc into

three planes: IoT data, Wi-Fi extension, and control. The control plane employs ESP-NOW for mesh optimisa-

tion, while Wi-Fi ensures compatibility and expanded functionality. A prototype using ESP32-C6 DevKitC-1

modules demonstrates cost-efﬁciency, supporting stable connectivity with performance degradation beyond

50 metres. Experimental results conﬁrm the architecture’s ability to establish a self-organising, resilient mesh

network with dynamic reconﬁguration, offering a scalable and ﬂexible solution for IoT mesh networks.

1 INTRODUCTION

Wi-Fi technology is evolving rapidly, driven by the

increasing societal demand for wireless connectiv-

ity. It has become the preferred choice for Internet

of Things (IoT) devices, with the number of con-

nected devices worldwide expected to surpass 20 bil-

lion by 2025 (Analytics, 2024). Several initiatives

have been implemented to establish heterogeneous

networks that enable communication between differ-

ent devices (Zegeye et al., 2023). However, the in-

creasing demand for enhanced security and efﬁcient

device conﬁguration highlights the limitations of a

single data plane, particularly in terms of scalabil-

ity and vulnerability to security threats. As a result,

the use of multiple planes to forward data can help

mitigate (Kaljic et al., 2019). Providing Wi-Fi cover-

age for IoT devices, which are often widely dispersed,

presents signiﬁcant challenges. This is especially rel-

evant in environments and smart buildings such as ho-

https://orcid.org/0009-0000-2300-8441

https://orcid.org/0009-0001-7529-5857

https://orcid.org/0000-0001-9726-1087

https://orcid.org/0000-0003-2571-7940

https://orcid.org/0000-0002-2353-369X

https://orcid.org/0000-0001-5062-1241

tels, corporate ofﬁces, factories, hospitals, and univer-

sity campuses. (Khanna and Kaur, 2020). A solution

that involves extending the Wi-Fi network by lever-

aging existing IoT devices through a mesh network,

as there are already numerous devices available (e.g.,

microwaves, refrigerators, sensors, and other actua-

tors) is favourable. Ideally, this could be achieved by

simply updating the ﬁrmware of compatible devices,

enabling networks to become more conﬁgurable and

extend their coverage area.

This research aims to provide a solution that en-

hances current IoT devices with dual logical data

planes with the capability to create an IoT Wi-Fi mesh

network using the latest fully speciﬁed Wi-Fi protocol

(Ferro and Potorti, 2005), the Wi-Fi 6 / 802.11ax (Is-

lam and Kashem, 2022), and the low-level communi-

cation protocol ESP-NOW, which facilitates manag-

ing IoT devices and their mesh network. The solution

makes the following contributions:

• Development of a Dual Data Plane Architec-

ture: Conceptualised an architecture that makes

the use of two logical data planes possible, for IoT

devices and for Wi-Fi end devices users.

• Development of a Dual Stack Single Radio

Mesh Architecture: Designed an architecture

that integrates two different communication pro-

378

Vieira, G., Ortigoso, A. R., Fuentes, D., Frazão, L., Costa, N. and Pereira, A.

Enhancing Scalability in Wi-Fi IoT Networks with Logical Data Plane Segregation Using SDN Principles.

DOI: 10.5220/0013428800003944

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 10th International Conference on Internet of Things, Big Data and Security (IoTBDS 2025), pages 378-385

ISBN: 978-989-758-750-4; ISSN: 2184-4976

tocols (Wi-Fi 6 & ESP-NOW), to provide both

data segregation and extend coverage by using

other IoT devices as part of the network.

• Logical Separation of Data and Control

Planes: The architecture proposed introduces a

separation between control and two logical data

planes. This introduces an Software-Deﬁned Net-

working (SDN) inspired virtual separation that al-

lows independent management of data, reducing

interference and enhancing security.

• Cost-Effective Prototype Implementation: De-

velopment of a functional mesh network proto-

type using low-cost IoT devices that implement

the Wi-Fi 6 and ESP-NOW protocols concur-

rently.

• Comprehensive Functional and Performance

Evaluation: Testing the feasibility of the solu-

tion and the prototype to evaluate feasibility, func-

tional integrity, and performance metrics.

The article is structured as follows: section 2 pro-

vides an overview of the technologies employed and

their alternatives. Section 3 offers a literature review,

placing this research in the context of similar solu-

tions and prior work. Section 4 describes the pro-

posed architecture, integrating existing IoT devices

into the Wi-Fi infrastructure to provide network ac-

cess to nearby end-user devices. In Section 5, the im-

plemented prototype is presented with details on hard-

ware components, testing setup, control plane and

data plane. Section 6 outlines the results obtained

from the prototype, which are further analysed and

discussed in section 7 to provide insights into the so-

lution’s performance and functionality. Finally, sec-

tion 8 concludes the research by summarising key

ﬁndings and highlighting potential future work.

2 BACKGROUND

Wi-Fi is the most widely used wireless system, known

for its low cost, ease of installation and use, and mini-

mal skill requirements. The latest standard for IoT de-

vices, Wi-Fi 6 (802.11ax), is increasingly adopted in

industrial and IoT markets due to its high throughput,

low latency, precise localisation capabilities, efﬁcient

resource management through Resource Units (RUs),

support for speeds up to 9.6 Gbps, and tri-band oper-

ation (2.4, 5, and 6 GHz) (Karamyshev et al., 2024).

These recent advancements enable its use in battery-

powered IoT devices, solidifying its role as one of the

preferred choices for connecting both IoT and user

devices (Oughton et al., 2021) (Mozaffariahrar et al.,

2022b) (Perez-Ramirez et al., 2022).

ESP-NOW is a protocol designed to deliver low

latency, low power consumption, and long-distance

communication on the 2.4 GHz spectrum (Eridani

et al., 2021). The ESP-NOW protocol can transmit up

to 250 bytes of data and can coexist with both Wi-Fi

and Bluetooth (Espressif, 2023d) (Espressif, 2023c).

While the 250-byte payload may seem restrictive, it

is sufﬁcient for many IoT use cases, such as sending

sensor readings or control data. The following tables

1 and 2, detail the structure of ESP-NOW frame.

Table 1: ESP-NOW frame.

MAC

Header

24 bytes

Category

Code

1 byte

Organisation

3 bytes

Random

4 bytes

Vendor

Specific

7-257 bytes

FCS

4 bytes

Table 2: ESP-NOW vendor speciﬁc packet.

Element

Length Organisation

3 bytes

Type Version Body

1 byte 1 byte 1 byte 1 byte 0-250 bytes

Bluetooth is a Personal Area Network (PAN)

that operates within the 2.4 GHz spectrum using fre-

quency hopping to transmit data. There are two ver-

sions of this technology, Classic and Bluetooth Low

Energy (BLE) (Bisdikian, 2001). However, when us-

ing a dual-stack technology, BLE must share antenna

time, which results in reduced performance. (Espres-

sif, 2020b).

Thread is an Internet Protocol (IP) solution using

the IPv6 on the standard IEEE 802.15.4. Thread aims

for reliable, ﬂexible, low-power, device-to-device, ag-

nostic communication, and a self-conﬁguring net-

work that enhances functionality and reduces main-

tenance costs (Thread Group, 2020) (Thread Group,

2024). According to the scope of the work and to au-

thors in (Espressif, 2023f), concurrency with the other

mentioned protocols will not work.

ZigBee, based on IEEE 802.15.4, provides a low

data rate and simple connectivity, designed for low-

powered (battery-operated) devices. ZigBee supports

standard mesh networking, enhancing range and reli-

ability (ZigBee Alliance, 2017). However, it operates

on the same 2.4 GHz band as Wi-Fi, risking interfer-

ence. Its dual PHY adds complexity but offers limited

performance gains. In contrast, Wi-Fi, particularly

Wi-Fi 6, provides higher throughput, lower latency,

and better scalability for modern IoT networks, es-

pecially when leveraging SDN principles for logical

data segregation (Zigbee2MQTT, 2024).

In summary, Wi-Fi offers robust interconnectiv-

ity and performance, while ESP-NOW supports ex-

Enhancing Scalability in Wi-Fi IoT Networks with Logical Data Plane Segregation Using SDN Principles

379

tended ranges with minimal latency. Bluetooth has a

low power consumption, making it an optimal choice

for long-term applications across a range of devices.

ZigBee targets low-powered devices and has a built-

in mesh topology. Among these technologies, ESP-

NOW is noted for its low interference, better energy

efﬁciency, and lowest latency (Eridani et al., 2021).

A comparative analysis was conducted to iden-

tify low-cost IoT devices that support communica-

tion technologies like Wi-Fi 6, ESP-NOW, Bluetooth,

Thread, and ZigBee. The results highlight the com-

munication capabilities and average prices of the se-

lected devices, as presented in table 3.

Looking at the comparison in table 3 with device

features and prices in conjunction of the aforemen-

tioned, we conclude that for the required, ESP32-C6

meets the desired criteria: Wi-Fi 6 and ESP-NOW

support at a low cost. This device is a new addi-

tion to Espressif’s product line, featuring support for

Wi-Fi 6, BLE, Thread, and ZigBee. Additionally,

it integrates the Espressif IoT Development Frame-

work (ESP-IDF), an open-source project based on the

FreeRTOS kernel, offering well-documented drivers,

protocol support, and storage solutions that simplify

IoT development (FreeRTOS, 2024).

3 LITERATURE REVIEW

The scientiﬁc community has yet to extensively ex-

plore the integration of complementary communica-

tion protocols in resource-constrained environments.

Current research lacks comprehensive investigations

into their combined application for achieving scala-

bility, energy efﬁciency, and cost-effectiveness, high-

lighting a signiﬁcant gap in the ﬁeld. To the best of

our knowledge, this is one of the few prototypes in

this area.

In the study by (Muhendra et al., 2017), the Quick

Mesh Project (QMP) framework was used to de-

velop a WiFi mesh network with TP-LINK MR3020

routers, conﬁgured with the Quick Mesh Project

(QMP) based OpenWRT and BMX6 routing proto-

col. The network utilised the MQTT protocol for

machine-to-machine communication via a publish-

and-subscribe model. An IoT WiFi Client, based on

the low-power ESP8266 module, was also developed

to connect electronic devices such as sensors and ac-

tuators to the network. In contrast to this, the present

solution proposes using devices as network propaga-

tors with multiple planes, eliminating the need for

dedicated mesh routers and creating its own managed

mesh network.

Furthermore, the article by (Gergeleit, 2019) im-

plements a mesh network using the painlessMesh li-

brary, relying on NAT for external network access but

without incorporating a routing protocol. In a simi-

lar vein, Autotree utilises NAT alongside a distance

vector-like routing mechanism tailored for ESP8266

modules, forming a dynamic tree topology with lim-

ited node mobility and simpliﬁed deployment. How-

ever, it lacks inter-node IP connectivity. By contrast,

our solution introduces a dual-stack architecture with

logical data plane segregation based on SDN princi-

ples. By isolating control and data trafﬁc using ESP-

NOW and Wi-Fi 6, the system improves scalability

and route management. Moreover, it employs ESP32-

C6 modules to support contemporary protocols, such

as Wi-Fi 6, while enabling self-organising mesh net-

works.

In a related approach, the study by (Manvi and

Maakar, 2020) develops a wireless mesh network with

ESP-32 nodes, allowing decentralised communica-

tion without requiring internet access or routers. Data

is exchanged through TCP servers on port 5555, and

the network exhibits self-healing capabilities when

routes fail. Our work differs by enhancing compat-

ibility and implementing SDN principles to segregate

control and data planes. Through the use of ESP-

NOW and Wi-Fi 6, it achieves optimised trafﬁc ﬂow

and more efﬁcient resource utilisation, thereby sur-

passing the basic peer-to-peer methodology adopted

in (Manvi and Maakar, 2020).

The work of (Khanchuea and Siripokarpirom,

2019) explores the integration of ZigBee, ESP-NOW,

and ModBus protocols within a multi-protocol gate-

way to control IoT devices. ESP-NOW serves as

the foundation for a low-power, multi-hop wireless

network, while ZigBee forms subnetworks for de-

vice communication. Field trials highlight the ef-

fectiveness of ESP32 Wi-Fi/BLE chips combined

with ESP-NOW in constructing energy-efﬁcient, self-

organising sensor networks. In contrast, our solu-

tion focuses on logical data plane segregation using

SDN principles. By leveraging different protocols for

each distinct planes, the system ensures more efﬁ-

cient trafﬁc integration, moving beyond the modular,

multi-protocol approach presented in (Khanchuea and

Siripokarpirom, 2019).

Lastly, Espressif provides the ESP-WIFI-MESH

implementation (Espressif, 2024b), which supports

various conﬁgurations, including ”Internal Commu-

nication”, ”IP Internal Network”, and ”Manual Net-

working” (Espressif, 2024a). However, its functional-

ity is restricted to internal network communications,

as external devices (other Wi-Fi clients) cannot con-

nect to or interact with the mesh network.

Table 4 provides a comparison of the key fea-

IoTBDS 2025 - 10th International Conference on Internet of Things, Big Data and Security

380

Table 3: Comparison of native communication technology support in IoT devices.

Features /

Devices

Wi-Fi 6 ESP-NOW Bluetooth Thread ZigBee Avg. Price

Arduino

Nano ESP32

- ✓ ✓ - - 20$

Arduino

UNO Wi-Fi

REV2

- ✓ ✓ - - 25$

Espressif

ESP32-C6

✓ ✓ ✓ ✓ ✓ 8$

Raspberry

Pico W

- - ✓ - - 5$

Raspberry

Pi Zero W

Adapted

(Flayols, 2024)

✓ - - 16$

Raspberry

Pi 5

✓

Adapted

(Flayols, 2024)

✓ - - 70$

tures from the mentioned articles and the pro-

posed architecture, including: MQTT over ESP-NOW

(MoE), Data-Plane Technology (DPT), Control-

Plane Technology (CPT), Self-Organisation/Healing

(SOH), SDN Capable (SDNC), Propagates Network

(PN), Internet Connection, (IC), Data and Control

Planes Separation (DCPS), Easy One-click Conﬁg-

uration (EOC), Monitoring (M), NAT Service (NS),

ESP-WIFI-MESH (EWM), Allow External Device

Connections (AEDC).

4 PROPOSED ARCHITECTURE

The work proposes a new architecture that integrates

IoT devices with Wi-Fi mesh network, to ensure net-

work access to nearby end devices. The selection of

Wi-Fi and ESP-NOW is critical for the architecture’s

scalability and efﬁciency. Wi-Fi ensures high data

transmission capacity and broad compatibility for the

data plane, while ESP-NOW enables low-latency and

energy-efﬁcient operations for the control plane. This

combination leverages the strengths of both proto-

cols to enable concurrent operations across multiple

planes. This concurrent operation reduces interfer-

ence from each other and is crucial for the concurrent

use of both Wi-Fi and ESP-NOW.

Figure 1 illustrates the proposed architecture,

where connections between existing IoT devices cre-

ate a self-expanding mesh network. Wi-Fi and ESP-

NOW will work concurrently in different roles, acting

as the dual data plane and control plane, respectively,

to establish distinct production and management net-

works at separate layers. These run in the same inter-

face as shown in the ﬁgure 2.

The network includes a common router serving as

the internet gateway (where is possible to have multi-

Figure 1: Proposed mesh architecture with devices as

network propagators for both data and control planes.

Virtual

Interface 1

Virtual

Interface 2

Virtual

Interface

Device Interface

Data Plane (IoT) Control Plane

Wi-Fi

Thread

ZigBee

BLE

Wi-Fi

EspNow

HaLow

Data Plane (Wi-Fi ext)

Figure 2: Device with a single interface for both dual data

and control planes.

ple gateways) and a simple Wi-Fi Access Point (AP)

that connects directly to the router. Both allow wire-

less access for other devices, namely IoT devices with

sensors and/or actuators (e.g., smart light bulbs, smart

doors, or a smart appliance). The IoT devices use

the ESP-NOW protocol to communicate, selecting the

best route based on peer signal strength, reachable

APs/routers or other metric. They monitor changes

in their surroundings and adjust their connections,

which are visible and conﬁgurable through an SDN

Controller accessible to any device. After achieving

convergence, IoT devices conﬁgure the Wi-Fi mesh

Enhancing Scalability in Wi-Fi IoT Networks with Logical Data Plane Segregation Using SDN Principles

381

Table 4: Comparison between related work and proposed architecture features.

Features (Espressif,

2024b)

(Muhendra

et al., 2017)

(Gergeleit,

2019)

(Manvi and

Maakar,

2020)

(Khanchuea

and

Siripokarpirom,

2019)

Proposed

DPT Wi-Fi MoE Wi-Fi ad-hoc Wi-Fi Zig-Bee Wi-Fi

CPT Wi-Fi MoE NAT TCP ESP-NOW &

ModBus

ESP-NOW

SOH ✓ ✓ ✓ ✓ ✓ ✓

SDNC - - - - - ✓

PN ✓ - ✓ - - ✓

IC ✓ - ✓ - - ✓

DCPS - - - - ✓ ✓

EOC - - - - - ✓

M - - - - ✓ ✓

NS ✓ - ✓ - - ✓

AEDC - - ✓ - - ✓

network by connecting to various APs/routers, ex-

tending the network using the same SSID. The Wi-

Fi mesh network remains active among IoT devices,

but broadcasting to end-user devices requires explicit

controller conﬁguration. The IoT devices can per-

form their primary functions, including acquiring sen-

sor data, executing actuator tasks, and communicating

with the IoT data collector. End-user devices (laptops,

smartphones, etc.) can connect to the Wi-Fi network

via any AP/router or any IoT device broadcasting that

network.

Figure 3 illustrates the implementation process of

the architecture: starting with raw operation, con-

ﬁguring interfaces and services, separating control

and data planes, initialising mesh networks for device

communication, and loading specialised software for

sensors or actuators.

Raw Operation

Initialization

Data Plane

Network

Configuration

Control Plane

Network

Configuration

Control Plane

Mesh

Initialization

Data Plane

Mesh

Initialization

Extra Software

Interfaces and

Services

Configuration

Figure 3: Proposal of the Software Flow the IoT devices.

5 IMPLEMENTED PROTOTYPE

Wi-Fi 6 is a relatively new technology in IoT terms

(Mozaffariahrar et al., 2022a), and manufacturers are

still in the process of adopting and releasing com-

patible devices. One such device is the Espressif

ESP32-C6 DevKitC-1 v0.0, which has been selected

for use in this project. This development board sup-

ports Wi-Fi 6, Bluetooth 5, Thread, and ZigBee com-

munications, according to the ofﬁcial documentation

(Espressif, 2023e), making it the ﬁrst low-cost IoT de-

vice capable of implementing Wi-Fi 6 for mesh net-

work development. A necessary note, is that the de-

vice used in the present work is a sample version

(v0.0), it has power stability issues as noted in the

sample paper accompanying the device, ”The ADC

in the current samples is not calibrated”, and also

doesn’t support external antennas (The ESP32-C6-

WROOM-1U version, which came out later (Espres-

sif, 2024c) supports and has this problems addressed).

The implemented prototype was developed us-

ing the Espressif ESP32-C6, as it is currently the

only low-cost IoT device meeting the necessary re-

quirements for the intended functionality (Espressif,

2023g). This device can communicate using both

protocol stacks concurrently via a single antenna, en-

abling the separation of the planes, with Wi-Fi serv-

ing the data plane (wireless clients) and ESP-NOW

for the control plane (IoT devices).

The dual data plane is constructed atop a mesh

network, where each device forwards data to the next

one until it reaches a gateway (an access point or

router). This implementation was necessary because

native routing cannot be set up directly on the de-

vice (Espressif, 2023a) (Espressif, 2020a) (Espressif,

2015). By this, it is meant that the devices select

the next hop by signal strength. The routing is han-

dled simply by the inherent features of a NAT device.

As such, it uses a NAT mechanism to forward trafﬁc

(Gergeleit, 2019). Implementing NAT in this speciﬁc

context has performance costs, especially for devices

closest to the gateways due to high trafﬁc volumes and

the number of dependent devices. Consequently, a re-

striction imposed by the manufacturer only allows up

to 17 connections (Espressif, 2024d) to be connected

to each network node. This value is further reduced to

8 devices per interface due to the requirement of two

virtual interfaces per node (6 devices and 2 nodes per

interface), and this can be rearranged according to the

necessities up to 8 slots per interface.

IoTBDS 2025 - 10th International Conference on Internet of Things, Big Data and Security

382

For the control plane, several technologies and

protocols are suitable for IoT communications, in-

cluding ZigBee, Thread, BLE, HaLow, and ESP-

NOW. Although all these protocols could theoreti-

cally implement a wireless communication architec-

ture, only ESP-NOW fully meets the requirements for

this speciﬁc use case. See section 2 for further details.

The device broadcasts a packet every 10 seconds

to announce its presence to other nearby devices.

There are two packet types: a search packet and a

keep-alive packet, and both currently transmit iden-

tical information, differ only in retransmission inter-

vals. The keep-alive packet having the longest inter-

val. When a neighbouring device receives a packet,

it checks whether the sender is already in the cached

neighbours list, if it exists, its dead timer is set to 0,

or else it increments.

In addition to the aforementioned, the device also

scans periodically for Wi-Fi access points in the vicin-

ity and then selects the nearest gateway/mesh. Before

connecting to any node (device or gateway), a false

positive check is performed three times, and if vali-

dated, the device attempts the connection, otherwise,

it attempts on another node. The process repeats ev-

ery 10 seconds for unconnected nodes and 30 seconds

for connected ones. These values were chosen as de-

fault settings to balance responsiveness and resource

usage. While they have not been experimentally vali-

dated, they can be adjusted based on speciﬁc applica-

tion needs in future work.

6 RESULTS

The prototype testing aimed to record the overall net-

work uptime, from boot to full operational mode,

and assess stability and performance using tools like

iperf3, hping3, nuttcp, and ping. The tests were con-

ducted using four devices spaced between 1 and 15

metres apart (1, 5, 10, and 15 metres), covering up

to 50 metres in a linear hop-by-hop mesh conﬁgu-

ration. While this approach allowed for straightfor-

ward evaluation of individual hops, it does not fully

exploit the resilience and redundancy typically asso-

ciated with mesh networks. In this setup, failure of

an intermediary node disrupts service for subsequent

nodes. Although the development of the project used

a full mesh topology, the testing phase employed a

hop-by-hop NAT conﬁguration for practical evalua-

tion of individual node performance. The same mesh

code was utilised in the test environment, ensuring

consistency between the mesh architecture and the

test conﬁguration. Future testing should investigate

the use of a mesh topology with more devices.

To streamline test execution, a Python script was

developed, incorporating both client and server re-

quirements in separate threads. The script’s server

mode provides an HTTP server to monitor device

readiness in the network, a Mosquitto server for re-

sult sharing, a nuttcp server to test throughput, and

an iperf3 server for bandwidth and data loss analysis.

Figure 4 illustrates the setup and the communication

between them, forwarded by the Espressif devices.

All devices have a default route to ensure connectivity

to the server and the Internet.

Figure 4: Arrangement of test equipment.

Table 5 summarises the results of the network

setup readiness and convergence tests, measuring up-

time from a cold boot at various distances. Each net-

work conﬁguration was tested 10 times with different

device quantities, totalling 40 tests (4 devices × 10

tests each). The overall average uptime across all dis-

tances was 28.75 seconds.

Table 5: Average uptime submitted by the devices.

Devices \Distance 1m 5m 10m 15m

Device 1 30s 30s 30s 30s

Device 2 26s 26s 26s 28s

Device 3 29s 30s 51s 26s

Device 4 50s 50s 148s 28s

Table 6 displays the response times and packet

loss rates measured by the ping tool, which gradually

increase with the distance between devices. Nuttcp

tools in 7, shows that results degrade as the dis-

tance increases, leading to higher response times.

This results in longer Round-Trip Times (RTT), re-

duced throughput, and increased packet loss. Re-

transmissions were not observed. All the results are

a compilation of 10 tests. The iperf3 results in table

8 also highlight the trend of signiﬁcant performance

degradation with increasing distance. However, when

using UDP, the connection maintains a stable rate of

1.05 Mbits/sec.

Table 6: Ping tool results.

Ping \Distance 1m 5m 10m 15m

Minimum 6.982ms 10.859ms 8.834ms 6264.071ms

Average 17.482ms 33.028ms 18.113ms 7078.394ms

Maximum 51.641ms 130.871ms 42.200ms 8609.763ms

Packet Loss 0% 0% 0% 50%

Enhancing Scalability in Wi-Fi IoT Networks with Logical Data Plane Segregation Using SDN Principles

383

Table 7: Nuttcp results.

Nuttcp \Distance 1m 5m 10m 15m

TCP Throughput 6.7604 Mbps 2.1619 Mbps 0.0524 Mbps -

TCP RTT 7.98ms 10.59ms 154.43ms -

TCP Retrans 0 0 0 -

UDP Throughput 1.0002 Mbps 1.0012 Mbps 0.2756 Mbps 0.0164 Mbps

UDP Packet Loss 0% 0% 66.18% 98.69%

Table 8: Iperf3 TCP, UDP, retries and jitter results.

iperf3

\Distance

1m 5m 10m 15m

TCP 7.15 Mbits/sec 2.25 Mbits/sec 78.6 Kbits/sec -

UDP 1.05 Mbits/sec 1.05 Mbits/sec 1.05 Mbits/sec -

Retry 17 9 2 -

Jitter 1.096 ms 3.996 ms - -

7 DISCUSSION

The prototype demonstrates the use of a single an-

tenna to accommodate the two data planes and a con-

trol plane. The antenna is used for three roles: IoT

client, access point for IoT end devices, and manage-

ment network. While the client and access point rely

on Wi-Fi 6, the management network uses ESP-NOW.

The use of a single-antenna design aims to deliver

functionality for existing devices at a low cost. Multi-

ple antennas could improve system performance, but

may shift the focus from simple, low-cost solutions to

complex implementations.

A concern on the prototype is the use of NAT in

the Lightweight TCP/IP (LwIP) stack that does not

support creating a network bridge, and as a solution

NAT was used instead, resulting in an inherent ”de-

lay” when many client devices are present in the net-

work, as it works like a funnel. While there is an

Ethernet Network Interface Card (NIC) based solu-

tion (Espressif, 2023b), the LwIP stack currently only

supports Ethernet interfaces for bridging. Each node

is limited to 8 connected devices (Espressif, 2024e)

an can be conﬁgured up to 17 different devices.

The use of NAT was necessitated by the lack of

support for direct interface bridging in the current de-

velopment framework. While NAT offers advantages

such as simpliﬁed route creation and privacy protec-

tion, its inherent limitations, including increased la-

tency and reduced number of connected neighbors,

highlight the need for future code framework im-

provements to support direct bridging for enhanced

performance. However these inherent limitations do

not affect the scalability of the mesh network.

The testing revealed coverage limitations possi-

ble due to a single antenna, IoT nature, and experi-

mental software/hardware. The best stable outcome

was achieved with devices with 10 metres, and reach-

ing up to 50 metres for a usable network. The data

shows that device uptime is relatively stable around

30 seconds, with constraints based on the connection

time from lower layers. If layer 3 devices cannot boot

due to layer 2 devices being inactive, subsequent lay-

ers wait for predeﬁned time intervals to recheck and

establish connections. Performance degradation be-

yond 10 metres is likely attributed to a combination of

factors, including the prototype’s development stage,

lack of external antennas, unoptimised code, and the

simultaneous use of multiple planes with a single an-

tenna attempting concurrent operations. Addressing

these hardware and software limitations could signif-

icantly enhance range and stability.

8 CONCLUSION

The paper presents a dual data plane architecture and

functional prototype enabling new and existing IoT

devices to establish their own mesh network while

separating data streams. It achieves this by allowing

devices to communicate via ESP-NOW for settings

adjustments and decision-making, thereby fostering

autonomous operation within the network, while the

Wi-Fi planes handle IoT functionality and Wi-Fi ac-

cess to end devices. The architecture supports concur-

rent operation of Wi-Fi 6 and ESP-NOW on ESP32-

C6 (v0.0) devices, utilising a single 2.4 GHz inter-

face. This setup enables devices to manage control

independently without requiring an SDN Controller

or central device, though it remains compatible with

such conﬁgurations if needed.

Future work should focus on seamless integra-

tion across multiple vendors and broader testing un-

der varied conditions. While this work does not en-

compass a detailed security analysis, future iterations

could include exploring security challenges speciﬁc

to ESP-NOW and mesh architectures. The integra-

tion of artiﬁcial intelligence techniques and a SDN

controller can improve network performance through

data-driven optimisation, failure prediction, and real-

time parameter adjustments. Code revisions can im-

prove environment scanning, routing, and updating

neighbour statuses. A study should investigate efﬁ-

ciency challenges and security aspects in communi-

cations, particularly in the ESP-NOW protocol.

ACKNOWLEDGEMENTS

This work was funded by FCT – Fundac¸

ao para

a Ci

encia e Tecnologia, I.P. under the project

UIDB/04524/2020.

IoTBDS 2025 - 10th International Conference on Internet of Things, Big Data and Security

384

REFERENCES

Analytics, I. (2024). State of IoT 2023: Number of con-

nected IoT devices growing 16% to 16.7 billion glob-

ally. [Online; accessed 8. May 2024].

Bisdikian, C. (2001). Bluetooth Technology Overview.

Eridani, D., Rochim, A. F., and Cesara, F. N. (2021).

Comparative Performance Study of ESP-NOW, Wi-

Fi, Bluetooth Protocols based on Range, Transmis-

sion Speed, Latency, Energy Usage and Barrier Re-

sistance. In 2021 International Seminar on Applica-

tion for Technology of Information and Communica-

tion (iSemantic), pages 322–328.

Espressif (2015). Routing/bridging - esp32 forum.

Espressif (2020a). Layer 2 bridging - esp32 forum.

Espressif (2020b). Usage ble and wi-ﬁ at the same program.

Espressif (2023a). Bridging wiﬁ softap with ethernet -

esp32 forum.

Espressif (2023b). esp-idf/examples/network/bridge at fea-

ture/lwip bridge w wiﬁ · kostaond/esp-idf.

Espressif (2023c). Esp-now - esp32-c3 - — esp-idf pro-

gramming guide latest documentation.

Espressif (2023d). Esp-now wireless communication pro-

tocol — espressif systems.

Espressif (2023e). Esp32-c6 wi-ﬁ 6 & ble 5 & thread/zigbee

soc — espressif systems.

Espressif (2023f). Openthread border router.

Espressif (2023g). Rf coexistence - esp32-c6.

Espressif (2024a). esp-idf/examples/mesh at master ·

espressif/esp-idf. [Online; accessed 11. Jul. 2024].

Espressif (2024b). ESP-WIFI-MESH - ESP32 - — ESP-

IDF Programming Guide v5.2.2 documentation. [On-

line; accessed 11. Jul. 2024].

Espressif (2024c). Esp32-c6-devkitc-1 user guide. [Online;

accessed 10. Jul. 2024].

Espressif (2024d). Wi-Fi Driver - ESP32 - — ESP-IDF Pro-

gramming Guide v5.2.1 documentation. [Online; ac-

cessed 10. May 2024].

Espressif (2024e). Wi-Fi Driver - ESP32-C6 - — ESP-IDF

Programming Guide latest documentation. [Online;

accessed 11. Jul. 2024].

Ferro, E. and Potorti, F. (2005). Bluetooth and wi-ﬁ wireless

protocols: a survey and a comparison. IEEE Wireless

Communications, 12(1):12–26.

Flayols, T. (2024). Linux-ESPNOW. [Online; accessed 8.

May 2024].

FreeRTOS (2024). Freertos - market leading rtos (real time

operating system) for embedded systems with internet

of things extensions.

Gergeleit, M. (2019). Autotree: Connecting cheap iot nodes

with an auto-conﬁguring wiﬁ tree network. 2019 4th

International Conference on Fog and Mobile Edge

Computing, FMEC 2019, pages 199–203.

Islam, G. Z. and Kashem, M. A. (2022). A proportional

scheduling protocol for the ofdma-based future wi-ﬁ

network. J. Commun., 17(5):322–338.

Kaljic, E., Maric, A., Njemcevic, P., and Hadzialic, M.

(2019). A Survey on Data Plane Flexibility and Pro-

grammability in Software-Deﬁned Networking. IEEE

Access, 7:47804–47840.

Karamyshev, A., Liubogoshchev, M., Lyakhov, A., and

Khorov, E. (2024). Enabling industrial internet of

things with wi-ﬁ 6: An automated factory case

study. IEEE Transactions on Industrial Informatics,

20(11):13090–13100.

Khanchuea, K. and Siripokarpirom, R. (2019). A multi-

protocol iot gateway and wiﬁ/ble sensor nodes for

smart home and building automation: Design and im-

plementation. 10th International Conference on Infor-

mation and Communication Technology for Embed-

ded Systems, IC-ICTES 2019 - Proceedings.

Khanna, A. and Kaur, S. (2020). Internet of things

(iot), applications and challenges: A comprehen-

sive review. Wireless Personal Communications,

114(2):1687–1762.

Manvi, M. M. and Maakar, M. S. K. (2020). Implement-

ing wireless mesh network topology between multi-

ple wi-ﬁ powered nodes for iot systems. Interna-

tional Research Journal of Engineering and Technol-

ogy, 7(10):1242–1244.

Mozaffariahrar, E., Theoleyre, F., and Menth, M. (2022a).

A Survey of Wi-Fi 6: Technologies, Advances, and

Challenges. Future Internet, 14(10):293.

Mozaffariahrar, E., Theoleyre, F., and Menth, M. (2022b).

A Survey of Wi-Fi 6: Technologies, Advances, and

Challenges. Future Internet, 14(10):293.

Muhendra, R., Rinaldi, A., Budiman, M., and Khairurrijal

(2017). Development of wiﬁ mesh infrastructure for

internet of things applications. Procedia Engineering,

170:332–337.

Oughton, E. J., Lehr, W., Katsaros, K., Selinis, I., Bubley,

D., and Kusuma, J. (2021). Revisiting Wireless Inter-

net Connectivity: 5G vs Wi-Fi 6. Telecommunications

Policy, 45(5):102127.

Perez-Ramirez, J., Seijo, O., and Val, I. (2022). Time-

Critical IoT Applications Enabled by Wi-Fi 6 and Be-

yond. IEEE Internet of Things Magazine, 5(3):44–49.

Thread Group (2020). [accessed 24. May 2024].

Thread Group (2024). Thread Beneﬁts. [Online; accessed

24. May 2024].

Zegeye, W., Jemal, A., and Kornegay, K. (2023). Connected

smart home over matter protocol. 2023 IEEE Interna-

tional Conference on Consumer Electronics (ICCE),

pages 1–7.

ZigBee Alliance (2017). Zigbee green power.

Zigbee2MQTT (2024). Improve network range and stabil-

ity — zigbee2mqtt.

Enhancing Scalability in Wi-Fi IoT Networks with Logical Data Plane Segregation Using SDN Principles

385