Communication between xapps and e2 nodes

Abstract

The present disclosure relates to a method of a policy enforcement node (130) of communicating with a radio access network node (120) in a communications network (100), and a policy enforcement node (130) performing the method. The present disclosure further relates to a method of a radio access network node (120) of communicating with a policy enforcement node (130) in a communications network (100), and a radio access network node (120) performing the method. In an aspect, a method of a policy enforcement node (130) is provided of communicating with a radio access network (RAN) node (120) in a communications network (100), the policy enforcement node (130) hosting applications (131) for performing the communication and comprising a policy enforcement node framework (132) over which communication is initialized with the RAN node (120). The method comprises transmitting (S101), by the application (131) via the policy enforcement node framework (132), a request to the RAN node (120) to access a service provided to the RAN node (120) over a direct communication path (140) between the application (131) and the RAN node (120), receiving (S106), from the RAN node (120) via the policy enforcement node framework (132), a response indicating whether or not the request is allowed and if so establishing (S107) the direct communication path (140) between the application (132) and the RAN node (120) for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework (132).

Description

COMMUNICATION BETWEEN XAPPS AND E2 NODESTECHNICAL FIELD

[0001] The present disclosure relates to a method of a policy enforcement node of communicating with a radio access network node in a communications network, and a policy enforcement node performing the method. The present disclosure further relates to a method of a radio access network node of communicating with a policy enforcement node in a communications network, and a radio access network node performing the method.BACKGROUND

[0002] The Open Radio Access Network (O-RAN) Alliance promotes a disaggregated, virtualized, and open radio access network (referred to as Open RAN) augmented by software-based control components for RAN performance optimization, enabled by open and standardized multi-vendor interfaces.

[0003] Figure 1 depicts the main components of an O-RAN architecture 100 where control applications referred to as Radio applications (rApps) 111 and extended applications (xApps) 131 execute on Non-Real Time RAN Intelligent Controllers (RICs) 110 and Near- Real Time RICs 130 respectively to proactively steer the RAN performance towards declared non- and near realtime RAN performance objectives. Such objectives may be provided to rApps 111 in the form of standardized intents to a service management and orchestration (SMO) framework 113 that are delivered to the Non-RT RIC 111 and rApps 111 being hosted by the SMO framework 113.

[0004] The Near-RT RICs 130 control E2 nodes 120 (embodied in the form of e.g. radio base stations) of the RAN, and in order to expose the data collection and RAN control capabilities of the E2 interface to the xApps 131, a Near-RT RIC application programming interface (API) is specified in O-RAN for providing a set of services to the xApps 131. Authorized xApps 131 can thus request E2 interface related services from the Near-RT RIC 130 which then result in interactions between the xApps 131 and the E2 nodes 120 over the Near-RT RIC API via an entity referred to as a Near- RT RIC framework 132 or a Near-RT RIC platform 132 (in the following the term “framework” will be used).

[0005] This is a somewhat inefficient way of providing communication between the xApps 131 and the E2 nodes 120 as all communication between the xApps 131 and the E2 nodes 120 inevitably must pass over the Near-RT RIC framework 132.SUMMARY

[0006] One objective is to solve, or at least mitigate, the above mentioned problem and thus to provide an improved method of a policy enforcement node of communicating with a radio access network node in a communications network.

[0007] This objective is attained in a first aspect by a method of a policy enforcement node of communicating with a radio access network (RAN) node in a communications network, the policy enforcement node hosting applications for performing the communication and comprising a policy enforcement node framework over which communication is initialized with the RAN node. The method comprises transmitting, by the application via the policy enforcement node framework, a request to the RAN node to access a service provided to the RAN node over a direct communication path between the application and the RAN node, receiving, from the RAN node via the policy enforcement node framework, a response indicating whether or not the request is allowed and if so establishing the direct communication path between the application and the RAN node for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework.

[0008] This objective is attained in a second aspect by a policy enforcement node configured to communicate with a RAN node in a communications network, the policy enforcement node hosting applications for performing the communication and comprising a policy enforcement node framework over which communication is initialized with the RAN node, the policy enforcement node comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the policy enforcement node is operative to transmit, by the application via the policy enforcement node framework, a request to the RAN node to access a service provided to the RAN node over a direct communication path between the application and the RAN node, receive, from the RAN node via the policy enforcement node framework, a response indicating whether or not the request is allowed and if so to establish the direct communication path between the applicationand the RAN node for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework.

[0009] This objective is attained in a third aspect by a method of a RAN node of communicating with a policy enforcement node in a communications network, the policy enforcement node hosting applications for performing the communication and comprising a policy enforcement node framework over which communication is initialized with the RAN node. The method comprises transmitting, to the application via the policy enforcement node framework, a request to communicate data relating to a service provided by the RAN node over a direct communication path between the RAN node and the application and establishing the direct communication path between the RAN node and application for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework.

[0010] This objective is attained in a fourth aspect by a RAN node configured to communicate with a policy enforcement node in a communications network, the policy enforcement node hosting applications for performing the communication and comprising a policy enforcement node framework over which communication is initialized with the RAN node, the RAN node comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the RAN node is operative to transmit, to the application via the policy enforcement node framework, a request to communicate data relating to a service provided by the RAN node over a direct communication path between the RAN node and the application and to establish the direct communication path between the RAN node and application for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework.

