Performance Evaluation of an Open Source Implementation of a 5G Standalone Platform

Fifth-generation (5G) mobile communication systems are currently implemented worldwide. Moreover, the diversity between different deployments is growing, from operator-deployed macro networks to local private networks. The 5G system is very flexible with a large number of parameters and configurations impacting platform performance. With the availability of private spectrum and open-source software, there is an increasing possibility to get insight into what performance can be achieved in different dimensions, and how it depends on the configuration of various parameters, through experiments and testing. This paper presents a detailed account of a 5G Standalone (SA) platform based on the open5GS and srsRAN software suites installed on a general-purpose workstation. The performance of the platform is measured and compared to theoretical results and information from the 3GPP standardisation documentation. While some aspects of the performance are close to the theoretical expectations, others are further away. The software-defined radio (SDR) platform and the lack of hardware acceleration are probably the main limiting factors on coverage, uplink throughput and latency. The paper goes through several radio parameters and their impact on performance and discusses the performance implications and limitations of the experimental platform to share the lessons learned.


I. INTRODUCTION
Mobile communication systems have evolved into an indispensable part of societal infrastructure, seamlessly integrating into our daily lives [1].The latest fifth generation (5G) of mobile communication systems was first standardized some years ago with the freezing of 3GPP Release 15 in 2019.The upcoming Release 18 is anticipated to achieve stability and freeze in 2024.5G introduces novel services such as enhanced Mobile Broadband (eMBB), ultra-Reliable Low Latency Communications (uRLLC), and massive Machine Type Communications (mMTC) with performance requirements exceeding those of previous generations [2].
Traditionally, mobile network deployments have a closed radio access network (RAN) architecture leading to vendor The associate editor coordinating the review of this manuscript and approving it for publication was Faissal El Bouanani .lock-in and restricting the operators' possibility to alter network architecture.The consequence is an incomplete control over the network infrastructure they have invested in.Addressing this challenge, a new paradigm known as open RAN has recently emerged, capturing substantial attention from academia as well as industry [3].Open RAN solutions promote virtualized RAN where disaggregated components communicate via standardized interfaces.This paradigm offers compelling features, including the utilization of open-source software, the deployment of general-purpose hardware, the separation of hardware from software with full transparency, and enhanced interoperability.This shift represents a promising departure from the constraints imposed by closed RAN concepts, empowering operators with greater flexibility and control over their networks.
Spectrum allocation authorities have become more supportive of private network deployments, such as the Citizens Broadband Radio Service in the USA.In Norway, where our platform has been deployed, the regulation authorities opened in January 2023 for spectrum licensing of private networks in the 3.8 to 4.2 GHz band.These licenses are not intended for mobile network operators to extend their coverage and are therefore limited to networks operating in standalone (SA) mode within specified geographical areas.
Despite the presence of 5G systems for several years, they have predominantly been 5G Non-Standalone (5G NSA) deployments without the incorporation of the new 5G Core (5GC).Furthermore, only a limited number of handsets currently support 5G SA networks.
In this paper, we present an open-source platform based on a RAN from SRS called srsRAN and a 5GC from open5GS.A software-defined radio (SDR) is used for the air interface transmitting in the n77 band with a centre frequency of 3880 MHz, corresponding to a New Radio Absolute Radio Frequency Channel Number (NR-ARFCN) of 658666.The main contributions of the paper are as follows: • We give an overview of the 5G SA platform, offering insights into its constituent elements, encompassing the user equipment (UE) side, RAN and 5GC.
• The configurations required to make the platform operational are described.
• We evaluate performance in terms of coverage, throughput and latency, and compare the results to theoretical and standardization expectations.
• We analyze the relationship between performance and key parameters, such as the number of base station antennas, bandwidth, Modulation and Coding Scheme (MCS) table used, and frame structure.
The rest of this paper is organised as follows.Section II provides an overview of related work using open-source platforms.Then, the different parts of our platform are described in Section III.In Section IV, results from coverage, throughput and latency measurements are provided and compared to what is expected.Then, the results are discussed in Section V before conclusions are drawn in Section VI.

