Open-radio access network node and methods therein, in a communications network

Abstract

A method performed by an Open Radio Access Network (O-RAN) node is provided. The method is for preventing a conflict caused by one or more applications in a Radio Access Network (RAN) of a communications network. The one or more applications is operating in the O-RAN node and communicates with an E2 node through a network interface. The E2 node is a RAN node that terminates the network interface. The O-RAN node receives (401) one or more first requests from the first application. These one or more first requests is requesting an action related to an E2 service towards the E2 node. The O-RAN node observes (402) actions of the first application related to the requested E2 service performed in the E2 node. The O-RAN node, based on the observed actions, identifies (403) the action related to the E2 service as a possible cause of conflict in the RAN. The O-RAN node classifies (404) the identified action related to the E2 service as a conflict-causing action related to the E2 service for the first application. The O-RAN node prevents a conflict caused by the identified action related to the E2 service related to the first application. The O-RAN node prevents the conflict by evaluating (405) a second 15 request from the first application. This second request is requesting the action related to the E2 service. The evaluation is performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO. The O-RAN node prevents the conflict by masking (406) the requested action related to the E2 service through the 20 network interface. The masking of the E2 service comprises one or more out of: a blocking of the action related to the E2 service for the first application and a diversion of the action related to the E2 service of the first application to the DT node. The DT node is a digital twin of the E2 node.

Description

[0001] OPEN-RADIO ACCESS NETWORK NODE AND METHODS THEREIN, IN A

[0002] COMMUNICATIONS NETWORK

[0003] TECHNICAL FIELD

[0004] Embodiments herein relate to an Open Radio Access Network (O-RAN) node and methods therein. In some aspects, embodiments relate to preventing a conflict caused by one or more applications in a Radio Access Network (RAN) of a communications network.

[0005] BACKGROUND

[0006] In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and / or User Equipment (UE), communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point, a Base Station (BS) or a radio base station (RBS), which in some networks may also be denoted, for example, a Base Station (BS), a NodeB, eNodeB (eNB), or gNodeB (gNB) as denoted in Fifth Generation (5G) telecommunications. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on a radio frequency with the wireless devices within the range of the radio network node.

[0007] 3rd Generation Partnership Project (3GPP) is the standardization body for specifying the standards for the cellular system evolution, e.g., including 3G, 4G, 5G and the future evolutions. Specifications for Evolved Universal Terrestrial Radio Access (E- UTRA) and Evolved Packet System (EPS) have been completed within the 3GPP. In 4G also called a Fourth Generation (4G) network, EPS is core network and E-UTRA is radio access network. In 5G, 5G Core (5GC) is core network, NR is radio access network. As a continued network evolution, the new release of 3GPP specifies a 5G network also referred to as 5G New Radio (NR) and 5GC.

[0008] Frequency bands for 5G NR are being separated into two different frequency ranges, Frequency Range 1 (FR1) and Frequency Range 2 (FR2). FR1 comprises sub-6 GHz frequency bands. Some of these bands are bands traditionally used by legacy standards but have been extended to cover potential new spectrum offerings from 410 MHz to 7125 MHz. FR2 comprises frequency bands from 24.25 GHz to 52.6 GHz. Bands in this millimeter wave range have shorter range but higher available bandwidth than bands in the FR1.

[0009] Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. For a wireless connection between a single user, such as UE, and a base station (BS), the performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. This may be referred to as Single-User (SU)-MIMO. In the scenario where MIMO techniques is used for the wireless connection between multiple users and the base station, MIMO enables the users to communicate with the base station simultaneously using the same time-frequency resources by spatially separating the users, which increases further the cell capacity. This may be referred to as Multi-User (MU)-MIMO. Note that MU-MIMO may benefit when each UE only has one antenna. The cell capacity can be increased linearly with respect to the number of antennas at the BS side. Due to that, more and more antennas are employed in BS. Such systems and / or related techniques are commonly referred to as massive MIMO.

[0010] In a typical wireless communications network, the RAN controls the access of the UE to the communications network and its radio resources. The radio resources may be allocated to the UEs in the form of Physical Resource Blocks (PRBs) for downlink and uplink communication. A RAN node uses standardized interfaces and control processes to allocate radio resources to the UEs and improve their quality-of-service. The RAN node may e.g., be eNB, gNB and their disaggregated forms i.e. , Central Unit-Control Plane (CU-CP), Central Unit-User Plane (CU-UP) and Distributed Unit (DU).

[0011] Traditionally, 3GPP has been the standardization forum for the specification of the RAN nodes, interfaces, and their internal functionality. The Open-RAN (O-RAN) alliance is a forum that aims to bring more openness, intelligence, and interoperability to the RAN via specification of new RAN functions and interfaces. Figure 1 shows some of the main functional blocks and interfaces of the O-RAN architecture that are relevant herein. The O-RAN architectural elements in Figure 1 includes a Service Management and Orchestration (SMO) platform, a Non-Realtime RAN Intelligent Controller platform (Non- RT RIC), a Near-Realtime RAN Intelligent Controller platform (Near-RT RIC), enhanced RAN interfaces and RAN control and optimization applications. The enhanced RAN interfaces may e.g., be A1 interface, 01 interface and E2 interface as seen in Figure 1. The RAN control and optimization applications may e.g., be xApps for Near- RT optimizations and rApps for Non-RT optimizations. The Near-RT RIC platform hosts the xApps that assist the RAN nodes by providing control and optimization solutions based on Artificial Intelligence (Al) and / or Machine Learning (ML). The RAN nodes in the O-RAN may be referred to as E2 nodes.

[0012] The xApps are third party control applications that use the E2 Interface and its standardized service models for RAN performance optimization. The service models in the E2 interface may be referred to as E2 Service Models (E2SMs). The service models such as e.g., E2SM-RAN Control (E2SM-RC) define services for data collection and RAN control over E2 interface. Using the E2 interface and E2SMs, the xApps collect data for analysis from the RAN nodes such as E2 nodes. The xApps then use this data together with Al and / or ML algorithms to generate proposals for control and optimization of RAN nodes in the O-RAN i.e. , E2 nodes. Finally, the xApps exercise these generated proposals over the internal functionality of the E2 nodes via direct control through the E2 interface. The xApps may suspend, resume and / or override the default control processes in an E2 node with its generated proposals based on these standardized E2SMs.

[0013] The rApps, running on the Non-RT RIC platform also aim to optimize the performance of the RAN in non-real-time intervals, by sending policies and enrichment information to the Near-RT RIC. These policy and enrichment information may be sourced externally to the receiving Near-RT RIC. The policies provide scope and resources to the Near-RT RIC which are then used as inputs by the Near-RT RIC and the corresponding xApps for optimization of the E2 nodes by using E2 control actions. The scope e.g., RAN nodes, slices, UE groups may refer to targets within the RAN for which the policy may be applied. The resources suggested and / or indicated by the rApps for optimization may e.g., be radio resources and QoS flows. The E2 control actions performed by the Near-RT RIC and the xApps may e.g., be allocating specific radio resources to UEs and triggering UE handovers.

[0014] SUMMARY

[0015] As part of developing embodiments herein, the inventors identified some problems that first will be described.

[0016] Since xApps have direct control over the operations of the E2 nodes in an O-RAN, the xApps play a central role in the overall O-RAN control architecture and are critical for the stability and performance of the RAN. It is important that the control actions performed by the xApps do not cause any conflicts and adverse effects when overriding the default control functionalities of the E2 nodes. Conflict may e.g., refer to any situations in the RAN where the RAN performance gets degraded or unnecessary scenarios emerge due to incorrect and / or contradictory E2 control and / or policies executed by the xApps on the E2 nodes using the E2 interface. Examples of the conflicts may be (i) direct conflicts such as e.g., xApp-1 and xApp-2 requesting to set contradictory values to a certain parameter for the E2 node and / or the UE, (ii) indirect conflicts such as e.g., xApp-1 aiming to handover some of the UE’s load to a different cell for load balancing by setting handover offsets while xApp-2 working to improve cell coverage for the same UE via antenna tilt optimization, and (iii) implicit conflicts such as e.g., xApp-1 working to allocate more resources to improve the performance of the Guaranteed Bit Rate (GBR) users while xApp-2 working to allocate more resources to improve the performance of the non-GBR users over the same physical resources.

[0017] The xApps may be developed independently by third party developers and so their actions to control the RAN can cause unintended conflicts with the actions of other xApps or with the internal default functionality of the E2 nodes which are provided by E2 node vendors. It is difficult for an xApp developer to test for and design the xApp such as to avoid all conflicts with other third party xApps and E2 nodes’ functionality in a real RAN environment. Therefore, the Near-RT RIC platform, being the host and service provider to xApps, comprises a conflict mitigation function in the Near-RT RIC platform which is responsible for avoiding such conflicts by providing guidance to the xApps and other Near-RT RIC platform functions that control access to E2 control actions for E2 nodes.

[0018] Figure 2a shows the standard Near-RT RIC Architecture defined in O-RAN, with the conflict mitigation function highlighted. The conflict mitigation function is responsible for mitigating or avoiding the above-stated conflict types e.g., direct conflicts, indirect conflicts and implicit conflicts in an O-RAN.

[0019] Despite having a conflict mitigation function in the Near-RT RIC platform of the O- RAN to mitigate the different conflict types as mentioned above, there are some limitations to the conflict mitigation function in the current specifications of O-RAN, as described below.