[0011] Advantageously, this bypasses the policy enforcement node framework and any communication between the application and the RAN node will be performed via the established direct communication path. Thus, with embodiments described herein, a greatly improved method of communicating between the application(s) and the RAN node(s) is provided, where a direct communication path is established. With the direct communication path, alternative protocols, data models and security mechanisms between the application and the RAN node is facilitated as compared to those used in the prior art when communicating over the policy enforcement node framework of the policy enforcement node. Thesealternative protocols, data models and security mechanism may be better suited to the specific nature of offered E2 service(s), such as e.g., real-time data streaming.

[0012] In an embodiment, the transmitted request further comprises authentication data to be validated at the policy enforcement node framework in order for the request to be allowed.

[0013] In an embodiment, the received response further comprises information indicating requirements with which the established direct communication path is to comply in order to be successfully established.

[0014] In an embodiment, control plane data is configured to be transported carried over the policy enforcement node framework, while user plane data is configured to be transported via the direct communication path.

[0015] In an embodiment, information is acquired indicating whether or not a direct communication path is available for establishment with the RAN node before transmitting said request.

[0016] In an embodiment, the RAN node receives, from the application via the policy enforcement node framework, a response indicating whether or not the request is allowed; and if so establishing the direct communication path between the RAN node and application.

[0017] In an embodiment, the RAN node provides the policy enforcement node with information indicating whether or not communication via the direct communication path (140) is available for the RAN node.

[0018] In a fifth aspect, a computer program is provided comprising computerexecutable instructions for causing a policy enforcement node to perform steps recited in the method of the first aspect when the computer-executable instructions are executed on a processing unit included in the policy enforcement node.

[0019] In a sixth aspect, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program according to the fifth aspect embodied thereon.

[0020] In a seventh aspect, a computer program is provided comprising computer-executable instructions for causing a RAN node to perform steps recited inthe method of the third aspect when the computer-executable instructions are executed on a processing unit included in the RAN node.

[0021] In an eighth aspect, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program according to the seventh aspect embodied thereon.

[0022] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, in which:

[0024] Figure 1 schematically illustrates a prior art O-RAN architecture in which embodiments may be implemented;

[0025] Figure 2 shows a signalling diagram illustrating a method of an embodiment;

[0026] Figure 3 schematically illustrates a direct communication path established in the O-RAN architecture of Figure 1 according to an embodiment;

[0027] Figure 4 shows a signalling diagram illustrating a method of a further embodiment;

[0028] Figure 5 shows a signalling diagram illustrating a method of an embodiment;

[0029] Figure 6 illustrates a policy enforcement node according to an embodiment; and

[0030] Figure 7 illustrates an E2 node according to an embodiment.DETAILED DESCRIPTION

[0031] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown.

[0032] These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0033] Figure 1 has previously been briefly described and shows the main components of an O-RAN architecture 100.

[0034] Shown in Figure 1 is a service management and orchestration (SMO) framework 113 hosting a policy administration node referred to as a Non-RT RIC 110 and numerous rApps 111, which SMO framework 113 communicates with E2 nodes 120, for example radio base stations referred to as gNBs, via an 01 interface and provides control signals to policy enforcement nodes referred to as Near-RT RICs 130 via an Al interface for instance in the form of policy-based guidance based on which the Near-RT RICs 130 control the E2 nodes 120 of the RAN.

[0035] Applications for the Near-RT RIC 130 (also referred to as xApps 131) include handover decisions, dual connectivity, predicting quality of experience (QoE) of a wireless communication device such as a smart phone, tablet, connected vehicle, etc., while example applications for the Non-RT RIC 110 (also referred to as rApps 111) include orchestration, programmability and optimization. To execute control, an rApp 111 of the Non-RT-RIC 110 sends a recommendation for action to an xApp 131 of the Near-RT-RIC 131, e.g., updating operational parameters, changing an execution policy, deploying an updated policy, etc., over the Al interface which in its turn will be executed by the Near-Rt RIC 130 towards the E2 nodes 120 via the E2 interface. As shown, the Non-RT RIC 110 comprises rApps 111 communicating with a Non-RT RIC framework 112 over an Ri interface, while the Near-RT RIC 130 comprises xApps 131 communicating with a Near-RT RIC framework 132 via Near-RT RIC application programming interfaces (APIs).

[0036] Also illustrated in Figure 1 are functional entities included in the E2 nodes 120, the E2 nodes for instance being implemented in the form of gNBs. The above- mentioned wireless communication devices are commonly referred to as User Equipment (UE).

[0037] A gNB 120 comprises a central unit (CU) being split into a CU-CP 121 (“control plane”) and a CU-UP 122 (“user plane”) being interconnected over an El interface.

[0038] The CU-CP 121 connects to the SMO framework 113 via interface 01 and to the Near-RT RIC 130 via interface E2. Near-RT RIC communication over the E2 interface passes over the Near-RT RIC platform 132. The CU-CP 121 further connects to a distributed unit 123 (DU) via interface Fi-C which in its turn connects to a radio unit 124 (RU) over an open fronthaul (OFH) interface for communicating with one or more UEs (not shown in Figure 1) via the RU 124 communicating wirelessly with the UEs.

[0039] The CU-UP 122 also connects to the SMO framework 113 via interface 01 and to the Near-RT RIC 130 via interface E2. The CU-UP 122 also further connects to the DU 123 via interface Fi-U which in its turn connects to the RU 124 over the OFH interface for wirelessly communicating with the UEs via the RU 124.

[0040] Moreover, the DU 123 connects to the SMO framework 113 via interface 01 and to the Near-RT RIC 130 via interface E2.