II. RELATED WORK
Several publications describe activities using open-source platforms, most of them using 4G or 5G NSA platforms.The performance of 4G and 5G NSA platforms is demonstrated in [4].For the 4G platform, both 2 × 2 Multiple Input Multiple Output (MIMO) and Single Input Single Output (SISO) are demonstrated, while only SISO is included for 5G NSA.Gabilondo et al. [5] utilize a 4G platform, comparing Open Air Interface (OAI) and srsRAN-based platforms for broadcast and multicast services.Meanwhile, Dauphinais et al. [6] employ a srsRAN 5G NSA platform to exhibit a fuzz-testing digital twin framework.In [7], srsRAN eNB and Evolved Packet Core (EPC) are used to demonstrate different functional splits between Distributed Unit (DU) and Central Unit (CU), as defined by the 3GPP.Furthermore, in [8], srsRAN's 4G platform is used to demonstrate how eNBs and the EPC can be connected via Wi-Fi links, enabling multiple flying eNBs.Some publications are also reporting results using 5G SA platforms.In [9], a 5G SA platform based on open5GS and srsRAN enabling slicing is presented.The authors describe how to set up the platform but do not give any assessment of the performance.In [10], the performance in terms of throughput and latency is reported for a 4G, a 5G NSA and a 5G SA platform.The 5G platform is similar to the one presented in this publication.Their results are, however, below what we have found.Moreover, they have not assessed the performance as a function of key parameters such as bandwidth, number of antennas or frame structure as we do in this publication.Another publication reporting the modest performance of an OAI 5G SA platform is [11], naming only limitations in the USRP as a potential explanation.One publication that looks into the impact of parameter settings is [12], where they consider Medium Access Control (MAC) layer resource scheduling and impact on throughput using an OAI platform.This is one of few publications that take advantage of the opportunity open source platforms give to experiment and tune the networks.A Localisation Management Function (LMF) is implemented in [13] using OAI.5G Non-terrestrial networks (NTNs) are the topic in [14], where an OAI 5G SA platform is used to communicate via a geostationary satellite.
Hence, we can note that there are several open-source implementations to chose from.Table 1 shows an overview over those most relevant.While not all functionality of the 3GPP specifications are included in each of the implementations, all of them support functionality for deploying a single cell.In addition to the ones in the table, it is worth mentioning SD-Core which is the Open Networking Foundation (ONF) core network implementation based on code from Free5GC and OMEC EPC.It is initially released for ONF members only, but will be released under the Apache license at a later time.It is also worth mentioning Magma which is backed by the Linux Foundation and OAI and implements generic core network functionality for edge deployment with a variety of access networks.
To select which one to use, several studies have pointed out that Open5GS and srsRAN are easier to deploy than OAI [4], [9].OAI, free5GC and Open5GS core network implementations have been compared by Reddy et al. [15], from both a qualitative and quantitative point of view.The quantitative evaluation reveals that OAI 5G CN results in a round trip time (RTT) that increases significantly with increasing number of UEs, while free5GC and Open5GS have RTTs that are less dependent on the number of UEs.Lando et al. [16] also compares the three 5GC implementations and note that OAI 5G CN is less mature and fail some tests.The results also reveal that Open5GS performs better than Free5GC with respect to control plane procedures for session establishment and registration, while Free5GC data plane performs better than Open5GS, in particularly as the number of UEs increases.Also, [15] measures the processing load and concludes that Open 5GS has the lowest processing load while OAI 5G CN has the highest.Based on these results from the related work, Open5GS and srsRAN seem like a good choice for our tests.

III. DESCRIPTION OF THE PLATFORM A. OVERALL ARCHITECTURE
Our 5G SA platform is illustrated in Fig. 1.It is installed on a Ryzen Threadripper 3970X with 64 CPUs and 256 GB RAM.The operating system is Ubuntu 22.04.The 5G SA platform consists of a 5G Core network from open5GS (v2.6.4) and an O-RAN Alliance-compliant Radio Access Network (RAN) from srsRAN (v23.10).It connects to the public internet using an Ethernet interface and running a masquerade script.The radio unit is a USRP B210 connected to the RAN via USB3.The USRP contains a GPS disciplined oscillator (GPSDO) and 5GHz compatible hinged external antennas from Molex.
Three different UEs connect to the 5G SA platform.One UE from srsRAN is installed in a separate namespace within the workstation.This is a 4G UE which can be used to test 5G NR but with some limitations, such as 15 kHz sub-carrier spacing (SCS).It is useful to test the 5G SA platform without being concerned by the air interface and propagation conditions.The second UE is a laptop with a Simcom SIM8262E-M2 5G modem.The modem can be configured and monitored from the laptop using AT commands.It is located close to the 5G SA platform and is useful to test throughput and latency.The last UE is an Oneplus Nord CE 2 Lite 5G phone.It is useful to test coverage and received signal level as a function of distance.Both the modem and the phone have a SIM card installed from Sysmocom.The SIM cards are programmed using a SIM card reader/writer from Omnikey.
The platform operates in the n77 band with a centre frequency of 3.88 GHz.This is a license granted by the Norwegian Communication Authorities (Nkom) for use at specific locations.According to the license conditions, the transmit power is limited to 30 dBm with 0 dB antenna gain, and the maximum bandwidth is 80 MHz.The maximum antenna height above ground is 10 meters.

