Prioritized Physical Resource Block Allocation for Mobile Handsets over Fixed-Wireless Routers to Enhance Throughput and Speedtest Performance in 5G NSA Networks

Prioritized Physical Resource Block Allocation for Mobile Handsets over Fixed-Wireless Routers to Enhance Throughput and Speedtest Performance in 5G NSA Networks

Abdul Quader Syed (1), Hasan Omair Mohammed (2), Syed Naveed Maqdoom (3)

Nokia Siemens Networks

Abstract – Mobile handsets and fixed-wireless-access (FWA) routers are increasingly served from the same 5G cell, yet the scheduling decisions that shape a subscribers Speedtest score are usually made with no awareness of which device class is asking for capacity. This paper presents a device-class-aware Physical Resource Block (PRB) allocation policy for 5G Non-Standalone (NSA) networks that gives mobile handsets priority over co-located FWA routers while keeping router service-level agreements (SLAs) intact. The policy first reserves the guaranteed PRBs each network slices SLA requires, then redistributes the remaining pool using a tunable boost factor that favours handset traffic, subject to a minimum Jain fairness threshold that keeps the router from being starved. Enforcement runs through a closed, slice-aware RAN control loop: a management-layer policy function sets the desired boost and fairness floor for the slice, and a near-real-time RAN controller computes and applies per-UE PRB shares directly at the gNB scheduler, with measured KPIs reported back to close the loop. The allocation completes in O(N log N) per control window. We describe a reproducible testbed built from commercial off-the-shelf devices and a scripted Speedtest workflow, and report the pattern of results the policy is designed to produce: a 20 percent handset PRB boost moves median downlink throughput from 220 Mbps to 285 Mbps (a 30 percent gain) and PRB utilisation from 55 percent to 67 percent, while the routers allocation stays above its configured floor. These figures illustrate the behaviour the algorithm is designed to produce and are not yet drawn from live radio measurements. We release the allocation algorithm, the logging schema, the plotting scripts, and an example dataset so the workflow can be reproduced once testbed data is available, giving operators a standards-aligned, slice-preserving way to tune the handset experience without renegotiating router commitments.

Keywords5G NSA; network slicing; Physical Resource Block allocation; slice SLA assurance; Jain fairness index; RAN controller; Speedtest benchmarking; device-class scheduling

1. Introduction

   The shift from Long-Term Evolution (LTE) to fifth- generation (5G) radio access has changed how operators provision capacity, latency, and reliability across a far more heterogeneous mix of devices. In Non-Standalone (NSA) deployments, the 5G New Radio (NR) carrier sits on top of an existing LTE anchor, letting an operator bring wider bandwidth and improved scheduling into service well before a full Standalone (SA) core is ready. Within that setting, the Physical Resource Block (PRB) remains the smallest unit of time-frequency capacity the scheduler can hand out, and the way PRBs are split across competing user equipment (UE) ultimately decides the throughput any one device experiences.

   A tension operators run into constantly is what happens when a mobile handset and a fixed-wireless-access (FWA) router are attached to the same gNB. Routers tend to pull steady, high-volume traffic around the clock, while a handsets demand is bursty and tied to whatever the subscriber happens to be doing often a Speedtest run that becomes, fairly or not, the figure a customer judges the whole network by. Operators are routinely asked to lift the handset experience without touching the routers SLA, and existing slice-level controllers do not offer an easy way to do that: they manage resources at the level of the slice, not at the level of this is a phone, that is a router.

   This paper proposes a device-class-aware PRB allocation policy that closes that gap. The scheme first reserves whatever guaranteed resources each slices SLA calls for, then redistributes what is left over using a configurable boost factor that favours handset traffic, with a minimum Jain fairness threshold acting as a floor under the routers share. A near-real-time controller computes the policy and a base-station scheduler enforces it, with measured KPIs closing the loop back to the controller. The contributions of this paper are:

   1. a formalisation of handset-over-router prioritisation as a weighted, fairness-constrained PRB assignment problem, together with a reproducible O(N log N) algorithm;

   2. a measurement protocol that ties the radio-resource decision to the benchmark subscribers actually see, using the Speedtest application with paired hypothesis testing and effect-size thresholds;

   3. an account of the qualitative effect a 20 percent handset PRB boost is expected to produce roughly a 30 percent gain in median downlink throughput while the routers allocation stays bounded from below; and

   4. a public release of the algorithm, the logging schema, the plotting scripts, and an example dataset so other groups can reproduce and extend the study before committing testbed time to it.