[0041] Further shown is the SMO framework 113 connecting via 02 interface to a cloud computing platform 125 (O-Cloud) hosting a set of hardware and software components providing cloud computing capabilities to execute the RAN network functions.

[0042] As mentioned, in order to expose the data collection and RAN control capabilities of the E2 interface to the xApps 131, a Near-RT RIC API is specified in O- RAN for providing a set of services to the xApps 131. Authorized xApps 131 can thus request E2 interface related services from the Near-RT RIC 130 which then result in interactions between the xApps 131 and the E2 nodes 120 via the Near-RT RIC framework 132.

[0043] This is a somewhat inefficient way of providing communication between the xApps 131 and the E2 nodes 120 as all communication between the xApps 131 and the E2 nodes 120 inevitably must pass over the Near-RT RIC framework 132.

[0044] In terms of functionality, the E2 interface defines “E2 services” for data collection and RAN control which include services such as E2 REPORT service, E2 CONTROL service, E2 INSERT service, E2 POLICY service, etc. These services are offered to the Near-RT RIC and xApps using a set of E2 service procedures such as “RIC Subscription”, “RIC Indication” and “RIC Control” procedures, etc.

[0045] Example services being provided to the xApps 131 (on for instance a per UE, per cell or per slice basis), i.e. which functionality an xApp 131 may control in the E2 nodes 120, include control of UE handovers, Quality of Service (QoS) parameters, radio resource allocation, etc., are specified in a separate set of O-RAN specifications referred to as E2 Service Model (E2SM) specifications.

[0046] The Near-RT RIC framework 132 acts as service provider for the xApps 131 but also as a gatekeeper towards the RAN formed by the E2 nodes 120 by managing all interactions over the E2 interface on behalf of the xApps 131. The xApps 131 utilize the Near-RT RIC APIs to request the Near-RT RIC framework 132 to provide access to the E2 interface and thus the services and functionality of the E2 nodes 120 (provided by E2SMs).

[0047] Hence, the Near-RT RIC framework 132 acts as a service provider interface for the xApps 131 and offers its services using a different set of protocols and data models than that utilized over the E2 interface as specified by E2 Application Protocol (E2AP) specification. An xApp 131 may, using the E2 related services of the Near-RT RIC framework 132 and the E2SMs offered by the E2 nodes 120, optimize the default functionality of the RAN nodes (O-CU-CP 121, O-CU-UP 122, O-DU 123, etc.) for use cases such as traffic steering, QoS and Multiple Input Multiple Output (MIMO) optimization, etc.

[0048] The relationship of the E2AP and the E2SMS can be viewed as that of a carrier and payload. The E2AP offers services that enable the exchange of E2SM specified IES between the xApps 131 and the E2 nodes 120, where the E2AP carries the E2SM payload in dedicated IEs in E2AP messages.

[0049] As described above, the E2 interface acts as a payload carrier for E2SMs. However, if an E2 node 120 offers a proprietary E2SM, the Near-RT RIC 130 may not be able to parse information elements (IES) that carry the E2SM specific information in E2AP messages. Therefore, to act as a gatekeeper, there are some information exchanged over the Near-RT RIC APIs and the E2 interface only to support the gatekeeper role of the Near-RT RIC framework 132 which are not needed for the functionality offered by the E2 nodes 120 to the Near-RT RIC 130 and xApps 131. For example, the Near-RT RIC 130 has to map a received E2 indication message from the E2 node 120 having a “RIC Request ID” to a message for the xApp 131 over the Near- RT RIC API with a different “E2 Request ID”. This means that the Near-RT RIC framework 132 must keep an internal mapping of requests over the Near-RT RIC APIs with xApps 131 and interactions over the E2 interface with E2 nodes 120. This mapping becomes even more complex when a single E2 service is consumed by multiple xApps 131.

[0050] In the communication between the xApps 131 and the E2 nodes 120, the xApps 131 comply with the protocols and data models specified for the E2 related services in the Near-RT RIC API specification for accessing said E2 related services of the Near-RT RIC framework 132. The Near-RT RIC 130 verifies the validity of requests over the Near-RT RIC API in terms of e.g. authorization and conflicts before transforming the requests of the xApps 131 received into Near-RT RIC requests transmitted over the E2 interface towards the E2 nodes 120. Hence, the E2 nodes 120 perceive only the Near-RT RIC framework 132 as the consumer of E2 interface services while the xApps 131 are non-visible to the E2 nodes 120. The non-visibility of the xApps 131 also implies, as previously mentioned, that the Near-RT RIC framework 132 serves as a gatekeeper for every message between the xApps 131 and the E2 nodes 120 in both directions, having as a result that a two-hop message transfer approach is applied between the xApps 131 and the E2 nodes 120.