B. 5G CORE NETWORK
Open5GS is an open-source 5G core network, where the code is made available under the terms of the GNU AGPL v3.0 license.In contains both a 5G NSA core and a 5G SA core.The 5G NSA core is essentially a 4G core network, but with some modifications, such as separation between the user plane and the control plane.In the work presented here, only the 5G SA core is used.The 5G SA core contains the following Network Functions (NFs): • AMF (Access and Mobility Management Function)  • BSF (Binding Support function) The three most central NFs are the AMF, SMF and UPF.The AMF is the only NF in the control plane that has interfaces to the gNB and the UEs, so all other control plane NFs communicating with the gNB or the UE do this via the AMF.The AMF also handles authentication of UEs and mobility together with the AUSF, UDM and UDR.The SMF is in charge of managing sessions and, among other tasks, allocates IP addresses to the UEs.The UPF is the only NF in the user plane, and all user data flows through the UPF to external networks such as the public internet.Fig. 2 shows the NFs and the most important interfaces.The red color corresponds to the user plane, and the blue color to the control plane.
The user credentials are entered using a web interface and stored in the AUSF.The credentials consist of the Subscription Permanent Identifier (SUPI) (same as the IMSI in 4G), the operator code OPc and the subscriber authentication key K i .These must be the same as those stored on the SIM card.In addition, it specifies which Data Network Name (DNN) the subscriber can connect to.The DNN is analogous to the Access Point Name (APN) in 4G, but in 5G it is related to network slicing, which is a key feature of 5G networks.

C. 5G NR
srsRAN 5G is open-source code distributed under the terms of the MIT license.Its features include Frequency Division Duplex (FDD) and Time Division Duplex (TDD), all sub-6 GHz bands (FR1), up to 4 × 4 MIMO in the downlink, up to 256 QAM modulation, 15 kHz and 30 kHz SCS, and slicing.Currently, multi-cell support and handover are not supported.The architecture of the gNB is illustrated in Fig. 3.It consists of a Distributed Unit (DU), a Central Unit (CU), and a near real-time RAN Intelligent Controller (near-RT RIC) with limited functionality.The SDR constitutes the Radio Unit (RU).The fronthaul interface connects the RU and the DU.The DU is then split between DU low, responsible for the Upper PHY processing, and DU high, responsible for the MAC and Radio Link Control (RLC) layers.
The midhaul interface connects the DU to the CU.The CU is split between the control plane (CP) and the user plane (UP).The CU-CP is responsible for the handling of control plane messaging, in particular, the control part of the Packet Data Convergence Protocol (PDCP).The CU-CP has interfaces to the DU high (F1-c), CU-UP (E1), 5G Core (NG-c or N2) and near-RT RIC (E2-CP).The CU-UP is responsible for handling the user plane messaging, in particular, the user plane aspect of the PDCP and Service Data Adaptation Protocol (SDAP) protocols.The CU-UP communicates with the UPF through the NG-u, also called N3, interface.The interface between the gNB and the 5G Core is called the backhaul interface.
A Around 400 parameters are exposed in the gNB configuration file, providing a great deal of flexibility in configuring the network and monitoring the behaviour and performance.The configuration file contains a block of radio-related parameters such as device driver, transmit and receive gain, frequency offset, synchronisation parameters etc.Another block contains cell-related parameters such as frequency band, bandwidth, number of base station antennas, and the Public Land Mobile Network (PLMN) containing Mobile Country Code (MCC) and the operators' Mobile Network Code (MNC).The MCC and MNC are linked to the license.Also, specific parameters related to the different channels can be set, as well as the TDD frame format when TDD is used.Finally, all functions and interfaces can write log files and pcap files that allow inspection of all packets flowing through the various interfaces.This is useful for debugging as well as for gaining an understanding of the functionalities of the network.

D. RADIO UNIT (RU)
The RU connecting to the gNB is a USRP B210 from Ettus, using the driver UHD v.4.1.0.5-3.The radio can support two transmit and two receive antennas.The maximum bandwidth supported by the USRP with one channel is 56 MHz, while it is 30.72 MHz in dual-channel mode.This means that the 25812 VOLUME 12, 2024 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.maximum bandwidth with one antenna is 40 MHz, while it is 20 MHz with two antennas.The B210 contains a boardmounted GPSDO.Without a GPS lock, the 5G mobile phone will not connect to the 5G SA platform, while the 5G modem from Simcom is able to connect.This shows that the tolerance limits when it comes to clock accuracy are different for different UEs.
According to the specifications, the maximum transmit power of the B210 is between 6 dBm and 16 dBm, depending on the application.A spectrum analyzer connected to the antenna port was used to measure the maximum transmit power.It was found to be 12 dBm.This is 18 dBm lower than the maximum allowed transmit power, according to the license.

