Policy-Based Traffic Steering and Load Balancing in O-RAN-Based Vehicle-to-Network Communications

Vehicular communication (V2X) is one of the challenging use cases in the context of 5G and beyond networks due to its temporal and spatial dynamics. It is very specific and demanding from the perspective of a mobile network, especially since it covers a wide range of services with different requirements. On the other end, one of the key ideas behind the Open Radio Access Network (O-RAN) concept is to embed intelligence into the RAN to allow network and resource optimization through tailored applications. This is possible due to the introduction of the RAN Intelligent Controller (RIC), along with xApps and rApps. In this paper, we bring both of these worlds together and propose the use of Traffic Management and Traffic Steering applications in V2X scenarios. We also emphasize the usage of enrichment information (EI), enabled by O-RAN, specific to vehicular services (e.g., car platoon geolocation, or emergency situation notifications) which allows for optimal policy control. The numerical results for multiple V2X use cases show that the flexibility, provided by the O-RAN architecture enables optimized handling of the resources through policy control when dynamic changes occur on the road. Thus, we conclude that O-RAN is fit for purpose for the V2X scenarios.


I. INTRODUCTION
A UTONOMOUS vehicles are envisaged as an important part of the Intelligent Transportation System (ITS), aimed at increasing the efficiency and safety of road traffic while maintaining the comfort of passengers.However, with many solutions proposed to realize these paradigms, such as lane assist systems, pre-collision assist, Adaptive Cruise Control (ACC) systems, or automated motion controllers, large amounts of data need to be processed for their proper functioning.A wide variety of onboard sensors (cameras, RADARs, LIDARs) is used to increase the situational awareness of vehicles.These can be complemented with wireless communications between vehicles to further extend the awareness range by exchanging information acquired through sensing.
To address the need for reliable wireless communication between vehicles, the 3rd Generation Partnership Project (3GPP) extended the Long Term Evolution (LTE) standard with the cellular vehicle-to-everything (C-V2X) communications concept, that entails, among others, both the direct vehicle-to-vehicle (V2V) connectivity or vehicle-to-network (V2N) communications [1].This concept has been further extended in the fifth generation (5G) of cellular communications, making use of the new radio interface to increase the capability of C-V2X.Different traffic profiles have been defined: from high-capacity and delay-tolerant traffic, corresponding to infotainment services, to low-throughput and delay-sensitive communications, corresponding to control and mission-critical-related services.Various applications and use cases have been proposed in [2], focusing either on the direct V2X communication using the PC5 interface or involving network elements in V2N mode, where a vehicle communicates with a base station (BS) via the Uu interface [1].This fact, together with the differentiated traffic profiles of V2X, brings the necessity of sophisticated and flexible control of V2X user equipment (UE) from the network side.
Incorporating vehicular UEs in the cellular network brings a significant challenge from the network management perspective, as they are typically characterized by high mobility.The movement of a UE in the network usually requires the user to be switched between the cells to maintain the connectivity, known as the handover.The handover procedure aims to change the BS serving a UE to keep the sufficient quality of wireless transmission and avoid interruptions [3].When V2X communication is considered, handovers are particularly challenging, as any disruptions leading to delays or packet losses are unaffordable for certain services that require Ultra-Reliable and Low-Latency Communications (URLLC).Thus, latency becomes a critical issue in the management of vehicular UEs.
One concept that might help to manage the V2X services to address the low latency requirements is the Open Radio Access Network (O-RAN).More specifically, through O-RAN it is possible to introduce use-case-specific algorithms to optimize the network operations tailored to the actual needs.The idea of O-RAN relies on three main paradigms [4]: r openness -to attract more participants and collaboration of vendors and researchers in the design and implementation process of RAN; r base station disaggregation and virtualization; r intelligence -to enable artificial intelligence (AI) and machine learning (ML) based optimization in RANs for autonomous deployment.As O-RAN architecture relies on virtualization and split of the network functions into a Central Unit (CU), Distributed Unit (DU), Radio Unit (RU), and RAN Intelligent Controller (RIC), it brings the possibility of employing ML algorithms in resource management to act in a predictive way aiming at, among others, minimizing latency [3], [4].However, the O-RAN concept is relatively new when it comes to the analysis of the mobility management problem (specifically in high mobility scenarios), with only initial studies performed so far [3], [5].
High mobility and non-uniform distribution of UEs or their different data traffic requirements may lead to the overloading of certain network parts while the others are underutilized.To handle non-uniform data demand, traffic steering (TS) is considered one of the most important functions in current mobile networks.From the core network perspective, such functionality has been standardized in Release 16 (5G phase II) in the form of the Access Traffic Steering, Switching, and Splitting (ATSSS) [6].It introduces the so-called multi-access protocol data unit (PDU) session, for which the data traffic can be served over one or more radio access technologies (RATs).However, in this work, we concentrate only on the RAN domain, thus ATSSS is not considered.Mobile Network Operators (MNOs) may set different policies for TS operation considering a set of inputs (e.g., radio conditions, UE capabilities, available RATs and RAT-specific features, etc.).When it comes to the TS application with high mobility, various solutions have been proposed.A TS solution for path selection and multipath searching algorithms for mobile-edge computing networks is proposed in [7].A latency-oriented dynamic TS is proposed in [8] using the availability of both Uu and PC5 interfaces.Furthermore, a traffic routing-based computation offloading problem for the Internet of Vehicles is studied in [9].
In the RAN area, TS is considered a function to control the UE-to-BS association.It may be related to a single connection (through handover or cell reselection), or multi-connectivity (using e.g., a dual connectivity (DC) mode).More work on TS has been performed in O-RAN, where dedicated virtualized functions, known as xApps, are deployed within RIC [4].ML-based handover management is considered in [3], [10].A similar solution is proposed in [11], employing user access control mechanisms based on reinforcement learning.Finally, a joint traffic prediction, dynamic user association, and radio resource management framework are proposed in [12] for O-RAN deployment.Recently, in [13], the authors have proposed a joint optimization framework to achieve flow-split distribution, congestion control, and scheduling with the ultimate goal of intelligent traffic steering.However, neither of the mentioned works truly considers the TS problem in the O-RAN architecture, accounting for the variety of properties and requirements of different V2X services.
In this paper, we propose a two-stage approach to the TS problem in O-RAN.Here, the Traffic Steering xApp (TS-xApp) deployed with a Near-Real Time (Near-RT) RIC is responsible for UEs associations to BSs, while the steering process is performed according to a policy selected in Traffic Management rApp (TM-rApp) running within the Non-Real Time (Non-RT) RIC.The main contributions can be summarized as follows: r We show through computer simulations that the proposed two-tier TS approach adapts to the changing conditions and traffic requirements via a policy change, significantly reducing the need for handovers of V2N connections while maintaining the required service quality for the prioritized V2X applications.The remainder of this paper is structured as follows: Section II brings the details of envisaged O-RAN architecture and selected use cases in the context of V2X communications.Section III introduces the details of the proposed policy-based approach to traffic steering in O-RAN.Section IV presents the outcomes of the conducted simulation experiments, explaining the details of the three considered use cases.Finally, Section V concludes the work.