[0051] Now, this two-hop message transfer approach between the xApps 131 and the E2 nodes 120 for exploiting E2SM based functionality creates several issues, some being discussed in the following: xApps 131 should ideally control the RAN in real-time; the 0-RAN specified bounds for Near-RT RIC control applications ranges from around 10ms to is. To meet the lower end of this time budget in particular, the communicationbetween an instant where the E2 node 120 observes an event in the RAN to the instant where a control command from the xApp 131 accordingly is received at the E2 node 131 should be fast. The transport of an E2SM encoded message over two interfaces, i.e. E2 and Near-RT RIC API, for reaching an xApp 131 in uplink or E2 node 120 in downlink, including the requirement of mapping / translating from different protocols and data models in the Near-RT RIC framework 132, creates problems for low-latency control loops. In some cases, the extra checks that the Near- RT RIC framework 132 must perform for every E2 message exchanged between the xApps 131 and the E2 nodes 120 may create a functional bottleneck for some xApp use cases; in some implementations, an xApp 131 can set a timer in the E2 node 120 to trigger sending required information at every occurrence of the timer reaching its set limit. The lower limit of that timer may be set to ims, but the current two hop approach for a message to reach the xApp 131 makes meeting these time budget difficult; given that the Near-RT RIC framework 132 is the gatekeeper for all E2 interactions and that xApps 131 neither accesses the E2 interface directly nor interact with other xApps 131 communicating via the Near-RT RIC framework 132, their requests for E2 services can easily exhaust the capacity of the Near-RT RIC framework 132 (in terms of e.g., processor usage and memory buffers etc) to handle all incoming and ingoing messages since the E2 interface carries both uplink data reports towards the xApps 131 and downlink controls and policy commands towards the E2 nodes 120. For a given number of xApps 131 communicating via the Near-RT RIC framework 132 and resulting E2 interface service subscriptions, the capacity of the E2 interface and message buffers in the Near-RT RIC 130 can easily be exhausted with the current architecture; the mapping from Near-RT RIC API request messages to E2AP subscription request messages, and from over E2 received indication messages to the Near-RT RIC API notification messages, results also in unnecessary load due to certain IES defined in these two hops to support this mapping task alone. For example, a Procedure Transaction ID (PTI) IE in the Near-RT RIC API specification is used to identify a communication between the xApp 131 and Near-RT RIC framework 132 and serves no purpose on the E2AP side except to support thegatekeeping role of the Near-RT RIC framework 132. The impact of using these supporting IES can be high if the number of xApps increase to a significant number; the current O-RAN specified E2SM messages are encoded in Abstract Syntax Notation One (ASN.i) and JavaScript Object Notation (JSON). When the Near-RT RIC 130 needs to parse the E2SM, it needs to support different data model processing which increases complexity of the Near-RT RIC framework 132 and increases latency; and the E2 interface uses Internet Protocol Security (IPsec) for security while the Near-RT RIC API specification mandates different security requirements for different platform services, e.g. Transport Layer Security (TLS). The E2 nodes 120 currently cannot enforce a different security solution for E2SMs as there is no possibility to negotiate alternative security protocols between xApps 131 and the E2 nodes 120 for E2SM services.

[0052] In the current E2 interface specifications, the E2 node 120 uses a well- established E2 setup procedure to send an E2 setup request message to the Near-RT RIC 130 and expose information about which E2SMs the E2 node 120 offers / supports. IEs comprised in the E2 setup request message are shown in Table 1 below.Table 1. Information Elements of the E2 setup request message

[0053] In the E2 setup request message, the “RAN Functions Added List” IE carries details about E2SMs available in the E2 node 120. Specifically, the sub-IE called “RAN Function Definition” carries the details of an E2SM specifications such as which E2 services (REPORT, INSERT, CONTROL, etc.) are offered in the E2SMs. Details such as which event triggers can be set by an xApp 131 in the E2 node 120 and what type of data exposure can be requested are all carried in this “RAN Function Definition” IE. All E2SM specifications in O-RAN therefore define the structure for this “RAN Function Definition” IE.

[0054] Table 2 below shows the “RAN Function Definition” IE for the O-RAN standardized E2SM- Key Performance Measurement (KPM) service model specification which offers only the E2 REPORT service to the Near-RT RIC 130 and xApps 132.Table 2: RAN function definition IE for E2SM-KPM.

[0055] As shown in Table 2, the “RAN Function Definition” IE contains information about the data exposure services available in the E2SM-KPM specification. Since the E2SM-KPM specification does not offer any downlink CONTROL or POLICY services to the xApps 131, the RAN Function Definition IE in Table 2 has no information about those services. For all standardized E2SMs, the Near-RT RIC framework 132 can parse and store the information provided by the E2 node 120 in the RAN Function Definition IE. An xApp 131 can discover this at a later time, e.g., after registering with the Near-RT RIC framework 132, and acquire the details about how it can create event triggers in the E2 node 120 and when thosetriggers are activated, how to request the E2 node 120 to send certain measurements in the E2 indication messages in chosen “Indication Message Formats”.

[0056] We propose to extend the handshake between the Near-RT RIC and E2 node at “E2 Setup Procedure” (clause 8.3.1 in [3]) and / or at “RIC Service Update” procedure (clause 8.3.4 in [3]) to enable the E2 node to express its capability of supporting its E2 services (e.g. measurement reporting) over alternative / sidelink interface(s). This may be realized by extending the “RAN Function Definition” IE of an E2SM to carry information about which services of the E2SM can be used outside the normal “E2 interface” two-hop path, on alternative path(s) having different protocols, data models and security requirements than those specified for E2AP.

[0057] Figure 2 shows a signalling diagram illustrating a method of a policy enforcement node - i.e. the Near-RT RIC 130 - of communicating with an E2 node in the form of a gNB 120 according to an embodiment for resolving one or more the above-discussed issues.

[0058] Reference is further made to Figure 3 illustrating the O-RAN architecture 100 of Figure 1, but in addition with a direct communication path 140 established between the xApp 131 and the E2 node 120 according to an embodiment.