2. Related Work

   Network slicing supplies the foundation most differentiated resource management in 5G is built on. Ordonez-Lucena et al. set out how Software-Defined Networking (SDN) and Network Function Virtualization (NFV) make it possible to run end-to-end logical networks that stay isolated from one another while sharing the same physical infrastructure [1]. Tonini et al. push that idea toward automation, arguing that slices need to adapt to changing demand with as little manual intervention as possible [2]. Habibi et al. examine how a single vertical can be served by several tailored slice instances, each mapped onto its own dedicated resources [3].

   Dynamic resource allocation at the radio layer has been approached from several directions. Chergui and Verikoukis treat RAN slicing as an OPEX-constrained problem and apply deep learning to estimate PRB demand from live datasets [4]. Datar et al. model the way application service providers compete for and price resources as a Stackelberg game, which brings out how budget limits shape the resulting allocation [5]. Hamad et al. examine the overload risk operators take on when they overbook multi-tenant resources to push utilisation higher [6].

   Programmable, controller-based approaches to RAN resource management have also matured in parallel. Qazzaz et al. describe a machine-learning-driven controller that selects a PRB allocation policy from traffic and QoS indicators, improving scheduler behaviour close to the point of enforcement [7]. Bonati et al. demonstrate a dynamic framework for RAN-level SLA control, and open- source slicing platforms have since been proposed to support exactly this kind of experimentation [11], [12]. Mohamed et al. compare SA and NSA performance indoors and show that changes in NR bandwidth measurably affect latency and achievable rate [8]; Abood et al. bring deep learning into QoS protection within SDN- based slicing [9]; and Chochliouros et al. survey the broader challenges dynamic slicing still faces [10].

   What these studies share is that they manage resources at the slice or SLA level. What we add here is a device-class boost exposed explicitly between a handset and an FWA router sharing the same cell, together with a validation of that effect against the Speedtest benchmark that subscribers actually use to judge the network.