II. O-RAN ARCHITECTURE IN THE CONTEXT OF V2X
The open RAN concept, as defined by the O-RAN AL-LIANCE follows the principles of open interfaces, RAN disaggregation, hardware-software split, and native intelligence introduced by a new element in the RAN networks called RAN Intelligent Controller (RIC) [14].
In this chapter, we present the overall O-RAN architecture as specified by O-RAN ALLIANCE, introducing nodes and interfaces.Later, we discuss two use cases related to the V2X scenario within O-RAN specifications, namely, Traffic Steering tailored to V2X and context-based handover optimization for V2X.One of the key items in this discussion is the use of Enrichment Information (EI) which can include V2X-related data to improve the efficiency of the optimization and is also treated by the O-RAN standards.

A. O-RAN Architecture Overview
The O-RAN architecture (see Fig. 1), specified within O-RAN ALLIANCE, is built upon the 3GPP standard for 5G.It follows the idea that the O-RAN architecture, with all interfaces, shall be consistent with the corresponding 3GPP architecture and interfaces to the extent possible [15].To comply with this, the O-RAN standards adopt the RAN function split and Control Plane (CP) -User Plane (UP) split from 3GPP.O-RAN architecture also supports Non-Standalone (NSA) and Standalone (SA) 5G The architecture of Non-RT RIC, including the interaction with rApps and the operation using the corresponding A1 interface, is specified in [16].The rApps interact with the Non-RT RIC framework using the standardized R1 interface.The A1 interface, in turn, is responsible for providing the A1 policies, EI, and ML models to the Near-RT RIC.The rApp can create, modify, or delete policy, which can be provided to other rApps or to the Near-RT RIC (to be consumed by xApps) [16].In addition to that, the enrichment information can be delivered by Non-RT RIC.EI can be utilized by the rApps or sent over the A1 interface to the Near-RT RIC (to be consumed by the xApps) to support the policy with additional data to help optimize the network operation.Examples of EI are e.g., user location information, RF fingerprinting, radio environment maps, etc.In Fig. 1, one more aspect is shown, namely input to the Non-RT RIC from external sources.This is defined within [16], and allows obtaining EI from, e.g., external location servers, databases, applications, Operations Support Systems (OSS), or even provisioned as manual input from human operators.This is useful, in particular, in the advanced V2X scenarios, where the Non-RT RIC could get the information about, e.g., approaching car platoons, so that it can adjust the policies.

B. O-RAN Traffic Steering Use Case in V2X Context
Traffic steering is defined and described in the O-RAN AL-LIANCE documents ( [17], [18]), as one of the basic programmability use cases to be adopted in O-RAN networks.This is especially important in a multi-access system, where there is a need to switch traffic across various access technologies, spectrum bands, and transmission nodes, based on system changes in the radio environment, and application requirements and possibly split the traffic across those technologies and nodes (e.g., using DC feature) to satisfy performance requirements [17].
It is more and more inevitable that the customized and individual approach to traffic distribution to the transmission nodes and user-to-cell assignment is required to fulfill the variety of QoS types (e.g., low latency, high throughput).In the traditional approaches, the control is limited to adjustment of the cell reselection and handover parameters, or cell priorities.This makes those methods cell-centric and, in consequence, treats all the UEs similarly, i.e., focusing on average performance requirements, rather than being UE-specific.Thus, the key point for this use case is to change it by allowing operators to flexibly configure the optimization policies, on a per-UE/per-service type/per-slice fashion to enable intelligent and proactive traffic management (leveraging ML schemes) using different objectives depending on the application [17].
An additional optimization may be done when the EI would be available to support the decision-making by the TS-xApp.As an example, the Near-RT RIC detects cell congestion, and it requests analytics from Non-RT RIC via A1-EI, used as supporting input by the xApp to take decisions aiming at decreasing the congestion.