[0059] In a first step S101, the xApp 131 transmits a request to establish a direct communication path 140 with the gNB 120. This may be preceded by an E2 setup procedure to be described in detail hereinbelow with reference to Figure 5. This request is transmitted over the Near-RT RIC API to the Near-RT RIC framework 132 and further comprise a request to access a service provided to the gNB 120 (commonly referred to as an E2 subscription request). For instance, the xApp 131 may request to observe certain operational data and / or events in the gNB 120, such as information pertaining to handovers of UEs served by the gNB 120s.

[0060] Thus, in S101, the xApp 131 may as specified in the O-RAN Near-RT RIC API specification request the Near-RT RIC framework 132 to send an E2 subscription request to the gNB 120 using the current E2AP functional procedures. As is understood, it may be that the xApp 131 requests to communicate with the gNB 120 over the direct communication path 140 to be established for some of the requested E2 services while communicating over the Near-RT RIC API via the Near-RT RIC framework 132 for some other of the requested E2 services. Further, the request tocommunicate with the gNB 120 over the direct communication path 140 may be applicable to certain service types e.g., E2 REPORT services, or to all communication related to a specific session between the xApp 131 and the gNB 120.

[0061] Optionally in S102, the Near-RT RIC framework 132 may validate and / or authorize the request in order to proceed with the establishing of the direct path. The xApp 131 may be required to provide additional details required for allowing communication over the direct communication path 140, such as e.g. a public key of the xApp in case the direct path requires security based on for instance TLS. The Near-RT RIC framework 132 may advantageously not parse all details of the xApp request such as the actual preference of the xApp 131 for establishing the direct communication path 140.

[0062] Upon successful validation / authorization in S102 of the request received in S101 for direct communication path establishment, the Near-RT RIC framework 132 transmits in S103 a RIC subscription request message including the request for the establishment of the direct communication path establishment request to the gNB 120 for the desired E2 service to be accessed. This RIC subscription request message may carry an indication of which interface the xApp 131 has expressed a preference for and associated required information. It should be noted that the Near-RT RIC framework 132 not necessarily is aware of that the request from the xApp 131 in S101 actually comprises a request for setting up the direct path 140; the xApp’s preferences for direct path and any details for that preference e.g., a TLS certificate, maybe fully transparent to the Near-RT RIC framework 132, which forwards the information to the gNB 120.

[0063] Once the request for an E2SM offered service is received by the gNB 120 node with an indication that the service is desired by the xApp 131 to be provided on a (supported) direct communication path 140, the gNB 120 processes the request in S104 to determine whether or not the request is to be allowed. In other words, the gNB 120 may either accept or reject the request depending on local decision criteria, e.g., whether or not the gNB 120 can offer the requested service via the direct communication path 140 at that particular time. Assuming that the request is allowed in S104, the gNB 120 will provide a response in S105 to inform the Near-RT RIC framework 132 that the subscription request was successfully admitted and that the requested service will be available the direct communication path 140, the responsepossibly comprising additional information associated with the direct path, such as preferred communication format, services provided, security protocol applied, etc. Again, this information may be transparent to the Near-RT RIC framework 132 which thus forwards the information to the xApps 131.

[0064] The Near-RT RIC framework 132 will in its turn in step S106 provide a response indicating that the request initially transmitted by the xApp 131 in S101 indeed is allowed, and the xApp 131 may proceed with communicating with the gNB 120 over the established direct communication path 140 in S107 for communicating data in the downlink and / or uplink relating to the service to which access is requested in S101. Advantageously, this bypasses the Near-RT RIC framework 132 and any communication between the xApp 131 and the gNB 120 will, after the initializing steps of S101-S105 have been undertaken, be performed via the established direct communication path 140.

[0065] Further, the response of S106 may in an embodiment be configured to comprise information regarding the established direct communication path 140 required for accessing the service provided by the gNB 120, the information e.g. being carried in E2SM specific IES in the E2AP messages. This may include information such as e.g. a Uniform Resource Identifier (URI) for discovery and access of any physical resources provided by the gNB 120, protocol information, and security details in the form of for instance an authentication token which may only be valid for that specific session, xApp or user of the xApp. The xApp 131 may, at this point, start using the direct path 140 for E2 service by establishing the path 140 using any received and required details. The communication over the direct communication path 140 may operate in either push mode (gNB 120 sends data to xApp 131) or pull mode (xApp 131 fetches data from the gNB 120). In other words, the received response of step S106 may comprise information indicating requirements with which the established direct communication path 140 is to comply in order to be successfully established in S107.

[0066] Advantageously, with the embodiment described above with reference to Figures 2 and 3, a greatly improved method of communicating between the xApp(s) 131 and the gNB(s) 120 is provided, where a direct communication path 140 is established between the xApps 131 and the gNBs 120. As described with reference to Figure 2, control signalling is initially performed via the Near-RT RIC API and theNear-RT RIC framework 132 to establish the direct communication path 140 while the service path transporting payload data is carried over the established direct communication path 140, thereby bypassing the Near-RT RIC framework 132. Thus, any data being considered to constitute control plane data is typically carried over the Near-RT RIC framework 132, while data being considered to constitute user plane data is typically carried over the direct communication path 140.