E. USER EQUIPMENT (UE) 1) SRSUE VIA ZEROMQ
When testing the setup of the 5G core and gNB, and the configurations of internal interfaces within the workstation, it is convenient to simulate communication to an UE within the workstation.This can be done through ZeroMQ, an asynchronous messaging library.A separate namespace is created for the UE, and then messages are passed between the gNB and the UE.Unfortunately, the srsRAN Project does not include a full 5G UE, as it is a CU/DU solution.It does however include a prototype 5G UE (srsUE) which can be used for testing of 5G SA networks.There are, however, some limitations.Only 15 kHz SCS is supported, and only one base station antenna can be used.Also, other parameters, such as frame structure, can not be modified.Still, testing the performance of the 5G SA platform using ZeroMQ makes it possible to compare the results with theory and standards without being concerned that radio conditions will have an impact.

2) 5G MODEM
The 5G modem from Simcom has two transmit and two receive antennas, allowing for 2 × 2 MIMO in the downlink.It can be configured using an application called Minicom to transmit AT commands.Examples of useful AT commands are AT+CIMI showing the SUPI, AT+CSQ reporting RSSI, AT+CREG showing the network it is connected to; and AT+CGDCONT that can be used to add Packet Data Unit (PDU) services.The DNN provided in the web interface of open5GS must be among the PDU services.By default, the PDU services Internet, IP Multimedia Subsystems(IMS) and SOS are defined in the modem.The DNN value Internet is set in the open5GS web interface, as our network is a pure data network.It can be noted that leaving the other two PDU services enabled leads to warnings in the AMF log file, but that has no consequence as the modem connects to the Internet PDU service.

3) 5G PHONE
Three types of phones were tested to see if they could connect to the 5G SA platform.Only one succeeded.This was a Oneplus Nord CE 2 Lite 5G phone running Android 13.In order to connect to the 5G SA platform, the APN settings had to be adjusted, including the correct DNN, the MCC and MNC, and the APN type that must be set to default.In addition, the app ''5G Switch -Force 5G Only'' version 3.0.1 is installed, in which the preferred network type is set to 'NR(New Radio) only'.Without this app, the phone does not connect to the network.
The phones not able to connect were an iPhone 14 running iOS17 and a Google Pixel 6 running Android 13.It was as expected that the iPhone did not connect, as it requires IMS to register.It was more surprising that the Google Pixel did not connect, as it is on the list of tested commercial off-theshelf (COTS) UEs provided by SRS.It is most likely a matter of configuration.

4) SIM CARD PROGRAMMING
The SIM cards installed in the modem and the phone are purchased from Sysmocom and are of the type sysmoISIM-SJA2.They come with IMSI numbers starting with 99970, corresponding to MCC = 999 and MNC = 70.Our license requires that the IMSI numbers start with our MCC (242) and MNC (71), so this must be reprogrammed and be the same as those inserted in the open5GS web interface.The reprogramming of the SIM cards is done using a SIM card reader/writer and running the pySim-shell.pyscript, which is a part of the pySim suite of programs for interfacing with SIM cards.Care must be taken that the IMSI number, the operator code OPc, and the 128-bit encryption key K i are the same as those inserted in the open5GS web interface.If not, a Message Authentication Code (MAC) failure will prevent the UE from connecting to the network.
In addition to updating the IMSI of the SIM card, the Subscriber Concealed Identifier (SUCI) service must be deactivated, as this, by default, is enabled in the SIM cards while open5GS does not support it.With the PLMN updated and SUCI service-disabled, the SIM cards can be inserted into the modem and the phone to connect to the base station.

IV. PERFORMANCE ANALYSIS
The base station is located in an office environment, and the performance in terms of coverage, throughput and latency is measured and compared to what could be expected from the theory and from the standard.