[0020] It is unspecified when the conflict mitigation function be requested for guidance by xApps and what information will be returned as guidance by the conflict mitigation function to assist an xApp in avoiding conflicts. When the conflict mitigation function returns a guidance information to the xApps, there are no standardized stage-3 Application Programming Interfaces (APIs) provided in the specification to infer this information, making it impossible for an xApp designer and / or a vendor to encode the logic for seeking guidance from conflict mitigation function in the Near-RT RIC.

[0021] The O-RAN specifications for conflict mitigation in the Near-RT RIC platform do not make the conflict mitigation function fully responsible to perform conflict mitigation. An xApp is not mandated to seek guidance from the conflict mitigation function before executing its E2 control actions. Thus, the xApp designer may design the xApp such that its application logic requiring to seek guidance from the conflict mitigation function may be an optional feature.

[0022] It is unclear how the Near-RT RIC platform keeps track of any guidance information it provided to a particular xApp. It is also unclear what the Near-RT RIC platform does to check if the provided guidance was considered by the xApp i.e., whether an xApp modified its E2 control action if it was provided guidance to do so.

[0023] It is expected that the guidance from the conflict mitigation function will suggest an xApp to modify its E2 control actions to avoid causing conflicts. Such modifications are very subjective and will be difficult to realize in practice for general guidance.

[0024] It is unclear what knowledge the conflict mitigation function will base its guidance on such as e.g., whether it is based on design-time knowledge on what types of conflicts to detect and prevent or runtime configurations or realtime learning from observation of the RAN.

[0025] It is unspecified how the Near-RT RIC will prevent an xApp from exercising E2 control actions. As per the current O-RAN architecture, an xApp may e.g., be removed, uninstalled, disabled and / or reconfigured by the SMO to prevent it from conflicting behaviour. It is unspecified how and what to reconfigure on xApps for preventing conflicts when xApps’ configurations are likely based on third party implementation. Also, these methods of preventing an xApp from exercising E2 control actions require the intervention of entities external to the Near-RT RIC to assist in conflict mitigation.

[0026] According to the O-RAN standard specifications of Near-RT RIC architecture and APIs, when the applications such as e.g., an xApp gets instantiated, it establishes its connectivity, identity, and authorization with the Near-RT RIC comprising the Near-RT RIC platform with the conflict mitigation function by using standardized application registration procedure. The applications may be operating in the Near-RT RIC and communicates with the O-RAN node 111. As part of this registration procedure, the applications inform the Near-RT RIC about the A1 policies it can enforce and the E2SMs it needs to use over the E2 interface for that purpose. In response, the applications receives an application identifier such as e.g., a Universally Unique Identifier (UUID) string from the Near-RT RIC in case of success. Figure 2b shows the standard application registration procedure.

[0027] 201. Registration request

[0028] The registration request is sent by the application such as e.g., xApp to the Near-RT RIC comprising the Near-RT RIC platform. The request carries the description of the application e.g., description of the xApp, required APIs and data types, list of supported A1 policy types and list of E2SMs.

[0029] 202: Registration processing

[0030] The registration processing is performed by the Near-RT RIC upon receiving the request from the application. The processing comprises validating the received request from the application. After validation, the Near-RT RIC assigns an application identifier to the application and creates an application Managed Object Instance (MOI), a configuration object for the application such as application in the Near-RT RIC.

[0031] 203: Registration response

[0032] After processing of the request, the Near-RT RIC sends a registration response to the application. The response comprises a successful registration and carries the UUID based application identifier.

[0033] There are stage-3 details of the request and response messages in Figure 2 as described in Actions 201 and 203 to show the information is passed in these flows. The stage-3 details herein refer to the information carried in the request and response messages. However, Action 202 is unspecified and therefore unclear on what steps are involved in e.g., the validation of an application performed by the Near-RT RIC. The validation may pertain to checking any one or more out of: whether the required APIs, data types, A1 policies and listed E2SMs are available in the O-RAN node 111 to facilitate the operation of the application. Also, the registration response message described in Action 203 does not carry sufficient information in the standard procedure to inform the application whether it has access to some or all of its requested E2 services. The success response in Action 203 is currently a binary yes or no response and only communicates a registration failure in case of failure or sends an application identifier in case of successful registration. An object of embodiments herein is to improve the handling of conflicts caused by applications in a RAN of a communications network.

[0034] According to an aspect of embodiments herein, the object is achieved by a method performed by an Open Radio Access Network, O-RAN, node. The method is for preventing a conflict caused by one or more applications in a Radio Access Network, RAN, of a communications network. The one or more applications is operating in the O- RAN node and communicates with an E2 node through a network interface. The E2 node is a RAN node that terminates the network interface. The O-RAN node receives one or more first requests from the first application. These one or more first requests are requesting an action related to an E2 service towards the E2 node. The O-RAN node observes actions of the first application related to the requested E2 service performed in the E2 node. The O-RAN node, based on the observed actions, identifies the action related to the E2 service as a possible cause of conflict in the RAN. The O-RAN node classifies the identified action related to the E2 service as a conflict-causing action related to the E2 service for the first application. The O-RAN node prevents a conflict caused by the identified action related to the E2 service related to the first application. The O-RAN node prevents a conflict by evaluating a second request from the first application. This second request is requesting the action related to the E2 service. The evaluation is performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO. The O-RAN node prevents a conflict by masking the requested action related to the E2 service through the network interface. The masking of the E2 service comprises one or more out of: a blocking of the action related to the E2 service for the first application and a diversion of the action related to the E2 service of the first application to the Digital Twin, DT, node. The DT node is a digital twin of the E2 node.

[0035] According to another aspect of embodiments herein, the object is achieved by an O- RAN node. The O-RAN node is configured to prevent a conflict caused by one or more applications in a Radio Access Network, RAN, of a communications network. The one or more applications is operating in the O-RAN node and communicates with an E2 node through a network interface. The E2 node is a RAN node that terminates the network interface. The O-RAN node is further configured to receive one or more first requests from the first application. The one or more first request are requesting an action related to an E2 service towards the E2 node. The O-RAN node 111 is further configured to observe actions of the first application, related to the requested E2 service performed in the E2 node. The O-RAN node is further configured to based on the observed actions, identify the action related to the E2 service as a cause of conflict in the RAN. The O-RAN node is further configured to classify the identified action related to the E2 service as a conflictcausing action related to the E2 service for the first application. The O-RAN node is further configured to prevent a conflict caused by the identified action related to the E2 service related to the first application. The O-RAN node prevents the conflict by further configuring the O-RAN node to evaluate a second request from the first application. This second request is requesting the action related to the E2 service. The evaluation is adapted to be performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO. The O-RAN node prevents the conflict by further configuring the O-RAN node to mask the requested action related to the E2 service through the network interface. The masking of the E2 service is adapted to comprise one or more out of: a blocking of the action related to the E2 service for the first application, and a diversion of the action related to the E2 service of the first application, to the Digital Twin, DT, node, which DT node is a digital twin of the E2 node.

[0036] Thanks to that the O-RAN node can mask the E2 service for the conflict-causing actions performed by the first application, the O-RAN node is able to prevent conflicts in the RAN. This will result in an improved handling, mitigating and / or avoiding of conflicts in the RAN of the communications network by only masking the specific action of the first application that is causing conflicts in the E2 node of the RAN rather than isolating, disabling and / or uninstalling the application completely.

[0037] Embodiments herein may provide one or more of the following advantages:

[0038] - They prevent conflicts occurring in the E2 node. This is achieved by transparent diversion of the control actions of the applications towards the DT node thereby avoiding performance degradation in the E2 node. The DT node may be a sophisticated simulated equivalent of the E2 node exposed via the network interface or a more generic network interface simulator that responds to the E2 service requests. - They profile the application for conflict mitigation by diverting their actions related to E2 services towards the DT node and observing any conflicts caused in that DT node to gather knowledge on the potential conflicts of the application in the E2 node.

[0039] - They prevent the application from harmful interferences in the RAN without blocking, reconfiguring or un-installing the application completely from the O-RAN node.

[0040] - They selectively mask features of the E2 services from an application at runtime and in a fine-grained manner to prevent it from e.g., controlling the E2 node, controlling UE groups, using certain E2SMs and using specific services from an E2SM.

[0041] - They enable the O-RAN node to have full control on conflict avoidance in the RAN instead of delegating it to the applications’ design-time implementation or runtime functionality.

[0042] - They relieve the application designers from identifying potential conflicts with other applications’ actions at design and implementation stage of the application. The application can assume that the O-RAN node will always be responsible for preventing conflicts with other applications and conflict with the default functionality of the E2 node.

[0043] - They infuse conflict mitigation knowledge in the O-RAN node from the SMO and its respective applications, realizing a conflict mitigation solution that is driven from runtime knowledge gathered over the network interface as well as configured knowledge from the SMO.

[0044] - They enable to learn direct, indirect, and implicit conflicts caused by multiple applications at runtime by using Al and / or ML and DT node. This is achieved by profiling the application’s E2 sessions as control loops and their impact on the RAN performance.

[0045] - They enable to validate and / or generate conflict mitigation information in the O- RAN node.

[0046] BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Examples of embodiments herein are described in more detail with reference to attached drawings in which:

[0048] Figure 1 is a schematic block diagram according to prior art.

[0049] Figure 2a is a schematic block diagram according to prior art.

[0050] Figure 2b is a combined signaling scheme and flowchart according to prior art.

[0051] Figure 3 is a schematic block diagram illustrating embodiments of a communications network.

