Energy-Aware System-Level Evaluation of Post-Quantum TLS on Embedded User Equipment over a Disaggregated 5G Network
arXiv:2607.03988v1 [cs.CR] 4 Jul 2026
Sanzida Hoque, Abdullah Aydeger Florida Institute of Technology, Melbourne, FL, USA, 32901 Emails: [email protected], [email protected]
Abstract—The transition to quantum-resistant security is a critical priority for the next generation of mobile networks, particularly within the disaggregated architecture of 5G. This paper presents an energy-aware system-level evaluation of PostQuantum Cryptography (PQC) integrated into the Transport Layer Security (TLS) handshake on embedded User Equipment (UE). Using Raspberry Pi 5s as representative embedded processing platforms, we evaluate the performance of NIST-standardized combinations of classical and post-quantum signature and key exchange mechanisms (KEM), incorporating direct on-device power measurements to estimate per-handshake energy consumption. Results experimentally validate a strong coupling between latency and energy consumption, indicating that execution time is the dominant contributor to energy cost. Hash-based signature schemes incur up to 4x higher latency and 2x energy compared to lattice-based alternatives, while the impact of KEMs is comparatively smaller. The analysis further reveals that overall system performance is primarily constrained by cryptographic computation and concurrency-induced contention rather than network transport effects. These findings provide practical guidance for PQC deployment in mobile environments and demonstrate that lattice-based signatures offer a more favorable balance between security, efficiency, and scalability for 5G systems. Index Terms—Post-quantum cryptography, TLS, 5G, user equipment, performance evaluation, testbed, energy efficiency, latency, embedded systems
I. I NTRODUCTION The emergence of quantum computing poses a fundamental threat to widely deployed public-key cryptographic systems, including Rivest–Shamir–Adleman (RSA) and elliptic curve cryptography (ECC). These schemes form the foundation of secure communication protocols such as Transport Layer Security (TLS), which are extensively used in modern cellular networks [1]. In 5G systems, secure communication between user equipment (UE), the radio access network, and the core infrastructure is essential for ensuring data confidentiality and integrity. Consequently, the transition to post-quantum cryptography (PQC) has become a critical requirement for futureproofing mobile communication systems [2]. Recent standardization efforts by the National Institute of Standards and Technology (NIST) [3], [4] have identified several promising PQC algorithms, including lattice-based and hash-based schemes. While these algorithms provide resistance against quantum adversaries, they introduce additional computational complexity compared to classical approaches,
this raises concerns regarding their deployment in resourceconstrained environments such as mobile devices, where latency, energy efficiency, and processing capability are tightly constrained. Existing research on PQC performance has largely focused on isolated cryptographic benchmarks or protocol-level evaluations in controlled environments. While valuable, these studies often overlook system-level interactions in real-world deployments, including network stacks, protocol implementations, and device-level power consumption. In 5G, where strict performance and energy requirements must be met, these factors are crucial to assessing the practical feasibility of PQC adoption. To address this gap, this paper presents a system-level evaluation of PQC-enabled TLS handshakes on an end-to-end 5G testbed integrating embedded UE devices, an emulated NGRAN, and a standards-compliant 5G core. This setup enables end-to-end experimentation under controlled yet representative conditions. Furthermore, the use of onboard power monitoring allows direct observation of UE-side energy consumption during cryptographic operations, providing insights that are not captured by conventional benchmarking approaches. The main contributions of this work are as follows: We conduct a system-level evaluation of classical and postquantum TLS handshakes on an end-to-end 5G testbed, using embedded UE integrated with disaggregated radio access and core network components. • We employ on-device Power Management Integrated Circuit (PMIC) measurements to approximate UE-side power and energy consumption, enabling practical and reproducible evaluation without external instrumentation. • We analyze the relationship between latency and energy consumption, showing that execution time is a primary contributor to energy cost in PQC-enabled TLS. • We examine the impact of cryptographic primitives on system performance, observing that signature algorithms contribute the majority of latency and energy overhead, with hash-based schemes incurring higher cost than latticebased alternatives. • We provide a concurrency-driven evaluation of postquantum TLS, quantifying how increasing numbers of client UEs impact energy consumption, system stress, •
© 2026 IEEE. Accepted for publication in the Proceedings of IEEE LCN 2026. The final version will appear in IEEE Xplore.
and stability on edge-class hardware, identifying distinct performance trends and the onset of saturation at high load. • We assess the relative contributions of computation and networking to end-to-end performance, showing that cryptographic processing dominates under the evaluated conditions. The remainder of this paper is organized as follows. Section II reviews related work. Section III describes the architecture and design of the system. Section IV presents experimental methodology, the results, and discussion. Finally, Section V concludes the paper and outlines future research directions. II. R ELATED W ORK The transition toward PQC has been accelerated by recent standardization activities. In 2024, NIST finalized the first set of post-quantum cryptographic standards, including the ModuleLattice-Based Key-Encapsulation Mechanism (ML-KEM, FIPS 203 [5]), Module-Lattice-Based Digital Signature Algorithm (ML-DSA, FIPS 204 [6]), and Stateless Hash-Based Digital Signature Algorithm (SLH-DSA, FIPS 205 [7]) for quantumresistant key establishment and digital signatures. This standardization has motivated extensive research on integrating PQC into transport protocols, particularly TLS 1.3, where cryptographic primitives directly impact handshake latency, message size, and deployment compatibility. PQC Integration in TLS Protocols. A growing body of work evaluates PQC within transport-layer protocols. Recent studies show that ML-KEM-based TLS introduces moderate overhead, primarily due to increased key sizes and message payloads rather than computational complexity [8]. Other work demonstrates that hardware-aware optimizations can significantly improve PQC-TLS handshake performance [9]. Prior work has evaluated PQC-enabled TLS in constrained IoT settings, including embedded-device energy consumption [10] and TLS tunneling [11]. Kampanakis et al. [12] further show that PQC handshake overhead has limited end-to-end impact in stable, high-bandwidth networks as application data increases. However, these studies remain largely protocol-level or controlled-environment evaluations and do not assess PQC-TLS in realistic 5G deployments, where protocol overhead, network behavior, device performance, and energy consumption interact. PQC Tooling and Industry Deployment. To support such experimentation, the Open Quantum Safe ecosystem has emerged as a widely adopted platform for PQC prototyping. The liboqs library enables integration of PQC algorithms into TLS stacks such as OpenSSL, wolfSSL, and BoringSSL. Industry deployments further demonstrate the practical relevance of PQCenabled TLS. For example, Google has introduced hybrid postquantum KEM in Chrome [13], while Cloudflare reports that a significant portion of Internet traffic is already protected using post-quantum key agreement [14]. These efforts highlight the rapid transition toward PQC in real-world systems, particularly for mitigating “harvest-now, decrypt-later” threats. Similarly, industry analyses, including those by Akamai and others, highlight practical challenges in integrating hybrid PQC into TLS,
such as increased handshake sizes, compatibility constraints, and client-server interoperability issues [15]. While these efforts provide valuable insights into deployment feasibility at Internet scale, they primarily focus on compatibility and protocol behavior, and do not address device-level energy characteristics or system-level evaluation in mobile network environments. PQC on Embedded and Edge Platforms. Another line of work investigates PQC performance on embedded and edge platforms. Patterson et al. [16] propose an energy measurement framework for PQC key generation on Raspberry Pi devices, demonstrating that PQC schemes can be competitive with classical cryptography under certain conditions. However, their analysis is limited to isolated cryptographic operations and does not consider end-to-end communication. Similarly, recent studies show that PQC-enabled TLS can be deployed on embedded devices with manageable overhead [17]. Recent benchmarking efforts further evaluate PQC-enabled TLS in embedded and networked environments, focusing on certificate size and handshake latency [18]. Despite these contributions, such evaluations are typically conducted in standalone or conventional network environments and do not capture device-level energy behavior or system-level effects. Liu et al. [19] demonstrate PQC migration on a physical 5G testbed, highlighting challenges such as larger ciphertexts, buffer constraints, and latency overheads in protocols like TLS and SUCI. In contrast, our work focuses on system stress and energy behavior under concurrent client UEs. PQC in 5G and System-Level Studies. More recent work has begun to bridge the gap between protocol-level and systemlevel evaluation. Our prior work [20] demonstrated the feasibility of PQC-enabled TLS in a 5G UE-to-UE communication setting using UERANSIM and Open5GS, focusing on systemlevel metrics such as latency, CPU utilization, and bandwidth overhead. This paper extends that work by shifting the focus to an energy-aware evaluation on resource-constrained Raspberry Pi 5 devices, jointly analyzing power consumption, energy cost, thermal behavior, and concurrency effects. Other studies explore integrating PQC into 5G systems [21], [22], including modifications to core network signaling, demonstrating that PQC can be incorporated into mobile networks with acceptable overhead [23]. Scalise et al. explored integrating PQC key encapsulation mechanisms into 5G core networks, demonstrating minimal impact on latency and bandwidth during VNF-to-VNF communication [24]. However, these works primarily focus on network and protocol performance rather than device-level energy and thermal behavior. In summary, prior work has independently addressed (i) PQC-enabled TLS performance, (ii) embedded PQC execution, and (iii) 5G testbed-based performance evaluation, but these dimensions remain disconnected: protocol-level studies overlook mobile network effects, embedded evaluations omit end-to-end communication, and 5G studies do not characterize device-level power and thermal behavior. This paper bridges these gaps by evaluating PQC-enabled TLS on physical embedded UE over a disaggregated 5G data path, jointly characterizing latency, en-
ergy, instantaneous power, and thermal response across the full set of NIST-standardized PQC KEM and signature schemes. III. S YSTEM A RCHITECTURE AND D ESIGN This work presents a disaggregated PQC-enabled 5G testbed designed to precisely measure the computational, thermal, and energy characteristics of PQC algorithms as illustrated in Fig 1. The system is composed of two tightly integrated domains: (i) a physical hardware layer, where PQC operations are executed on real devices, and (ii) a virtualized 5G network layer, which emulates the Radio Access Network (RAN) and Core Network functions. This separation enables independent control of computation and networking variables by executing PQC operations on dedicated physical hardware while confining network functions to a virtualized environment, thereby eliminating resource contention and scheduler-induced interference between the two domains.
nodes are interconnected via an Ethernet underlay network that provides connectivity to the virtualized environment. B. Virtualized Software Layer The virtualized software layer emulates a disaggregated 5G network. The network functions are deployed in a disaggregated manner, separating control-plane signaling from user-plane data forwarding in accordance with contemporary 5G architectural principles. The virtualized RAN component (gNB) provides the access interface, bridging the physical nodes to the core network. The core network itself is logically divided into: (i) a control plane, responsible for signaling, authentication, and session management, and (ii) a user plane, responsible for forwarding application data. This separation ensures that control signaling does not interfere with user-plane measurements, thereby preserving the integrity of PQC performance evaluation. C. Data Flow and Operation
Physical Hardware Environment UE1 & PQC Client
TP-LINK Omada Router
UE2 & PQC Server
Configured as Central Switch
UERANSIM
PQC Client (BoringSSL)
PMIC (Power)
Power/Temp Logger
LAN Underlay: 192.168.0.x/24
PQC Server (BoringSSL)
UERANSIM
Server Monitor
Physical IP: 192.168.0.10 5G IP: 10.45.0.10
Physical IP: 192.168.0.20 5G IP: 10.45.0.20
Virtualized Software Environment
PQC TLS Handshake Ethernet
Ubuntu 22.04 LTS gNB
Control Plane
User Plane Gateway
Physical IP: 192.168.0.4 Backhaul IP: 192.168.235.4
Backhaul IP: 192.168.235.x
Backhaul IP: 192.168.235.5
UERANSIM
Open5gs
Open5gs
Internals: gNB Services
Internals: AMF, SMF etc.
Internals: UPF, N6 routing
Fig. 1: Disaggregated 5G PQC Testbed Architecture. The reddashed path denotes the logical end-to-end PQC TLS handshake overlay, while the blue solid lines indicate the hardwarelevel Ethernet connections.
A. Physical Hardware Layer The hardware layer comprises two embedded nodes, both implemented on Raspberry Pi 5 devices and each operating as a 5G UE: (i) UE1 acts as the TLS client, initiating PQC-enabled handshakes; (ii) UE2 acts as the TLS server, terminating the handshakes and processing application data. Each node is instrumented to monitor system behavior during execution. Power consumption is obtained from onboard power interfaces, and temperature is collected from integrated sensors. These measurements enable correlation between cryptographic operations and device-level energy and thermal responses. The
The end-to-end communication follows a structured multistage process. The UE client node generates PQC-enabled TLS traffic, which is forwarded to the virtualized access network. The traffic is then encapsulated within a tunneling protocol and transported through the virtualized core network. Upon reaching the user-plane gateway, the packet is decapsulated and forwarded to the destination node in the physical layer. This design ensures that the network path reflects 5G data-path behavior, including GTP-U encapsulation and UPF forwarding, while the cryptographic operations remain fully observable on physical hardware. The radio access is emulated by UERANSIM rather than transmitted over-the-air; this study targets the cryptographic-cost and data-path dimensions, which are independent of PHY/MAC effects. IV. E XPERIMENTAL E VALUATION A. Experimental Setup Experiments are conducted on the testbed described in Section III. Both embedded nodes are implemented on Raspberry Pi 5 with 8GB RAM devices and operate as 5G UEs using UERANSIM. At the application layer, one node acts as a client and the other as a server, executing PQC-enabled TLS sessions using a BoringSSL integrated with the liboqs to support PQC. The virtualized 5G network is deployed using UERANSIM for the access network (gNB) and Open5GS for core network functionality, hosted on a single-core Intel64 system operating at 1.7 GHz via a VMware-based platform. Each experiment consists of repeated TLS session establishments under identical conditions. TP-Link Omada ER605 router serves as the central switching fabric, providing the physical underlay network. The network follows a multi-tier addressing scheme: the LAN Underlay (192.168.0.x) provides the physical interconnect via the Omada switch, the RAN Backhaul (192.168.235.x) facilitates gNB-to-Core communication, and the 5G User Plane (10.45.0.x) encapsulates the PQC handshake. All reported TLS handshakes are exchanged over the UE-assigned 5G user-plane addresses (10.45.0.x), traversing the UERANSIM gNB and
Open5GS UPF path, rather than directly over the physical LAN underlay, and they are averaged across multiple runs to ensure consistency and reliability. Although the host running the virtualized 5G plane is modestly provisioned, the consistently low and stable RTT observed across all concurrency levels (Section IV-C5) confirms that the virtualized network plane is not a measurement bottleneck. B. Metrics and Methodology We evaluate TLS handshake performance across heterogeneous cryptographic suites in a 5G edge deployment. Our methodology captures end-to-end performance, system resource utilization, and network/client-side effects under controlled multi-UE concurrency. 1) Workload and Concurrency Model: We model realistic access scenarios by representing concurrency as multiple client UEs simultaneously initiating TLS handshakes toward a single edge server. This experiment isolates cryptographic processing load from RAN-level multi-UE scheduling effects, allowing the study to focus on the computational and energy cost of PQC under aggregated load. Concurrency C denotes the number of independent BoringSSL client UEs issuing handshake requests in parallel. We evaluate C ∈ {1, 4, 10, 20, 40}, chosen to reflect distinct operating regimes: • C = 1 (Baseline): Single UE, capturing pure cryptographic cost without contention. • C = 4 (Optimal Parallelism): Matches the 4-core architecture of the server CPU, representing ideal hardware utilization. • C = 10 (Contention Onset): Exceeds core count, introducing scheduling overhead and queueing. • C = 20 (Saturation): System operates near maximum processing capacity. • C = 40 (Stress Limit): Extreme load, exposing stability limits and failure behavior. Each UE performs 50 TLS handshake attempts per run. Under high concurrency, some handshake attempts may not complete successfully due to system overload. We therefore distinguish between (i) attempted handshakes, defined as the total requests issued by all UEs, and (ii) completed handshakes, defined as the successfully processed connections at the server. All performance metrics (latency, throughput, and energy per connection) are computed using only completed handshakes, ensuring consistent comparison across configurations. Throughout this paper, power and energy are used with distinct meanings: power refers to instantaneous system load, whereas energy represents consumption over a given duration and reflects the cost of completing a TLS handshake. 2) End-to-End Performance Metrics: These metrics capture the user-perceived performance of TLS handshakes under concurrent UE load. Latency (ms): Measured at the client UE as the elapsed time between handshake initiation and successful completion. Application-layer timestamps are used to ensure end-to-end
coverage. Same time-stamping procedure is used for all configurations to ensure fair comparison. Reported values are averaged across completed handshakes. Throughput (KB/s): Measured at the server as the total volume of handshake-related data processed per second. This includes key exchange messages, certificates, and signature payloads, which vary significantly across cryptographic schemes. Energy per Connection (mJ/conn): Derived from serverside power measurements. Average power over the experiment duration is used to estimate total energy consumption, which is then normalized by the number of completed handshakes. 3) Server-Side Resource Metrics: These metrics quantify computational load, energy consumption, and thermal behavior of the edge server. CPU Utilization (%): Measured as average CPU usage across all cores during the experiment. This reflects the computational demand imposed by concurrent cryptographic operations and system overhead. Server Average Power (mW): Computed from PMIC telemetry by averaging power readings over the experiment duration. This captures steady-state energy consumption under load. Server Peak Temperature (◦ C): Maximum observed CPU temperature during execution. This metric is used to verify whether the system approaches thermal throttling limits. 4) Network and Client-Side Metrics: These metrics capture network stability and client-side computational impact, enabling separation of communication and processing bottlenecks. Retransmissions: Measured using TCP statistics at the server. This metric indicates packet loss or delays caused by congestion or processing bottlenecks. Round-Trip Time (RTT, ms): Measured at the transport layer. Across all experiments, RTT remains nearly constant, indicating stable network conditions and confirming that performance degradation is not network-induced. Client Peak Power (mW): Maximum instantaneous power observed at the UE during handshake execution. This captures burst computational demand associated with cryptographic operations. 5) Measurement Limitations and Validity: While the proposed measurement framework provides comprehensive visibility into system behavior, several limitations should be noted. Power measurements are obtained via the onboard PMIC, which reports estimated voltage and current values. As a result, absolute power may incur an error margin of approximately ±510%, and short-lived transient spikes may not be fully captured due to the sampling interval (100 ms). Similarly, client-side peak power relies on device-level telemetry, which may smooth high-frequency variations. CPU utilization and latency measurements are subject to operating system scheduling and timer resolution [25], introducing minor variability (typically within 1-2 ms), particularly at low concurrency levels. Retransmission statistics are derived from transport-layer counters and do not explicitly separate network losses from processing-induced delays. However, the consistently low and stable RTT across all experiments indicates that retransmissions
TABLE I: End-to-End Performance Across Concurrency Levels (Client-Observed Latency, Server-Observed Throughput, and Energy) Latency (ms)
Throughput (KB/s)
Energy (mJ/conn)
Category
Configuration
C1
C4
C10
C20
C40
C1
C4
C10
C20
C40
C1
C4
C10
C20
C40
Class
P-256 + SLH-DSA X25519 + SLH-DSA ML-KEM + SLH-DSA HQC + SLH-DSA
202 199 194 203
506 470 459 481
1277 1202 1201 1262
2355 2404 2362 2524
4733 4800 4750 4500
225 226 233 264
376 420 448 495
399 432 452 476
447 446 462 495
446 445 462 504
213 215 233 250
238 219 225 200
200 208 200 207
200 219 217 198
200 199 203 336
High Cost High Cost High Cost Worst Case
P-256 + Falcon X25519 + Falcon ML-KEM + Falcon HQC + Falcon
107 111 104 139
118 133 120 208
306 370 312 546
632 756 636 1105
1282 1550 1274 2260
39 39 52 88
148 135 348 242
160 135 212 263
157 143 218 296
168 143 223 288
188 188 143 197
139 148 126 155
151 139 142 145
142 147 141 157
144 139 140 142
Efficient Moderate Best Hybrid Heavy
ML-KEM + ML-DSA HQC + ML-DSA P-256 + ML-DSA X25519 + ML-DSA
108 137 109 115
118 205 122 142
315 552 322 385
648 1104 671 795
1325 2180 1345 1600
94 119 81 80
347 351 291 260
366 353 308 266
374 377 316 268
389 416 316 272
180 194 223 131
126 160 151 139
145 150 140 139
145 146 139 143
140 148 140 146
Balanced Heavy Efficient Moderate
P-256 + P-256 X25519 + P-256 ML-KEM + P-256 HQC + P-256
106 110 106 135
120 132 120 207
306 363 305 549
626 743 629 1111
1260 1527 1265 2250
18 18 32 76
68 63 116 194
75 66 130 205
78 75 138 238
88 79 151 262
176 177 151 194
133 149 146 144
141 141 140 149
145 132 139 144
139 139 141 152
Baseline Moderate Efficient Hybrid Heavy
ML-KEM denotes ML-KEM-512; ML-DSA denotes ML-DSA-44; Falcon (aka FN-DSA) denotes Falcon512; SLH-DSA denotes SPHINCS+ SHA2128f-simple. Concurrency levels (C1-C40) indicate the number of simultaneous client UEs.
TABLE II: System Resource Utilization Across Concurrency Levels (CPU Utilization, Server Power Consumption, and Temperature) CPU (%)
Server Avg Power (mW)
Server Peak Temp (°C)
Configuration
C1
C4
C10
C20
C40
C1
C4
C10
C20
C40
C1
C4
C10
C20
C40
P-256 + SLH-DSA X25519 + SLH-DSA ML-KEM + SLH-DSA HQC + SLH-DSA
6 5 8 11
6 18 7 22
21 24 22 22
31 34 22 31
36 35 33 35
1245 1257 1375 1510
1308 1855 1306 1828
1846 1991 1912 1845
2292 2484 1972 2193
2464 2194 2344 2424
62 62 63 62
66 65 65 65
67 68 67 68
69 69 68 69
69 70 69 69
P-256 + Falcon X25519 + Falcon ML-KEM + Falcon HQC + Falcon
0.3 0.7 0.4 1.5
0.9 1.6 1.1 3.2
1.1 2.3 1.1 5.3
1.5 2.3 1.1 5.3
1.5 3.1 1.3 7.0
1284 1320 1366 1343
1809 1657 1896 1692
1984 1958 2206 2097
2393 1972 2249 2177
2376 2274 2430 2482
61 60 62 60
64 64 66 65
67 68 67 68
68 68 68 69
68 69 68 70
ML-KEM + ML-DSA HQC + ML-DSA P-256 + ML-DSA X25519 + ML-DSA
0.2 1.1 0.4 0.9
1.1 3.8 1.3 2.3
1.5 6.5 1.3 2.4
1.3 7.2 1.5 3.7
1.5 7.6 1.0 3.7
1223 1207 1338 1241
1897 1793 1962 1830
2297 2335 1984 1887
2156 2465 2094 2446
2331 2545 1714 2450
60 60 60 61
66 66 64 65
68 68 67 67
68 69 68 68
68 69 68 68
P-256 + P-256 X25519 + P-256 ML-KEM + P-256 HQC + P-256
0.2 0.7 0.2 1.4
0.5 1.9 0.7 4.9
0.7 2.6 0.9 5.4
0.8 2.8 0.9 6.8
1.2 3.1 1.0 6.0
1336 1329 1242 1332
1703 1851 1959 1969
1879 2162 2228 2172
1967 2262 2192 2517
2440 2442 2349 2295
61 60 61 60
65 65 65 66
67 67 67 67
69 68 69 69
68 69 68 69
CPU: green < 2%, yellow 2-10%, red >10%. Power: green <1500 mW, yellow 1500-2200 mW, red >2200 mW. Temperature not color-coded (all within safe operating range).
are primarily driven by computational contention rather than network impairments. Finally, experiments are conducted in a controlled testbed with stable networking conditions and active cooling. While this ensures reproducibility, it does not capture all environmental variability present in real deployments. Despite these limitations, the results remain robust. All experiments are repeated twice under identical conditions with consistent trends across runs. Our objective is comparative evaluation across cryptographic algorithms executed on identical hardware under identical conditions. Therefore, relative differences are more important than absolute values. The observed differences across cryptographic configurations, often exceeding 2×, significantly outweigh measurement uncertainty.
Additionally, thermal measurements confirm operation below throttling thresholds, ensuring that performance degradation reflects system-level and computational effects rather than hardware constraints. C. Results Analysis This section presents a detailed analysis of system behavior under increasing concurrency, focusing on latency, energy consumption, computational load, network behavior, and hardware characteristics. Results are derived from Tables I, II, and III. Across these results, three trends dominate. First, signature choice has a stronger effect on latency, energy, CPU utilization, and retransmissions than KEM choice. Second, ML-KEM paired with Falcon or ML-DSA remains close to classical
TABLE III: Network Stability and Client-Side Impact (Retransmission, Round Trip Time, Client UE Power Draw) Retransmissions
RTT (ms)
UE Peak Power (mW)
Configuration
C1
C4
C10
C20
C40
C1
C4
C10
C20
C40
C1
C4
C10
C20
C40
P-256 + SLH-DSA X25519 + SLH-DSA ML-KEM + SLH-DSA HQC + SLH-DSA
0 1 0 0
4 1 0 2
2 0 2 12
0 0 1 26
1 2 1 7
4.7 4.7 4.6 5.4
5.3 4.8 4.8 5.5
5.3 4.8 4.9 5.6
4.9 4.8 4.9 5.6
4.9 4.9 4.9 5.7
2775 3774 3195 3305
5172 5524 3188 3625
5328 6200 5329 6041
6717 5599 7785 6066
8026 7534 7851 6429
P-256 + Falcon X25519 + Falcon ML-KEM + Falcon HQC + Falcon
0 0 0 0
0 4 1 1
4 14 3 4
4 26 6 12
20 54 15 22
13.3 12.8 11.4 10.8
13.9 13.8 8.9 13.1
15.9 16.0 14.6 13.1
15.9 16.0 14.4 13.2
15.7 15.9 14.1 13.2
4329 2962 4943 3403
3406 4633 3186 5452
6529 3432 3336 8258
3473 5175 5653 4349
7753 5672 6853 4379
ML-KEM + ML-DSA HQC + ML-DSA P-256 + ML-DSA X25519 + ML-DSA
0 3 0 0
1 0 2 4
4 4 1 7
6 9 13 24
17 28 30 51
8.6 8.6 9.4 9.0
8.9 10.6 10.0 9.8
10.4 10.8 11.7 11.7
10.7 10.6 11.7 11.6
10.7 10.6 11.6 11.6
2681 3403 2726 2726
3185 3678 3233 3117
4190 4237 5233 3510
3357 4201 3444 3481
5552 6276 4754 3618
P-256 + P-256 X25519 + P-256 ML-KEM + P-256 HQC + P-256
0 0 0 0
1 1 0 1
2 4 4 6
2 4 11 26
12 20 22 35
15.6 14.9 13.2 12.9
16.7 16.5 14.2 15.5
18.3 18.7 16.1 15.5
18.3 18.7 16.0 15.6
17.9 18.4 15.7 15.6
2884 5434 2617 4804
3536 3186 3154 3811
3310 5613 5264 4254
5335 3534 4947 4213
3557 5200 3618 6926
Retransmissions: green = 0, yellow = 1-5, red = >5. UE peak power: green <3500 mW, yellow 3500-6000 mW, red >6000 mW. RTT not color-coded due to negligible variation.
multi-core utilization and a more even distribution of fixed system overhead across concurrent handshakes. Beyond this point, energy remains largely stable across most configurations, with increases at C = 40 indicating contention and system saturation. Energy consumption is strongly correlated with latency, as higher-latency configurations incur greater total energy due to longer execution time. Fig. 2 illustrates this relationship, where SLH-DSA-based configurations form a distinct high-latency, high-energy cluster, while Falcon and ML-DSA-based schemes remain closer to classical performance. Signature SLH-DSA Falcon ML-DSA Classical
325 300 Energy per Connection (mJ)
performance across the evaluated concurrency range. Third, SLH-DSA pushes the system toward saturation at high concurrency, increasing latency and CPU utilization while reducing completed handshakes in the worst case. 1) Latency Scaling with Concurrency: Latency increases with concurrency across all evaluated configurations, with distinct scaling behavior depending on the cryptographic primitives. SLH-DSA-based configurations exhibit the steepest increase, rising from approximately 195-205 ms at C = 1 to 4700-4800 ms at C = 40, corresponding to more than a 20× increase. In contrast, lattice-based configurations demonstrate significantly more moderate scaling. For example, ML-KEM + Falcon increases from approximately 104 ms at C = 1 to 12701300 ms at C = 40, while ML-DSA-based configurations remain within approximately 110-1600 ms across the same range. Classical configurations (P-256 and X25519) exhibit similar scaling, reaching approximately 1200-1500 ms at C = 40. Latency growth is approximately linear up to moderate concurrency (C ≤ 20), after which deviations appear for computationally intensive schemes, particularly SLH-DSA, where latency increases more sharply. 2) Energy Consumption Characteristics: Energy consumption per connection remains relatively stable at low and moderate concurrency but diverges across cryptographic schemes under higher load. SLH-DSA-based configurations typically consume around 200-230 mJ per connection at moderate concurrency, increasing to over 320 mJ in the worst-case configuration (HQC + SLH-DSA at C = 40). In contrast, Falcon and ML-DSA-based configurations maintain lower and more stable energy consumption, generally within 135-155 mJ per connection across all concurrency levels, closely matching classical configurations. A reduction in per-connection energy is observed as concurrency increases from C = 1 to C = 4, reflecting improved
KEM P256 X25519 ML-KEM HQC
275 250 225 200 175 Load C=1 C=40
150 125
0
1000
2000 3000 Latency (ms)
4000
Fig. 2: Latency-energy relationship for classical and postquantum TLS configurations at low (C = 1) and high (C = 40) concurrency. Marker shape represents the signature schemes, and color denotes the KEMs. 3) Computational Load and Resource Utilization: CPU utilization varies significantly across configurations. SLH-DSA-
based configurations exhibit the highest CPU utilization, exceeding 30% at high concurrency (e.g., approximately 36% at C = 40), while Falcon and ML-DSA-based configurations remain below 2-3%. Memory usage was monitored throughout all experiments and remained stable and well within available capacity (e.g., within approximately 5.8-6.2 MB) across every configuration and concurrency level, confirming that observed performance differences are not memory-bound. Detailed memory traces are omitted from the tables for brevity. CPU values are averaged over the full experiment interval across all cores; short cryptographic bursts can therefore produce low average percentages even when they dominate per-handshake latency. 4) Throughput Behavior and Saturation: Throughput increases with concurrency up to a saturation point. For example, throughput increases from approximately 200-250 KB/s at C = 1 to approximately 440-460 KB/s at C = 20 for SLH-DSA-based configurations. Beyond C = 20, throughput plateaus, with minimal improvement at C = 40. This indicates that the system reaches its maximum cryptographic processing capacity at moderate concurrency levels. 5) Network Behavior and Stability: Network-related metrics remain stable across all configurations. RTT varies from approximately 4.7 ms to 18.0 ms across all concurrency levels, with no dependence on the cryptographic scheme. The significant disparity between handshake latency and RTT indicates a shift in the dominant performance bottleneck. While RTT remains stable across all concurrency levels, latency increases with both the complexity of the cryptographic primitives and the number of concurrent client UEs. This suggests that the primary constraint in post-quantum TLS is computational processing rather than network transmission overhead, with systemlevel contention under concurrency further amplifying the effect. Retransmissions remain negligible at low concurrency and increase under high load, indicating increasing processing delays rather than network instability. 6) Concurrency-Induced Stress and System Degradation: As concurrency increases, retransmissions rise across most configurations, as shown in Fig. 3. For example, X25519 + Falcon increases from 0 retransmissions at C = 1 to over 50 at C = 40, while ML-DSA-based configurations exhibit similar monotonic growth. SLH-DSA-based configurations show irregular behavior at high load. In particular, HQC + SLH-DSA increases to approximately 26 retransmissions at C = 20, followed by a decrease to below 10 at C = 40. This reduction corresponds to incomplete handshake execution (approximately 1315 out of 2000), indicating reduced processing capacity rather than improved performance. Fewer packets are transmitted, leading to fewer retransmissions. This behavior reflects a transition from a congestion regime to a saturation regime, where it is unable to sustain the requested workload. 7) Power Characteristics: Server peak power remains within approximately 3.5-5 W across all configurations. Client peak power is significantly higher, reaching up to 7.5-8 W under high concurrency. These peaks are transient and correspond to bursts of cryptographic processing and network activity.
8) Thermal Behavior: Server temperature increases from approximately 60-62◦ C at C = 1 to 68-70◦ C at high concurrency, remaining below the 80◦ C throttling threshold. A thermal plateau is observed beyond C ≥ 20, indicating steadystate operation. Client temperature remains approximately 57◦ C lower than server temperature. 9) Operating Regimes: Three operating regimes are observed: (i) Low concurrency (C ≤ 4): low latency (< 120 ms), minimal retransmissions, low energy consumption (e.g., ∼100 ms for ML-KEM + Falcon). (ii) Moderate concurrency (10 ≤ C ≤ 20): latency increases (300-700 ms for efficient schemes such as ML-DSA-based configurations), retransmissions rise, throughput approaches maximum. (iii) High concurrency (C = 40): latency peaks (up to ∼4800 ms for SLH-DSA), throughput saturates, and incomplete handshake execution occurs. D. Design Implications 1) Computational Bottleneck and Network Decoupling: The results reveal a clear decoupling between network performance and application-level performance. Despite stable RTT and minimal packet loss, latency increases significantly with concurrency, indicating that system performance is dominated by computational overhead rather than network limitations. From a design perspective, optimizing network infrastructure alone is insufficient to improve end-to-end performance for postquantum TLS. Instead, system design must prioritize computational efficiency at the cryptographic layer. 2) The Computational Wall of Hash-Based Signatures: SLH-DSA configurations exhibit a sharp increase in latency under concurrency, reaching multi-second delays. This reflects the computational intensity of hash-based signature schemes, where repeated hash operations dominate execution time. The observed saturation behavior indicates the presence of a computational limit beyond which additional concurrency does not improve throughput but instead increases delay. This suggests that hash-based signatures are not suitable for high-concurrency environments without hardware acceleration or workload offloading. 3) Energy-Latency Coupling: Energy consumption closely follows latency trends, demonstrating that execution time is the dominant factor in energy cost. Although instantaneous power remains bounded, prolonged execution results in higher total energy consumption. This implies that reducing latency is directly aligned with improving energy efficiency. System designers should therefore prioritize algorithms and implementations that minimize execution time rather than focusing solely on reducing peak power. 4) Power and Thermal Asymmetry: A notable asymmetry exists between client and server behavior. The client experiences higher peak power due to burst-driven cryptographic operations, while the server exhibits sustained thermal load due to continuous processing. The observed thermal plateau indicates that the system operates near a steady-state thermal limit. This suggests that sustained PQC workloads require careful thermal and power provisioning, particularly for continuously operating server nodes.
Retransmissions
P-256
X25519
ML-KEM
HQC
SLH-DSA
Falcon
ML-DSA
P-256
40
20
Retransmissions
0
40
20
0 1 4
10 20 Concurrent client UEs
40
1 4
10 20 Concurrent client UEs
40
Fig. 3: Retransmissions versus concurrent client UEs across signature schemes and KEMs. Each subplot shows a signature scheme, with lines denoting KEMs. Retransmissions increase with concurrency, indicating growing delays. The drop for HQC + SLH-DSA reflects saturation, where fewer retransmissions result from incomplete handshakes rather than improved performance. 5) Throughput Saturation and System Capacity: Throughput saturation at moderate concurrency levels indicates a hard upper bound on system capacity. Beyond this point, additional concurrency increases latency and retransmissions without improving throughput. This behavior implies that system scalability is constrained by cryptographic processing capacity. Effective system design must therefore consider concurrency limits and implement mechanisms such as load balancing or admission control to maintain performance. 6) Implications for PQC Algorithm Selection: Cryptographic design has a direct impact on system feasibility. Hashbased signatures introduce substantial computational and energy overhead, while lattice-based schemes achieve significantly better performance characteristics. This indicates that algorithm selection is a critical design decision. For resourceconstrained platforms, computationally efficient PQC schemes are essential to achieve acceptable performance and energy efficiency. 7) Suitability for 5G Applications: The evaluated configurations highlight limitations for latency-sensitive applications. Computationally intensive PQC schemes introduce substantial delays even under low concurrency, with latency increasing significantly under load. This suggests that such schemes are not suitable for applications with strict latency requirements unless supported by hardware acceleration or architectural optimizations. 8) System-Level Implications: Overall, the results demonstrate that: (i) system performance is CPU-bound rather than network-bound, (ii) energy consumption is primarily determined by execution time, (iii) throughput is limited by cryptographic processing capacity, and (iv) hardware constraints sig-
nificantly influence PQC deployment. These findings emphasize the need for co-design between cryptographic algorithms and system architecture to enable efficient and scalable deployment of post-quantum secure communication systems. V. C ONCLUSION AND F UTURE W ORK This paper presented a system-level evaluation of classical and post-quantum TLS handshakes between embedded UEclass nodes over a disaggregated UERANSIM/Open5GS 5G user-plane path. The results show that performance is primarily limited by cryptographic computation and concurrency-induced contention rather than network transport effects. Signature choice is a key factor: hash-based signatures impose substantial computational and energy overhead, reducing scalability under load, while lattice-based schemes maintain more stable performance and energy behavior. As concurrency increases, the system progresses from efficient execution to congestion and saturation, where capacity is bounded by computational throughput. These findings highlight the need to select postquantum primitives that align with the constraints of resourcelimited 5G platforms. Future work will explore hardware acceleration, broader device and deployment evaluations, protocol-level cost analysis, dynamic network conditions, over-the-air radio effects, and external shunt-based or dedicated power-analyzer measurements. ACKNOWLEDGMENT This work was supported in part by the National Science Foundation under CAREER Award No. 2542642 and Grant No. 2552681.
R EFERENCES [1] J. K. Lastre, Y. Ko, H. Kwon, and I. You, “Evaluating transport layer security 1.3 optimization strategies for 5g cross-border roaming: A comprehensive security and performance analysis,” Sensors, vol. 25, no. 19, p. 6144, 2025. [2] S. Hoque, A. Aydeger, and E. Zeydan, “Exploring post quantum cryptography with quantum key distribution for sustainable mobile network architecture design,” in Proceedings of the 4th workshop on performance and energy efficiency in concurrent and distributed systems, pp. 9–16, 2024. [3] National Institute of Standards and Technology, “Post-quantum cryptography.” https://csrc.nist.gov/projects/post-quantum-cryptography, 2024. [4] G. Alagic, M. Bros, P. Ciadoux, D. Cooper, Q. Dang, T. Dang, J. Kelsey, J. Lichtinger, Y.-K. Liu, C. Miller, D. Moody, R. Peralta, R. Perlner, A. Robinson, H. Silberg, D. Smith-Tone, and N. Waller, “Status report on the fourth round of the nist post-quantum cryptography standardization process,” Tech. Rep. NIST IR 8545, National Institute of Standards and Technology (NIST), March 2025. [5] National Institute of Standards and Technology, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” Federal Information Processing Standard FIPS 203, National Institute of Standards and Technology, Aug. 2024. Planning note (Nov. 17, 2025): future revision anticipated; see errata documentation. [6] National Institute of Standards and Technology, “Module-Lattice-Based Digital Signature Standard,” Federal Information Processing Standard FIPS 204, National Institute of Standards and Technology, Aug. 2024. Published August 13, 2024; planning note indicates minor errata to be addressed in a future revision. [7] National Institute of Standards and Technology, “Stateless Hash-Based Digital Signature Standard,” Federal Information Processing Standard FIPS 205, National Institute of Standards and Technology, Aug. 2024. Published August 13, 2024. [8] J. A. Montenegro, R. Rios, and J. Bonilla, “Comparative analysis of postquantum handshake performance in quic and tls protocols,” Computer Networks, p. 111957, 2025. [9] J. Zheng, H. Zhu, Y. Dong, Z. Song, Z. Zhang, Y. Yang, and Y. Zhao, “Faster post-quantum tls 1.3 based on ml-kem: Implementation and assessment,” in European Symposium on Research in Computer Security, pp. 123–143, Springer, 2024. [10] G. Tasopoulos, C. Dimopoulos, A. P. Fournaris, R. K. Zhao, A. Sakzad, and R. Steinfeld, “Energy consumption evaluation of post-quantum tls 1.3 for resource-constrained embedded devices,” in Proceedings of the 20th ACM International Conference on Computing Frontiers, pp. 366–374, 2023.
[11] J. Barton, W. J. Buchanan, N. Pitropakis, S. Sayeed, and W. Abramson, “Post quantum cryptography analysis of tls tunneling on a constrained device.,” in ICISSP, pp. 551–561, 2022. [12] P. Kampanakis and W. Childs-Klein, “The impact of data-heavy, postquantum tls 1.3 on the time-to-last-byte of real-world connections,” Cryptology ePrint Archive, 2024. [13] Google Chromium Team, “Protecting chrome traffic with hybrid kyber kem,” 2023. https://blog.chromium.org/2023/08/protecting-chrometraffic-with-hybrid.html. [14] B. Westerbaan, “State of the post-quantum internet in 2025,” 2025. Online; accessed 26-Apr-2026. [15] J. Schaumann, “Post-quantum cryptography implementation considerations in tls,” August 2025. Accessed: 2026-04-25. [16] J. C. Patterson, W. J. Buchanan, and C. Turino, “Energy consumption framework and analysis of post-quantum key-generation on embedded devices,” Journal of Cybersecurity and Privacy, vol. 5, no. 3, p. 42, 2025. [17] C. İnce, “Hybrid ml-kem in tls 1.3: Performance analysis on arm64 under network stress,” Computer Science, no. 2026, 2026. [18] M. Sim, G. Song, S. Eum, M. Lee, S. Yoon, A. Baksi, and H. Seo, “Integrating and benchmarking kpqc in tls/x. 509,” Electronics, vol. 14, no. 18, p. 3717, 2025. [19] D. Liu, S. I. Jang, N. Sultan, S. Lai, S. C.-K. Chau, J. Chan, and H. Suzuki, “Post-quantum cryptography migration of a physical 5g testbed,” in Proceedings of the 2025 1st Workshop on Quantum-Resistant Cryptography and Security, pp. 63–72, 2025. [20] S. Hoque, A. Aydeger, E. Zeydan, and M. Liyanage, “Analysis of postquantum cryptography in user equipment in 5g and beyond,” in 2025 IEEE 50th Conference on Local Computer Networks (LCN), pp. 1–9, IEEE, 2025. [21] S. Hoque, A. Aydeger, J. Baranda, E. Zeydan, and F. Wilhelmi, “Postquantum cryptography integration into the future mobile core: A servicebased architecture perspective,” IEEE Network, 2026. [22] S. Hoque, A. Aydeger, and E. Zeydan, “Post-quantum secure ue-to-ue communications,” in 2024 15th International Conference on Network of the Future (NoF), pp. 28–30, IEEE, 2024. [23] R. A. Faval, R. Moreira, and F. d. O. Silva, “Empowering mobile networks security resilience by using post-quantum cryptography,” arXiv preprint arXiv:2603.28626, 2026. [24] P. Scalise, R. Garcia, M. Boeding, M. Hempel, and H. Sharif, “An applied analysis of securing 5g/6g core networks with post-quantum key encapsulation methods,” Electronics, vol. 13, no. 21, p. 4258, 2024. [25] Y. Etsion, D. Tsafrir, and D. G. Feitelson, “Effects of clock resolution on the scheduling of interactive and soft real-time processes,” in Proceedings of the 2003 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, pp. 172–183, 2003.