A. COVERAGE
The coverage of the base station is measured in an office building using the app ''Network Cell Info Lite'' (Release 6.7.4) installed on the mobile phone.UEs measure the SS-RSRP for cell selection and re-selection, power control and more, and these measurements can be exposed by different apps.The SS-RSRP is the average power (averaged in linear scale) received from a single Resource Element (RE) allocated to the secondary Synchronization (SS) signal.The bandwidth of a RE is equal to the SCS, in our case, 30 kHz.For a 20 MHz signal containing 51 resource blocks and 612 sub-carriers, a correction factor of 27.9 dB must, therefore, be applied to get the power over the entire bandwidth.
The received signal level can be estimated analytically through the path loss L p .L p is typically modelled as a function of frequency, distance, and the path loss exponent n: where the distance d is in meters, and the frequency f is in Hz.The path loss exponent is equal to 2 for free space but generally higher in most environments due to structures and obstructions.Finding the received signal level P 0 at a reference distance d 0 , the received signal level can be estimated as [17]: d 0 is typically set to 1 meter.The RSRP is measured along the corridor outside the office where the base station is located.The results are shown in Fig. 4 for one and two antennas, together with the calculated values for different path loss exponents.The larger circles illustrate the mean value at a distance.The figure indicates that the path loss exponent in the office building is close to 3.5.The UE loses connection at about −110 dBm to −120 dBm, indicating that the range is in the order of 20 meters.It must be noted that the transmitted power is far below the permitted power level of 30 dBm.With a more powerful transmitter, the coverage area can be increased significantly.Assuming a path loss exponent of 3.5 and 18 dB more transmit power, the RSRP is −110 dBm at 35 meters and −120 dBm at 68 meters.
Coverage measurements using the 5G SA network have only been done indoors.For outdoor environments with lineof-sight between the base station antenna and the UE, the range will be increased and may be sufficient for some use cases.Still, using a USRP like the B210 will constitute a limitation for many of the operational use cases of 5G SA networks, indoors as well as outdoors.

B. THROUGHPUT 1) CALCULATED THROUGHPUT
The expected throughput can be calculated using the equation provided in TS 38.306 [18].The equation includes the possibility of having several component carriers.In our case, we have only one component carrier, and the equation can be simplified.For one component carrier, the throughput R in bps is given by: The number of layers ν Layers is 1 for one antenna and 2 when 2 × 2 MIMO is applied.Q m is the maximum supported modulation order and can be 6 or 8, corresponding to 64 QAM and 256 QAM, respectively.In the specification, TS 38.214 [19], four Modulation and Coding Scheme (MCS) tables (Table 5 The scaling factor f can take the values 1, 0.8, 0.75 and 0.4 and is related to carrier aggregation.With only one carrier, the scaling factor is 1.R max is the maximum target code rate given by the MCS index tables in TS 13.214.The maximum value for the LPCD code is 948/1024, corresponding to a spectral efficiency of 5.5547 bps/Hz with 64 QAM and 7.4042 bps/Hz with 256 QAM.
The maximum resource block allocation N µ PRB with SCS equal to 30 kHz is 51 for bandwidth 20 MHz and 106 for bandwidth 40 MHz.The average OFDM symbol duration T µ s is given by the numeration µ [18]: For 30 kHz SCS, µ is 1 [20] and T µ s = 35.714µs, assuming normal cyclic prefix.
Finally, the overhead OH is 0.14 for the downlink and 0.08 for the uplink.The overhead is due to PHY signalling, including control channels, synchronization signals and reference signals for channel estimation.
According to the standard and the license, TDD must be applied in the n77 band.The scheduler defines how many time slots are allocated to each direction of the link.This can be set in the srsRAN gNB configuration file.Each slot is 0.5 ms long and contains 14 OFDM symbols.A typical frame structure can be that six slots are allocated to the downlink and three to the uplink.One last slot is a special slot so that the frame structure may look like this: DDDDDDSUUU, where ''D'' designates downlink slots, ''U'' designates uplink slots, and ''S'' is the special slot.The special slot must contain a Guard Period (GP) between downlink and uplink symbols.For cell sizes as small as ours, 1 GP symbol is enough.The special slot can then, for example, contain seven downlink symbols, 1 GP symbol and six uplink symbols, denoted 7:1:6.The downlink and uplink throughput is then found from (3), including the percentage of the frame structure that contains downlink and uplink symbols, respectively.
It may be noted that this is an example of parameters that are difficult to adapt in wide area networks since those need to be synchronized and use the same UL/DL configuration in adjacent cells and in adjacent frequency bands.This is due to the excessive interference that would result if one UE is receiving while a nearby UE is transmitting on the same or an adjacent frequency band simultaneously.
The maximum throughput in both directions is shown in Table 2 for frame structure DDDDDDSUUU (7:1:6) with some combinations of a number of MIMO layers ν layers , bandwidth BW and modulation order Q m .Note that srsRAN only supports 2 × 2 MIMO in the downlink.It must be emphasized that the maximum throughput values in the table require that the propagation conditions are good enough to support the highest MCS mode.If the propagation conditions are not good enough, the throughput will be lower due to a lower target code rate R and lower modulation order such as Q m = 4 (QPSK) or Q m = 2 (BPSK).

2) MEASURED THROUGHPUT
In this section, results of measured throughput are shown for some parameter settings and compared with the maximum throughput calculated using (3).The measurements are done with about one-meter distance between the base station antennas and the modem antennas.The propagation conditions should therefore be very good.The application used to measure the throughput is iperf3 version 3.9.
First, the effect of using two antennas in the base station is compared to only using one antenna.In Fig. 5, the throughput in downlink and uplink is shown for the three cases: 2 antennas and 20 MHz bandwidth, one antenna and 40 MHz bandwidth, and one antenna and 20 MHz bandwidth.The mean values are shown in Table 3.In the downlink, the throughput using two antennas as 20 MHz is quite similar to the throughput using one antenna and 40 MHz.So the benefit of having more than one antenna element in congested  areas is clear.Reducing the bandwidth to 20 MHz with one antenna cuts the throughput in half.Comparing the measured throughput with the calculated maximum throughput shows that we obtain about 80% of maximum throughput in the downlink.The curves in Fig. 5 show that the throughput varies quite a lot, indicating that the adaptive coding and modulation (ACM) algorithm increases and decreases the MCS mode depending on whether the transmissions are successful or not.In the uplink, the throughput is lower.It is clear from the curves that 2 × 2 MIMO is not supported in the uplink so the throughput is similar to 20 MHz bandwidth independent of a number of antennas.The measured throughput compared to the calculated maximum throughput is lower for all three cases than in the downlink.As the propagation is reciprocal, i.e., the conditions are similar in downlink and uplink, it might seem as if the Simcom modem is better at decoding the signal than the srsRAN gNB.It may be that some of this difference between uplink and downlink performance is a matter of configuration.With so many parameters to be set, it might be that the performance in the uplink can be improved by tuning some parameters.Still, it is likely that limitations in the general purpose processor (GPP) in the workstation is an important cause for the reduced uplink throughput.
Next, the effect of selecting the two supported MCS tables is tested.Fig. 6 shows the measured throughput in downlink and uplink selecting the 64QAM and 256QAM tables, and the mean values are shown in Table 4.The maximum throughput should be reduced by 25% with Q m = 6 compared to Q m = 8.The results confirm this.The downlink curve corresponding to 256 QAM varies much more than the downlink curve corresponding to 64 QAM, indicating that the  variation in data rate is due to fluctuating channel conditions.It is a bit surprising that the 64 QAM curve is stable, but with throughput below the calculated maximum throughput value.If the channel conditions generally are better than the threshold for the highest MCS mode, one should expect higher throughput.
Finally, the throughput is measured for different frame structures.The results are shown in Fig. 7 and the mean numeric values in Table 5.In the downlink, the throughput is above 80% of the calculated maximum values for all the frame structures.For the uplink, the throughput is much lower for all frame structures and even as low as 17% for the DDSUU frame structure.Again, it seems as if the base station is struggling to process the received signal optimally, possibly due to noise introduced by the oscillator, antenna or other parts of the reception chain in the USRP in addition to processing limitations in the workstation.