[0067] Further advantageous in establishing the direct communication path 140 is that usage of alternative protocols, data models and security mechanisms between the xApps 131 and the gNB 120 is facilitated as compared to those used in the prior art when communicating over the Near-RT RIC API and the Near-RT RIC framework 132. These alternative protocols, data models and security mechanism may be better suited to the specific nature of the offered E2 service, such as e.g., real-time data streaming. Further advantages include: the bypassing of the Near-RT RIC framework 132 greatly reduces overhead of Near-RT RIC mapping or translation of Near-RTR API messages to E2AP messages (and vice versa), resulting in efficiency gains and improves load balancing; the IES specified in Near-RT RIC API and E2AP messages that enables the Near-RT RIC framework 132 to perform its gatekeeping can be reduced to a minimum, resulting in efficiency in resource consumption; the xApps 131 are enabled to pull the data they need from the gNBs 120 instead of relying on the data being pushed from the gNBs 120 and the Near-RT RIC framework 132 resulting in low latency and efficient communication between the xApps 131 and the gNBs 120; the xApps 131 and the gNBs 120 E2 nodes can use alternative protocols and data models e.g., Kafka streaming, Hypertext Transfer Protocol (HTTP), REpresentational State Transfer (REST) APIs, etc., instead of being constrained or limited to Stream Control Transmission Protocol (SCTP) ASN.i and IPsec of the E2 interface, for instance, more suitable streaming protocols can be used, meaning an entire SCTP message does not need to be decoded to access the first data elements, and an SCTP buffer does not need to be filled before sending data; and support is enabled for separating proprietary and third party xApps communication with the E2 nodes, i.e., proprietary xApps may use an alternative toE2AP while third party xApps can remain on the E2AP path. In other words, some xApps 131 may communicate with the E2 nodes 120 via the E2 interface over the Near-RT RIC framework 132 while others may bypass the Near-RT RIC framework 132 by communicating over the direct path 140. While communication between the Near-RT RIC framework 132 and the E2 nodes 120 complies with the SCTP, any appropriate protocol may be applied for the communication over the direct path 140.

[0068] While Figure 2 illustrates the xApp 131 performing a request to establish a direct communication path 140 with the gNB 120, it may alternatively be the gNB 120 that performs a request to establish a direct communication path 140 with the xApp 131.

[0069] Figure 4 shows a signalling diagram illustrating such an embodiment.

[0070] Similar to Figure 2, the xApp 131 sends a request for an E2 service in step S201 to the Near-RT RIC framework 132, which in its turn transmits in S202 a RIC subscription request to the gNB 120 for the desired E2 service to be accessed. As is understood, the Near RT RIC framework may validate the received request as previously discussed.

[0071] However, a difference with this embodiment as compared to that described with reference to Figure 2 is that the E2 service request of step S201 does not comprise a request for establishment of the direct path 140. Rather, in this embodiment, the request for the establishment of the direct path 140 is performed by the gNB 120.

[0072] The gNB 120 may wish to transmit any data related to the service to be accessed via the direct communication path 140 and thus sends a request to this effect in S203 to the Near-RT RIC framework 132, which in its turn sends the direct path request to the xApp 131 in S204.

[0073] Once the request is received by the xApp 131, the xApp 131 processes the request in S205 to determine whether or not the request is to be allowed. Assuming that the request is allowed in S205, the xApp 131 will provide a response in S206 via the Near-RT RIC framework 132 that the request was successful, which in its turn forwards the positive response to the gNB 120 in step S207 that the direct communication path 140 indeed will be available for communication, and the gNB 120 may proceed with communicating with the xApp 131 over the established directcommunication path 140 in S208 for communicating data relating to the service to which access is requested. Advantageously, this bypasses the Near-RT RIC framework 132 and any communication between the xApp 131 an the gNB 120 will, after the initializing steps of S201-S207 have been undertaken, be performed via the established direct communication path 140 as discussed hereinabove. It should be noted that in steps S206 and S207, the E2AP CONTROL procedure may be used to inform the gNB 120 that the direct path request is accepted and thus that the direct path 140 should be established. Further, it may be envisaged that the request of step S204 comprises information allowing the xApp 131 to establish the direct path as illustrated with S208 without performing steps S206 and S207 (thereby making steps S206 and S207 optional).

[0074] Now, in the current E2 procedures and E2SM defined “RAN Function Definitions” discussed with reference to Tables 1 and 2 above, it is not possible for the gNB 120 to indicate an option to expose E2 data and provide access to RAN services over an alternative interface, i.e. the direct communication path 140.

[0075] Figure 5 shows a signalling diagram illustrating an initialization procedure according to an embodiment, where the gNB 120 indicates the E2 setup request that a direct communication path indeed is available for establishment.

[0076] As per the current O-RAN Near-RT RIC API specification, an xApp 131 can use the Near-RT RIC APIs to fetch information about available RAN functions and E2SMs in an E2 node, i.e. in this case the gNB 120. An xApp 131 can use shared data layer (SDL) services to acquire information regarding configurations, supported RAN functions, provided E2SMs, etc., of the gNB 120. This is realized by the Near-RT RIC 130 providing information about “RAN Functions Added List” which the Near-RT RIC 130 obtains during E2 setup.

[0077] The E2 setup request message currently used in O-RAN can thus be modified to allow a gNB 120 to indicate that communication via the direct communication path 140 indeed is available, either by adding the direct communication path information in an existing IE or by adding the information in a new IE included in the E2 setup request message, e.g. in a new RAN Function Definition IE.

[0078] With such modification, an xApp 131 can discover that certain services of a RAN function in the gNB 120 are available outside the E2AP and Near-RT RIC API two-hop communication path including the Near-RT RIC framework 132 using separate protocols, data models and / or security mechanisms. The information may enable an xApp 131 to decide or prioritize for each service, i.e. whether the xApp 131 wishes to use the normal E2AP and Near-RT RIC API two-hop path for service consumption or the direct communication path 140 with its own separate protocols, data model and security requirements, etc., which also may be stated in an IE.