C. O-RAN Handover Optimization in V2X Network
There is another use case related to vehicular communication within O-RAN ALLIANCE documents, namely: "Context-Based Dynamic Handover Management for V2X".It addresses a scenario where vehicles travel along a highway, and due to their high speed and the heterogeneous environment, V2X UEs are handed over frequently, sometimes in a suboptimal manner.This, in some cases, causes handover (HO) anomalies, like short stays, ping-pongs, call drops, etc.Such handover issues may impact the V2X applications, which are typically sensitive to latency performance.The mentioned use case aims at avoiding or resolving those by using navigation and radio statistics to enable customization of HO sequences on a per-UE level utilizing ML functionality.In addition to resolving those issues, the use case aims at helping to better utilize and adjust radio resource allocation policies through O-RAN architecture by, e.g., reducing latency [17].
As mentioned, the V2X HO optimization aims at the minimization of handover anomalies for V2X UEs and can be split into the following two applications/functions (see the top part of Fig. 2) [19]: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.r First, long-term analytics using AI/ML algorithms are employed at the Non-RT RIC in the form of an rApp.V2X AS keeps the UE-based HO events and mobility data which are shared with Non-RT RIC.Therefore, the rApp can identify causes of HO anomalies and derive optimized HO sequences (i.e., sequences of cell changes taking into account the direction, speed, service types, etc.).In addition, a database is maintained to keep track of resolutions to anomalies.
r Second, near-real-time optimization is performed, offered by the trained ML model in the Near-RT RIC within an xApp.The xApp would monitor UE-specific mobility context.A deployed ML model can be used to detect and predict unexpected HO events and generate desired HO sequences to decrease the amount of HO anomalies.Those HO sequences are fed to the E2 Nodes to invoke proper handover decisions.The xApp may also maintain UE-specific Neighbor Relations Tables (NRTs) to improve the performance of the V2X users.

D. Joint HO Optimization and Traffic Steering for V2X
One can imagine a combined approach utilizing both use cases, as described in II-B and II-C.In this approach, the xApps and rApps would jointly optimize the network operations for V2X scenarios, including handover anomaly minimization, radio resource utilization, and performance improvements for individual users.
It should be noted, however, that using those algorithms as separate functions could lead to conflicts due to the distinct applications affecting handover parameters, but for different purposes.While TS focuses on optimal resource distribution and individual user QoS fulfillment, V2X HO optimization focuses on avoiding HO anomalies.Therefore, the combined approach would require deriving a co-designed xApp/rApp in which both optimization goals are taken into account jointly.Alternatively, one could let the conflict mitigation function mitigate the potential conflicts [20].

III. O-RAN-BASED POLICY-BASED TRAFFIC STEERING FOR V2X
Following the Open RAN architecture overview and the concise description of the use cases related to V2X scenarios from the previous chapter, let us now provide the details of the proposed hierarchical policy-based traffic steering in the vehicular communications context.The considered approach assumes the presence of a policy-oriented rApp that observes the state of the network and analyzes the EI available from external databases (sources) and, in consequence, generates the appropriate policy for the underlying TS-xApp.

A. Considered Scenario
In our work, we concentrate on a heterogeneous C-V2X network, where macro and micro base stations deliver various services to pedestrian and vehicle users.By assumption, a macro Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

TABLE I TRAFFIC TYPES CLASSIFICATION
cell covers a wide geographical area, fulfilling the requirement of the so-called coverage layer, whereas the micro base station provides high capacity and lower latency.The microcells are deployed as the so-called road-side units (RSUs) in such locations where it is needed from the perspective of the traffic hot spots; RSUs are also deployed along the highway to support specific traffic flows generated by vehicle users.Let us recap that, following [21], an RSU is not an architectural entity; it is an implementation option and is achieved by collocating a V2X application logic/server with other 3GPP system entities.Without the loss of generality, we limit the analysis to a scenario with a single macro cell coverage area, where a set of microcells is located and where a multi-lane highway crosses the macro cell.The exemplary scenario is illustrated in Fig. 2.Moreover, we assume the presence of two types of UEs: pedestrian UEs (pUEs), which are distributed randomly across the entire considered area, and vehicle UEs (vUEs), which travel along the street.From the wireless transmission perspective, the pUEs may generate possibly two traffic types, mainly voice data (VD, representing low-data rate case) and mobile broadband data (MBB, representing high-data rate case).Besides these two traffic types, vUEs may generate three other classes of wireless data flows.The first one corresponds to autonomous platooning (AP) and is characterized by low latency, high reliability, and high data rate.The second one is associated with emergency services (ES), where extremely high data rates and reliability are considered; moreover, a very high priority in accessing wireless resources is assumed.Finally, the dedicated class of traffic relates to the case where multiple sensors and elements on the road and inside cars cooperate for better car driving; here, we refer to the common sensing (CS) case.These five classes of traffic are compared in Table I.A specific setup of these traffic classes is presented in the next section, where the simulation use cases are discussed.