C. LATENCY
The latency is measured as RTT.The RTT incorporates both UL and DL latency.According to TS 38.913 [21], the target for user plane latency for eMBB should be 4ms for UL and 4ms for DL.The number for URLLC is 0.5 ms for both UL and DL latency.
The RTT can be split into several components.For each direction, the main components are [22]: Data transmission processing latency, data scheduling latency, data transmission delay, and data reception processing delay.Propagation delay is on the order of ns for cell sizes of a few tens of meters, and, therefore, negligible.
The data transmission processing latency is the time it takes for the base station or UE to process data from higher  layers and make it ready for scheduling.Similarly, the data reception processing latency is the time it takes for the base station or the UE to process received data and send it to the upper layers.Both the transmission and reception processing delays are related to the processing capacities of the units.
The data scheduling latency is the time it takes to schedule a packet.In the DL, the base station can schedule data without transmitting any scheduling instructions and does the scheduling and processing in the same time slot.In the UL, the UE must receive scheduling instructions.There are three different modes of UL scheduling [23].In SR-based scheduling, the UE transmits a scheduling request (SR) to the base station.The base station then responds with a transmit UE grant, after which the UE transmits the data according to the received grant.The SR transmission period is typically 5 ms.In pre-scheduling mode, the base station transmits the UL grant periodically so that the UE does not need to send an SR.This reduces latency but may waste resources if the UE does not have any data to transmit.Finally, in Grant Free mode, the UE transmits data without having received any grant.This mode will give the lowest latency and may be used for URLLC, but packets may be lost due to collisions if several UEs transmit at the same time [24].In srsRAN, SR-based scheduling is applied.
The data transmission delay is the time required for packets to be transmitted after being scheduled.In the UL, the UE needs to prepare and process the data based on the scheduling instructions from the BS.In TDD, both the base station and the UE must wait for the right type of slot to transmit.The RTT due to scheduling and waiting can be estimated as illustrated in Fig. 8 for the frame format with 6 DL slots, an S slot and 3 UL slots.Each time slot consists of 14 OFDM symbols, of which the first three contain control information in the DL (PDCCH), and the last two contain control information in the UL (PUCCH).The duration of an OFDM symbol for SCS 30 kHz is 35.7 µs including the cyclic prefix, giving a slot duration of 0.5 ms and frame duration of 5 ms.The time between UL data is available until an SR is transmitted t 1 ranges from 0 ms to 5 ms, as the SR transmission period is typically 5 ms.The time from the SR is transmitted until a UL grant is transmitted t 2 is 1.5 ms.The time until UL data is transmitted t 3 is 3.5 ms, and finally, the time until DL data is transmitted 4 is 1.5 ms.Hence, the part of the RTT due to scheduling ranges from 6.5 ms to 11.5 ms.We will get the same result using other frame structures with a length of 10 slots.If the frame length is reduced to 2.5 ms, e.g., with frame structure DDSUU, the part of the RTT due to scheduling and waiting ranges from 3.5 ms to 6 ms, assuming the SR transmission period in this case is 2.5 ms.
Fig. 9 shows the measured RTT using iputils'(20211215) 'ping' command with an interval of 10 ms and count 1000 for different frame structures.As the interval is a multiple of the 2.5 ms and 5 ms frame lengths, the time between data becoming available until the SR is transmitted remains quite constant.It is, therefore, natural to assume that the periodic nature of the curves is due to the scheduling.The spikes for 5 ms frame lengths occur every 2.5 ms, and the spikes for 2.5 ms frame lengths occur each 1.25 ms.The minimum and mean values are shown in Table 6.For a frame length of 2.5 ms, the minimum RTT is 5.3 ms, while it is around 7 ms for a frame length of 5 ms.Around 10% of the packets report an RTT at the minimum value.The rest are distributed quite evenly until an RTT of 20-25 ms.There may be several reasons why not all the packets report the minimum RTT.It might be that the processing in the base station, in the UE or in both is too slow for the packet to be processed and formatted into the OFDM symbols in time.If that happens, a new SR must be transmitted.There are two parameters in the srsRAN gNB configuration file concerning the SR.One is the maximum number of SR transmissions that take the values 4, 8, 16, 32 and 64, where 64 is the default.The other one is the timer for SR transmission of PUCCH in ms.Varying these two parameters does not significantly change the RTT.