3. Network Slicing Concepts and Device-Class Use Cases in 5G NSA

   1. Slice Types and QoS Differentiation in 5G

      Network slicing lets a single physical 5G deployment behave as several logically separate networks, each configured for a different category of service through the Single Network Slice Selection Assistance Information (S- NSSAI) framework [19]. Three generic slice/service types are the usual starting point for any deployment: enhanced Mobile Broadband (eMBB), aimed at high sustained

      throughput for consumer data and video; Ultra-Reliable Low-Latency Communication (URLLC), for traffic that cannot tolerate delay or loss; and massive Machine-Type Communication (mMTC), built for very large numbers of low-rate, intermittent IoT connections. Every PDU session within a slice carries one or more QoS flows, and each flow is characterised by a target packet delay budget, an acceptable error rate, and, for GBR flows, a guaranteed bit rate [19], [20]. Table II summarises how these three slice types typically differ and where handset and FWA router traffic sit relative to each.

      TABLE II. REPRESENTATIVE 5G SLICE TYPES AND ALIGNMENT WITH DEVICE CLASSES

      Slice Type	Defining Characteristic	Typical NSA Use Case	Relevance to Handset/FWA Contention
      eMBB	High sustained throughput; moderate latency tolerance	Handset mobile broadband; FWA fixed-line substitution; video streaming	Both device classes normally share this slice the boost policy in this paper operates here
      URLLC	Very low latency; high reliability	Industrial automation; certain enterprise control loops	Rarely shares a cell with consumer FWA/handset traffic; isolated via its own guaranteed PRBs
      mMTC	Very high device density; low per- device rate	Sensor and metering IoT	Negligible PRB contention with handsets or FWA due to low per- device demand

      In the scenario this paper is concerned with, the mobile handset and the FWA router are almost always provisioned under the same eMBB slice: neither imposes the sub- millisecond latency bound that would justify a dedicated URLLC slice, and neither generates the sparse, small- packet traffic mMTC slicing is built around. That shared classification is exactly what creates the problem addressed here. Slice-level SLA enforcement can guarantee that the eMBB slice as a whole receives its committed bit rate, but it has nothing to say about how that bit rate should then be divided between a handset session and a router session once both sit inside the same slice.

   2. NSA Deployment Scenarios and Device-Class Contention

      This tension shows up in several NSA deployment patterns operators run into routinely. Suburban and rural macro sites are one: FWA has become a common substitute for fixed-line broadband there, and it now competes for capacity with every handset that also attaches to the same eNB/gNB pair. Urban infill sites are another, where FWA is deployed opportunistically to relieve fixed-line congestion alongside a dense population of handsets running everyday applications and benchmark tests. A third is the small enterprise or campus case, where an FWA router backs an office or branch while employee handsets share the same NSA carrier for day-to-day connectivity.

      In each of these settings, the operators commercial commitment to the FWA subscriber typically a minimum sustained rate sits in tension with the fact that handset Speedtest results are what a much larger population of subscribers uses to judge network quality day to day. NSA also sharpens this contention rather than diluting it: because the control plane still leans on the LTE anchor through EN-DC signalling, and because the NR carrier is often deployed with less additional spectrum than a full SA build would carry, the PRB pool actually available at the NR layer tends to be tighter to begin with.

      The device-class-aware allocation policy proposed in this paper is best understood as a control that operates inside a single eMBB slice rather than across slices. It assumes the slice-level guarantees from network slicing are already in place and asks a narrower question: given whatever residual capacity is left once every slices SLA has been met, how should that remainder be split between the device classes competing within it, in a way that stays transparent, bounded, and easy for an operator to reason about? Positioning the mechanism this way keeps it compatible with existing slice orchestration rather than competing with it, and explains why the boost factor and the fairness floor introduced in Section V operate strictly on the best- effort remainder of the PRB pool rather than on any slices already-guaranteed portion.

   3. Slice SLA Assurance and Guaranteed PRB Reservation

      3GPPs management and orchestration framework already gives operators a standard way to describe and monitor a slices SLA: a Network Slice Management Function (NSMF) and its subnet-level counterpart, the NSSMF, translate a tenants service requirements into a Network Resource Model that the management system can provision, monitor, and re-tune over time [21], [22]. The guaranteed-PRB reservation step in the allocation policy proposed here is deliberately designed to sit underneath that model rather than beside it: the guaranteed bit rate a slice has been provisioned with is what determines how many PRBs the reservation stage sets aside before any device-class boost is even considered.

      Framed this way, slice SLA assurance and device-class prioritisation are two different layers of the same resource hierarchy rather than competing mechanisms. The management layers job is to keep the eMBB slice as a whole within its committed bit-rate envelope; the allocation policys job is to decide, once that envelope has been honoured, how the slices best-effort remainder should be split between the handset and router sessions that make up its traffic mix. A change to the slices SLA a higher guaranteed rate negotiated for the FWA tenant, for instance changes the size of the reserved pool at the first stage of the algorithm in Section V, but leaves the boost- and-fairness logic that governs the remainder untouched. That separation is what lets an operator retune

      the handset experience without renegotiating the routers underlying slice agreement at all.

4. System Model

   We consider a single gNB running in NSA mode and serving a set of UEs that includes at least one mobile handset and one FWA router. Time-frequency resources are organised into PRBs, and the scheduler makes an allocation decision every transmission time interval. Each UE u reports a signal-to-interference-plus-noise ratio (SINR) that the system maps onto a spectral efficiency, and every UE belongs to both a device class and a slice, the latter carrying an associated guaranteed bit rate.

   A closed control loop governs how the policy is expressed and enforced (Fig. 1). A management-layer policy function consistent with the slice management framework introduced in Section III-C sets the desired handset boost and the fairness floor for the slice. A near- real-time RAN controller turns that intent into per-UE PRB shares and pushes them directly to the gNB scheduler. Measured KPIs flow back from the scheduler to the controller and, in turn, to the management layer, closing the loop.

   Fig. 1. Closed-loop RAN control architecture for device-class-aware PRB allocation, showing the control-plane path from slice policy down to the scheduler, alongside the data-plane and measurement paths.

   Given b PRBs assiged to UE u and a per-PRB spectral efficiency (bits/s/Hz), the achievable throughput of UE u follows directly from the PRB bandwidth W:

   R = b · W ·

   Spectral efficiency is obtained from the reported SINR through a Shannon mapping capped by the highest modulation and coding scheme the link can sustain, with bounding the realisable rate [13], [14]:

   = min{ log(1 + ), }

   To quantify how equitably the N served UEs are treated, we use Jains fairness index over their per-UE throughputs [15]:

   J = ( R)² / (N · R²)

   J equals one when the allocation is perfectly equal and falls as the allocation becomes more skewed toward particular UEs.

