Inter national J our nal of Recongurable and Embedded Systems (IJRES) V ol. 15, No. 3, No v ember 2026, pp. 837 ∼ 847 ISSN: 2089-4864, DOI: 10.11591/ijres.v15.i3.pp837-847 ❒ 837 Thr oughput bottleneck shift in an embedded W i-Fi gateway Jianan Zhao, Y uanbin Mu Department of Applied Electronic T echnology , School of Internet of Things T echnology , Hangzhou Polytechnic, Hangzhou, China Article Inf o Article history: Recei v ed Apr 22, 2026 Re vised Aug 24, 2026 Accepted Sep 11, 2026 K eyw ords: ESP32-S3 Internet of things P ack et loss Softw are access point Throughput ceiling T ransmission control protocol g ate w ay T w o-f actor analysis of v ariance ABSTRA CT An ESP32 softw are access point (SoftAP) often serv es as the sole transmission control protocol (TCP) g ate w ay in eld deplo yments without routers; ho we v er , prior benchmarks v aried only one f actor at a time. W e v aried tw o f actors that dif fer in practice: TCP connection count (3, 5, and 10) and per -pack et payload size (10, 64, and 256 bytes), yielding 9 congurations. Each w as tested at in- creasing send frequencies, with each frequenc y repeated 3 times, for a total of 246 60-second runs. T w o-w ay analysis of v ariance (ANO V A) on the 30 Hz data conrms that both f actors and their interaction are signicant (all p < 0 . 001 ). W ith 10 connections and 10-byte payloads, the g ate w ay sustained 3,237 pack- ets per second (pps) with zero loss; switching to 256-byte payloads dropped the safe rate belo w 946 pps and pushed central processing unit (CPU) utilization past 100%. In our e xperiments, system constraints shift from per -frame media access control (MA C) o v erhead to channel-bandwidth saturation as payl oad size increases. W e present a stability-re gion chart that helps designers understand the limits of system stability , optim ize system performance, and choose the appro- priate connection count and message size. This is an open access article under the CC BY -SA license . Corresponding A uthor: Y uanbin Mu Department of Applied Electronic T echnology , School of Internet of Things T echnology Hangzhou, China Email: muyuanbin@qq.com 1. INTR ODUCTION ESP32 serv es as a data g ate w ay in re gions without wireless netw ork co v erage (e.g., agricultural areas or disaster sites) [1], [2], while also performing local data aggre g ation and backhaul services [3]–[5]. ESP32- enabled g ate w ays are widely deplo yed in lo w-cost pri v ate deplo yments [6]. Recent studies in this journal demonstrated ESP32-based internet of things (IoT) systems for ood w arning [7] and smart parking [8]. The sensor data the y process are time-sensiti v e and unreco v erable [9], [10]. Unfortunately , prior benchmarks ha v e v aried only one f actor at a time, lea ving the combined ef fect unkno wn. As a result, the zero-loss throughput ceiling becomes the primary concern for system designs [11]. This ceiling is a ne-grained stability limit that con v entional iperf tests cannot precisely resolv e because of their best-ef fort traf c generation. The ESP32 f amily has become v ery popular as a general-purpose IoT prototyping platform. Prior w ork characterized it from multiple perspecti v es: Naik [1] surv e yed its messaging protocols and dual-radio wireless delity (W i-Fi)/Bluetooth lo w ener gy (BLE) adv antages; Maier et al . [2] v alidated its eld-readiness; Plauska et al . [12] pro vided compute baselines in C/C++, MicroPython, and Rust, though not for netw orking w orkloads; at the system le v el, ESP32 has been applied in message queuing telemetry transport (MQTT)-based automation [13] and reusable IoT g ate w ays [6], both focusing on application-layer interoperability rather than throughput limits. Recent w ork e xplored ESP32 as a smart-home g ate w ay [14] and e v aluated its real-time synchronization performance [15], b ut multi-f actor stress testing under concurrent transmission control proto- J ournal homepage: http://ijr es.iaescor e .com Evaluation Warning : The document was created with Spire.PDF for Python.
838 ❒ ISSN: 2089-4864 col (TCP) loads remains unaddressed. Although the of cial documentation [3], [16] states that the maximum number of associated stations is 10, this limit pro vides no indication of the sustainable pack et rate without loss. T o address this uncertainty , we performed a load-sweep e xperiment. Ev ery 802.11 transmission requires an una v oidable o v erhead before the rst bit of payload reaches the air . Bianchi [17] modeled this cost with a Mark o v-chain model for the distrib uted coordinati o n function (DCF), c h a racterizing a total delay (DCF inter -frame space, random back of f, and ph ysical layer pre amble (PHY preamble)) between 200 and 250 µ s per frame, and independent of the payload size. The IEEE 802.11-2020 standard [18] species these timing parameters; Tselishche v et al . [9] sho wed that greater contention among stations diminishes aggre g ate throughput with higher collision probability; ho we v er , their simulations assumed idealized media access control (MA C) layer conditions, ignoring the softw are-stack o v erhead present in real system on chip (SoC) implementations. Additionally , Montori et al . [19] e xamined the ener gy ef cienc y of W i- Fi for IoT and of fer a vie w of throughput through a MA C-layer constr aint. Ne v ertheless, all these studies treat the radio layer in isolation. F or an inte grated softw are access point (SoftAP) g ate w ay , the radio subsystem and the TCP/IP stack share the same dual-core central processing unit (CPU). Consequently , MA C-layer o v erhead and softw are processing latencies are tightly coupled: precisely the hardw are-softw are interaction that our e xperiments were designed to in v estig ate. The lightweight internet protocol (l wIP) stack, dened by Dunk els [20], remains the most popular TCP/IP stack for resource-constrained embedded systems. Espressif distrib utes l wIP in the espressif IoT de v el- opment frame w ork (ESP-IDF) (v2.1.2) [21], which is spe cically tuned so that TCP windo w sizes, maximum se gment size (MSS), and memory-pool depth can be set to the required le v el. W orks on the o v erall IoT -edge- cloud continuum, such as those by Gk onis et al . [22], Perera et al . [23], point out that TCP congestion at the g ate w ay layer is increasingly becoming a bottleneck i n the end-to-end data pipeline. Although this is widely ackno wledged, there are fe w studies of t he ESP32-S3’ s limit s in the literature, particularly when it runs SoftAP while simultaneously handling se v eral high-throughput TCP sessions. Our study lls this g ap by designing a stress-test procedure to measure the performance ceiling under multi-f actor conditions. In future high-density deplo yments, we can of oad TCP/IP processing to a eld-programmable g ate array (FPGA) f abric or a ded- icated v ery-lar ge-scale i nte gration (VLSI) netw ork processor . This approach si gnicantly reduces softw are bottlenecks. Identifying bottleneck positions is essential for most hardw are acceleration schemes. Existing ESP32 W i-Fi benchmarks mainly focus on single-stream TCP/user datagram protocol (UDP) throughput [1], [12]. These benchmarks measure the ra w pipe capacity of a g ate w ay , b ut do not capture its response to synchronized short-pack et b ursts from multiple sources. T w o f actors that v ary simultaneously in real deplo yments are the number of concurrent TCP connections and the payload size. Ho w each f actor af fects the performance bottleneck of a g ate w ay is not well understood. Increasing the connection count puts more pressure at the system le v el (A CKs, sock et-b uf fer allocation, and l wIP conte xt switching); increasing the message length changes the ratio of x ed 802.11 MA C-layer o v erhead (distrib uted inter -frame space (DIFS), back of f, and preamble) to actual data payloads [20]–[24]. W e cannot predict from theoretical analysis alone ho w the performance de gradation caused by more connections is amplied or dampened by longer messages; empirical observ ation is needed to nd the stable operating boundaries. In this paper , we e v aluate the ESP32 in SoftAP mode through a controlled tw o-f actor e xperiment. Our contrib utions are: i) a test matrix co v ering 246 trials, crossing connection count (3, 5, and 10) with payload size (10 B, 64 B, and 256 B), repeated three times. These le v els represent minimal sensor readings, mod- erate multi-sensor telemetry , and lar ge diagnostic pack ets, respecti v ely; the connecti on counts co v er lo w- to high-density deplo yments, with 10 being the SoftAP rmw are limit; ii) identi cation of a bottleneck shift: for small payloads, throughput is limited by MA C-layer o v erhead; for lar ge payloads, by channel-bandwidth saturation. The interaction is conrmed statistically signicant ( p < 0 . 001 ) by tw o-w ay analysis of v ariance (ANO V A)—optimizing only one f actor is inef fecti v e once the payload size shifts the bottleneck to a dif fer - ent subsystem; and iii) a stability-re gion chart mapping the safe operating en v elope for designers, which also informs the conguration of recongurable hardw are g ate w ays or FPGA accelerators in high-density IoT . 2. METHOD 2.1. Hard war e and softwar e platf orm F or our e xperiments, we used an ESP32-S3-N16R8 inte grated on a De vKitC-1 de v elopment board [16]. T o emulate a resource-constrained deplo yment, we disabled the 8 MB pseudo-static random-access mem- Int J Recongurable & Embedded Syst, V ol. 15, No. 3, No v ember 2026: 837–847 Evaluation Warning : The document was created with Spire.PDF for Python.
Int J Recongurable & Embedded Syst ISSN: 2089-4864 ❒ 839 ory (PSRAM), lea ving about 281 KB of usable heap at boot. The softw are stack ran the Arduino frame w ork on ESP-IDF v4.4.7, with the stock l wIP v2.1.2 stack and def ault TCP parameters. The W i-Fi dri v er w as pinned to Core 0 and the applicat ion loop to Core 1. Otherwise, W i-Fi interrupts could steal CPU c ycles a w ay from the pack et-parsing logic, and we w ould not be able to tell which core runs out of capacity rst. The full conguration is gi v en in T able 1. T able 1. Full conguration of the e xperimental platform P arameter V alue SoC ESP32-S3 (Xtensa LX7 dual-core) CPU frequenc y 240 MHz Flash/PSRAM 16 MB/8 MB (PSRAM not enabled) SRAM (heap) 359 KB total and ∼ 281 KB free at boot W i-Fi 802.11 b/g/n, 2.4 GHz, and PCB antenna SoftAP cong C hannel 6, WP A2-PSK, and max 10 ST As Firmw are Arduino frame w ork and ESP-IDF v4.4.7 l wIP v2.1.2, def ault TCP WND/MSS, and Nagle on T ask allocation W i- Fi on Core 0 and app loop on Core 1 F or traf c generation, a laptop-based Python program serv ed as the client, connecting to the ESP32 SoftAP at 1.5 m. The test en vironment w as a single-person of ce with no competing access points on Chan- nel 6, so co-channel interference w as minimal. T o model high-concurrenc y sensor traf c, each TCP connection w as implemented as an independent Python thread, with each thread handling data from 11 logical terminals. The ph ysical topology and the tw o-f actor e xperimental matrix are sho wn in Figure 1. Figure 1. Experimental setup and tw o-f actor test matrix 2.2. T w o-factor experimental design F or our e v aluation, we used a fully crossed f actorial design to test the system for tw o f actors: i) F actor A: concurrent TCP connections: three le v els (3, 5, and 10); since each connection multiple x es data for Thr oughput bottlenec k shift in an embedded W i-F i gate way (Jianan Zhao) Evaluation Warning : The document was created with Spire.PDF for Python.
840 ❒ ISSN: 2089-4864 11 logical terminals, the total count of terminals increased to 33, 55, and 110, respecti v ely and ii) F actor B: payload size: three le v els (10, 64, and 256 B). The 10-byte payload pack et used for baseline testing consists of a terminal identier (ID) and an American Standard Code for Information Interchange (ASCII) sequence number . W e pad the pack et to 64 bytes and 256 bytes using padding characters. In this paper , to ensure consistenc y in application-layer o v erhead, the g ate w ay rmw are code parses only the terminal ID and sequence number , discarding all padding bytes. By crossing the tw o f actors, we obtained nine distinct test congurations. F or each conguration, we designed eight transmission frequencies ranging from 10 to 50 Hz. Ev ery t rial ran for 60 seconds and w as repeated three times, yielding a total of 246 v alid runs. F or the 3- and 5-connection congurations, additional higher frequencies were applied with the intent of probing the Python client’ s saturation beha vior , and thereby localizing the global interpreter lock (GIL) bottlenecks. 2.3. Measur ement metrics W e e v aluated each e xperimental run usi ng v e metrics: i) zero-loss throughput ceiling (pps): the highest pack et rate at which e v ery pack et arri v ed intact; ii) loss rate (%): ratio of lost to total recei v ed pack ets, computed by scanning for g aps in per -terminal sequence numbers; iii) a v erage processing delay (ms): the mean time interv al from the start of readBytesUntil() to the completion of sscanf(); i v) delay jitter (ms): computed from the cumulati v e sum of squared delays, which remo v es the need for a per -pack et b uf fer; and v) CPU utilization (%): the proportion of each 60-second windo w spent in the b usy loop rather than in the free real-time operating system (FreeR T OS) idle task. T w o deri v ed quantities were also computed: goodput and per -frame payload fraction. The former is dened as G = ( ¯ R × L ) / 1024 (kB/s), where ¯ R is the mean recei v ed pack et rate (pps) and L is the payload size (bytes). The latter quanties the proportion of each frame occupied by useful data, gi v en by φ = L/ ( L + H ) , where H = 72 bytes account for the TCP (20 B), IP (20 B), and 802.11 MA C/logical link control (LLC, 32 B) headers [18], [24], e xcluding the frame check sequence (FCS, 4 B) and optional TCP timestamp elds. 2.4. Statistical method Each of the three repetitions per condition deli v ered one set of measures. W e report the means and sho w error bars ± 1 standard de viation in all gures. T o test if connection count and payload size af fect the throughput independently or interacti v ely , we ran a tw o-w ay x ed-ef fects ANO V A on the pps v alues recorded at 30 Hz, the highest frequenc y at which all nine settings had v alid (i.e., not o v ero wed) data. The signicance le v el w as α = 0 . 05 . The ANO V A partitions total v ariance into components for the main ef fect of connection count, the main ef fect of payload size, their interaction, and the residual error . This method enables us to assess the main inuence of each f actor and to e xamine whether the ef fec t of one f actor depends on the le v el of the other . 3. RESUL TS AND DISCUSSION 3.1. Effect of connection count (payload=10 B) Figure 2 plots pack et loss ag ainst send frequenc y for three connection counts, all with a 10-byte pay- load. The 3- and 5-connection congurations e xperience d no pack et loss, with aggre g ated throughput peaking at approximately 1,480 and 2,410 pps, respecti v ely . Importantly , these throughput plateaus were caused by the Python client’ s GIL limit rather than g ate w ay CPU e xhaustion; only at 10 connections did the g ate w ay CPU become the bottleneck. Ev en at a per -terminal frequenc y of 30 Hz (3,237 pps a v erage), there w as zero loss. When the frequenc y w as increased to 32 Hz, there w as an immediate jump in loss, gro wing to abo v e 20%. F or small payloads, the zero-loss ceiling is go v erned by total pack et rate rather than connection count. W ith 3 or 5 connections, the g ate w ay still had headroom while the Python client saturated due to the GIL, so those measured v alues are lo wer bounds on hardw are capacity . A GIL-free client (e.g., C-based or multiple machines) is required to obtain the true ceiling. 3.2. Effect of payload size (connections=10) Figure 3 also uses a connection count of 10 and v aries the payload size. The dif ference with subsec- tion 3.1 is striking. At 10 bytes, the g ate w ay maintains 3,237 pps with zero loss (30 Hz). At 64 bytes, zero-loss holds only at 10 Hz (1,088 pps); by 20 Hz, pack ets are already lost. At 256 bytes, loss occurred at all tested Int J Recongurable & Embedded Syst, V ol. 15, No. 3, No v ember 2026: 837–847 Evaluation Warning : The document was created with Spire.PDF for Python.
Int J Recongurable & Embedded Syst ISSN: 2089-4864 ❒ 841 frequencies; a v erage pps drops to 200–600, and CPU utilization e xceeded 100%. Multiplying the payload sizes by about 25 (from 10 to 256 bytes) lo wered the zero-loss ceiling by a f actor of three or more. Figure 2. Ef fect of connection count on pack et loss (payload=10 B) Figure 3. Ef fect of payload size on pack et loss (connections=10) 3.3. Interaction effects and the 3 × 3 matrix T able 2 lists the zero-loss ceiling for all nine congurations. The tw o-w ay ANO V A at 30 Hz (T able 3) sho ws signicant ef fects for all three terms. T able 2. Zero-loss throughput ceiling (pps) for all congurations Connections 10 B 64 B 256 B 3 ≥ 1,483* ≥ 1,289* ≥ 802* 5 ≥ 2,411* ≥ 1,600* ≥ 1,001* 10 3,237 1,088 ≤ 946 *Client-side bottleneck; ESP32 has remaining capacity . The interaction F-v alue ( F (4 , 17) = 77 . 66 , p < 0 . 001 ) is signicant. The partial eta-squared v al- ues ( η 2 p > 0 . 76 for all sources) conrm that the observ ed ANO V A ef fects are substanti v ely meaningful both statistically and practically . Statistically , with a 10-byte payload, increasing the connection count only raised Thr oughput bottlenec k shift in an embedded W i-F i gate way (Jianan Zhao) Evaluation Warning : The document was created with Spire.PDF for Python.
842 ❒ ISSN: 2089-4864 the total pack et rate (pps), indicating that the client w as the limiting f actor . W ith a 256-byte payload, the 3- and 5-connection congurations achie v ed roughly 800–1,000 pps, while the 10-connection throughput dropped sharply . In other w ords, connection count has a ne gligible impact on g ate w ay throughput f o r small pack ets, b ut it signicantly de grades performance for lar ge pack ets. From a practical perspecti v e, engineers should consider multiple f actors jointly to predict combined performance, because the interaction between f actors can signi- cantly alter the bottleneck. This i s because the system bottleneck shifts from MA C-layer frame-rate limitations to channel-bandwidth and b uf fer -pool capacity constraints. T able 3. T w o-w ay ANO V A results (dependent v ariable: pps at 30 Hz) Source SS df MS F p η 2 p Connections (A) 1,520,746 2 760,373 27.40 < 0.001 0.763 P ayload (B) 8,166,606 2 4,083,303 147.13 < 0.001 0.945 A × B 8,621,237 4 2,155,309 77.66 < 0.001 0.948 Error 471,808 17 27,753 T otal 18,780,396 25 3.4. P ayload fraction analysis T able 4 breaks do wn the x ed per -frame o v erhead. Each frame carries a x ed o v erhead of 72 bytes (TCP 20 B + IP 20 B + MA C 32 B). Ho we v er , the lar ger frames no w occup y considerably more channel time. This e xplains wh y the pps ceiling decreases as fram e size gro ws. It also challenges a common intuition: a high payload fraction alone does not guarantee high throughput on a resource-constrained g ate w ay . F or e xample, a conguration with a 78% payload fraction saturates the channel at 946 pps, whereas one with only 12.2% sustains 3,237 pps. The latter achie v es 3.4× the pack et processing rate of the former , deli v ering signicantly higher throughput. T able 4. Per -frame payload and header fractions by payload size P ayload (B) Frame total (B) P ayload fraction (%) Header fraction (%) 10 82 12.2 87.8 64 136 47.1 52.9 256 328 78.0 22.0 3.5. Delay and jitter analysis Figure 4 presents the a v erage processing delay across all e xperimental congurations. F or the 10- byte payload, the delay remained v ery lo w under all connection counts and increased only slightly e v en at the peak frequenc y , indicating that the system w as f ar from reaching its computational capacity limit. F or the 64- byte payload, the delay of the 10-connection group rose sharply to > 1.5 ms once the transmission frequenc y e xceeded 20 Hz, f ar e xceeding the delay observ ed with the 10-byte payload. Under the 256-byte payload condition, the processing delay reached its maximum at the peak frequenc y . These observ ations indicate that the internal b uf fer pools were e xhausted, and system-le v el netw ork bottlenecks be g an to emer ge. Figure 4. A v erage processing delay vs. send frequenc y Int J Recongurable & Embedded Syst, V ol. 15, No. 3, No v ember 2026: 837–847 Evaluation Warning : The document was created with Spire.PDF for Python.
Int J Recongurable & Embedded Syst ISSN: 2089-4864 ❒ 843 3.6. Central pr ocessing unit utilization Figure 5 sho ws the CPU utilizat ion at a x ed 30 Hz for all nine congurations of the e xperim ents. F or the 3-connection case, utilization ranged from 11% to 43%, depending on the payload. Con v ersely , the 10-connection/256-byte case had a CPU utilization e xceeding 100%. This indicates that our application-layer b usy-loop counter , which tracks time spent outside the FreeR T OS idle task, f ails to capture interrupt-conte xt processing o v erhead. The cumulati v e b usy time recorded by our counter e xceeds the 60-second measurement windo w , indicating that interrupt-conte xt processing (W i-Fi ISRs, l wIP timer callbacks) w as acti v e during interv als not captured by the application-le v el timer . While the absol ute v alue abo v e 100% is not ph ysically meaningful, it conrms that no idle c ycles remain and the system is fully saturated. Figure 5. CPU utilization at 30 Hz send frequenc y 3.7. Bottleneck shift mechanism Our e xperiments sho w tw o distinct operational re gimes, with the transition occurring near a 64-byte payload. Small-payload re gime (10 B). Here, the channel is limited by a x ed per -frame temporal o v erhead that is independent of the payload. Summing the DIFS ( ∼ 50 µ s), random back of f ( ∼ 67 µ s at CW min =15), the PHY preamble ( ∼ 40 µ s) and the SIFS-plus-A CK e xchange ( ∼ 50 µ s) [17], [18] yields a total non-payload cost of 200–250 µ s per transmission. The 10-byte payload tak es almost no airtime ( ∼ 1 µ s). Hence, the frame rate is bound in principle to ∼ 4,000 frames/s. Our observ ed ceiling of 3,237 pps agrees with this estimate after accounting for l wIP softw are delays (interrupt servicing, pb uf allocation, and application-loop jitter). In this re gime, neither increasing nor decreasing the TCP connection count changes the bottleneck: the bottleneck is gi v en by the serialized MA C-layer queue. Lar ge-payload re gime (256 B). When the payload is resized to 256 B, the bottleneck shifts from frame rate to channel capacity and memory pressure. In addition to the e xtra airtime needed for 2,608 bits, each pack et needs more space in the l wIP pb uf pool [20]. Specically , each 256 B pb uf consumes approximately four times the memory of a 10 B pb uf. Gi v en the x ed size of the system b uf fer pool, lar ger payloads occup y most a v ailable memory , lea ving insuf cient space for TCP A CK b uf fers and retransmis sion queues. Lik e wise, TCP control-plane comple xity (including windo w management and A CK coalescing) scales with payload size [25]. This 10-connection case is particularly vulnerable here, as 10 streams compete for a nite pb uf pool at the same time that the y generate a 10 × increase in A CK traf c compared with a single-stream baseline. Statistical ngerprint. This bottleneck shift, from MA C-c ycle limits at small payloads to channel or memory saturation at lar ge payloads, is corroborated by the highly signicant ANO V A interaction term ( p < 0 . 001 ), marking the transition from a pack et-rate-limited to a throughput-limited system. 3.8. Design guidelines Our empirical data pro vide four k e y design heuristics to maximize ESP32-S3 SoftAP performance [26], [27]: i) for small messages ( ≤ 64 B), the throughput ceiling is strictly in terms of the total pps rate rather Thr oughput bottlenec k shift in an embedded W i-F i gate way (Jianan Zhao) Evaluation Warning : The document was created with Spire.PDF for Python.
844 ❒ ISSN: 2089-4864 than TCP connections. The designer can use up to 10 concurrent sock ets wit hout a throughput penalty if the total pps does not approach the saturation point; ii) increasing the payload size from 10 to 256 bytes reduces the zero-loss ceiling by a f actor of more than 3. F or high-frequenc y telemetry , sensors need to fragment lar ge payloads into smaller pack ets or reduce the sampling frequenc y; iii) operating at 80% of the measured ceiling ( ∼ 26 Hz per terminal) is a necessary operating mar gin ag ainst temporary traf c b ursts and electromagnetic pollution; i v) processing delay is a more sensiti v e early-w arning indicator than pack et loss. Across all setups, the mean lat enc y continues to rise wel l before the pack et drops occur , and a per -pack et delay li mit of about 0.1 ms should trigger automatic rat e limiting. Therefore, a scheme can be designed to be directly inte grated into the g ate w ay rmw are: once the per -pack et latenc y e xceeds a user -congurable threshold, pack et reception is throttled. Figure 6 depicts the safe operating en v elope: a mult idimensional map of zero-loss operating points across connec tion counts and payload sizes. The shaded area represents the deterministic stability re gion, with zero loss observ ed in all e xperiments. Figure 6. System stability re gion 3.9. Implications f or r econgurable and embedded systems The abo v e bottleneck analysis applies not only to the ESP32 platform b ut also to general embedded g ate w ay sys tems. When incoming pack et rates e xceed the softw are process ing capacity of general-purpose SoCs, of oading TCP/IP processing to recongurable FPGA hardw are becomes an ef fecti v e optimization so- lution [28]. This approach has been v alidated across the IoT domain: FPGA-based accelerators ha v e demon- strated substantial throughput g ains in high-density sensor netw orks [29]. The MA C-layer interrupt o v erhead observ ed in small-payload scenarios could potentially be eliminated by deplo ying hardw are-based pack et pars- ing pipelines [26]. This hardw are implementation bypasses the entire l wIP softw are stack and w ould bypass rele v ant softw are constraints. Similarly , a dedicated VLSI netw ork processor with independent pack et b uf fer memory could alle viate the pb uf pool contention caused by lar ge payloads [30]. The stability re gion chart in Figure 6 pro vides a quantitati v e baseline for e v aluating hardw are acceleration performance. An y FPGA or VLSI acceleration design may impro v e the zero-loss throughput ceiling be yond the 3,237 pps limit of the pure softw are g ate w ay implemented in this study . Furthermore, embedding real-time throughput monitoring into IoT g ate w ays supports dynamic system adaptation. The delay-based early-w arning indicator proposed in sub- section 3.8 could enable recongurable systems to adjust hardw are resource allocation dynamically according to real-time traf c characteristics. This mechanism could f u r ther enhance the operational sta bility and resource utilization of high-density IoT deplo yments. 3.10. Limitations Our ndings are subject to some constraints. First, the e xperiments are perf ormed under a baseline RF situation, a single- o c cupant indoor en vironment on a single W i-Fi channel. Actual functioning in dense Int J Recongurable & Embedded Syst, V ol. 15, No. 3, No v ember 2026: 837–847 Evaluation Warning : The document was created with Spire.PDF for Python.
Int J Recongurable & Embedded Syst ISSN: 2089-4864 ❒ 845 electromagnetic en vironments w ould reach a much lo wer saturation rate o wing to the additional contention and interference. Second, we only analyzed TCP . UDP has no A CK generation or o w-control o v erhead at the transport layer , so its performance en v elope is lik ely to dif fer . Third, the zero-loss ceilings reported for 3- connection and 5-connection groups at 10 B and 64 B payloads are client-side GIL artif acts; the true ESP32-S3 hardw are ceiling for these congurations lies abo v e the measured v alues. Consequently , the claim in subsection 3.7 that connection count does not shift the bottleneck in the small-payload re gime should be interpreted as: within the tested range where client-side saturation w as a v oided (10 connections), the MA C-layer fr ame-rate limit dominates independently of sock et count. The small- payload beha vior at intermediate connection counts remains to be v eried with a non-GIL-const rained client. F ourth, we had disabled PSRAM; increasing e xternal RAM w ould lik ely reduce b uf fer -pool pressure for high- throughput lar ge payloads. Fifth, as this w ork used the ESP32-S3, our results may not be immediately trans- posable to other f amily members (e.g., wireless module (WR OOM-32E)) due to v ariations in radio-frequenc y front-end and memory architectures [14]. 4. CONCLUSION This study identied a bottleneck-shift phenomenon in an ESP32-S3 SoftAP g ate w ay using a fully crossed tw o-f actor e xperiment (connection count and payload size, 246 trials in total). T w o-w ay ANO V A con- rmed that both f actors, and crucially their interaction, are statis tically signicant ( p < 0 . 001 ), implying that system stability is not additi v e: a design v alidated under one payload size cannot be assumed to w ork un- der another . Specically , while small payl oads (10–64 B) k eep the g ate w ay lim ited by per -frame MA C-layer o v erhead, lar ge payloads (256 B) shift the bottleneck to channel bandwidth and l wIP b uf fer -pool contention, re- ducing the zero-loss throughput ceiling from thousands of pack et s per second to belo w 946 pps. These ndings lead to three practical guidelines for embedded g ate w ay design: i) when higher transmission frequencies are required, the pack et length should be reduced appropriately; ii) the g ate w ay should be designed with suf cient mar gin to absorb traf c b ursts; and iii) per -pack et delay should be considered as an early-w arning indicator , and the transmission frequenc y should be throttled at appropriate times. Be yond the ESP32 platform, the identied bottlenecks (MA C-layer per -frame o v erhead and pb uf-pool contention) are suitable tar gets for recongurable hardw are acceleration. FPGA/VLSI of oading may further raise the zero-loss ceiling, and the reported results can serv e as a baseline for e v aluating such designs. Future w ork includes e xtending the study to UDP , enabling PSRAM, and comparing other ESP32 v ariants to v erify the generality of the observ ed beha vior . FUNDING INFORMA TION This w ork w as supported in part by the Hangzhou Joint Fund of Zhejiang Pro vincial Natural Science F oundation of China (No. LHZQN26H180003), the Scientic Research Fund of Zhejiang Pro vincial Educa- tion Department (No. Y202559018), the Zhejiang Pro vince Ne w T alent Program for Colle ge Students (No. 2025R463A002, 2025R463A004), and the K e y Project of Hangzhou Polytechnic (No. HKYZXZD-2025-3). A UTHOR CONTRIB UTIONS ST A TEMENT This journal uses the Contri b ut or Roles T axonomy (CRediT) to recognize indi vidual author contrib u- tions, reduce authorship disputes, and f acilitate collaboration. Name of A uthor C M So V a F o I R D O E V i Su P Fu Jianan Zhao ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Y uanbin Mu ✓ ✓ ✓ ✓ ✓ ✓ ✓ C : C onceptualization I : I n v estig ation V i : V i sualization M : M ethodology R : R esources Su : Su pervision So : So ftw are D : D ata Curation P : P roject Administration V a : V a lidation O : Writing - O riginal Draft Fu : Fu nding Acquisition F o : F o rmal Analysis E : Writing - Re vie w & E diting Thr oughput bottlenec k shift in an embedded W i-F i gate way (Jianan Zhao) Evaluation Warning : The document was created with Spire.PDF for Python.
846 ❒ ISSN: 2089-4864 CONFLICT OF INTEREST ST A TEMENT Authors state no conict of interest. D A T A A V AILABILITY The data that support the ndings of this study are a v ailable from the corresponding author upon reasonable request. REFERENCES [1] N. Naik, “Choice of ef fec ti v e messaging protocols for IoT systems: MQTT , CoAP , AMQP and HTTP , ” in 2017 IEEE International Systems Engineering Symposium (ISSE) , V ienna, Austria, 2017, pp. 1–7, doi: 10.1109/SysEng.2017.8088251. [2] A. Maier , A. Sharp, and Y . V ag apo v , “Comparati v e analysis and practical implementation of the ESP32 microcontroller mod- ule for the Internet of Things, ” in 2017 Internet T ec hnolo gies and Applications (IT A) , Wre xham, UK, 2017, pp. 143–148, doi: 10.1109/ITECHA.2017.8101926. [3] Espressif Systems, “ESP-IDF Programming Guide, ” 2023. [Online]. A v ailable: https://docs.espressif.com/projects/esp- idf/en/latest/.(Accesed: Dec 1. 2025). [4] R. Ratasuk, B. V ejlg aard, N. Mang alv edhe, and A. Ghosh, “NB-IoT system for M2M communication, ” in 2016 IEEE W ir eless Communications and Networking Confer ence , Doha, Qatar , 2016, pp. 1–5, doi: 10.1109/WCNC.2016.7564708. [5] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A surv e y , ” Computer Networks , v ol. 54, no. 15, pp. 2787–2805, Oct. 2010, doi: 10.1016/j.comnet.2010.05.010. [6] D. C. Y . V ar g as and C. E. P . Salv ador , “Smart IoT Gate w ay F or Heterogeneous De vices Interoperability , ” in IEEE Latin America T r ansactions , v ol. 14, no. 8, pp. 3900-3906, Aug. 2016, doi: 10.1109/TLA.2016.7786378. [7] A. Hasib uan et al ., “Design of ood w arning prototype using ESP32 module-based ultrasonic sensors, ” International J ournal of Recongur able and Embedded Systems (IJRES) , v ol. 14, no. 1, pp. 126–135, Mar . 2025, doi: 10.11591/ijres.v14.i1.pp126-135. [8] P . Ranjani and N. Harini, “IoT Based Cloud-Inte grated Smart P arking System W ith Res erv ation, ” in 2024 International Confer - ence on System, Computation, A utomation and Networking (ICSCAN) , Puducherry , India, 2024, pp. 935–938, doi: 10.1109/IC- SCAN62807.2024.10894637. [9] Y . Tselishche v , A. Boulis and L. Libman, “Experiences and Lessons from Implementing a W ireless Sensor Netw ork MA C Protocol in the Castalia Simulator , ” 2010 IEEE W ir eless Communication and Networking Confer ence , Sydne y , NSW , Australia, 2010, pp. 1-6, doi: 10.1109/WCNC.2010.5506096. [10] C. Bormann, M. Ersue, and A. K eranen, “T erminology for constrained-node netw orks, ” Internet Engineering T ask F or ce (IETF) Request for Comments: 7228 , May 2014, doi: 10.17487/RFC7228. [11] S. Li, L. D. Xu, and S. Zhao, “5G Internet of Things: A surv e y , ” J ournal of Industrial Information Inte gr ation , v ol. 10, pp. 1–9, Jun. 2018, doi: 10.1016/j.jii.2018.01.005. [12] I. Plauska, A. Liutk e vi ˇ cius, and A. Jana vi ˇ ci ¯ ut ˙ e, “Performance e v aluation of C/C ++, MicroPython, Rust and T in yGo programming languages on ESP32 microcontroller , ” Electr onics , v ol. 12, no. 1, p. 143, 2023, doi: 10.3390/electronics12010143. [13] S. K umar , N. K. T omar , L. Gupta, Mana v , V . T ripathi, and P . Kalv ak ota, “Design and Implementation of an IoT -Based Indus- trial Process Control Simulator using ESP32, MQTT and Android, ” in 2025 2nd International Confer ence on Recent T r ends in Electrical , Electr onics and Computing T ec hnolo gies (ICRTEECT) , W arang al , India, 2025, pp. 1–6, doi: 10.1109/ICR- TEECT67512.2025.11448784. [14] F . Serepas, I. P apias, K. Christakis, N. Dimitropoulos, and V . Marinakis, “Light weight embedded IoT g ate w ay for smart homes based on an ESP32 microcontroller , ” Computer s , v ol. 14, no. 9, p. 391, 2025, doi: 10.3390/computers14090391. [15] M. J. Espinosa-Ga vira, A. Ag ¨ uera-P ´ erez, J. C. P alomares-Salas, J. M. Sierra-Fernandez, P . Remigio-Carmona, and J. J. G. de-la- Rosa, “Characterization and performance e v aluation of ESP32 for real-time synchronized sensor netw orks, ” Pr ocedia Computer Science , v ol. 237, pp. 261–268, 2024, doi: 10.1016/j.procs.2024.05.104. [16] Espressif Systems, “ESP32-S3 Series Datasheet, ” v1.2, 2023. [Online]. A v ailable: https://www .espressif.com/sites/def ault/les/documentation/esp32-s3 datasheet en.pdf. [17] G. Bianchi, “Performance analysis of the IEEE 802.11 distrib uted coordination function, ” in IEEE J ournal on Selected Ar eas in Communications , v ol. 18, no. 3, pp. 535-547, Mar . 2000, doi: 10.1109/49.840210. [18] “I EEE Standard for Information T echnology–T elecommunications and Information Exchange between Systems - Local and Metropolitan Area Netw orks–Specic Requirements - P art 11: W ireless LAN Medium Acce ss Control (MA C) and Ph ysi- cal Layer (PHY) Specications, ” in IEEE Std 802.11-2020 (Re vision of IEEE Std 802.11-2016) , pp.1-4379, Feb . 2021, doi: 10.1109/IEEESTD.2021.9363693. [19] F . Montori, L. Bedogni and L. Bononi, “ A Collaborati v e Internet of Things Architecture for Smart Cities and En vironmental Moni- toring, ” in IEEE Internet of Things J ournal , v ol. 5, no. 2, pp. 592-605, Apr . 2018, doi: 10.1109/JIO T .2017.2720855. [20] A. Dunk e ls, “Design and implementation of the l wIP TCP/IP stack, ” Swedish Institute of Computer Science , v ol. 2, no. 277, 2001. [21] Es pressif Systems, “ESP-IDF l wIP documentation, ” 2023. [Online]. A v ailable: ht tps://docs.espressif.com/projects/esp- idf/en/latest/esp32s3/api-guides/l wip.html. [22] P . K. Gk onis, P . T . T rakadas, and D. I. Kaklamani, “ A comprehensi v e study on simulation techniques for 5G netw orks, ” Electr onics , v ol. 9, no. 3, p. 468, 2020, doi: 10.3390/electronics9030468. [23] C . Perera, A. Zasla vsk y , P . Christen and D. Geor g ak opoulos, “Conte xt A w are Computing for The Internet of Things: A Surv e y , ” in IEEE Communications Surve ys & T utorials , v ol. 16, no. 1, pp. 414-454, 2014, doi: 10.1109/SUR V .2013.042313.00197. [24] P . Gupta and P . R. K umar , “The capacity of wireless netw orks, ” IEEE T r ansactions on Information Theory , v ol. 46, no. 2, pp. 388-404, Mar . 2000, doi: 10.1109/18.825799. Int J Recongurable & Embedded Syst, V ol. 15, No. 3, No v ember 2026: 837–847 Evaluation Warning : The document was created with Spire.PDF for Python.