V. DISCUSSIONS
Obtaining a private 5G licence and deploying an opensource 5G SA platform is a great way to get experience with 5G networks, protocols and technologies.In particular, the gNB can be configured through many parameters, which may be difficult to match with more expensive commercial equipment.This means that the performance of the network, to a large extent, can be adapted to the requirements of the users and applications.Also, the capability to inspect log files and pcap files containing information about packets flowing through the various interfaces is valuable.Finally, access to the source code of both the gNB and the 5GC opens the possibility of expanding the platform with functionality not already implemented.
As pointed out in [25], the computational load of 5G NR has grown significantly compared to its predecessors due to among others larger bandwidths, sophisticated LDPC codes and massive MIMO.Meeting stricter requirements of coverage, throughput and latency become increasingly costly with GPPs.In our platform, the entire PHY layer is located in the general-purpose workstation and only the RF part is located in the USRP (functional split 8).In order to achieve the specified performances in terms of throughput and latency, it will be critical to rely on hardware acceleration to offload computational heavy processing to specialized hardware such as graphic processing units (GPUs), data processing units (DPUs), ASICs and FPGAs to meet the performance requirements.The O-RAN Alliance Working Group (WG) 6 are developing standardized hardware acceleration abstractions called Acceleration Abstraction Layers (AALs) [26] and OAI is collaborating with NVIDIA to build an accelerated 5G virtual RAN.No such collaboration seems to be in the horizon for srsRAN.One possible improvement would be however to use a O-RAN compatible RU with 7.2 split instead of the USRP, which would offload the lower PHY functions to the RU.
As already mentioned, one limitation of the USRP is that the transmit power is far below what is allowed by the license.This limits some use cases, for example, connecting moving UEs such as drones or autonomous vehicles, which would be easier with longer range.Moreover, the number of antennas is limited to two in uplink and two in downlink.srsRAN supports up to 4 × 4 MIMO in the downlink.Having more antennas would boost the throughput significantly.Also, the bandwidth supported by the USRP is low, only 20 MHz using antennas.The license allows 80 MHz bandwidth, so the throughput could, in principle, been four times higher.Alternatives to the USRP B210 could be the USRP X310 or USRP X410, or one of the many O-RAN-compliant commercial 5G NR radio units.
The current srsRAN version is well suited to deploy a private 5G SA network.The number of parameters exposed in the configuration file is high and will probably increase as new versions become available.There are, however, some limitations in the current version, such as the SCS that can only be set to 30 kHz in the n77 band, MIMO is only supported in the downlink etc.At some point, it would also be useful if higher frequencies were supported (FR2).Recently, the near-RT RIC was included with limited functionality.It will be interesting if this is expanded, allowing a wider range of xApps to be added.Also, the open5GS version is sufficiently developed to deploy a private 5G SA network, supporting the deployment of multi-slice networks.From a researcher's point of view, it would be interesting if more NFs were included.For instance, a Network Exposure Function (NEF) would make it possible to expose network parameters to third-party applications or, together with information from a near-RT RIC, be used to configure the network using AI/ML techniques, for instance, in a non-RT RIC.Another option would be to include a Location Management Function (LMF) in a similar way as in [13] so that researchers could explore different UE-based and UE-assisted 5G positioning techniques.
The current network configuration is quite simple.It is a pure data network that does not include IMS/VoNR.It contains one cell, so that handover is not an issue.Roaming and any integration of public and non-public networks (NPNs) are not envisioned.It only contains one slice, although open5GS claims to support multi-slice networks.The core network, the RAN and the radio unit are co-located, so any implications of distributed infrastructure are avoided.The current hot topic of NTNs [14] is another feature that is not envisioned.So, although the platform shows good performance, there are many directions one may pursue to develop it further.
The performance of the platform is at such a level that it can be used in some practical use cases.However, certain enhancements are required to facilitate this.A limitation of the platform is that it is not very accessible or portable.It is deployed on a workstation in an office and is not very portable due to weight and form factor.It would be more convenient to install the software on smaller, more portable units or in cloud environments, although this in some cases might lead to poorer performance.The software is installed on bare metal, which does not make it very portable.In continuation, the software should be installed in containers, e.g., using Docker and Kubernetes.There are many configuration and executable files to keep track of when configuring and operating the platform.Some kind of user interface or web service would make it easier for anyone without deep knowledge of the platform to operate it.For many applications, a better radio unit will be required to increase both the coverage and the throughput.