[0079] With this additional information, an xApp 131 can check whether a certain E2SM service e.g., measurement reporting service of E2SM-KPM, is offered over the direct communication path 140 to E2AP, e.g., over HTTP / REST or KAFKA based streaming in addition to being over the E2AP. In addition, the xApp 131 can check what security mechanism is required to consume those services over the direct communication path 140 to E2AP. The E2 node 120 may support all or a subset of its offered E2 services (REPORT, CONTROL, POLICY, etc.) over the direct communication path 140. For example, an E2 node may support data exposure related services (e.g., E2 REPORT) belonging to a specific E2SM over a HTTP / REST or KAFKA based interface in addition to E2 interface while offering E2 Control and Policy services only on E2AP.

[0080] The Near-RT RIC 130 may store the information about E2SMs available on an E2 node 120 including the information about over the direct communication path 140 in the Near-RT RIC database. The xApps 131 may then use the Near-RT RIC APIs to discover the available E2SMs and their support for the direct communication path 140.

[0081] In Figure 5, the gNB 120 sends an E2 setup request message in S301. However, in contrast to the E2 setup request message utilized in the prior art (and discussed in detail hereinabove), the E2 setup request message of this embodiment also indicates in an IE whether or not communication over a direct communication path 140 is available for accessing E2 services of the gNB 120.

[0082] The Near-RT RIC stores in S302 the information of the request received by the Near-RT RIC framework 132 in S301 and optionally acknowledges a successful E2 setup process in S303.

[0083] Subsequently, i.e. before the xApp 131 sends a request to the Near-RT RIC framework 132 to access an E2 service of the gNB 120 via the direct communication path 140 as illustrated in step S101 of Figure 2, the xApp 131 may acquire the stored information regarding the availability of the direct communication path 140 and supported service models of the gNB 120 in S304.

[0084] Advantageously, by using the direct communication path 140 for communication payload data between the xApp 131 and the gNB 120, numerous messages which currently are passed over the Near-RT RIC framework 132 may be omitted. Table 3 below illustrates one or more IES that may be omitted with the proposed embodiments.Table 3: E2 Indication message.

[0085] Figure 6 illustrates a policy enforcement node 130 in the form of a Near- RT RIC configured to communicate with an E2 node (such as the gNB 120) in a communications network 100 according to an embodiment, where the steps of the method performed by the Near-RT RIC 130 in practice are performed by a processing unit 211 embodied in the form of one or more microprocessors arranged to execute a computer program 212 downloaded to a storage medium 213 associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit 211 is arranged to cause the Near-RT RIC 130 to carry out the method according to embodiments when the appropriate computer program212 comprising computer-executable instructions is downloaded to the storage medium 213 and executed by the processing unit 211. The storage medium 213 may also be a computer program product comprising the computer program 212. Alternatively, the computer program 212 may be transferred to the storage medium213 by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program 212 may be downloaded to the storage medium 213 over a network. The processing unit 211 may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. The Near-RT RIC 130 further comprises a communication interface 214 (wired and / or wireless) over which the Near-RT RIC 130 is configured to transmit and receive data.

[0086] Figure 7 illustrates an E2 node 120, i.e. a RAN node, in the form of a gNB configured to communicate with a policy enforcement node in the form of a Near-RT RIC 130 in a communications network 100 according to an embodiment, where the steps of the method performed by the gNB 120 in practice are performed by aprocessing unit 311 embodied in the form of one or more microprocessors arranged to execute a computer program 312 downloaded to a storage medium 313 associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit 311 is arranged to cause the gNB 120 to carry out the method according to embodiments when the appropriate computer program312 comprising computer-executable instructions is downloaded to the storage medium 313 and executed by the processing unit 311. The storage medium 313 may also be a computer program product comprising the computer program 312. Alternatively, the computer program 312 may be transferred to the storage medium313 by means of a suitable computer program product, such as a DVD or a memory stick. As a further alternative, the computer program 312 may be downloaded to the storage medium 313 over a network. The processing unit 311 may alternatively be embodied in the form of a DSP, an ASIC, an FPGA, a CPLD, etc. The gNB 120 further comprises a communication interface 314 (wired and / or wireless) over which the gNB 120 is configured to transmit and receive data.

[0087] The methods according to the herein disclosed embodiments are suitable to be performed by devices residing in a cloud computational environment. All the functional elements of the devices of the embodiments disclosed herein can be realized in a distributed manner and are subject to virtualization / containerization. The SMO framework, rApps, Non-RT RIC, Near-RT RIC, xApps, and E2 nodes can all be realized as separate distributed nodes connected via standardized and proprietary interfaces.

[0088] The aspects of the present disclosure have mainly been described above with reference to a few embodiments and examples thereof. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

[0089] Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

CLAIMS1. A method of a policy enforcement node (130) of communicating with a radio access network, RAN, node (120) in a communications network (100), the policy enforcement node (130) hosting applications (131) for performing the communication and comprising a policy enforcement node framework (132) over which communication is initialized with the RAN node (120), the method comprising: transmitting (S101), by the application (131) via the policy enforcement node framework (132), a request to the RAN node (120) to access a service provided to the RAN node (120) over a direct communication path (140) between the application(131) and the RAN node (120); receiving (S106), from the RAN node (120) via the policy enforcement node framework (132), a response indicating whether or not the request is allowed; and if so establishing (S107) the direct communication path (140) between the application (132) and the RAN node (120) for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework (132).

