O-RAN Hierarchical Traffic Management for an Advanced V2X Scenario Covering Emergency and Cybersecurity Services

The 5G and 6G wireless networks are characterized by high heterogeneity, introducing many new services and device types. This poses a serious challenge to Radio Resource Management (RRM) in Radio Access Networks (RANs), due to the various imposed requirements, including those related to throughput, latency, or maintenance of continuity of service. To make the best use of the available radio resources, one of the proposed solutions to cope with such demands is to perform Traffic Steering (TS). In general, TS is responsible for routing user traffic through the most suitable resources, which can be achieved e.g., by performing flexible association of User Equipments (UEs) to Base Stations (BSs). Examples of such approaches include load-balancing techniques or service-based TS.

This blog describes a work that extends the application of TS in the O-RAN framework in the form of Hierarchical Traffic Management (HTM), described in more detail in [1] and presented also here. We evaluate the HTM in a challenging scenario of a heterogeneous network with high mobility, where the behavior and the set of services used by UEs change significantly over time. The considered use case assumes dynamic changes in the network over time, including the appearance of high-priority emergency services, such as Emergency Special Services (ESS) and First Responders (FRs), and a challenging denial of service cyberattack in a high-demand situation. This demo and its outcomes have been presented in a Lightening Talk at the 2024 RIC Forum, March 26-28 2024, Dallas, TX, USA

O-RAN Hierarchical Traffic Management

The proposed HTM approach has been described already in detail here. It makes use of two applications, as presented in Fig. 1:

• Traffic Management (TM) rApp, which observes the network status through the O1 interface, and generates policies controlling the behavior of the TS. It also makes use of the Enrichment Information (EI), such as the traffic route of a vehicle, or emergency service/car arrival, provided from external sources to formulate and apply policies proactively. These policies are then sent via A1 to near-RT RIC.
• Traffic Steering (TS) xApp, which can be controlled with the policies provided by the TM rApp. The TS xApp makes use of the two key features: service-based traffic offloading and load balancing, by associating the users with the BSs, taking into account radio conditions, cell types, cell loads, and service type/QoS profile. The association is performed using handover control messages, being sent from the near-RT RIC to E2 nodes.

The joint use of the two applications in the HTM system provides us the key features, such as automated policy selection, which can be performed based on RAN observation and external EI and per-user/per-slice association decision-taking. This way we can configure the RAN to secure the resources for high-priority services to minimize their outage, minimize the number of handovers, or perform load balancing to maximize the network performance.

In our considered scenario the two Hierarchical Traffic Management applications are deployed using a RAN Intelligent Controller (RIC) provided by VMware and are used to modify the behavior of RAN, which is represented using the Rimedo Labs simulator. We dynamically apply multiple sets of policies, depending on the observed behavior of the network and the expected changes in the environment, indicated in the EI.

Use Case Description of Traffic Management

The demonstrate the use of Hierarchical Traffic Management in a high mobility scenario we consider a use case, where an emergency is happening at the Embassy Suites Hotel, Dallas, TX, USA (ESH – the venue where the 2024 RIC Forum was located). Among the actors involved in this evaluation we can distinguish:

• Vehicular and pedestrian UEs – moving on the streets or sidewalks and using two types of services: Mobile Broadband (MBB), and voice connectivity (VoIP calls).
• Emergency Special Service (ESS) unit – a group of vehicles (police, ambulances, etc.) dispatched to handle the emergency at the ESH. It will appear in the area after the emergency is detected, drive towards the hotel, and stay there to handle the situation. It makes use of the emergency service type, which is characterized by the highest priority and very high throughput, latency, and connection continuity requirements.
• First Responders (FRs) – these are special-type UEs that activate once the emergency is detected and help organize the traffic in the area. The wireless service used by FR is of higher priority than for normal UEs and is characterized by moderate throughput and connection continuity requirements.
• A cyberattack perpetrator, which is one of the First Responders that turns out to be an undercover villain, trying to disrupt the network operation with a Denial of Service (DoS) cyberattack.

The Scenario

In our evaluation we consider a map of part of Dallas city center representing the area surrounding the ESH, as shown in Fig. 2 . The dimensions of the area translate to approximately 1 km width and 600 m height. To model the scenario we used realistic city traffic traces from the SUMO simulator [2], with vehicles and pedestrians moving on the roads and sidewalks, respectively, according to the well-tested following models. There are 6 BS deployed in the whole area: a Macro BS (violet star) and 5 small BSs (green stars). Furthermore, after the emergency event is detected, an Emergency Special Service unit and First Responders appear as a new high-priority UE type.

Time evolution

As we represent a system that evolves dynamically over time, we split the use case into 5 phases depending on the events happening in the system, as shown in Fig. 3. These include:

• Phase A – normal traffic in the city center: vehicular and pedestrian UEs present, using voice or MBB services. The network is moderately loaded.
• Phase B – an emergency event detected at ESH: no changes in the UE behavior and network state.
• Phase C – emergency public services intervene – First Responder UEs activate and the ESS unit starts driving towards ESH. New high-priority and high-volume traffic is present in the network.
• Phase D – special service unit arrives at ESH and the FRs block traffic in the surrounding area: significant increase in network traffic in the central part of the considered area due to new services, traffic jams, and crowd gatherings.
• Phase E – cyberattack: one of FR turns out to be a malicious user launching a DoS cyberattack and trying to overload the network.