VI. CONCLUSION
This paper has presented a walk-through of a private 5G SA network and key factors that have an impact on the performance in terms of coverage, throughput and latency.The usefulness of the open-source platform to reveal the relationship between configuration and performance has been demonstrated.The implementation also demonstrates the limitations of the platform, as the full potential of the 5G technology is not reached due to limitations in both general-purpose hardware and open-source software suites.The incorporation of hardware accelerators and better radio units together with the continuous development of open source software does, however, have the potential to reduce or close the gaps in performance to commercial closed platforms, in particular for private 5G SA networks.
near-RT RIC from the FlexRIC framework is included in the 23.10 version of srsRAN.It is still under development and only supports the service models ''E2SM_KPM'' and ''E2SM_RC''.Only Control Service Style 2 is supported for E2SM_RC, while all Report Service Styles (1 -5) are supported for E2SM_KPM.The following three dummy DU metrics are exposed: Channel Quality Information (CQI), Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ), while the following ORAN-defined metrics are exposed: UL packet success rate, UE UL throughput, RLC DL packet drop rate, RLC DL transmitted SDU volume and RLC UL transmitted SDU volume.The implemented code contains the xApp KPIMON.It requests information about the RSRP from the RAN through the E2 interface and receives the RSRP as a response.In an expansion of the near-RT RIC, other xApps can subscribe to this information.Currently, the RSRP is periodically printed to a terminal window.

FIGURE 5 .
FIGURE 5. Measured throughput using one and two antennas.

TABLE 3 .
Measured throughput using one and two antennas with a percentage of calculated maximum throughput in parenthesis.

FIGURE 6 .
FIGURE 6. Measured throughput selecting the two MCS tables.

TABLE 4 .
Measured throughput selecting the two MCS tables with percentage of calculated maximum throughput in parenthesis.

FIGURE 7 .
FIGURE 7. Measured throughput for different frame structures.

TABLE 5 .
Measured throughput for different frame structures with percentage of calculated maximum throughput in parenthesis.

TABLE 6 .
Measured RTT for different frame structures.