[0052] Figure 4 is a flowchart depicting an embodiment of a method in an O-RAN node. Figure 5 is a combined signaling scheme and flowchart according to an example embodiment of a method herein.

[0053] Figure 6 is a combined signaling scheme and flowchart according to an example embodiment of a method herein.

[0054] Figure 7 is a combined signaling scheme and flowchart according to an example embodiment of a method herein.

[0055] Figure 8 is a schematic block diagram illustrating embodiments of an O-RAN node.

[0056] Figure 9 schematically illustrates embodiments of a communication system.

[0057] Figure 10 is a generalized block diagram of embodiments of a UE.

[0058] Figure 11 is a generalized block diagram of embodiments of a network node.

[0059] Figure 12 is a generalized block diagram of embodiments of a host.

[0060] Figure 13 is a generalized block diagram of embodiments of a virtualization environment.

[0061] Figure 14 is a generalized block diagram of embodiments of a communication diagram of a host.

[0062] DETAILED DESCRIPTION

[0063] Examples of embodiments herein provides a way for conflict mitigation in the O- RAN node by selective masking of the E2 interface services at runtime. The O-RAN node may e.g., be the Near-RT RIC such as e.g., the Near-RT RIC platform, an Open Central Unit Control Plane (O-CU-CP) with embedded Near-RT RIC functionality. Example embodiments herein improves e.g., the conflict mitigation function in the Near-RT RIC platform in the O-RAN node e.g., the Near-RT RIC. According to example embodiments herein, the masking of the E2 service enables the O-RAN node, e.g., the Near-RT RIC comprising the Near-RT RIC platform with the conflict mitigation function, to block the application from controlling the RAN at coarse and / or fine-grained manner. The application may e.g., be an xApp comprised in the Near-RT RIC. Masking herein may e.g., refer to blocking and / or diversion of the communication of the application e.g., xApp from the E2 nodes to their digital equivalents i.e. , Digital Twin node at runtime. The blocking of an application from controlling the RAN may e.g., be to block the application from RAN nodes, UEs and / or E2 services available to the application at runtime. The RAN nodes in the O-RAN may herein be referred to as E2 nodes. The E2 node may e.g., be a RAN node that terminates the E2 interface. The E2 node may e.g., be an O-CU-CP, an Open Central Unit User Plane (O-CU-UP), an Open Distributed Unit (O-DU), and an Open-eNB (O-eNB). O-RAN and RAN may herein be used interchangeably and refer to an Open-RAN. Similarly RAN node and O-RAN node may be used interchangeably but refers to any RAN node e.g., eNB, gNB, CLI-CP, CU-LIP, DU in an Open-RAN architecture. Embodiments herein provide a DT node comprised in the O-RAN node e.g., Near-RT RIC platform. The DT node may be maintained by the O-RAN node as a platform function or may be external but accessible to the O-RAN node via standardized network interface such as e.g., E2 interface. In some embodiments, the masking of the E2 services by the O-RAN node e.g., Near-RT RIC platform services is transparent to the application e.g., xApp and the masking avoids the application to be reconfigured, uninstalled, removed and / or isolated from the O-RAN node for the purpose of conflict mitigation.

[0064] The conflict mitigation function comprised in the O-RAN node may be involved in the control loop for all E2 related actions performed by the application. A control loop is e.g., marked by upstream data inputs to an application such as e.g., xApps from E2 nodes and downstream control and configuration actions from the application to the E2 nodes. These actions may be performed by the application using the standard Application Programming Interfaces (APIs) for the application subscription management function comprised in the O-RAN node. The subscription management function is the functionality in the Near-RT RIC platform that acts as the gatekeeper to the E2 services and E2 nodes. According to example embodiments herein, when the application sends an E2 RIC subscription request towards a specific E2 node or UE using a standardized or proprietary E2SM, the application subscription management function in the O-RAN node may seek guidance from the conflict mitigation function in the O-RAN node. The E2 RIC subscription request is a standardized E2 service request over E2 interface. This guidance may be to decide whether the requested action is rejected completely, allowed and performed on the real E2 node, or allowed and performed on the DT node which is an equivalent of the E2 node. The DT may be a sophisticated simulated equivalent of the actual E2 node exposed via the network interface e.g., E2 interface or a more generic network interface simulator that responds to E2 service requests. The conflict mitigation function comprised in the O- RAN node may take responsibility of the conflict mitigation job as it may effectively block the impact of the application on the RAN in coarse or fine-grained manner. This may be achieved e.g., by blocking all the application requests for a specific E2 nodes and / or UE, by blocking specific E2 services belonging to a certain E2SM or by performing time-based diversion of the application request towards the DT node. The knowledge of which application to block from which E2 services or specific E2 nodes, may be provided to the conflict mitigation function by the SMO via the network interface such as e.g., 01 interface configuration. This information may be learned by the conflict mitigation function comprised in the O-RAN node using Al and / or ML while monitoring the service requests of the applications and their impact on the RAN performance. Assuming a good correlation between the real E2 node and the DT node, the examples of embodiments herein may also be used to validate or improve the guidance provided by the conflict mitigation function in the O-RAN node.

[0065] Figure 3 is a schematic overview depicting a communications network 100 wherein embodiments herein may be implemented. The communications network 100 comprises one or more RANs, such as RAN 105, and one or more CNs such as CN 106, which communicate with a server 140. The communications network 100 may use 5G NR but may further use a number of other different technologies, such as, 6G, Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications / enhanced Data rate for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

[0066] RAN nodes, such as the O-RAN node 111, the E2 node 112, and the DT node 107 operate in the RAN 105 of the communications network 100 and communicate with each other using the network interface 150. The RAN nodes 111, 112, 107 may each be a transmission and reception point e.g. a radio access network node such as a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), an NR Node B (gNB), a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, or any other network unit capable of communicating with UEs, such as a UE 121 , within a cell, served by the respective base station 111 , 112. The respective RAN nodes 111 , 112 may be referred to as a serving radio network node and may communicate with the UE 121 with Downlink (DL) transmissions to the UE 121 and Uplink (UL) transmissions from the UE 121. The RAN 105 referred to herein may e.g., be an Open-RAN (O-RAN).

[0067] RAN nodes, such as e.g., O-RAN node 111 , may operate in the RAN 105 and communicate with the server 140 to host the applications 141, 142 comprised in the server 140. The O-RAN node 111 communicates with the E2 node 112 through the network interface 150. The network interface 150 may e.g., be an E2 interface. In some embodiments, the O-RAN node 111 may comprise e.g., the DT node 107 e.g., as a function. In some embodiments, the O-RAN node 111 may e.g., be represented by a Near-RT RIC comprising the Near-RT RIC with the conflict mitigation function.

[0068] RAN nodes, such as e.g., E2 node 112, may operate in the RAN 105 and communicate with the O-RAN node 111 using the network interface 150. The network interface 150 may e.g., be an E2 interface. In some embodiments, the E2 node 112 may e.g., be represented by an E2 node in O-RAN, a RAN node comprising Central Unit (CU) and Distributed Unit (DU), eNB, gNB, Open-CU (O-CU)-Control Plane (CP) and Open-CU (O-CU)-User Plane (UP), Open-DU (O-DU).

[0069] RAN nodes, such as e.g., DT node 107, may operate in the RAN 105 and communicate with the O-RAN node 111 through the network interface 150. The DT node 107 may e.g., be a digital twin of the E2 node 112. The DT node 107 may e.g., be a digital twin of one or more E2 nodes such as e.g., E2 node 112. In some embodiments, the DT node 107 is external to the RAN 105 and may act as a Distributed node (DN) and its functionality e.g., comprised in the cloud 170. In these embodiments, the DT node 107 communicates with the O-RAN node 111 through the network interface 150. In some embodiments, the DT node 107 may e.g., be represented by a simulated RAN.

[0070] One or more UEs operate in the communications network 100, such as e.g. the UE 121. The UE 121 may represent a client 120 communicating with the server 140 using a transport layer protocol e.g., QUIC. The data connection between the UE 121 and the CN 106 may be via RAN nodes e.g., O-RAN node 111 and E2 node 112. The UE 121 may e.g., be a wireless device, an NR device, a mobile station, a wireless terminal, an NB-loT device, an MTC device, an eMTC device, a CAT-M device, a WiFi device, an LTE device, a wired device and a non-access point (non-AP) STA, a STA. It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, client, mobile client, IMS client, wireless communication terminal, user equipment, Device to Device (D2D) terminal, or node e.g., smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a car or any small base station communicating within a cell.

[0071] Servers, such as e.g., server 140, operate in the communications network 100. The server 140 comprises the applications 141 , 142. The applications 141 , 142 may e.g., be xApps and Self-Organizing Network (SON) applications. The applications 141, 142 communicate with the E2 node 112 and the DT node 107 through the O-RAN node 111 via the network interface 150 such as e.g., E2 interface. In some embodiments, the applications 141, 142 may be operating in the O-RAN node 111.

[0072] Methods according to embodiments herein are performed by the O-RAN node 111. This node may be Distributed Nodes (DN) and functionality, e.g. comprised in a cloud 170 as shown in Figure 3.

[0073] Examples of embodiments herein provide a method to mitigate conflicts in the RAN 105 by masking the E2 node 112 and / or the network interface 150 such as e.g., E2 interface from the applications 141 , 142 that are suspected of causing conflicts. The masking of the network interface 150 may be performed by blocking the request from the applications 141, 142. In this case, the applications 141, 142 may be aware that the applications 141, 142 are being blocked. The masking of the network interface 150 may also be performed by diversion of the requests from the application to a DT node 107. In this case, the applications 141 , 142 may not be aware that the applications 141, 142 are being blocked.