Objectives

The main aim we want to achieve when applying Hierarchical Traffic Management is to keep the wireless network operational and as efficient as possible in any scenario we may expect. This includes operation in the:

• Normal mode, where the situation is stable and we want to maximize the QoS of all UEs according to their Slice-Level Agreements (SLAs).
• Emergency mode, where high-priority emergency services will appear in the system, so we want to provide them continuous connectivity according to their requirements, while simultaneously trying to fulfill the SLAs of other UEs if possible.
• Critical mode, where the network operation is endangered by a cyberattack, so we prioritize the security and emergency services to maintain their proper operation, eventually at the cost of reduced QoS of other UEs.

Applied Policies

To facilitate the cooperation of TS-xApp and TM-rApp we make use of the A1-Policy (A1-P) API, where Traffic Steering Preference policies are created in non-RT RIC and sent to near-RT RIC over the A1 interface [3]. To properly react to changes in the environment, and, consequently, in the network, we apply the following sets of policies in consecutive phases:

1. Phase A: a normal mode policy, where load balancing is performed in the network to maximize its performance.
2. Phase B: policy set B is applied proactively and consists of a single policy:
   1. Policy 1: all voice and MBB UEs shall prefer BSs no. 1 and 2 to offload the traffic from the emergency area.
3. Phase C: policy set C is used proactively, accounting for the planned appearance of the Emergency Special Service unit and First Responders. It comprises the following policies:
   1. Policy 1 – already used in Phase B and still maintained active.
   2. Policy 2 – the Emergency Special Service UEs shall be connected to Macro BS and the handover rate for them shall be minimized.
   3. Policy 3 – all UEs other than ESS shall avoid connections to Macro BS.
4. Phase D: policy set D is used in reaction to the increasing load of small BSs no. 4 and 5:
   1. Policy 1, 2, and 3  – already used in Phase C and still maintained active.
   2. Policy 4 – voice UEs shall prefer connections to small BS no. 1 and 3.
5. Phase E: applied in reaction to a cyberattack being detected. It makes use of:
   1. Policy 1, 2, 3, and 4  – already used in Phase D and still maintained active.
   2. Policy 5 – the detected cyberattack perpetrator UE is forbidden access to any of the cells.

You can notice that those policies are applied incrementally, combining them to obtain the required network behavior. However, it is also possible to withdraw some policies with HTM if needed.

Evaluation Results of Traffic Management

To demonstrate the capabilities and performance of Hierarchical Traffic Management we conduct simulation experiments, where we compare the performance of a reference system, that associates UEs with BS based on RSRP measurements only, and a system using Rimedo’s TM-rApp & TS-xApp.  Among the observed parameters we focus on the following:

• network load (per BS),
• number of UEs connected to a particular BS
• UEs outage (in percent)
• Number of handovers performed by the ESS unit.

Table I summarizes the average results obtained in each phase of the use case evolution. We can see that the network is initially (in Phase A) stable and performing well, with an average cell load of approximately 40-50% and no outage observed.

Table I Average results of cell load, number of associated UEs, and UEs outage for selected cells vs. use case phase.

		Phase A		Phase B		Phase C		Phase D		Phase E
		Ref	TS&TM	Ref	TS&TM	Ref	TS&TM	Ref	TS&TM	Ref	TS&TM
Cell 0	Cell load [%]	51.6	51.5	49.5	49.5	52.0	52.9	64.6	94.0	82.8	99.1
	No. UEs	46.0	46.6	43.4	43.4	46.2	42.5	51.7	13.0	56.6	16.2
	UE outage [%]	0	0	0	0	0	0	0	0	36.0	1.6
Cell 3	Cell load [%]	54.9	54.8	55.4	55.3	60.4	58.2	66.7	61.7	72.3	72.5
	No. UEs	44.6	44.6	40.6	40.5	42.1	41.0	49.3	47.8	62.7	64.6
	UE outage [%]	0	0	0	0	0	0	0	0	0	0
Cell 4	Cell load [%]	48.8	48.9	48.5	48.5	50.4	47.6	94.5	46.7	99.9	76.1
	No. UEs	42.0	42.1	42.8	42.8	42.1	39.8	27.1	31.3	69.4	46.3
	UE outage [%]	0	0	0	0	0	0	18.3	0	75.9	1.1
Cell 5	Cell load [%]	37.7	37.6	41.3	41.3	45.3	40.9	70.3	47.6	90.8	65.9
	No. UEs	30.8	30.7	32.0	32.1	29.0	29.5	52.8	37.1	55.5	47.3
	UE outage [%]	0	0	0	0	0.6	0	0	0	55.5	1.3