5. Methodology

   The allocation runs in three stages inside every control window. First, the controller maps each UEs reported SINR onto a spectral efficiency. Second, it reserves whatever guaranteed PRBs each slices SLA requires. Third, it distributes what remains of the PRB pool by weighting UEs so that handset-class UEs receive a boost factor of (1 + ) relative to router-class UEs. Once a tentative allocation has been produced, the controller checks Jains index; if fairness has dropped below the configured floor, the boost is scaled back and the distribution is recomputed before anything is applied. The accepted allocation is then pushed directly to the gNB scheduler, and the resulting KPIs are logged (Fig. 2).

   Fig. 2. Decision flow for device-class-aware PRB allocation with fairness-floor enforcement.

   The boost factor is the single knob exposed to the operator. Setting it to zero reproduces ordinary proportional fairness; positive values shift the residual pool toward the handset, while the fairness floor keeps the router from ever being pushed below a guaranteed minimum share. Because the guaranteed PRBs are reserved before the boost is applied at all, the routers SLA commitments are protected by construction rather than by policy discipline alone.

   Worst-case time complexity is O(N log N) per control window, driven by the need to sort UEs by weighted demand; the fairness re-evaluation adds a small, constant number of O(N) passes bounded by however many times the boost has to be scaled back. Space complexity is O(N) for the per-UE state the controller keeps. The full pseudocode is included in the accompanying source listing released alongside this paper.

6. Experimental Setup

   We propose a testbed assembled entirely from open components: an OpenAirInterface or srsRAN gNB, a programmable near-real-time RAN controller hosting the allocation logic, and commercial off-the-shelf UEs at minimum one Android handset and one FWA router attached to the same cell. The controller pushes resource decisions directly to the gNB scheduler, so no proprietary tooling is required to reproduce the setup.

   Throughput is measured with the Speedtest command-line client, which makes scripted, repeatable runs straightforward; a typical invocation writes machine- readable results that feed directly into the logging pipeline [16], [17]. Each scenario is repeated enough times to support the statistical tests that follow; we recommend at least thirty paired observations per scenario. Three scenarios are compared: a baseline proportional-fair allocation, a handset-boosted allocation, and a router- boosted allocation,

   For every observation we log a timestamp, the scenario label, device class, downlink and uplink throughput in Mbps, latency and jitter in ms, PRB utilisation as a percentage, the allocated PRB count, and SINR in dB. These fields populate both the results table and the figures that follow.

7. Results

   This section works through the pattern of results the policy is designed to produce. The values reported here are estimates, produced ahead of the testbed measurement campaign to show the expected shape of the data; they are not drawn from live radio conditions and should be read as a specification of what the evaluation will look like once real data is available, not as a finding in themselves.

   Fig. 3 lays out three views of the baseline-versus-handset- boosted comparison: the downlink throughput CDF, the Speedtest downlink/uplink box plots, and the PRB utilisation time series.

   Fig. 3. comparison of baseline and handset-boosted allocation. Values are projected estimates, pending testbed validation.

   Table I summarises the same per-scenario metrics using the exact headers and units the logging schema produces.

   Scenario	DL (Mbps)	UL (Mbps)	Lat (ms)	Jit (ms)	PRB (%)
   Baseline	220	38	24	6	55
   Handset +20%	285	46	21	5	67
   Router +20%	210	41	25	7	62

   TABLE I. PER-SCENARIO PERFORMANCE SUMMARY (PROJECTED VALUES)

8. Discussion

   Read qualitatively, these placeholder figures show the effect the policy is meant to produce: boosting the handset raises its downlink throughput and PRB utilisation, while the router protected by its reserved guaranteed PRBs keeps a bounded share rather than collapsing. The fairness floor is what stops the boost from going too far, and it gives the operator a single, legible parameter with which to trade handset gain against overall fairness.

   None of this removes the need for empirical confirmation. The actual size of the Speedtest improvement, how latency and jitter behave under load, and whether the control loop stays stable at short control-window lengths all depend on the scheduler implementation and the radio conditions on the day. We flag these as open items for the hardware campaign to settle, not as conclusions this paper is already entitled to draw.

9. Conclusion