B. Problem Identification
In the context of Open RAN, the installed applications -xApps and rApps -may be delivered independently by various solution providers.Such an approach causes each application to behave independently, yet hierarchical dependencies may be created.Moreover, the operator may specify various target optimization functions that will be executed by the Traffic Steering xApp (TS-xApp).In our paper, we exemplify the above situation by defining the optimization goal as the minimization of outage probability achieved by minimizing the number of handovers (thus reducing the control traffic load) and balancing the cell load across the base stations.The constraints to this optimization problem are constituted by the requirement of fulfillment of all service level agreements for each type of UE regardless of its location.In the proposed approach, the number of handovers is minimized, and the load among the cells is balanced with the use of a traffic steering algorithm, which associates the users among the cells in the network based on the detected network status.The association of UEs to base stations is done based on the received signal power modified by the artificially added offsets, which are, in turn, specified by the traffic management application, whose role is to define the general rules of UE management.
A separate aspect related to the hierarchical approach deals with the security of the solution and the privacy of the data used in such an approach.The way the policies are defined and executed, as well as how the EI is obtained and used in the O-RAN system, is particularly crucial from the perspective of security.Various security threats have been identified [23], [24].On the other hand, the policies may be defined to protect the system from cybersecurity attacks.These aspects, although important, are left for further study.

C. Policy Based Traffic Steering
In the considered scenario, we assume that the wireless network supporting C-V2X functionality tries to achieve various key performance criteria (KPC) for the served pUEs and vUEs.In particular, the overall network outage (understood as a number of UEs not being served properly according to their service requirements) should be minimized (see the relevant discussion in II-B).Next, the load among the base stations in the network shall be balanced, i.e., it should be avoided that specific BS is over-or under-loaded compared to the others.The micro BSs are deployed to improve capacity in specific areas and to minimize latency for latency-sensitive data flows; however, for the vUEs, especially when the velocity is high, the number of consecutive handovers should be minimized to reduce the CP load and to avoid frequent connection disruptions (see the relevant discussion in II-C).The relations among the above KPCs may be fixed for a given network, or they may be flexible and policy-dependent.
Having this in mind, we propose an Open RAN-oriented solution for elastic wireless traffic control in vehicular networks.In detail, as shown in Fig. 2, a dedicated TM-rApp is running in a large time-scale control loop (in terms of seconds or more), which observes specific network parameters via the O1 interface, analyzes them, and performs an action to improve network performance.I.e., it generates an O-RAN-compliant policy and delivers it via the A1 interface to the Near-RT RIC and finally to the registered and subscribed TS-xApp.Once the decision is made, the TM-rApp continues observation of the network status and makes new decisions if possible or necessary.Moreover, TM-rApp has access to external sources of data, which may influence its decisions.Let us recap that this kind of information Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
is accessed as EI.In particular, in our analysis (as it will be illustrated later) we consider that there could be access to the anonymized, planned trace and time of all autonomous platoons of cars.When the autonomous convoy starts its route, it has to know the exact final destination and such information can be shared and possibly accessed by the TM-rApp; finally, the TM-rApp may adjust the policy for traffic steering based on the current and predicted position of the platoon.Another external source of information considered in our work is related to emergency situations.Similarly to the above example of autonomous platooning, also the access to anonymized data of the route event can be distributed widely across the road users.Moreover, the driving path of emergency services (such as ambulances, police cars, fire trucks, etc.) can also be shared, thus improving wireless resource management.
Once the policy is decided, generated, and sent to the Near-RT RIC, it is then delivered to the TS-xApp.The applied policy rules the ways how the TS-xApp is steering the traffic in the underlying networks by forcing specific actions in the E2 Nodes.The proposed TS solution executes the TM-rApp guidelines (defined in the form of the policies) on one hand side, thus realizing the service-based traffic steering.On the other hand, the TS-xApp tries to balance the load among all wireless nodes.
It is worth noticing that once the changes forced by the TS-xApp are applied and executed in the E2 Nodes, the overall effect is permanently monitored by both TS-xApp and TM-rApp (via E2 and O1 interfaces, respectively).When necessary, appropriate adjustments are made.
In the following subsections, we are describing in detail the proposed solution for traffic management and steering for V2X applications.
1) TM-RApp Design and Policy Definition: In the proposed solution, the long-term analysis is carried out by the TM-rApp, which cooperates with the Near-RT RICs and influences the behavior of the associated TS-xApps.The proposed TM-rApp optimizes network performance by continuously monitoring the state of the network through the O1 interface.The observed parameters are primarily the loads on individual cells (i.e., the number of allocated resource blocks, number of users, and number of connections), as well as the presence and location of vehicles.In addition, the type of traffic (e.g., by means of required throughput) generated by vehicles is distinguished.In our research, we assumed that the ultimate goal is to minimize the outage probability (i.e., to minimize the number of unserved users) in the whole network, considering the hierarchy of importance of specific users.In particular, there might be types of traffic that have to be served without any problems or have priorities over other types.In our case, emergency services (like ambulances or fire trucks) belong to the highest class of traffic that has to be served without any disturbance.Moreover, to preserve the highest security level on the road, autonomous vehicles are assumed to be treated with higher priority compared to, e.g., traditional MBB traffic generated by pedestrians or vehicular drivers.In addition, the second goal is to minimize the number of handovers in the network; thus, if possible, the vehicular users shall be served by the macro base station so that the number of cell switches is reduced to a minimum.Finally, when all of the above aspects are fulfilled, the assumption is to keep the traffic load among the base stations at a similar level (i.e., balanced).
Going into more detail, in the case of the presence of vUE users who require MBB or voice traffic, an attempt is made to steer the traffic in such a way as to minimize the number of handovers of the indicated users.When it is impossible to provide the minimum number of handovers for V2N users of both types of traffic (e.g., there are too many users in the network), the optimization focuses mainly on vUE users generating voice traffic (because of the latency requirements for the voice services).The minimization of the number of handovers for vUEs of the MBB type is undertaken, but in the second place, which results in only a partially decreased number.With significant traffic, only Voice vUE users are subject to such optimization.Next, suppose a route of a platoon of autonomous cars runs through the serviced network area (at the indicated time).In that case, these users have a high priority to minimize the number of handovers to meet the reliability requirements.Finally, in the case of obtaining information about an accident or other critical event, vehicles using the emergency services get a reservation of resources at the strongest station and receive priority over other users.Traffic generated near the accident (other than the emergency vehicle) is diverted to the nearest station, which is relieved by other (more distant) users.
We assumed that the proposed TM-rApp can impact wireless traffic management at a high level by generating appropriate policies understood and taken into account by TS-xApp.The policy may indicate the rules applied while serving different types of traffic.It may be achieved in various ways, yet in our proposal, we have modified the effective received signal strength by adding specific, policy-based offsets to the reports on received power (the idea is similar to the one used in the cell-range extension procedure, known also as cell biasing [25]).Let us consider the following simplified example -there are two stations denoted as S 1 and S 2 , and one UE is trying to connect to the network.Let the UE observe the received power at the level of P 1 and P 2 , respectively, and P 1 > P 2 .In the regular case, the user will be associated with the first base station.However, the TM-rApp-originated policy may cause the effective received power visible at the network level to be modified by adding a specified offset.I.e., the policy may indicate that for a specific type of user (e.g., voice), the received signal strength from the first base station has to be modified by adding an offset ξ, so the effective received power at the network level will be P 1 + ξ.By properly selecting the offset, one may achieve that P 1 + ξ < P 2 , and, consequently, the UE will be associated with the second BS.
In our implementation, we have followed the O-RAN standards defining the policy types and ways how they are generated [26].The following policies have been used and applied to set the preferences of the association of specific user traffic types with certain BSs: r Policy SHALL -enforces the association of certain traffic to a specific cell(s); r Policy FORBID -is opposite to SHALL as it forbids the association of specific traffic to certain cell(s); r Policy PREFER -in the context of specific traffic type association, it sets a higher preference for an indicated cell among other cells (however, contrary to SHALL it does not force the user to be connected to a specific cell); r Policy AVOID -similar to PREFER case, in the context of specific traffic type, it sets a lower preference for an indicated cell among other cells (however, contrary to FORBID, it does not prevent the user from being connected to a specific cell).To exemplify the standardized policy applied in the experiment, we present the AVOID policy represented in JSON in Annex 1.The generic procedure responsible for policy selection is presented in Algorithm 1.