2. The method of claim 1, said transmitted (S101) request further comprising authentication data to be validated (S102) at the policy enforcement node framework(132) in order for the request to be allowed.

3. The method of claims 1 or 2, said received (S106) response further comprising information indicating requirements with which the established direct communication path (140) is to comply in order to be successfully established (S107).

4. The method of any one of the preceding claims, wherein control plane data is configured to be transported carried over the Near-RT RIC framework (132), while user plane data is configured to be transported via the direct communication path (140).5- The method of any one of the preceding claims, further comprising: acquiring (S204) information whether or not a direct communication path (140) is available for establishment with the RAN node (120) before transmitting (S101) said request.

6. A computer program (212) comprising computer-executable instructions for causing an application of a policy enforcement node (130) to perform steps recited in any one of claims 1-5 when the computer-executable instructions are executed on a processing unit (211) included in the policy enforcement node (130).

7. A computer program product comprising a computer readable medium (213), the computer readable medium having the computer program (212) according to claim 6 embodied thereon.

8. A method of a radio access network, RAN, node (120) of communicating with a policy enforcement node (130) in a communications network (100), the policy enforcement node (130) hosting applications (131) for performing the communication and comprising a policy enforcement node framework (132) over which communication is initialized with the RAN node (120), the method comprising: transmitting (S203), to the application (131) via the policy enforcement node framework (132), a request to communicate data relating to a service provided by the RAN node (120) over a direct communication path (140) between the RAN node (120) and the application (131); and establishing (S208) the direct communication path (140) between the RAN node (120) and application (132) for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework (132).

9. The method of claim 8, further comprising: receiving (S207), from the application (131) via the policy enforcement node framework (132), a response indicating whether or not the request is allowed; and if so establishing (S208) the direct communication path (140) between the RAN node(120) and application (132)10. The method of claims 8 or 9, further comprising: providing (S301) the policy enforcement node (130) with information indicating whether or not communication via the direct communication path (140) is available for the RAN node (120).

11. A computer program (312) comprising computer-executable instructions for causing a RAN node (120) to perform steps recited in any one of claims 8-10 when the computer-executable instructions are executed on a processing unit (311) included in the RAN node (120).

12. A computer program product comprising a computer readable medium (313), the computer readable medium having the computer program (312) according to claim 11 embodied thereon.

13. The method of any one of the preceding claims, the communications network (100) being an Open Radio Access Network, O-RAN, the policy enforcement node(130) being a Near-Real Time Radio Access Controller, Near-RT RIC, the application(131) being a radio application, rApp, and the RAN node (120) being a radio base station.

14. A policy enforcement node (130) configured to communicate with a radio access network, RAN, node (120) in a communications network (100), the policy enforcement node (130) hosting applications (131) for performing the communication and comprising a policy enforcement node framework (132) over which communication is initialized with the RAN node (120), the policy enforcement node (130) comprising a processing unit (211) and a memory (213), said memory containing instructions (212) executable by said processing unit (211), whereby the policy enforcement node (130) is operative to:transmit, by the application (131) via the policy enforcement node framework (132), a request to the RAN node (120) to access a service provided to the RAN node (120) over a direct communication path (140) between the application (131) and the RAN node (120); receive, from the RAN node (120) via the policy enforcement node framework (132), a response indicating whether or not the request is allowed; and if so to establish the direct communication path (140) between the application (132) and the RAN node (120) for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework (132).

15. The policy enforcement node (130) of claim 14, said transmitted request further being configured to comprise authentication data to be validated at the policy enforcement node framework (132) in order for the request to be allowed.

16. The policy enforcement node (130) of claims 14 or 15, said received response further being configured to comprise information indicating requirements with which the established direct communication path (140) is to comply in order to be successfully established.

17. The policy enforcement node (130) of any one of claims 14-16, wherein control plane data is configured to be transported carried over the Near-RT RIC framework (132), while user plane data is configured to be transported via the direct communication path (140).

18. The policy enforcement node (130) of any one of claims 14-17, further being operative to: acquire information whether or not a direct communication path (140) is available for establishment with the RAN node (120) before transmitting (S101) said request.19- A radio access network, RAN, node (120) configured to communicate with a policy enforcement node (130) in a communications network (100), the policy enforcement node (130) hosting applications (131) for performing the communication and comprising a policy enforcement node framework (132) over which communication is initialized with the RAN node (120), the RAN node (120) comprising a processing unit (311) and a memory (313), said memory containing instructions (312) executable by said processing unit (311), whereby the RAN node (120) is operative to: transmit, to the application (131) via the policy enforcement node framework (132), a request to communicate data relating to a service provided by the RAN node (120) over a direct communication path (140) between the RAN node (120) and the application (131); and to establish the direct communication path (140) between the RAN node (120) and application (132) for communication of data relating to the accessed service, thereby bypassing the policy enforcement node framework (132).

20. The RAN node (120) of claim 19, further being operative to: receive, from the application (131) via the policy enforcement node framework (132), a response indicating whether or not the request is allowed; and if so to establish the direct communication path (140) between the RAN node (120) and application (132).

21. The RAN node (120) of claims 19 or 20, further being operative to: provide the policy enforcement node (130) with information indicating whether or not communication via the direct communication path (140) is available for the RAN node (120).

Images