We have presented a device-class-aware PRB allocation policy that gives mobile handsets priority over fixed- wireless routers sharing a 5G NSA cell, enforced through a closed, slice-aware RAN control loop and evaluated against the Speedtest benchmark subscribers actually use. The policy reserves guaranteed resources ahead of any boost, applies a tunable handset preference on top of what remains, and bounds the fairness impact of doing so. We have set out a reproducible algorithm, the equations linking PRBs, SINR, and fairness, a statistically grounded measurement protocol, and the figures, schema, and tables needed to replicate the work. The next step is a hardware testbed campaign to replace the Projected results reported here with measured ones, and to explore whether the boost factor itself can be learned rather than fixed by the operator.

References

1. J. Ordonez-Lucena, P. Ameigeiras, D. Lopez, J. Ramos-Munoz,

   J. Lorca, and J. Folgueira, Network slicing for 5G with SDN/NFV: concepts, architectures, and challenges, IEEE Commun. Mag., vol. 55, no. 5, pp. 80-87, May 2017.

2. F. Tonini, C. Natalino, M. Furdek, C. Raffaelli, and P. Monti, Network slicing automation: challenges and benefits, in Proc. Int. Conf. Optical Network Design and Modeling (ONDM), 2020, pp.

   1-6.

3. M. A. Habibi, B. Han, F. Z. Yousaf, and H. Schotten, How should network slice instances be provided to multiple use cases of a single vertical industry?, IEEE Commun. Standards Mag., vol. 4, no. 3, pp. 53-61, 2020.

4. H. Chergui and C. Verikoukis, OPEX-limited 5G RAN slicing: an over-dataset constrained deeplearning approach, in Proc. IEEE Int. Conf. Communications (ICC), 2020, pp. 1-6.

5. M. J. Datar, E. Altman, and H. Le Cadre, Strategic resource pricing and allocation in a 5G network slicing Stackelberg game, IEEE Trans. Netw. Service Manag., vol. 20, no. 1, pp. 502-520, 2023.

6. Y. S. Hamad, B. Han, and O. Ucan, Online estimation of resource overload risk in 5G multi-tenancy network, arXiv:2106.07417, 2021.

7. M. M. H. Qazzaz et al., Machine learning-based xApp for dynamic resource allocation in O-RAN networks, in Proc. IEEE Int. Conf. Machine Learning for Communication and Networking (ICMLCN), 2024, pp. 492-497.

8. R. Mohamed, S. Zemouri, and C. Verikoukis, Performance evaluation and comparison between SA and NSA 5G networks in indoor environment, in Proc. IEEE Int. Mediterranean Conf. Communications and Networking (MeditCom), 2021, pp. 112-116.

9. M. Abood et al., Improved 5G network slicing for enhanced QoS against attack in SDN environment using deep learning, IET Commun., vol. 18, pp. 759-777, 2024.

10. I. Chochliouros et al., Dynamic network slicing: challenges and opportunities, in Artificial Intelligence Applications and Innovations (AIAI), vol. 585, 2020, pp. 47-60.

11. L. Bonati, S. DOro, M. Polese, S. Basagni, and T. Melodia, An Open RAN framework for the dynamic control of 5G service level agreements, in Proc. IEEE Conf. Standards for Communications and Networking, 2022.

12. H. Cheng et al., ORANSlice: an open-source 5G network slicing platform for O-RAN, in Proc. ACM Workshop on Open RAN, 2024.

13. 3GPP, NR; Physical channels and modulation, TS 38.211, 3rd Generation Partnership Project, 2023.

14. 3GPP, NR; Physical layer procedures for data, TS 38.214, 3rd Generation Partnership Project, 2023.

15. R. K. Jain, D. W. Chiu, and W. R. Hawe, A quantitative measure of fairness and discrimination for resource allocation in shared systems, DEC Research Report TR-301, 1984.

16. Ookla, Speedtest by Ookla: methodology and measurement, Ookla LLC, online report, 2024.

17. Ookla, Speedtest CLI documentation, Ookla LLC, online resource, 2024.

18. 5G-Tools, 5G NR throughput calculator and resource block overhead, online technical resource, 2023.

19. 3GPP, System architecture for the 5G System (5GS), TS 23.501, 3rd Generation Partnership Project, 2023.

20. 3GPP, Policy and charging control framework for the 5G System (5GS); Stage 2, TS 23.503, 3rd Generation Partnership Project, 2023.

21. 3GPP, Management and orchestration; Architecture framework, TS 28.533, 3rd Generation Partnership Project, 2023.

22. 3GPP, Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3, TS 28.541, 3rd Generation Partnership Project, 2023.