D. Traffic Steering and Load Balancing Xapp Design
Using O-RAN's service models, the TS-xApp takes control of UE HO decisions.In our design, the xApp subscribes to A3-Events received from UEs by E2 Nodes.The messages forwarded to the xApp indicate measurements of received power from serving and neighbor cells (e.g., RSRP) and other UEspecific parameters (e.g., 5QI, QoS flow, etc.).Based on this information, the TS-xApp makes a handover decision for a UE with traffic type i from a serving cell, S 1 , to a target cell, S 2 , according to the following formula: In the formula, ξ 1,i and ξ 2,i denote the individual offset for traffic of type i defined for S 1 and S 2 , respectively.By controlling these offset values, service-based steering is accomplished.The values of the offsets are defined (thus may be modified in time) by the policies generated by the TM-rApp and delivered to TS-xApp through the Near-RT RIC.The pseudocode for this approach is presented in Alg. 2. In addition to the serviceoriented offsets, we introduced the additional term responsible for the distribution of load among the base stations.Such an offset is denoted as ξ LB  1,2 and depends on the current PRB usage of both cells.The TS-xApp registers to periodic PRB usage reporting of all connected cells, which is also defined as O-RAN's E2SM-KPM.Given the PRB usages U 1 and U 2 for S 1 and S 2 respectively, the load-based offset is calculated as: where C is a controllable parameter determining the aggressiveness of applied load balancing.More details about the TS xApp can be found in [27].

E. Application of the ML Tools
Naturally, the logic presented behind both applications -TM-rApp and TS-xApp -may be realized in various ways.The selection of the most promising policy and its definition, as well as the setup of the decision thresholds, may be done in the form of predefined heuristics, as described in both presented algorithms' pseudocodes.However, with the rapid advancement of AI/ML solutions, there is space for the implementation of such approaches as well.Based on the observations of the user movement, traffic patterns, and other parameters, the implemented AI tool may provide the answer to which policy from the predefined set would be the most promising, given the current network state.Moreover, the policy itself could be automatically generated based on the observed parameters describing the network and the data provided as EI.Similar conclusions can be drawn for the thresholds and offsets applied in the traffic steering algorithms.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.In our research, we have trained the selected AI models over various user deployments and used these models to find the best policy from the available set in TM-rapp.In particular, we considered Logistic Regression (LR), Linear Discriminant Analysis (LDA), k-Nearest Neighbours (KNN), Classification and Regression Tree (CART), Naive Bayes (NB), and C-Support Vector Machine (SVC).