When we move to phase B, with an emergency call dispatched, there are no changes to the network behavior as users are still unaware of the emergency. However, when Phase C starts, First Responder UEs start activating and a platoon of 3 special service vehicles appears. Network load starts increasing, but remains within acceptable boundaries. Here, upon receiving external information on emergency and special services, the TM-rApp sets new policies (emergency mode) based on provided EI (proactive change), that associates the high-priority services with Macro BS and sets the preference of other UEs towards small cells.

Such an approach pays off when we move into the challenging Phase D, where Special service arrives at the hotel and traffic jams start forming. In this phase, we observe a significant increase in network load due to the presence of new high-priority and demanding services. In such a case the reference system becomes overloaded in cell no. 4, where over 18% of UE outages are noted, which is due to the high demand for resources from the high-priority services. With Rimedo’s TS&TM these are associated with Macro BS, while other UEs are offloaded to small cells, which results in better load distribution (although Macro BS is almost fully loaded) and no outage is experienced.

Finally, we move to the critical point in Phase E, where the Denial of Service cyberattack is launched by one of the First Responder UEs. In such a case the reference network becomes heavily overloaded and a significant outage is experienced (especially in cells no. 4 and 5), which indicates the network is no longer available in this area. With Rimedo TS-xApp & TM-rApp, after the DoS is detected, the access for the malicious UE is denied with a new policy set, and the network stays operational. It manages to maintain continuous connectivity of high-priority services, while also keeping the SLAs of other UEs when possible. With Rimedo’s solution only minimal outage is temporarily experienced, visible in Fig. 4, due to the delay in detection of the DoS attack.

So in general, we can state that during the whole simulation, we observed significant changes in traffic, with high-priority UEs appearing and consuming most of the resources. While the reference systems struggle to provide the necessary services, and a significant outage is experienced, the application of Rimedo’s TS-xApp & TM-rApp results in priority UEs being served mostly by Macro BS, while other UEs are offloaded to small cells. Application of TS&TM provides operational stability even in the case of a cyberattack, where the malicious UE, after being detected, is excluded from service, which results in minimal outage only due to the detection delay. Hence, we can conclude that the O-RAN HTM allows us to keep the network operational and achieve our objectives: minimize outages, particularly for high-priority services, guarantee the QoS, and maximize the network performance.

We also observe the number of handovers performed by the Emergency Special Service unit, presented in Fig. 5. Here, we can observe that with the reference system (on the left) a continuous increase in the number of handovers is observed. With Rimedo’s TS&TM (on the right) only initially a handover is applied to the ESS unit, when it is re-associated with Macro BS, with no more changes observed later. Thus, we conclude that we achieved our 4^th objective: minimization of the number of handovers of the high-priority services.

Summary

In this work, we evaluated the Hierarchical Traffic Management system proposed by Rimedo Labs and comprising two applications: the TM rApp issuing the TS policies, and the TS-xApp responsible for associating UEs with BS according to these set policies. Application of such HTM allows us to keep the network operational in all operation modes, including those particularly challenging: emergency mode with high-priority traffic, and a critical mode, where a DoS attack is launched. With HTM priority is given to the emergency services and FR in the emergency mode, with other SLAs fulfilled when possible. Furthermore, when a DoS perpetrator is detected it is denied service in the considered area to secure correct operation of emergency services. So, in general, we can state that the HTM is a solution providing a flexible and adaptive resource allocation strategy mechanism relying on creating and applying policies, which makes use of the RAN status observations, and, if available, also of the EI provided by external sources.
The approach employing TS-xApp cooperation with TM-rApp, described here, was demonstrated during the 2024 RIC Forum in Dallas, TX, USA, on 26-28 March 2024, organized by the NTIA and U.S. DoD.

You can watch the technical video demonstrating this use case here: O-RAN Hierarchical Traffic Management for V2X Application in an Emergency Situation (Demo)

References

[1] P. Sroka, Ł. Kulacz, S. Janji, M. Dryjański and A. Kliks, „Policy-Based Traffic Steering and Load Balancing in O-RAN-Based Vehicle-to-Network Communications,” in IEEE Transactions on Vehicular Technology, doi: 10.1109/TVT.2024.3399924

[2] P. A. Lopez, M. Behrisch, L. Bieker-Walz, J. Erdmann, Y.-P. Flotterod, R. Hilbrich, L. Lucken, J. Rummel, P. Wagner, and E. Wiesner, “Microscopic Traffic Simulation using SUMO,” in The 21st IEEE International Conference on Intelligent Transportation Systems. IEEE, 2018. [Online]. Available: https://elib.dlr.de/124092/.

[3] O-RAN.WG2.A1AP-R003-v04.01 A1 interface: Application Protocol.

Related blog posts

• V2X Overview, Requirements and Architecture: V2X communications within the 3GPP standards
• 3GPP Rel-18 RAN features: 3GPP Rel-18: 5G-Advanced RAN Features
• 3GPP Rel-18 SA2 features: 5G-Advanced: 3GPP Rel-18 SA2 Features
• Preliminary discussion on 3GPP Rel-18: 3GPP Rel-18: The Preliminary Discussions
• 3GPP Rel-17 overview: 3GPP Rel-17: Way forward within 5G standardization

Author Bio