[0074] Some embodiments herein enable the O-RAN node 111 comprising e.g., the conflict mitigation function to avoid or mitigate conflicts in the RAN 105 and / or the E2 node 112 without the need to isolate, disable and / or uninstall the applications 141 , 142 that are causing the conflicts. Moreover, depending on the sophistication of the DT node 107 and its alignment with the real E2 node 112, embodiments herein may be used to validate or test the applications 141 , 142 for suspected conflicts thereby improving the guidance provided by the O-RAN node 111 comprising e.g., the conflict mitigation function. In some embodiments, the knowledge of which action related to the E2 service to mask and when to mask from a specific application such as e.g., application 141 is provided by the SMO. In these embodiments, the SMO configures the O-RAN node 111 with the conflict mitigation information via the network interface 150 such as e.g., 01 interface. The knowledge of which action related to the E2 service to mask and when to mask from a specific application such as e.g., application 141 may be obtained by the O-RAN node 111 by performing profiling of the application 141 using Al and / or ML. Profiling of the application 141 may e.g., be based on both evaluating the actions of the application 141 in the E2 node 112 and in the DT node 107 where a profile gives an indication of possible conflicts that may be caused if the requested actions is allowed. A number of embodiments will now be described, some of which may be seen as alternatives, while some may be used in combination.

[0075] A method according to embodiments will first be described as seen from the view of the O-RAN node 111 together with Figure 4.

[0076] Figure 4 shows exemplary embodiments of a method performed by the O-RAN node 111. In some embodiments, the O-RAN node 111 is represented by any one out of: a Near-Real Time, Near-RT, RAN Intelligence Controller, RIC, comprising a conflict mitigation function.

[0077] The method is for preventing a conflict caused by one or more applications 141 , 142 in a Radio Access Network, RAN, 105 of a communications network 100. In some embodiments, the conflict is between one or more out of: the first application 141 , the second application 142, the E2 node 112. The one or more applications 141, 142 may e.g., be an xApp. The one or more applications 141, 142 is operating in the O-RAN node 111. These applications 141 , 142 communicate with an E2 node 112 through a network interface 150. The network interface 150 may e.g., be an E2 interface. The E2 node 112 is a RAN node that terminates the network interface 150. In some embodiments, the application such as the first application 141 communicates with one or more E2 nodes 112 resulting in conflicts in the one or more E2 nodes 112 in the RAN 105. The conflicts may e.g., be contradictory control and / or configuration requests to the E2 nodes. The E2 node 112 may be represented by any one out of: an E2 node in O-RAN, a RAN node comprising Oil and DU, eNB, gNB, O-CU-CP O-CU-UP, O-DU, O-eNB. In some embodiments, the conflicts caused by the applications 141 , 142 in the E2 node 112 impacts the UE 121. These impact on the UE 121 may e.g., be degraded Quality of Service, excessive control plane signalling, and increased energy consumption.

[0078] According to an example scenario, the application e.g., application 141 is installed and / or instantiated in the O-RAN node 111 e.g., Near-RT RIC platform by the SMO to perform one or more optimizations of the RAN 105. The optimization may e.g., be UE handovers among different nodes such as E2 node 112 in the RAN 105. To perform the one or more optimizations of an E2 node 112 in the RAN 105, the application 141 may decide to perform an action related to an E2 service on the E2 node 112. Hence the application 141 may want to communicate with the E2 node 112 to optimize the performance of the E2 node 112 in the RAN 105 of the communications network 100. The method comprises the following actions, which actions may be taken in any suitable order. Optional actions are referred to as dashed boxes in Figure 4.

[0079] Action 401. The O-RAN node 111 receives one or more first requests from the first application 141 such as e.g., an xApp. The one or more requests may be to subscribe to the E2 node 112 or to perform performance optimization of the E2 node 112. These one or more requests are requesting an action related to an E2 service towards the specific E2 node 112. In some embodiments, the requested E2 service may e.g., be E2 Control, and / or E2 Policy. In these embodiments, the requested action related to the E2 service may e.g., be direct control or configuration of the internal functionality of the E2 node 112.

[0080] Action 402. The O-RAN node 111 observes actions of the first application 141 related to the requested E2 service performed in the E2 node 112. In some embodiments, the action related to the E2 service requested by the first application 141 is performed in the DT node 107. The DT node 107 may e.g., be a digital twin of the E2 node 112. In these embodiments, the observing of the actions of the first application 141 is related to actions related to E2 services performed in a DT node 107. According to the above- mentioned example scenario, the observed actions in the DT node 107 may be correlated to the E2 node 112 to mitigate conflicts in the E2 node 112 thereby improving the performance of the RAN 105. In some embodiments, the observing of the actions of the first application 141 related to the E2 service is performed by using one or more out of: Al and ML. In these embodiments, the Al and / or the ML may be trained in the DT node 107 to generate knowledge about conflict-causing actions belonging to one or multiple E2 services. The Al may comprise e.g., Machine Reasoning, Artificial Intelligence, and / or Machine Learning.

[0081] Action 403. Based on the observed actions, the O-RAN node 111 identifies the action related to the E2 service as a possible cause of conflict in the RAN 105. In some embodiments, the identification of the action related to the E2 service as a possible cause of conflict may be performed after observing the action related to only one first request from the first application 141. For example, a requested action that may have a direct conflict with the RAN 105 e.g., requesting handover of UE such as e.g., UE 121 to a blocked or congested i.e. , overloaded cell in the RAN 105. In some other embodiments, the identification of the action related to the E2 service as a possible cause of conflict may be performed after observing the action related to more than one first requests from the first application 141. For example, a repeated configuration request of an E2 node such as e.g., E2 node 112 that had previously caused an observable conflict in the RAN 105.

[0082] In some embodiments, the identifying of the E2 service as a possible cause of conflict in the RAN 105 is performed by using one or more out of: Al and ML. In these embodiments, the Al and / or the ML may be trained in the DT node 107 to generate knowledge about conflicting E2 services requests from one or multiple applications 141, 142. The Al may comprise e.g., Machine Reasoning, Artificial Intelligence, and / or Machine Learning.

[0083] Action 404. The O-RAN node 111 classifies the identified action related to the E2 service as a conflict-causing action related to the E2 service for the first application 141. The classification may be performed to separate the conflict-causing actions from the non- conflict-causing actions related to the E2 service for the first application 141. In some embodiments, this classification may be useful in determining the allowed E2 services for the second application 142 as described in Action 408. In these embodiments, the second application 142 may be requesting the O-RAN node 111 to provide the same E2 service to communicate with the E2 node 112. The actions related to the requested E2 service may have been classified as conflict-causing as observed from the actions of the first application 141. These conflict-causing actions related to the E2 service may then be classified as non-allowed E2 services for the second application 142.

[0084] The O-RAN node 111 prevents a conflict caused by the identified action related to the E2 service related to the first application 141 by performing Actions 405 and 406 below:

[0085] Action 405. The O-RAN node 111 evaluates a second request from the first application 141. The second request may e.g., be e.g., a RAN performance optimization request. The second request is requesting the action related to the E2 service. In some embodiments, the requested E2 service may e.g., be E2 Control, and / or E2 Policy. The evaluation of the second request is performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO. In some embodiments, the SMO configures the conflict mitigation function of the O-RAN node 111 with the pre-built knowledge of the conflicts in the SMO. In these embodiments, this information may be provided by the SMO to the O-RAN node 111 through the network interface 150 e.g., 01 interface.

[0086] Action 406. The O-RAN node 111 then masks the requested action related to the E2 service through the network interface 150. The masking of the E2 service comprises one or more out of: a blocking of the action related to the E2 service for the first application 141 , and a diversion of the action related to the E2 service of the first application 141, to the DT node 107. The DT node 107 is a digital twin of the E2 node 112. In some embodiments, the DT node 107 may be digital twin of one or more E2 nodes such as e.g., E2 node 112. As described in the example scenario, the request received from the first application 141 to optimize the performance in the E2 node 112 may in some embodiments as described in Action 404 be classified as conflict-causing. In these embodiments, the request to perform the action requested by the first application 141 will be diverted to be executed in the DT node 107. The DT node may e.g., be a digital and / or a simulated version of the E2 node 112. If the DT node 107 and the E2 node 112 are close enough, then the actions of the first application 141 in the DT node 107 may be correlated to the action of the first application 141 in the E2 node 112 thereby reducing the conflicts in the E2 node 112 and improving the performance of the RAN 105. This way the performance of the conflict mitigation function may be improved as well so that the conflict mitigation function may detect and avoid conflicts in a better way.

[0087] In some embodiments, preventing of the conflict caused by the identified E2 service related to the first application 141 by masking of the E2 service through the network interface 150 is performed by masking the network interface 150 for the action related to the E2 service.

[0088] Action 407. The O-RAN node 111 may receive a request from the second application 142 in the O-RAN node 111 to register to the O-RAN node 111. This request comprises the E2 services required by the second application 142. In some embodiments, the request from the second application 142 may be requesting to perform the same action related to the E2 service classified as conflict-causing by the O-RAN node 111 as described in Action 404.