IV. SIMULATION SCENARIO
In the prepared simulation, a fragment of a multi-lane road (3 km long) along which there is a sidewalk and several perpendicular sidewalks (150 m long) was considered.There were cars with different speeds and different types of traffic on the road.Pedestrians walked on sidewalks and used MBB or Voice traffic.The whole road and pedestrian mobility model has been created using SUMO [28], providing a realistic representation of vehicles and human behavior.An illustration showing the topology under consideration is shown in Fig. 3.A division into 20% of MBB users and 80% of Voice users was adopted, unless specified explicitly otherwise.The mobility models from the SUMO environment have been included in the Rimedo RAN simulator, used for emulation of the above-mentioned wireless network.
All simulations have been carried out using a 5G network model, where one macro base station and four small base stations have been deployed.We have concentrated on the downlink transmission.The operated in FDD mode with the center frequency of 1.8 GHz, bandwidth of 20 MHz, andfollowing 3GPP notation -base numerology of 15 kHz subcarrier spacing.The maximum transmit power for the BS was set to 40 dBm and for SC -to 30 dBm.The gain of the transmitter antenna on both types of base stations was set to 15 dBi.The base stations (E2 Nodes) connect via a standard compliant E2 interface to the commercial Near-RT RIC.The TS-xApp subscribes to the necessary parameters reported to the Near-RT RIC by the controlled base stations.The TM-rApp communicates with Near-RT RIC via the A1 interface following the O-RAN specifications and delivers standard-compliant policies.Using the logical O1 interface, it also collects necessary information from the network to make a reliable decision regarding the policy definition.
For path loss calculation, we have applied the 3GPP TR 38.901 channel model (Urban Macro for BS, and Urban Micro for SC).The UEs have been classified as defined in Table I, and the traffic requirements of each user have been mapped into the number of requested resource blocks based on the Shannon formula for a certain signal-to-interference-plus-noise-ratio (SINR) and then adjusted due to link level performance for 5G networks (TR 38.803).At the same time, we treat the user as being in an outage if its observed SINR value is below the threshold or there are not enough resources to fulfill the allocation requirement of this user.The trajectory of users has been generated using SUMO environment [28], where the speeds of pedestrians and vehicles were dynamically changing according to their mobility models, with the maximum values set to 5 km/h and 130 km/h, respectively.All the simulations have been realized in the form of a computer-driven experiment, using the commercially available RAN Intelligent Controller provided by VMware (called distributed RIC, dRIC).The TS-xApp and TM-xApp communicate via the dRIC and emulated E2 and A1 interfaces.Moreover, the EI about the platoon and ambulance location and trajectory was assumed to be accessible from the remote servers.
To verify the effectiveness of the proposed architecture, we have defined four use cases, which have been evaluated in terms of observed network performance -outage and cell load.The three initial use cases should be considered single-run examples, where we intentionally present the time interactions between the TM-rApp and TS-xApp over the simulation time.They should be treated as specific examples of the application of the proposed approach in the V2X context.However, to guarantee statistical reliability, we have included the fourth use case, where the results do not show a specific realization but are averaged over tens of runs.In this part, we also discuss the performance of the proposed AI tools.In detail, the following use cases have been defined: r Use Case A: here, we simulate the situation where there is a traffic change on the road during rush hours.We start with low car traffic; next, in the first phase, we continuously increase the car density, and in the second phase, we decrease it.The idea here is to illustrate the policy-based traffic steering and load balancing on the long-term scale due to the change of policies.
r Use Case B: after showing the traffic steering and manage- ment concept in regular traffic conditions, in the second use case, we concentrate on the short period where a platoon of autonomous cars is driving over a specific area.We assume that information about the prospective route of the platoon is available in the form of EI at the TM-rApp, whichbased on the observation of the vUE location -is able to proactively prepare a new policy and send it to the Near-RT RIC to be applied within TS-xApp.
r Use Case C: in the last use case, we are evaluating the impact of the sudden event (like a car accident) on the behavior of the wireless network.We start with regular low-traffic cases.At some specific point in time, a road event is signalized (car crash, car damage, etc.), and in consequence, the cars start the procedure of coordinated lane change (so, a new type of wireless traffic appears).It will result in a traffic jam on the road near the road event.Moreover, after some time the emergency service car is coming, which has the highest priority in accessing wireless resources for sending data.The TM-rApp utilized the knowledge obtained from the emergency system databases to apply appropriate policy for such a situation and deliver it back to the RICs.
r Use Case D: It is conceptually the same as Use Case B, where a platoon of cars enters the serving area.However, to present the general performance improvement of the proposed solution of TM-rApp and TS-xApp, the results have been averaged over numerous realizations.In this case, we also present the results achieved by incorporating ML tools for policy selection in TM-rApp.

