1 Introduction↩︎

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 future-proofing 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 resource-constrained 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 NG-RAN, 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 post-quantum 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 lattice-based alternatives.

• We provide a concurrency-driven evaluation of post-quantum TLS, quantifying how increasing numbers of client UEs impact energy consumption, system stress, 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 2 reviews related work. Section 3 describes the architecture and design of the system. Section 4 presents experimental methodology, the results, and discussion. Finally, Section 5 concludes the paper and outlines future research directions.

2 Related Work↩︎

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 Module-Lattice-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 quantum-resistant 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 PQC-enabled TLS. For example, Google has introduced hybrid post-quantum 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 system-level 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 system-level 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, energy, instantaneous power, and thermal response across the full set of NIST-standardized PQC KEM and signature schemes.

3 System Architecture and Design↩︎

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.

3.1 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 nodes are interconnected via an Ethernet underlay network that provides connectivity to the virtualized environment.

3.2 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.

3.3 Data Flow and Operation↩︎

The end-to-end communication follows a structured multi-stage 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.

4 Experimental Evaluation↩︎

4.1 Experimental Setup↩︎

Experiments are conducted on the testbed described in Section 3. 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.

4.2 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.

4.2.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 \in \{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.

4.2.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 server-side 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.

4.2.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 (\(^\circ\)C): Maximum observed CPU temperature during execution. This metric is used to verify whether the system approaches thermal throttling limits.

4.2.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.

4.2.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 \(\pm\)​5-10%, 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 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\(\times\), 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.

4.3 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 ¿tbl:tab:e2e?, ¿tbl:tab:resource?, and ¿tbl:tab:network?. 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 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.

4.3.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\times\) 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 1270-1300 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 \leq 20\)), after which deviations appear for computationally intensive schemes, particularly SLH-DSA, where latency increases more sharply.

4.3.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 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.

4.3.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.3.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.

4.3.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 system-level 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.

4.3.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.

4.3.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.

4.3.8 Thermal Behavior↩︎

Server temperature increases from approximately 60-62\(^\circ\)C at \(C=1\) to 68-70\(^\circ\)C at high concurrency, remaining below the 80\(^\circ\)C throttling threshold. A thermal plateau is observed beyond \(C \geq 20\), indicating steady-state operation. Client temperature remains approximately 5-7\(^\circ\)C lower than server temperature.

4.3.9 Operating Regimes↩︎

Three operating regimes are observed: (i) Low concurrency (\(C \leq 4\)): low latency (\(<120\) ms), minimal retransmissions, low energy consumption (e.g., \(\sim\)​100 ms for ML-KEM + Falcon). (ii) Moderate concurrency (\(10 \leq C \leq 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 \(\sim\)​4800 ms for SLH-DSA), throughput saturates, and incomplete handshake execution occurs.

4.4 Design Implications↩︎

4.4.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 post-quantum TLS. Instead, system design must prioritize computational efficiency at the cryptographic layer.

4.4.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.

4.4.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.4.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.

4.4.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.

4.4.6 Implications for PQC Algorithm Selection↩︎

Cryptographic design has a direct impact on system feasibility. Hash-based 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 resource-constrained platforms, computationally efficient PQC schemes are essential to achieve acceptable performance and energy efficiency.

4.4.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.

4.4.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 significantly 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.

5 Conclusion and Future Work↩︎

This paper presented a system-level evaluation of classical and post-quantum TLS handshakes between embedded UE-class 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 post-quantum primitives that align with the constraints of resource-limited 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.

References↩︎