[0089] Action 408. The O-RAN node 111 may determine one or more allowed E2 services for the second application 142 based on the classified conflict-causing action related to the network interface service for the first application 141. As described above, the second application in some embodiments may be requesting the action classified as conflictcausing related to the E2 service to be performed on the E2 node 112. In these embodiments, the classification performed in Action 404 to separate the conflict-causing actions from the non-conflict-causing actions related to the E2 service for the first application 141 may be used to determine the allowed E2 services for the second application 142. Action 409. The O-RAN node 111 may register the second application 142. The registration may be performed with a list of allowed E2 services for the second application 142.

[0090] Action 410. The O-RAN node 111 may send a registration response to the second application 142. The registration response comprises the determined allowed E2 services.

[0091] In this way by performing the methods above, the O-RAN node 111 masks the network interface 150 from the action related to E2 service classified as conflict-causing action for the first application 141. The above method is also useful in determining the allowed E2 services for the second application 142 based on the identified similar conflictcausing actions. Thus, the above-mentioned method helps to reduce the number of conflicts in the E2 node 112 thereby improving the performance of the RAN 105.

[0092] Embodiments herein such as the embodiments mentioned above will now be further described and exemplified. The text below is applicable to and may be combined with any suitable embodiment described above.

[0093] Registering the applications 141 , 142 with the O-RAN node 111:

[0094] As mentioned earlier, according to the O-RAN standard specifications of Near-RT RIC architecture and APIs, when the applications 141, 142 such as e.g., an xApp gets instantiated, it establishes its connectivity, identity, and authorization with the O-RAN node 111 such as e.g., Near-RT RIC comprising the Near-RT RIC platform with the conflict mitigation function by using standardized application registration procedure. The applications 141, 142 may be operating in the O-RAN node 111 or be present in the server 140 and communicates with the O-RAN node 111.

[0095] Examples of embodiments herein provide, as illustrated in Figure 5, an enhancement to the standard registration procedure illustrated in Figure 2b. According to these embodiments, steps 202 and 203 in Figure 2b is expanded as depicted in Figure 5 to include seeking guidance from the O-RAN node 111 e.g., Near-RT RIC platform as part of the application registration procedure.

[0096] Action 501. Registration request

[0097] As described Action 407, the application such as e.g., the second application 142 requests the O-RAN node 111 to register the second application 142. The request comprises information as described in step 201 of Figure 2b in the standard application registration procedure.

[0098] Action 502. Guidance request

[0099] The request sent from the second application 142 is received by e.g., the

[0100] 5 registration service point in the O-RAN node 111 which in turn sends a guidance request to the conflict mitigation function in the O-RAN node 111 as part of the Action 408. The conflict mitigation function comprises the previously recorded conflict-causing actions related to the E2 services as described in Action 404. The SMO may configure the conflict mitigation function in the O-RAN node 111 and provide the pre-built information related to actions causing conflicts to the O-RAN node 111 e.g., Near-RT RIC platform with the conflict mitigation function.

[0101] Action 503. Evaluation of registration request

[0102] As described in Action 408, the conflict mitigation function in the O-RAN node 111 performs a determination of the allowed services for the second application 142. 5 The determination may be e.g., which E2SMs, API and / or data type the first application 141 is allowed to access.

[0103] Action 504. Guidance response

[0104] The determined allowed services for the second application 141 are sent as a guidance response from the conflict mitigation function in the O-RAN node 111 e.g., 0 Near-RT RIC platform to the registration service point in the O-RAN node 111.

[0105] Action 505. Registration processing

[0106] This action is similar to step 202 and as described in Action 409.

[0107] Action 506. Registration response

[0108] As described in Action 410, this action is similar to step 203 but in addition the response also comprises the allowed services for the second application 142.

[0109] Thus, according to embodiments herein as seen in Action 502, the application registration request is evaluated based on pre-configured conflict mitigation information from the SMO via network interface 150 such as e.g., 01 interface. The application is then 0 informed about which E2SMs, data types and / or APIs it is allowed to use from the O-RAN node 111 e.g., Near-RT RIC platform. Examples of embodiments herein provide an updated registration response message as detailed below in Table 1.

[0110]

[0111] Embodiments herein provide a response message which in addition to the standard specified application identifier also comprises the allowed E2SMs, APIs such as e.g., SDL APIs, A1 APIs and data types. The list of allowed APIs, E2SMs and data types that are

[0112] 5 communicated to the second application 142 in the registration response message creates an initial operational context for the second application 142. Using this basic application specific operational context, the O-RAN node 111 may, based on the SMO configuration as described in Action 405 and 502, avoid direct conflicts e.g., by limiting different applications 141 , 142 to non-overlapping optimizations in the RAN 105. 0

[0113] Profiling the applications 141 , 142 for runtime conflicts:

[0114] The capabilities available to the application such as first application 141 in an E2SM may go beyond those needed to enforce a specific A1 policy. In other words, an E2SM that the first application 141 is allowed to use may provide more control and optimization 5 knobs than needed for a specific use case e.g., enforcing traffic steering policy. To prevent the applications 141 , 142 from indirect and implicit conflicts during runtime, it is required that the O-RAN node 111 e.g., Near-RT RIC platform with the conflict mitigation function be able to observe, validate, and attribute conflicts in the RAN to the actions of specific applications 141, 142. For this purpose, some embodiments herein provide 0 application profiling of the E2 node 112 and DT node 107 as in Action 402 to evaluate the impact of the actions of the applications 141 , 142 on performance of the RAN 105 and to evaluate any conflicts created by those actions. Profiling used herein may refer to e.g., observing the actions of the first application 141 as part of a control loop such as e.g., a sequence of related actions as described in Action 402, identifying a control loop as a possible cause of conflict as described in Action 403, and building knowledge about the first application 141 on which actions of the first application 141 are prone to cause

[0115] 5 indirect or implicit conflicts as described in Action 404. These steps are detailed below. a) Observing the applications’ 141, 142 interactions with the E2 node 112 in the RAN 105.

[0116] This action describes in detail the Action 402 as mentioned above. For an 0 application such as first application 141 that registers with the O-RAN node 111 e.g., Near-RT RIC platform, the conflict mitigation function starts profiling the first application 141 based on its requested E2 services and used E2 service models. Table 2 below shows the standard E2 subscription request message content. »E2 Subsequent Action

[0117] The Message Type IE in Table 2 is a structure that includes information about which type of E2 request is being made by the first application 141. This IE may indicate to the O-RAN node 111 whether the first application 141 wants to create an E2 subscription which indicates initiation of a control loop or whether the first application 141 wants to perform optimization of the RAN 105 via E2 control or E2 policy services which indicates execution of control loop. The list of actions the first application 141 may request to observe the E2 node 112 and control the E2 node 112 is limited to the services offered by E2 Application Protocol (E2AP). Note that in case of proprietary E2SMs, some of the lEs in the E2 subscription request may not be parsed by the O-RAN node 111.

[0118] According to example embodiments provided herein related to the applications’ 141, 142 profiling, the O-RAN node 111 treats each E2 subscription request from the applications 141 , 142 as an indicator of an independent control loop anchored at the applications 141, 142. For example, an application e.g., first application 141 may want to create an event-based trigger on one or more specific E2 nodes such as e.g., E2 node 112 for a certain E2SM. Such a request from the first application 141 may be executed on the DT node 107 and / or on the E2 node 112 by the O-RAN node 111 and gets assigned a unique RIC request identifier over the network interface 150. The O-RAN node 111 may observe subsequent messages such as e.g., report and policy, as part of that control loop, from the E2 nodes 112 and / or DT node 107 i.e., by using the RIC request identifier IE in the E2AP. Note that the O-RAN node 111 will do the mapping between the communication over the network interface between the E2 node 112 and the O-RAN node 111 e.g., Near-RT RIC platform and over the Near-RT RIC APIs between the O-RAN node 111 e.g., the Near-RT RIC platform and the applications 141 , 142.

[0119] Figure 6 shows examples of embodiments related to the process where an application e.g., first application 141 has two separate E2 related subscription requests. In these embodiments, the O-RAN node 111 may create those subscriptions across E2 node 112 and the DT node 107. For every E2 subscription request, the application subscription management function in the O-RAN node 111 described as registration service point in Figure 5 seeks guidance from the conflict mitigation function in the O-RAN node 111 to decide whether an E2AP level subscription is created on the E2 node 112 or to the DT node 107 which is the digital and / or simulated version of the E2 node 112. b) Observation and detection of conflicts caused by the applications 141 , 142. This action describes in detail the Action 403 as mentioned above. According to example embodiments herein, the O-RAN node 111 may use the network interface 150 to observe the impact of the actions of the applications 141 , 142 in real time and over a long-term duration. The O-RAN node 111 may, independent from the communication with the applications 141 , 142, observe the overall RAN performance using the network interface 150. The performance monitoring may happen simultaneously in the E2 node 112 and the DT node 107. The O-RAN node 111 may also determine which KPIs may be a configurable attribute to monitor as critical performance indicators of the E2 node 112 by obtaining conflict mitigation information from the SMO as mentioned in Action 405 over network interface 150 such as e.g., over 01 interface.