A. Use Case A: Low and Dense Road Traffic
This use case represents a scenario where a significant increase in road traffic is experienced temporarily, e.g. during rush hours or after an event is finished.Only voice and eMBB UEs are considered here.Initially, the simulation starts with approximately 100 vUEs and 220-250 pUEs deployed on the road and sidewalks, respectively.Cars travel along the motorway with a velocity of up to 130 km/h.After t = 100 s the density of cars starts increasing, representing the wave of cars coming in rush hours, reaching its peak of 250 vehicles on average on the road at t = 200 s.The road traffic remains then constant until time instant t = 350 s is reached.At this moment the average number of vehicles starts decreasing, reaching finally the average of 150 vehicles at the end of the simulation.The average number of pedestrians is constant for the whole simulation duration.
In this use case, during the whole analyzed time, TM-rApp sustains policy for pUEs to forbid association to the macro cell.
In the marked timestamps (indicated also in Figs.4-6) the following TM-rApp behavior is observed: r timestamp A -TM-rApp detects low road traffic, so policy for both Voice and MBB UEs inside cars (i.e., SHALLpolicy for macro cell) is created and sent to Near-RT RIC; r timestamp B -TM-rApp detects a slightly increased num- ber of UEs (near the limit of macro cell capacity), so the policy for Voice UEs inside cars (i.e., SHALL-policy for macro cell) is sustained, but the policy for MBB UEs inside  cars is modified (i.e., from SHALL-to PREFER-policy for macro cell); r timestamp C -TM-rApp detects an even higher number of UEs (again with the current setup -near the macro cell capacity), so the policy for Voice UEs inside cars (i.e., SHALL-policy for macro cell) is sustained, but the policy for MBB UEs inside cars is modified (i.e., from PREFERto FORBID-policy for macro cell) as the macro cell is not able to serve both types of UEs inside cars; r timestamp D -TM-rApp detects a higher number of UEs (this time macro cell cannot serve all Voice UEs inside cars), so the policy for Voice UEs inside cars is modified (i.e., from SHALL-to PREFER-policy); r timestamp E -TM-rApp detects the lower number of UEs; and applies policies mentioned in timestamp C; During this simulation, we can observe the number of UEs of both types in Fig. 4.This figure reflects the discussed changes in the generated traffic inside the network.Next, in Fig. 5 the average number of handovers done by voice UEs is shown, whereas in Fig. 6 -the average number of handovers done by MBB UEs is presented.One can observe that in line with the applied policies, in the first phases, the selected policies have minimized the handover counts of both voice and MBB users.However, when the overall number of users in the served area increases significantly, causing resource scarcity issues at the Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.macro base station, the decision was to keep the quality of service at the highest possible level while increasing the control traffic (i.e., increasing the handover count).Let us note that the visualized scenario may not be in line with the priorities specified by a certain operator.The adjustment of the TM-rApp and TS-xApp by the operator is of course possible, as well as the individual definition of new policies, so the specific needs of the operator may be met.

B. Use Case B: Autonomous Platooning
This use case aims to evaluate the operation of the proposed scheme in a scenario where a group of prioritized UEs arrives in the network.Such a situation is represented here with a platoon of autonomous vehicles moving along the motorway in a coordinated manner, maintaining short inter-vehicle distances and an average velocity of 90 km/h.Due to the use of autonomous controllers in platoon vehicles, a new service type is considered here apart from voice and eMBB UEs, namely AP as defined in Table I.It is characterized by a high data rate, extremely high reliability, and low latency requirements; thus, it should be prioritized by traffic steering policies.A platoon of 5 vehicles is considered here, arriving on the road at time instant t = 100 s and traveling along the considered section of the motorway up to t = 230 s.Appearance and detection of such a platoon should result in traffic offloading from macro BS, as the AP communication is prioritized.The average number of other vehicles and pedestrians, in this case, is similar to the initial state of simulation in use case A and remains approximately the same for the whole simulation time.
In this use case, TM-rApp detects the presence of a platoon.TM-rApp can also obtain the route and timetable of the platoon from some remote database in the form of enrichment information.TM-rApp creates a policy to move all UEs in the platoon from the nearest small cells to the macro cell -to avoid multiple handovers along the road.In Fig. 7, the moment of entering and leaving the platoon in the considered area can be indicated (marked as timestamp A).Please note that the number of non-platoon UEs is not changed in the simulation, so it is not visualized here.In Fig. 8, an average number of handovers made by V2N UEs (in the platoon) can be found.As can be seen, in the case of TM-rApp presence, the number of handovers in this area can be reduced to a minimum (denoted by the red curve).In particular, there was no need for handover for the platoon members at all, being the effect of the new policy upload.When there is no policy for protecting AP traffic, one may observe the increasing number of total handovers in time.This stepwise increase in V2N handover count reflects the route of the platoon in the considered area -it switches the cell to the closest one as it travels along the highway.One may conclude that by utilization of the access to EI information, the rApp may prepare in advance appropriate policy and upload it; once it is available in the TS-xApp, it will manage the UE association with the BS to achieve expected goals (in the considered case -reduction of the control traffic via frequent handover).

C. Use Case C: Car Accident and Emergency
Use case C, considered in this paper, represents a scenario where one of the vehicles crashes on the road and emergency life-saving service is required.Hence, a connected ambulance vehicle will appear to collect any passengers requiring immediate medical attention.In this case, the simulation starts with normal road traffic, where the average number of vUEs and pUEs is around 130 and 220-250, respectively.At the time t = 100 s one of the vehicles crashes and emergency service is called.A connected ambulance appears on the road at t = 150 s and reaches the crash position at t = 250 s.It stays there for 180 s to collect any persons requiring medical assistance, and finally leaves, exiting the considered road section at t = 470 s.The crashed car causes a slowdown or even a small traffic jam, with the average number of vehicles on the road increasing to approximately 160.As the connected ambulance makes use of a variety of ES, such as ultrasound video, 4 K video streaming, or life monitoring devices [22], it requires a very reliable, low-latency, and extremely high-data rate connectivity.Moreover, as it is considered a life-saving service, it will be of the highest priority when traffic steering is applied.As the crash site is considered a hazardous area, vehicles approaching it introduce a new type of service -CS -related to their increased sensing and mobility coordination activities, requiring moderate data rate and low latency (Table I).In this use case, at the moment of the car accident detection (indicated in figures by the vertical line), cars that stop (or slow down near a speed equal to zero) change the required traffic type from MBB or Voice to CS V2N.Such a situation leads the TM-rApp to create policies that emergency V2N UE shall be served by the macro cell (to avoid handovers) and at the same time, the network will avoid handling pUEs by the macro cell (to leave some more resources for emergency services).Then TM-rApp creates a policy to serve CS V2N UEs, which means that for such types of UEs, the association with the nearest small cell will be preferred (the location of the accident is known), and for pUEs the association with such small cell will be avoided (to leave some more resources for CS V2N UEs).As a result, we can observe similar behavior of TM-rApp in emergency V2N UE, as in the previous use case, i.e., in platoon UEs.The number of handovers with the presence of TM-rApp is reduced to a minimum due to the policy set by the TM-rApp, which moved emergency V2N UEs to the macro cell (SHALL preference).This can be seen in Fig. 10.The challenging situation that is considered in this use case can be seen in Fig. 9, where the total PRB usage of all cells was plotted (a significant increase of required resources is visible).However, TM-rApp logic will handle this situation, not only in terms of emergency V2N UE handovers but also in terms of overall outage observed in the network, plotted in Fig. 11.One may observe that the overall PRB usage in the network in both cases (with and without rApp) is similar (with a slight advantage for active rApp cases), and increases significantly as the emergency services are detected in the network.At this point, when no TM-rApp is running, the situation becomes hard from the wireless communication perspective -a high user outage is observed and emergency cars face frequent cell handovers.The application of TM-rApp enhances the overall network performance, as by the proper uploading of the adjusted policy, the observed UE outage is reduced, and no handover is observed for the high-priory user.