[0120] As described in Action 404, to classify the actions of the applications 141, 142 i.e., its use of E2 control or E2 policy as a cause for a conflict in the E2 node 112, the O-RAN node 111 may use both short term and long-term performance metrics of the E2 node 112 in the RAN 105 into account. For example, if an application e.g., first application 141 requests to change the handover thresholds for a UE such as UE 121 or group of UEs, and there is a subsequent observable change in the number of ping-pong handovers in E2 nodes such as E2 node 112 or DT node 107, the O-RAN node 111 may establish a correlation with the control loop that potentially caused it. As mentioned above, the conflicts caused in the E2 node 112 by the applications 141, 142 may impact the performance of the UE such as e.g., UE 121. While the O-RAN node 111 may or may not see actual parameters set by the first application 141 for handover threshold, it may detect that the first application 141 requested an E2 action for an E2SM that provides handover parameter control. There may be cases where the impact of the actions of the first application 141 may not be directly or immediately observable e.g., when the actions of the first application 141 triggers the second application 142 to do changes that subsequently impact the performance of the E2 node 112. In this case, in addition to the performance observation of the RAN 105, the O-RAN node 111 may employ Al and / or ML based long-term analysis according to embodiments herein described in Actions 402 and 403 to deduce the impact of the actions of the applications 141 , 142 on the performance of the RAN 105. The control loop profiling is therefore a process for classifying complex interactions of parallel control loops anchored in different applications 141, 142. c) Classifying the problematic applications 141, 142 and the corresponding control loops This action describes in detail the Action 404 as mentioned above. Note that the applications 141, 142 may have a different impact on the performance of the RAN 105 depending on the control loop and the E2 services it uses as part of that loop. For example, the first application 141 may use an E2SM e.g., E2SM-Key Performance Measurement (E2SM-KPM) that causes no observable conflicts or degradation in the RAN 105 but it may use another E2SM e.g., E2SM-RAN Control (E2SM-RC) which causes observable degradation in the RAN 105. Therefore, it is important that classification of problematic control loops i.e. , problematic actions related to the E2 service occurs in the O-RAN node 111 instead of classification of the applications 141, 142 as good and bad. For each control loop of the first application 141, the O-RAN node 111 may create a profile where the profile may record detailed information comprising:

[0121] - The E2 node 112 for which the control loop was created,

[0122] - UE or UE group which were set as triggers for control actions in the control loop,

[0123] - RAN slice(s) which were manipulated,

[0124] - The E2SM(s) used as part of the control loop,

[0125] - The specific services of an E2SM that were used as part of the control loop,

[0126] - The format / style of a specific service used in the control loop,

[0127] - Impact on monitored RAN KPIs,

[0128] - Possible impact on the actions of second application 142.

[0129] Note that some of the items in the non-exhaustive list above, may be determined at different points in time either via statistical processing of observable KPIs in the RAN 105 or using Al and / or ML based approaches.

[0130] Preventing conflicts by E2 service masking:

[0131] Once the O-RAN node 111 has generated the required knowledge about the control loops by classifying the conflict-causing actions related to the E2 service related to the first application 141 as described in Action 404, it may adopt certain ways to prevent the first application 141 from executing those control loops i.e., executing those actions related to the E2 service that have been classified as problematic i.e., creating conflicts in the RAN 105. The gathered knowledge may also be used when the second application 142 requests to register to the O-RAN node 111 to perform specific actions related to the E2 service in the E2 node 112. As described in Action 408, the O-RAN node 111 determines the allowed E2 services for the second application 142 based on the classified conflict-causing actions identified from the actions of the first application 141 related to the E2 service in the E2 node 112. The E2 subscription request message from the second application 142 may be rejected by replying with an E2 subscription response message indicating identification of the E2 node 112 and function identifier of the RAN 105 and a rejection cause IE. The cause IE may carry an E2 related API cause or an E2AP cause. The E2 related API cause may use control conflict as one possible value for rejection cause. This may be used to inform the second application 142 that all its requested E2 actions is not allowed and sending only the allowed E2 services for the second application 142 as described in Action 410.

[0132] Examples of embodiments herein, in addition to the standard specified method to reject an E2 related service request from the first application 141 , provide prevention of conflicts by E2 service masking as mentioned in Action 406. Masking used herein may refer to e.g., the runtime determination and diversion of the E2 service requests to a DT node 107. This runtime masking may be very granular and be based on information gathered as part of the control loop profiling of the first application 141. The following example scenarios may occur for E2 services requests of the applications 141 , 142.

[0133] - Service request for specific E2 node 112 may be diverted to the DT node 107,

[0134] - Service request for specific UE, UE Groups, Slices, QoS classes may be diverted,

[0135] - Service request for specific E2SM e.g., E2SM-RC may be diverted,

[0136] - Service request for specific E2 service such as e.g., E2 Control or E2 Policy in an E2SM may be diverted,

[0137] - Service request for specific E2 service style in an E2SM may be diverted to the DT node 107.

[0138] These may be exercised at different times and the impact of the diverted E2 services in the DT node 107 may be used to validate the gathered knowledge of the O-RAN node 111 e.g., Near-RT RIC with the conflict mitigation function about the conflicts and improve the O-RAN node’s 111 knowledge about the actions causing conflicts over time e.g., using Al and / or ML. As mentioned earlier, the actions of the first application 141 diverted to the DT node 107 may be observed by the O-RAN node 111 to train the Al and / or ML. The learning of the Al and / or the ML about the conflicts caused by the actions of the first application 141 in the DT node 107 may then be used to correlate and / or deduce the actions of the first application 141 in the E2 node 112 if the DT node 107 simulates the E2 node 112 as accurately as possible. In this way, the O-RAN node 111 may prevent conflicts in the E2 node 112 thereby improving the performance of the RAN 105. Figure 7 shows the above-described process visually in one possible realization flow of E2 service masking.

[0139] Action 701. The first application 141 sends an E2 subscription request that carries the standard specified subscription details e.g., E2 node 112 to create an E2 subscription and the RAN function offering a specific E2SM.

[0140] Action 702. The application subscription management function in the O-RAN node 111 seeks guidance from the conflict mitigation function in the O-RAN node 111 on whether the requested subscription request and / or subsequent actions related to that request i.e., the control loop would cause potential conflicts. The conflict mitigation function in the O-RAN node 111 will evaluate the request against any previous information for the same or similar control loops anchored for the first application 141 or different applications such as e.g., second application 142. If the conflict mitigation decides that creating that specific control loop may interfere with existing control loops for other applications such as e.g., second application 142 or the default functionality of the E2 node 112, then the requested E2 service may be advised to be diverted to the DT node 107 or if sufficient confidence exists in the classification of the requested control loop as conflict-causing, then the requested action may be rejected with appropriate cause information provided to the application.

[0141] Action 703. Based on the received guidance, the application subscription management function in the O-RAN node 111 will use the E2AP to create an E2 subscription for the requested E2 service in the DT node 107 or inform the first application 141 with an appropriate message. The first application 141 may remain unaware that it is exercising its control loop on an emulated DT node 107 if the former choice is adopted.

[0142] Action 704. The O-RAN node 111 observes the impact of the control loop in the DT node 107 to validate its provided guidance. Assuming a good correlation between the E2 node 112 and the DT node 107, the impact of the control loop in the DT node 107 may be used to validate or update the guidance provided by the O-RAN node 111. The observation of the actions in the DT node 107 may also be fed to the Al and / or ML based optimization algorithms inside the O-RAN node 111 to complement any pre-configured knowledge obtained by the conflict mitigation function in the O-RAN node 111 from the SMO over the network interface 150 such as e.g., 01 interface.

[0143] All the functional elements of the embodiments described herein may be realized in a distributed manner as mentioned earlier in DNs with their functionality comprised in the cloud 170. DT node 107 may be implemented as a separate node in the RAN 105 providing its functionality in line with standard E2 interface specifications. The DT node 107 may also be implemented as a function in the O-RAN node 111 e.g., Near-RT RIC platform. The conflict mitigation function in the O-RAN node 111 may be implemented as a separate node offering its guidance service over some service API e.g., REST. The applications 141, 142 may execute on separate infrastructure such as the server 140 than the O-RAN node 111.

[0144] Embodiments herein are aligned with O-RAN architecture and standards and directly mappable. The following O-RAN specifications may be directly impacted such as e.g., O-RAN Near-RT RIC Architecture Specification and O-RAN Near-RT RIC APIs specification.

[0145] To perform the method actions above, the O-RAN node 111 is configured to prevent a conflict caused by one or more applications 141, 142 in a Radio Access Network, RAN, 105 of a communications network 100. The one or more applications 141, 142 is operating in the O-RAN node 111 and communicates with an E2 node 112 through a network interface 150.

[0146] The O-RAN node 111 may comprise an arrangement depicted in Figure 8. The O- RAN node 111 may comprise an input and output interface 800 configured to communicate in the communications network 100, e.g., with the E2 node 112. The input and output interface 800 may comprise a wireless receiver not shown, and a wireless transmitter not shown.

[0147] The O-RAN node 111 is further configured to receive one or more first requests from the first application 141. The one or more first request are requesting an action related to an E2 service towards the E2 node 112. The O-RAN node 111 is further configured to observe actions of the first application 141, related to the requested E2 service performed in the E2 node 112. The O-RAN node 111 is further configured to based on the observed actions, identify the action related to the E2 service as a cause of conflict in the RAN 105. The O-RAN node 111 is further configured to classify the identified action related to the E2 service as a conflict-causing action related to the E2 service for the first application 141. The O-RAN node 111 is further configured to prevent a conflict caused by the identified action related to the E2 service related to the first application 141. The O-RAN node 111 prevents the conflict by further configuring the O- RAN node 111 to evaluate a second request from the first application 141. This second request is requesting the action related to the E2 service. The evaluation is adapted to be performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO. The O-RAN node 111 prevents the conflict by further configuring the O-RAN node 111 to mask the requested action related to the E2 service through the network interface 150. The masking of the E2 service is adapted to comprise one or more out of: a blocking of the action related to the E2 service for the first application 141 , and a diversion of the action related to the E2 service of the first application 141, to the DT node 107, which DT node 107 is a digital twin of the E2 node 112.