D. Use Case D: Averaged Performance for Autonomous Platooning
As discussed earlier, this use case is a form of generalization of Use Case B. Here, the presented results are averaged over numerous realizations to indicate what is the true, situationindependent performance of the proposed solution.In particular, we assume three variants of the percentage of MBB users in the whole UE population: 0%, 10%, and 20%.Moreover, there were three different movement trajectories of all users generated in the SUMO environment.Next, we repeat the simulation 10 times, randomly classifying the users as Voice or MBB according to the specified percentages and also averaging the results over all four available policies (i.e., operate normally, apply AVOID policy to voice users, apply AVOID policy to MBB users, apply AVOID to both types).In consequence, the presented results correspond to 3 × 10 × 4 = 120 different simulations for each fraction of MBB users.Each single experiment represents 2300 simulation steps, which correspond to 230 seconds of real traffic, where 1300 steps in the middle refer to the presence of the platoon in the considered area.Before and after that period (so 500 steps before the arrival of the platoon and 500 steps after), the network operates in its typical mode.These results illustrate what is the overall performance of the system regardless of the UE distribution, movement trajectory, and heuristically selected policy.However, as stated above, the selection of the best policy for the given network status could be subject to ML-based inference.Thus, in this experiment, we also provide the results Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.for the TM-rApp supported by the AI classifiers that select the best policy for the given situation.In the evaluation phase, six algorithms were tested, mainly Logistic Regression (LR), Linear Discriminant Analysis (LDA), k-Nearest Neighbours (KNN), Classification and Regression Tree (CART), Naive Bayes (NB) and C-Support Vector Machine (SVC).The AI models have trained over 400-time steps before the platoon arose by observing the cell load for each considered base station.In Fig. 12, we present the achieved accuracy for the evaluated algorithms.Based on these results, for the final implementation, we have selected LDA and incorporated it in the final algorithm running in TM-rApp.
Below, we present the averaged results for mean cell loads for macro (Fig. 13) and small cells (Fig. 14) as a function of time.One can easily notice the moment of appearance (50 s) and disappearance (180 s) of the platoon in the observed area, and the changes in the cell load distribution.In all cases, the application of the ML scheme, compared to the heuristic approach, illustrates the performance improvement in the form of reducing the load at a macro base station and increasing the load among the small cells.Such an approach results also in outage reduction, as illustrated in Figs. 15 and 16.   for various applications in vehicular scenarios.This can be realized by utilizing specialized xApps and rApps and the overall RIC framework.
To this end, in this paper, we have analyzed the application of O-RAN architecture and relevant use cases along with V2Xspecific enrichment information through O-RAN interfaces.Next, we proposed a TM-rApp and TS-xApp pair to optimize resource utilization, minimize handover signaling, and assure QoS requirements for V2X use cases.In this, several scenarios have been tested reflecting the dynamic nature of vehicular communications in real life like car traffic load variations, car platoon passing through or car accidents, traffic jams, and ambulance arrival.We have shown that a single xApp managing the user-to-cell association can efficiently handle those various situations when being properly controlled by policies delivered from the TM-rApp which overlooks its operation.The resource handling can be improved even more, when adding the EI, taking into account application-specific information, like (in the case of V2X) geolocation, service type, emergency services, or carplatoon tracking.Compared to the situation of lack of TM-rApp usage, when having such, we can avoid network congestion, and assure demanding QoS for dynamically changing situations.

rr
We analyze the O-RAN architecture from the perspective of V2X scenarios along with a detailed analysis of the relevant use cases, including the potential xApp conflicts; r We propose a two-tier optimization of traffic steering based on short-term TS-xApp decisions and long-term TM-rApp guidance; We consider three different use cases representing different possible scenarios of V2X applications;

Algorithm 2 :
Traffic Steering policy application.

Fig. 4 .
Fig. 4. Use Case A: Number of vUEs with split to different traffic demand.

Fig. 12 .
Fig. 12. Use Case D: Achieved accuracy score for considered AI models.

Fig. 13 .
Fig. 13.Use Case D: Mean cell load at macro base station over time.

Fig. 14 .
Fig. 14.Use Case D: Mean cell load at small cells over time.