[0148] In some embodiments, the preventing of the conflict caused by the identified E2 service related to the first application 141 by masking of the E2 service through the network interface 150 is adapted to be performed by masking the network interface 150 for the action related to the E2 service.

[0149] In some embodiments, the observing of the actions of the first application 141 is related to actions related to E2 services performed in a Digital Twin, DT, node 107.

[0150] In some embodiments, any one or more out of: the O-RAN node 111 is adapted to be represented by any one out of: a NearReal Time, Near-RT, RAN Intelligence Controller, RIC, comprising a conflict mitigation function. the E2 node 112, is adapted to be represented by any one out of: an E2 node in O-RAN, a RAN node comprising Oil and DU, eNB, gNB, O-CU-CP and O-CU- UP, O-DU, and O-eNB.

[0151] In some embodiments, wherein observing of the actions of the first application 141 related to the E2 service and identifying of the E2 service as a possible cause of conflict in the RAN 105 is adapted to be performed by using one or more out of: Artificial Intelligence, Al and Machine Learning, ML.

[0152] In some embodiments, the O-RAN node 111 is further being configured to receive a request from the second application 142 in the O-RAN node 111 to register to the O-RAN node 111, which request comprises the E2 services required by the second application 142. In these embodiments, the O-RAN node 111 is further being configured to determine one or more allowed E2 services for the second application 142 based on the classified conflict-causing action related to the network interface service for the first application 141. In these embodiments, the O-RAN node 111 is further being configured to register the second application 142 and send 410 a registration response to the second application 142, which registration response is adapted to comprise the determined allowed E2 services. In some embodiments, the conflict is between one or more out of: the first application 141, a second application 142, the E2 node 112.

[0153] Embodiments herein may be implemented through a respective processor or one or more processors, such as the respective processor 810 of a processing circuitry in the O-RAN node 111 depicted in Figure 8, together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the respective O-RAN node 111. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the respective O-RAN node 111.

[0154] The O-RAN node 111 may further comprise a respective memory 820 comprising one or more memory units. The respective memory 820 comprises instructions executable by the processor in the respective O-RAN node 111. The respective memory 820 are arranged to be used to store e.g., media functions, indications, tags, information, data, configurations, communication data, and applications to perform the methods herein when being executed in the respective O-RAN node 111.

[0155] In some embodiments, a respective computer program 830 comprises instructions, which when executed by the respective at least one processor 810, cause the at least one processor of respective O-RAN node 111 to perform the actions above.

[0156] In some embodiments, a respective carrier 840 comprises the respective computer program 830, wherein the respective carrier 840 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0157] Those skilled in the art will appreciate that units in the respective O-RAN node 111 described above may refer to a combination of analog and digital circuits, and / or one or more processors configured with software and / or firmware, e.g. stored in the respective O-RAN node 111, that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry ASIC, or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

[0158] ADDITIONAL EXPLANATION

[0159] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0160] Figure 9 shows an example of a communication system QQ100 in accordance with some embodiments.

[0161] In the example, the communication system QQ100 includes a telecommunication network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network QQ102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network QQ102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network QQ102, including one or more network nodes QQ110 and / or core network nodes QQ108.

[0162] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1, E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 121, QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.

[0163] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0164] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs QQ112 and / or with other network nodes or equipment in the telecommunication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network QQ102.

[0165] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one more core network nodes (e.g., core network node QQ108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier Deconcealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0166] The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and / or the telecommunication network QQ102, and may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0167] As a whole, the communication system QQ100 of Figure 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0168] In some examples, the telecommunication network QQ102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network QQ102. For example, the telecommunications network QQ102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0169] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi- RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0170] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and network nodes (e.g., network node QQ110b). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0171] The hub QQ114 may have a constant / persistent or intermittent connection to the network node QQ110b. The hub QQ114 may also allow for a different communication scheme and / or schedule between the hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between the hub QQ114 and the core network QQ106. In other examples, the hub QQ114 is connected to the core network QQ106 and / or one or more UEs via a wired connection. Moreover, the hub QQ114 may be configured to connect to an M2M service provider over the access network QQ104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub QQ114 via a wired or wireless connection. In some embodiments, the hub QQ114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node QQ110b. In other embodiments, the hub QQ114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node QQ110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0172] Figure 10 shows a UE QQ200 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes such as e.g., O-RAN node 111 , E2 node 112 and / or other UEs, such as e.g., UE 121. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0173] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input / output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0174] The processing circuitry QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory QQ210. The processing circuitry QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry QQ202 may include multiple central processing units (CPUs).

[0175] In the example, the input / output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE QQ200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0176] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and / or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[0177] The memory QQ210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[0178] The memory QQ210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ210 may allow the UE QQ200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory QQ210, which may be or comprise a device-readable storage medium.

[0179] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0180] In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0181] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface QQ212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0182] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smartwatch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in Figure 10.

[0183] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0184] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators. Figure 11 shows a network node QQ300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O- RAN nodes or components of an O-RAN node (e.g., 0-Rll, 0-Dll, O-CU).

[0185] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0186] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi- cel l / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0187] The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs) and some components may be reused (e.g., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node QQ300.

[0188] The processing circuitry QQ302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality.

[0189] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units.

[0190] The memory QQ304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device- readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations made by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and memory QQ304 is integrated.

[0191] The communication interface QQ306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface QQ306 comprises port(s) / terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0192] In certain alternative embodiments, the network node QQ300 does not include separate radio front-end circuitry QQ318, instead, the processing circuitry QQ302 includes radio front-end circuitry and is connected to the antenna QQ310. Similarly, in some embodiments, all or some of the RF transceiver circuitry QQ312 is part of the communication interface QQ306. In still other embodiments, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front-end circuitry QQ318, and the RF transceiver circuitry QQ312, as part of a radio unit (not shown), and the communication interface QQ306 communicates with the baseband processing circuitry QQ314, which is part of a digital unit (not shown).

[0193] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[0194] The antenna QQ310, communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0195] The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0196] Embodiments of the network node QQ300 may include additional components beyond those shown in Figure 11 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300. Figure 12 is a block diagram of a host QQ400, which may be an embodiment of the host QQ116 of Figure 9, in accordance with various aspects described herein. As used herein, the host QQ400 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host QQ400 may provide one or more services to one or more UEs.

[0197] The host QQ400 includes processing circuitry QQ402 that is operatively coupled via a bus QQ404 to an input / output interface QQ406, a network interface QQ408, a power source QQ410, and a memory QQ412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures QQ2 and QQ3, such that the descriptions thereof are generally applicable to the corresponding components of host QQ400.

[0198] The memory QQ412 may include one or more computer programs including one or more host application programs QQ414 and data QQ416, which may include user data, e.g., data generated by a UE for the host QQ400 or data generated by the host QQ400 for a UE. Embodiments of the host QQ400 may utilize only a subset or all of the components shown. The host application programs QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAG, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs QQ414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host QQ400 may select and / or indicate a different host for over-the-top services for a UE. The host application programs QQ414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0199] Figure 13 is a block diagram illustrating a virtualization environment QQ500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments QQ500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment QQ500 includes components defined by the O-RAN Alliance, such as an O- Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0200] Applications QQ502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0201] Hardware QQ504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers QQ506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs QQ508a and QQ508b (one or more of which may be generally referred to as VMs QQ508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer QQ506 may present a virtual operating platform that appears like networking hardware to the VMs QQ508.

[0202] The VMs QQ508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer QQ506. Different embodiments of the instance of a virtual appliance QQ502 may be implemented on one or more of VMs QQ508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. In the context of NFV, a VM QQ508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs QQ508, and that part of hardware QQ504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs QQ508 on top of the hardware QQ504 and corresponds to the application QQ502.

[0203] Hardware QQ504 may be implemented in a standalone network node with generic or specific components. Hardware QQ504 may implement some functions via virtualization. Alternatively, hardware QQ504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration QQ510, which, among others, oversees lifecycle management of applications QQ502. In some embodiments, hardware QQ504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system QQ512 which may alternatively be used for communication between hardware nodes and radio units.

[0204] Figure 14 shows a communication diagram of a host QQ602 communicating via a network node QQ604 with a UE QQ606 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE QQ112a of Figure 9 and / or UE QQ200 of Figure 10), network node (such as network node QQ110a of Figure 9 and / or network node QQ300 of Figure 11), and host (such as host QQ116 of Figure 9 and / or host QQ400 of Figure 12) discussed in the preceding paragraphs will now be described with reference to Figure 14.

[0205] Like host QQ400, embodiments of host QQ602 include hardware, such as a communication interface, processing circuitry, and memory. The host QQ602 also includes software, which is stored in or accessible by the host QQ602 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE QQ606 connecting via an over-the-top (OTT) connection QQ650 extending between the UE QQ606 and host QQ602. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection QQ650.

[0206] The network node QQ604 includes hardware enabling it to communicate with the host QQ602 and UE QQ606. The connection QQ660 may be direct or pass through a core network (like core network QQ106 of Figure 9) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0207] The UE QQ606 includes hardware and software, which is stored in or accessible by UE QQ606 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE QQ606 with the support of the host QQ602. In the host QQ602, an executing host application may communicate with the executing client application via the OTT connection QQ650 terminating at the UE QQ606 and host QQ602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection QQ650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection QQ650.

[0208] The OTT connection QQ650 may extend via a connection QQ660 between the host QQ602 and the network node QQ604 and via a wireless connection QQ670 between the network node QQ604 and the UE QQ606 to provide the connection between the host QQ602 and the UE QQ606. The connection QQ660 and wireless connection QQ670, over which the OTT connection QQ650 may be provided, have been drawn abstractly to illustrate the communication between the host QQ602 and the UE QQ606 via the network node QQ604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0209] As an example of transmitting data via the OTT connection QQ650, in step QQ608, the host QQ602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE QQ606. In other embodiments, the user data is associated with a UE QQ606 that shares data with the host QQ602 without explicit human interaction. In step QQ610, the host QQ602 initiates a transmission carrying the user data towards the UE QQ606. The host QQ602 may initiate the transmission responsive to a request transmitted by the UE QQ606. The request may be caused by human interaction with the UE QQ606 or by operation of the client application executing on the UE QQ606. The transmission may pass via the network node QQ604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step QQ612, the network node QQ604 transmits to the UE QQ606 the user data that was carried in the transmission that the host QQ602 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ614, the UE QQ606 receives the user data carried in the transmission, which may be performed by a client application executed on the UE QQ606 associated with the host application executed by the host QQ602.

[0210] In some examples, the UE QQ606 executes a client application which provides user data to the host QQ602. The user data may be provided in reaction or response to the data received from the host QQ602. Accordingly, in step QQ616, the UE QQ606 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE QQ606. Regardless of the specific manner in which the user data was provided, the UE QQ606 initiates, in step QQ618, transmission of the user data towards the host QQ602 via the network node QQ604. In step QQ620, in accordance with the teachings of the embodiments described throughout this disclosure, the network node QQ604 receives user data from the UE QQ606 and initiates transmission of the received user data towards the host QQ602. In step QQ622, the host QQ602 receives the user data carried in the transmission initiated by the UE QQ606.

[0211] One or more of the various embodiments improve the performance of OTT services provided to the UE QQ606 using the OTT connection QQ650, in which the wireless connection QQ670 forms the last segment. More precisely, the teachings of these embodiments may improve the latency and thereby provide benefits such as reduced user waiting time.

[0212] In an example scenario, factory status information may be collected and analyzed by the host QQ602. As another example, the host QQ602 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host QQ602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host QQ602 may store surveillance video uploaded by a UE. As another example, the host QQ602 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host QQ602 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0213] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection QQ650 between the host QQ602 and UE QQ606, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host QQ602 and / or UE QQ606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection QQ650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection QQ650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node QQ604. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host QQ602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection QQ650 while monitoring propagation times, errors, etc.

[0214] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0215] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0216] When using the word "comprise" or “comprising” it shall be interpreted as nonlimiting, i.e. meaning "consist at least of".

[0217] The embodiments herein are not limited to the preferred embodiments described above. Various alternatives, modifications and equivalents may be used.

Claims

CLAIMS1 . A method performed by an Open Radio Access Network, O-RAN, node (111), for preventing a conflict caused by one or more applications (141 , 142) in a Radio Access Network, RAN, (105) of a communications network (100), which one or more applications (141 , 142) is operating in the O-RAN node (111) and communicate with an E2 node (112) through a network interface (150), wherein the E2 node (112) is a RAN node that terminates the network interface (150), the method comprising: receiving (401) one or more first requests from the first application (141), requesting an action related to an E2 service towards the E2 node (112), observing (402) actions of the first application (141), related to the requested E2 service performed in the E2 node (112), based on the observed actions, identifying (403) the action related to the E2 service as a cause of conflict in the RAN (105), classifying (404) the identified action related to the E2 service as a conflictcausing action related to the E2 service for the first application (141), preventing a conflict caused by the identified action related to the E2 service related to the first application (141) by: evaluating (405) a second request from the first application (141) requesting the action related to the E2 service, which evaluation is performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO, and masking (406) the requested action related to the E2 service through the network interface (150) wherein the masking of the E2 service comprises one or more out of: a blocking of the action related to the E2 service for the first application (141), and a diversion of the action related to the E2 service of the first application (141), to the Digital Twin, DT, node (107), which DT node (107) is a digital twin of the E2 node (112).

2. The method according to claim 1 , wherein the preventing of the conflict caused by the identified E2 service related to the first application (141) by masking (406) ofthe E2 service through the network interface (150) is performed by masking the network interface (150) for the action related to the E2 service.

3. The methods according to any of claims 1-2, wherein the observing (402) of the actions of the first application (141) is related to actions related to E2 services performed in a Digital Twin, DT, node (107).

4. The method according to any of claims 1-3, wherein any one or more out of: the O-RAN node (111) is represented by any one out of: a Near-Real Time, Near-RT, RAN Intelligence Controller, RIC, comprising a conflict mitigation function. the E2 node (112,) is represented by any one out of: an E2 node in O-RAN, a RAN node comprising CU and DU, eNB, gNB, O-CU-CP, O-CU-UP, O-DU and O-eNB.

5. The method according to any of the claims 1-4, wherein observing (402) of the actions of the first application (141) related to the E2 service and identifying (403) the E2 service as a possible cause of conflict in the RAN (105) is performed by using one or more out of: Artificial Intelligence, Al and Machine Learning, ML.

6. The method according to any of the claims 1-5, further comprising: receiving (407) a request from the second application (142) in the O-RAN node (111) to register to the O-RAN node (111), which request comprises the E2 services required by the second application (142), determining (408) one or more allowed E2 services for the second application (142) based on the classified (404) conflict-causing action related to the network interface service for the first application (141), and registering (409) the second application (142) and sending (410) a registration response to the second application (142), which registration response comprises the determined allowed E2 services.

7. The method according to any of claims 1-6, wherein the conflict is between one or more out of: the first application (141), a second application (142), the E2 node (112).

8. A computer program (830) comprising instructions, which when executed by a processor (810), causes the processor (810) to perform actions according to any of the claims 1-7.

9. A carrier (840) comprising the computer program (830) of claim 8, wherein the carrier (840) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

10. An Open Radio Access Network, O-RAN, node (111), configured to prevent a conflict caused by one or more applications (141 , 142) in a Radio Access Network, RAN, (105) of a communications network (100), which one or more applications (141 , 142) is operating in the O-RAN node (111) and communicate with an E2 node (112) through a network interface (150), wherein the E2 node (112) is a RAN node that terminates the network interface (150), wherein the O-RAN node (111) is further configured to: receive one or more first requests from the first application (141), requesting an action related to an E2 service towards the E2 node (112), observe actions of the first application (141), related to the requested E2 service performed in the E2 node (112), based on the observed actions, identify the action related to the E2 service as a cause of conflict in the RAN (105), classify the identified action related to the E2 service as a conflict-causing action related to the E2 service for the first application (141), prevent a conflict caused by the identified action related to the E2 service related to the first application (141) by the O-RAN node (111) is further being configured to: evaluate a second request from the first application (141) requesting the action related to the E2 service, which evaluation is adapted to be performed based on one or more out of: the classified conflict-causing action related to the E2 service, information related to conflicts provided by a Service Management and Orchestration, SMO, and masking the requested action related to the E2 service through the network interface (150) wherein the masking of the E2 service is adapted to comprise one or more out of: a blocking of the action related to the E2 service for the firstapplication (141), and a diversion of the action related to the E2 service of the first application (141), to the Digital Twin, DT, node (107), which DT node (107) is a digital twin of the E2 node (112).

11. The Open Radio Access Network, O-RAN, node (111), according to claim 10, wherein the preventing of the conflict caused by the identified E2 service related to the first application (141) by masking of the E2 service through the network interface (150) is adapted to be performed by masking the network interface (150) for the action related to the E2 service.

12. The Open Radio Access Network, O-RAN, node (111), according to any of claims 10-11 , wherein the observing of the actions of the first application (141) is related to actions related to E2 services performed in a Digital Twin, DT, node (107).

13. The Open Radio Access Network, O-RAN, node (111), according to any of claims 10-12, wherein any one or more out of: the O-RAN node (111) is adapted to be represented by any one out of: a Near-Real Time, Near-RT, RAN Intelligence Controller, RIC, comprising a conflict mitigation function. the E2 node (112,) is adapted to be represented by any one out of: an E2 node in O-RAN, a RAN node comprising Oil and DU, eNB, gNB, O-CU-CP, O-CU- UP, O-DU and O-eNB.

14. The Open Radio Access Network, O-RAN, node (111), according to any of the claims 10-13, wherein observing of the actions of the first application (141) related to the E2 service and identifying of the E2 service as a possible cause of conflict in the RAN (105) is adapted to be performed by using one or more out of: Artificial Intelligence, Al and Machine Learning, ML.

15. The Open Radio Access Network, O-RAN, node (111), according to any of the claims 10-14, further being configured to: receive a request from the second application (142) in the O-RAN node (111) to register to the O-RAN node (111), which request comprises the E2 services required by the second application (142),determine one or more allowed E2 services for the second application (142) based on the classified conflict-causing action related to the network interface service for the first application (141), and register he second application (142) and send (410) a registration response to the second application (142), which registration response is adapted to comprise the determined allowed E2 services.

16. The Open Radio Access Network, O-RAN, node (111), according to any of claims 10-15, wherein the conflict is between one or more out of: the first application (141), a second application (142), the E2 node (112).

Images