Patent Description:
Embodiments herein further relates to computer programs and carriers corresponding to the above methods, RAN function node and network node.

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 Local Area Network such as a Wi-Fi network or a Radio Access Network (RAN) to one or more core networks (CN). 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 or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in <NUM>. 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 radio frequencies with the wireless device within range of the radio network node.

Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (<NUM>) network, have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (<NUM>) network also referred to as <NUM> New Radio (NR) or Next Generation (NG). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs used in <NUM> networks. In general, in E-UTRAN/LTE the functions of a <NUM> RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE, and the core network. As such, the RAN of an EPS has an essentially "flat" architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E-UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface.

Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. 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. Such systems and/or related techniques are commonly referred to as MIMO.

A major difference with <NUM> Core (5GC) compared to EPC is that 5GC's control plane (CP) functions interact in a Service-Based Architecture (SBA). A key Network Function (NF) of SBA is the Network Repository Function (NRF), which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another. SBA principles apply to interfaces between CP functions within 5GC only, so interfaces toward Radio Access Network (RAN), user equipment or user plane (UP) functions are excluded.

Other changes include several new functions, such as the Network Exposure Function (NEF).

RAN data when used herein relates to connectivity in a RAN, e.g. connectivity over a radio interface between a RAN node and a radio device in the RAN. Thus, examples of RAN data may comprise measurement collected by RAN standardized from 3GPP such as e.g. average and/or distribution of delay on the radio interface, DL and/or UL total and/or distribution of Physical Resource Blocks (PRB) usage, average and/or distribution of DL and/or UL UE throughput, and/or proprietary measurements and/or counters implemented by RAN vendor such as e.g., specific measurements of specific parameters at e.g. Radio Link Control (RLC) or Medium Access Control (MAC) layer not defined by 3GPP.

RAN data is important, this is since they capture in detail RAN behavior, and obviously RAN behavior impacts performance experienced by UEs served by the RAN. From one side, it is observed a raise of more complex applications, which could benefit by <NUM> leveraging on features such as network exposure from information of expected performance experienced over a mobile network. On another side, the SBA architecture of <NUM> opens for possibility to create new services leveraging on information exposed by another functions or nodes of the network. Consequently, RAN data represents a key factor, especially if properly processed, to support new services within a mobile network.

RAN data may be used to generate information or notifications of importance for many applications, such as applications running in radio devices such as e.g. Internet of Things (IoT) devices, radio devices in vehicles or smartphones, such as UEs.

<CIT> is a prior art technology disclosing methods and nodes for inadvance prediction notification.

<CIT> describes a network device (e.g. RAN) that obtains per session/flow control information from the entities involved in exposing control information to the 3rd parties.

As a part of developing embodiments herein a problem was identified by the inventors and will first be discussed.

RAN nodes have an ability to stream out data in near real-time. This may be to feed a management system to support off-line analysis of RAN performance, e.g. RAN observability. However direct exposure of RAN data to other than the management system may not be desired for several reasons, since what can be obtained from RAN is raw data. Raw RAN data, referred to as RAN data, when used herein means RAN data such as e.g. standardized measurements, proprietary measurements, etc., in the form as they are collected by the RAN.

Furthermore, the RAN data may need to be normalized to provide same information from different RAN vendors. To be normalized e.g. means that instead of providing an explicit value as for example "average DL throughput: 10Mbps", there may be a predefined normalization which translate the information as "DL throughput: good".

Another reason for direct exposure of RAN data not being desired, is that that the RAN data should not be exposed to non-authorized parties. This is to prevent misuse and potential privacy issues and, in general, the content of the RAN data could be different considering whether the final receiver could be either trusted or untrusted. Trusted when used herein means that the network operator trusts that the final receiver will not misuse the information received from the network, e.g. defined via some specific agreements, or the operator trusts that information provided to the receiver will not leave network trusted domain, e.g., the receiver is an application hosted in the network domain. A trusted receiver might be allowed to obtain more sensitive information than an untrusted receiver. , a trusted receiver may obtain the information "average predicted DL throughput: <NUM> Mbps" while an untrusted might obtain the information "average predicted DL throughput: good". Generally, RAN data should be generated with knowledge whether they are going to be exposed to trusted/untrusted receivers.

Currently, there is no standardized way for RAN to expose RAN data to external applications. External applications when used herein may comprise Application Function (AF) or an application server interested to receive information about expected network performance of UE(s) associated to the application.

An object of embodiments herein is to provide an improved way of securely exposing RAN data.

The proposed technology is defined by the appended independent claims and further embodiments are described by the dependent claims.

The publishing of the one or more RANs comprises an indication of which one of a trusted or an untrusted domain, that the generated one or more RAN insights are to be exposed in, by the network node. When the network node exposes the one or more RANs according to the indication, the risk for exposure of sensitive RAN insights is avoided since sensitive RAN insights will be exposed in a trusted domain.

This in turn provides an improved way of exposing RAN data that is processed to be RAN insights to suit a receiver of the RAN insights.

An example of embodiments herein relates to RAN exposure handling.

Embodiments herein are e.g. related to connectivity, and service continuity in a RAN.

Embodiments herein provide methods for exposure of processed RAN information, referred to as RAN insights, that are useful and, potentially, tailored for specific applications without risk for exposure of sensitive raw RAN data, referred to as RAN data.

<FIG> is a schematic overview depicting a wireless communications network <NUM> wherein embodiments herein may be implemented. The wireless communications network <NUM> comprises one or more RANs, such as the RAN <NUM> and one or more CNs. The wireless communications network <NUM> may use <NUM> Fifth Generation New Radio, (<NUM> NR) but may further use a number of other different Radio Access Technologies (RAT)s, such as, Wi-Fi, (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.

Network nodes, such as a RAN node <NUM>, or also called distributed node, operate in the RAN <NUM>. The distributed node <NUM> may provide radio access in one or more cells in the RAN <NUM>. This may mean that the RAN node <NUM> provides radio coverage over a geographical area by means of its antenna beams. The RAN node <NUM> may 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, an Access Point Station (AP STA), an access controller, a UE acting as an access point or a peer in a Device to Device (D2D) communication, or any other network unit capable of communicating with a radio device within the cell served by RAN node <NUM> depending e.g. on the radio access technology and terminology used.

According to embodiments herein, a RAN function node <NUM> operates in the wireless communications network <NUM>, e.g. in a RAN domain of the RAN <NUM> or in a management domain, e.g. of the CN. In some embodiments the RAN function node <NUM> operates in the RAN <NUM> or in the CN. The RAN function node <NUM> is adapted to gather RAN data, e.g. from the RAN node <NUM> using E-UTRAN and/or NG-RAN, and process such RAN data to generate RAN insights, e.g. analyzed, abstracted, processed and/or normalized RAN data. The RAN function node <NUM> may also be referred to as a RAN Prediction Function (PF). The RAN function node <NUM> uses RAN data to predict metrics related to performance that a UE such as e.g. a wireless device <NUM>, is expected to experience, e.g. based on historical data, estimation, and/or predictions, in an upcoming time window. Such metrics may be related to throughput, e.g., potential throughput changes, congestion, and/or related latency etc..

Throughput e.g. comprises upcoming throughput degradation or upcoming throughput improvement. Congestion e.g. comprises upcoming congestion or upcoming end of congestion. Related latency e.g. comprises upcoming latency increase.

As hinted above, the RAN data may e.g. be used to generate predictions of interruptions in connectivity, predictions of potential throughput changes, or predictions of potential congestion, or predictions of potential latency changes in the RAN. Predictions of potential throughput changes may e.g. comprise upcoming throughput degradation in the RAN. Predictions of potential congestion may e.g. comprise upcoming congestion and/or upcoming end of congestion. Predictions of potential latency changes may e.g. comprise upcoming latency increase in the RAN.

Such RAN insights, also referred to as RAN information may be used to inform applications in radio devices, such as e.g. the wireless device <NUM> about an upcoming change of achievable performance in the RAN and the application in the radio device may then adjust its behavior and configuration in order to mitigate bad experience in the application. , a vehicle may adjust its behavior in terms of reducing speed or changing automation level to overcome the fact that the current vehicle behavior may not be suitable considering the upcoming interruption or a drop in throughput or a congestion or a latency increase of the RAN.

Further, a network node <NUM> operates in the wireless communications network <NUM>. The network node <NUM> may e.g. be a core network node operating in the CN. The network node <NUM> may e.g. referred to as a network entity.

RAN insights are generated by the RAN function node <NUM> e.g. upon request from network node <NUM>.

Another network node <NUM> may in some embodiments operate in the wireless communications network <NUM>.

The network node <NUM> may e.g. be a Network Data Analytics Function (NWDAF) node, a Network Exposure Function (NEF) node, or and Application Programming Interfaces- Gateway (API-GW) node.

A NWDAF is e.g. responsible for providing network analysis information upon request from network functions.

A NEF is e.g. related to the 3GPP <NUM> Architecture. This function provides a means to securely expose the services and capabilities provided by 3GPP network functions.

An API-GW is e.g. responsible for providing APIs to external applications. An API-GW may allow external applications to use APIs of e.g. a NEF or of e.g. a NWDAF, although an external application might interact with NEF directly. An API-GW may be composed of several functionalities, e.g., including NEF functionalities, handling authorization of external applications, exchange of security keys, etc..

Wireless devices such as a wireless device <NUM> operate in the wireless communications network <NUM>. The wireless device <NUM> may e.g. be an NR device, a mobile station, a wireless terminal, an NB-loT device, an eMTC device, a CAT-M device, a WiFi device, an LTE device and an a non-access point (non-AP) STA, a STA, that communicates via such as e.g. the RAN node <NUM>, one or more RANs such as the RAN <NUM> to one or more CNs. It should be understood by the skilled in the art that the wireless device <NUM> relates to a non-limiting term which means any wireless device, UE, terminal, vehicle radio device, wireless communication terminal, user equipment, (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell.

Methods herein may e.g. be performed by the RAN function node <NUM>, the network node <NUM>. As an alternative, a Distributed Node (DN) and functionality, e.g. comprised in a cloud <NUM> as shown in <FIG>, may be used for performing or partly performing the methods.

Examples of embodiments herein provide methods for exposing processed RAN information, referred to as RAN insights, that are useful and, potentially, tailored for specific applications without risk for exposure of sensitive raw RAN data, referred to herein as RAN data.

The wording RAN insights when used herein e.g. means information generated by the RAN function node <NUM> from processing of RAN data. The RAN insights are relevant to expected or events that a certain UE or group of UEs is expected to experience in an upcoming time window. Expected may comprise estimated and/or predicted, and performance may comprise throughput, congestion, latency, etc. Events may comprise loss of connectivity, handover, UP unavailability, etc..

Examples of RAN insights and what they may be used for will be described more in detail below.

The wording RAN data when used herein e.g. means measurements collected by a RAN node such as the RAN node <NUM>, either standardized or proprietary. Collection of measurements may be performed with a certain frequency and measurements may be aggregated over a certain time window. Examples of RAN data may e.g. comprise:.

Such RAN data may be e.g. collected with different granularities, e.g., per UE, or per group of UEs, or per Quality class (QCI,5QI), or per radio bearer, etc..

Examples of what RAN data may be used for processing one or more RAN data to generate a RAN insight e.g. comprising:.

The wordings exposing and to expose, when used herein e.g. means that RAN insights generated from the RAN function node <NUM> are provided to one or more network functions and/or network nodes to be directly consumed and/or to be further processed to be provided to external receivers such as an AF or an application client/server.

The wording trusted domain when used herein e.g. means that information in a trusted domain may not require normalization and/or translation to hide sensitive data. The wording untrusted domain when used herein e.g. means that information in an untrusted domain may require normalization and/or translation to hide sensitive data.

According to embodiments herein, the network node <NUM> may be tailored depending on the final receivers of the RAN insights being in trusted or untrusted domains. Being tailored when used herein means that a RAN insight generated for a trusted domain may be a fine-granular and precise information e.g. indicating a specific value for an expected performance metric while a RAN insight generated for a untrusted domain may be a quantized or normalized information of an expected performance metric without containing a specific value.

, the network node <NUM> may be tailored depending on the final receivers of the RAN insights being in trusted or untrusted domains.

These RAN insights may e.g. be finally published by the RAN function node <NUM> to a network message bus, thus other network nodes such as the network node <NUM> may consume these RAN insights, e.g., for their internal usage or for exposure to external applications.

Example of embodiments herein enhances the RAN <NUM> by introducing a functionality such as the RAN function node <NUM> for creation, upon request, of one or more RAN insights generated from RAN data provided by the RAN node <NUM>. This allows the RAN function node <NUM> to generate useful RAN insights to be used e.g. by external applications and at the same time avoiding that RAN raw data, referred to herein as RAN data, are directly exposed. In some embodiments herein it may be considered that exposure of RAN insights should use a message bus for the exposure of RAN insights. In this way, the message bus could be used by the network node <NUM> in charge of exposing network information to applications, which subscribes to the relevant RAN insights. This, as well as by the RAN function node <NUM> itself to gather relevant RAN data to be used to generate the requested RAN insights. The RAN function node <NUM> may subscribe to and obtain from the RAN node <NUM> in the message bus, the RAN data in one authorization and/or security domain, i.e. in a trusted domain or an untrusted domain, the RAN function node <NUM> may be sent to the message bus to publish the processed "RAN insights" in another authorization/security domain.

Embodiments herein provide mechanisms to collect RAN data to process into RAN insights and distribute RAN insights to authorized consumers. Embodiments herein e.g. comprises the following advantages:.

The provided embodiments may be applicable for 3GPP and Open RAN (ORAN), i.e. the RAN function node <NUM> may be realized as internal RAN software (SW) or as external RAN SW in e.g. in an edge cloud, or in ORAN Non Real-Time RAN Intelligent Controller (Non-RT RIC), or in ORAN Real-Time RAN Intelligent Controller (RT RIC).

<FIG> shows example embodiments of a method performed by the RAN function node <NUM>, also referred to as a RAN PF, for handling connectivity in the RAN <NUM> of the wireless communications network <NUM>. In some embodiments, the network node <NUM> is a trusted network node. In some embodiments, the RAN function node <NUM>, the network node <NUM>, and the RAN node <NUM> are operating in the same trusted domain.

The method comprises one or more of the following actions, which actions may be taken in any suitable order. The method will be defined and exemplified more in detail below. Actions that are optional are marked with dashed boxes in the figure.

The RAN function node <NUM> receives a first subscription request from the network node <NUM>. The first subscription request is for one or more RAN insights relating to the connectivity, such as e.g. throughput prediction, requested for an application related to the wireless device <NUM>.

In some embodiments, the first subscription request for one or more RAN insights relating to the connectivity is received <NUM> from any one out of:.

The RAN function node <NUM> identifies RAN data needed to fulfil the subscription request for the one or more RAN insights.

The RAN function node <NUM> sends a second subscription request to the RAN node <NUM>. The second subscription request is for the identified RAN data.

When RAN data according to the second subscription request is available, the RAN function node <NUM> receives <NUM> from the RAN node <NUM>, published RAN data according to the second subscription request.

The RAN function node <NUM> generates the one or more RAN insights according to the first subscription request based on the received RAN data.

The RAN function node <NUM> establishes which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights are to be exposed in.

In some embodiments, this establishing comprises establishing that any one out of:.

In some embodiments, the establishing which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights shall be exposed in, is based on whether the application is trusted or untrusted.

The RAN function node <NUM> publishes the generated one or more RAN insights according to the first subscription request to reach the network node <NUM>, wherein the publishing comprises an indication, indicating to the network node <NUM> the established domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in. The nodes that the generated one or more RAN insights are to be exposed in may be nodes that will use the one or more RAN insights, they may be referred to as consumers, e.g. consumers of the generated one or more RAN insights. This node may the one requesting the one or more insights. This node may e.g. be any one out of: The network node <NUM>, a trusted network node <NUM>, <NUM>, e.g. a core network node such as e.g. NWDAF, NEF, API-GW, the application related to the wireless device <NUM> via the trusted network node <NUM>, <NUM>, or an external application via the trusted network node <NUM>, <NUM>.

The indication may be explicit or implicit and indicate the trusted or untrusted domain in several different ways.

In some embodiments, the indication comprises any one out of:.

<FIG> shows example embodiments of a method performed by the network node <NUM>, for handling connectivity in a RAN <NUM> of a wireless communications network <NUM>.

In some embodiments, the RAN function node <NUM>, the network node <NUM> are operating in the same trusted domain.

The method comprises one or more of the following actions, which actions may be taken in any suitable order. Actions that are optional are marked with dashed boxes in the figure.

In some embodiments, the network node <NUM> receives a first subscription request for one or more RAN insights relating to the connectivity from any one out of:.

The network node <NUM> sends a first subscription request to the RAN function node <NUM>, also referred to as RAN PF. The first subscription request is for one or more RAN insights relating to the connectivity, e.g. throughput prediction, requested for an application related to the wireless device <NUM>.

When one or more RAN insights according to the first subscription is generated and published by the RAN function node <NUM>, the network node <NUM> discovers the one or more RAN insights. The published one or more RAN insights comprises an indication. The indication indicates a domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in.

The indication may be explicit or implicit and may indicate the trusted or untrusted domain in several different ways.

The indicated domain out of a trusted domain or an untrusted domain the generated one or more RAN insights shall be exposed in, may be based on whether the application is trusted or untrusted.

In some embodiments, the indication indicates any one or more out of:.

The network node <NUM> then exposes the published one or more RAN insights in the indicated domain. This may mean that the network node <NUM> exposes the published one or more RAN insights in the indicated domain to a requesting node to be consumed.

As mentioned above, the nodes that the generated one or more RAN insights are to be exposed in may be nodes that will use the one or more RAN insights, they may be referred to as consumers, e.g. consumers of the generated one or more RAN insights. This node may the one requesting the one or more insights. This node may e.g. be any one or more out of: The network node <NUM>, a trusted network node <NUM>, <NUM>, e.g. a core network node such as e.g. NWDAF, NEF, API-GW, the application related to the wireless device <NUM> via the trusted network node <NUM>, <NUM>, or an external application via the trusted network node <NUM>, <NUM>.

The embodiments described above will now be further explained and exemplified. The example embodiments described below may be combined with any suitable embodiment above.

According to embodiments herein, the RAN <NUM> is extended with the RAN function node <NUM>, e.g. comprising a functionality which gathers RAN data from E-UTRAN and / or NG-RAN nodes such as the RAN node <NUM>, and processes such RAN data in order to generate useful RAN information referred to as RAN insights. The network node <NUM> may request specific RAN insights from the RAN function node <NUM>. These RAN insights may then be exposed to and directly be used by the network node <NUM> requesting the RAN insights, as well as could be then exposed to external applications.

The one or more RAN insights, here referred to as "the RAN insight" is a processed RAN data and may comprise either statistical or predicted information on e.g., RAN status such as congestion, load, etc., achievable performance such as throughput, latency, etc., where such information might have different levels of granularity, e.g., geographical location such as GPS coordinates, cell-level, tracking area level, etc..

A RAN insight may comprise, but not limited to, the following information.

To separate the consumers, the one or more RAN insights may be associated to different indications such as different metadata, i.e., the RAN function node <NUM> may publish the one or more RAN Insights using different indications such different metadata.

As an example, the RAN function node <NUM> publishes one RAN insight which has some information associated to a trusted metadata and other information associated to an untrusted metadata. In this case, a first message bus is in charge of delivering the RAN insight associated to the trusted metadata in a trusted domain to the trusted receivers, also referred to as consumers, and the RAN insight associated to untrusted metadata in an untrusted domain to untrusted receivers.

In another implementation, the RAN function node <NUM> may publish two different RAN insights, one associated with a trusted metadata and another associated with a "untrusted" metadata, so that trusted and/or untrusted receivers receive the right RAN insight in the respective trusted and/or untrusted domain. In this way, consumers of RAN insights may be separated, i.e., untrusted third party applications are aware used in a certain set of metadata in an untrusted domain, while a Mobile Network Operators (MNO) MNO internal and/or trusted application use a private set of metadata for the trusted domain. In addition to the separation of trusted and untrusted domains, the data may be further protected by using encryption, for example for the private MNO data using the vendor certificates, that may be included in the entities, to encrypt the "RAN Insights".

Some first example embodiments are shown in <FIG>. In the first example embodiments of the RAN function node <NUM> functionality a message bus is used to expose RAN insights, e.g. to other nodes such as node functions of a <NUM> core, e.g., NWDAF, or to external applications, in this example, e.g. through the network node <NUM> such as e.g. an API-GW.

In <FIG> the RAN function node <NUM> indicates which domain the one or more RAN shall be exposed in by tagging in metadata if a RAN Insight is for a trusted application to be exposed in a trusted domain or for an untrusted application to be exposed in an untrusted domain. The network node distributes the one or more RAN insights accordingly.

In <FIG>, the RAN function node <NUM> generates RAN insights upon request from other network entities such as the network node <NUM> by using RAN data. The RAN node <NUM> e.g. using E-UTRAN and/or NG-RAN, streams RAN data, this is published to a message bus <NUM> system, e.g. based on Kafka, including metadata that identifies the RAN data. The RAN function node <NUM> analyses and processes such RAN data and then produces one or more RAN Insights that are published on the message bus <NUM>, with meta data that identifies the RAN Insights. It may either be in the same message bus used for publishing RAN data or a different one, depending on implementation. Trough the message bus <NUM>, the one or more RAN insights may be exposed to the trusted domain for MNO applications or trusted third party applications residing and subscribing to the RAN Insights as well as delivered to 3rd party applications which reside on an untrusted domain.

<FIG> is a sequence diagram depicting an embodiment of the method in an example scenario relating to <FIG>, which is a case using the single message bus <NUM> in a trusted domain to expose the one or more RAN insights to both trusted and untrusted applications in respective trusted and untrusted domains.

In <FIG> the network node <NUM> subscribe to one or RAN insights generated by the RAN function node <NUM> considers the case of exposure to external application through the network node <NUM> and using the message bus <NUM> for RAN insights subscription and/or publish. In the diagram flow, it is considered that the message bus <NUM> used for subscription and/or publishing of data handles the process of subscription and publishing of data. The high-level diagram flow may be described as follows:.

In the diagram flow, the relevant nodes are aware of which data they can subscribe to. i.e., also, the network entity is aware of which RAN insights it can subscribe to from the RAN function node <NUM>.

Action <NUM>. An application <NUM> in a node sends an exposure request, to the network node <NUM>. The exposure request may e.g. be a service defined by 3GPP, e.g., subscription to QoS Sustainability Analytics offered by NWDAF through NEF, or a network-specific service. The exposure request may comprise information of required exposure information, application-specific information such as UE IDs, 5QIs, QFls, geographical area of relevance, time windows of relevance, etc..

Action <NUM>. The network node <NUM> maps the exposure request from the application <NUM> to relevant one or more RAN insight(s), an it may indicate if the exposure request is from trusted or an untrusted application.

The network node <NUM> in charge of handling the application's exposure request, processes the exposure request. The processes may include:.

Action <NUM>. The network node <NUM> then subscribes to selected RAN insight(s) through the message bus, e.g. the message bus <NUM>. This may be performed by sending the first subscription request to the RAN function node <NUM>. In this subscription process, the network node <NUM> may indicate:.

Action <NUM>. The RAN function node <NUM> maps the one or more RAN insight(s) to relevant RAN data. This means that the RAN function node <NUM> identifies RAN data needed to fulfil the first subscription request for the one or more RAN insights.

This may be performed by processing the first subscription request. The process may comprise checking which RAN data would be necessary to generate the required one or more RAN insight(s).

Action <NUM>. The RAN function node <NUM> subscribes to identified RAN data. This is performed by sending a second subscription request for the identified RAN data to the RAN node <NUM> vi the message bus <NUM>.

Action <NUM>. The RAN node <NUM> streams the RAN data according to the second subscription request.

Action <NUM>. When RAN data according to the second subscription request is available, the RAN node <NUM> publishes RAN data which then reach RAN PF through the message bus, e.g. the message bus <NUM>, to be reached by the RAN function node <NUM>.

Action <NUM>. The RAN function node <NUM> processes the RAN data to generate the one or more RAN insight(s) accordingly for exposure to a trusted and/or untrusted application. The RAN function node <NUM> finds out, also referred to as establishes, which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights are to be exposed in.

The RAN function node <NUM> may e.g. consider the metadata, comprised in the first subscription request from the network node <NUM> where the network node <NUM> may have indicated whether the RAN insights should be generated with trusted and/or untrusted metadata to be exposed in respective trusted domain or untrusted domain. The RAN function node <NUM> may process specific information included in the first subscription request from the network <NUM>. the RAN function node <NUM> may check the information associated to the final receiver, such as e.g., name, ID, and/or address, and obtain from this whether the final receiver is trusted or untrusted. As an alternative, e.g. the network node <NUM> may e.g. include specific tags in the first subscription request whether the final receiver of RAN insights is a trusted or untrusted receiver. The network node <NUM> may e.g. be aware that, for a certain metric e.g. throughput prediction, the RAN function node <NUM> supports two RAN insights, e.g. "throughput prediction for trusted receiver" and "throughput prediction for untrusted receiver," and the network node <NUM> may subscribe to the proper RAN insight depending on the final receiver being trusted or untrusted.

Action <NUM>. The RAN function node <NUM> then publishes the generated one or more RAN insights through the single message bus <NUM>. The published one or more RAN insights then reaches the relevant network entities such as in this scenario the network node <NUM>. This is since the generated one or more RAN insights are published in the single message bus <NUM> In some embodiments the message bus <NUM> may handles this. When the network node <NUM> subscribes to a RAN insight, it may be up to the message bus <NUM> to dispatch the RAN insight to the network node <NUM> once it has been published by the RAN function node <NUM>.

The published one or more RAN insights indicates to the network node <NUM>, whether to expose the generated one or more RAN insights in the trusted domain or in the untrusted domain.

Action <NUM>. When one or more RAN insights according to the first subscription is generated and published by the RAN function node <NUM>, network node <NUM> discovers the one or more RAN insights, e.g. by receiving it from the message bus <NUM>, since it is the message bus <NUM> that in this example handles the delivery of a published content to the right receiver. The published one or more RAN insights comprises the indication that indicates which domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in.

The network node <NUM> thus receives the one or more RAN insight associated to the metadata it subscribed to. The one or more RAN insights are finally processed for exposure to trusted or untrusted application, and eventually translated, for the final exposure to the application. The Translation may include operations e.g. change of addresses, identities, further processing e.g. removal of some information or aggregation of more information.

Action <NUM>. The network node <NUM> then exposes the one or more RAN insights accordingly to be reached by the application <NUM> in a trusted or untrusted.

Some second example embodiments are shown in <FIG>. In these second example embodiments, the the RAN function node <NUM> publishes the one or more RAN insights on different message buses, also referred to as message bus instances, depending on indication for trusted or untrusted application. In this example the network node <NUM> is trusted. However since an network node <NUM> may be from another vendor, there may also be more separation in case of different levels of "trust" in receivers, e.g. a third message bus instance may be used to deliver the one or more RAN insights to the ultimately trusted RAN O&M system which may be delivered from the RAN vendor.

In the second example embodiments of the RAN function node <NUM> functionality different message buss are used to expose the one or more RAN insights, e.g. to other nodes such as node functions of a <NUM> core, e.g., NWDAF, or to external applications, in this example, e.g. through the network node <NUM> such as e.g. an API-GW.

In <FIG>, the RAN function node <NUM> generates RAN insights upon request from other network entities such as the network node <NUM> by using RAN data. The RAN node <NUM> e.g. using E-UTRAN and/or NG-RAN, streams RAN data, this is published to a message bus <NUM> system, e.g. based on Kafka, including metadata that identifies the RAN data. The RAN function node <NUM> analyses and processes such RAN data and then produces one or more RAN Insights. The generated one or more RAN Insights are published on a first message bus <NUM> for exposure to untrusted domains and on a second message bus <NUM> for exposure to trusted domains.

<FIG> is a sequence diagram depicting an embodiment of the method in an example scenario relating to <FIG>, which is a case using different message buses to expose the one or more RAN insights to trusted and untrusted applications in respective trusted and untrusted domains.

In <FIG> the network node <NUM> subscribe to one or RAN insights generated by the RAN function node <NUM> considers the case of exposure to external application through the network node <NUM> and uses a first message bus <NUM> for RAN insights subscription and/or publish for an untrusted application <NUM> according to the example, in an untrusted domain and a second message bus <NUM> for RAN insights subscription and/or publish for a trusted application in a trusted domain. The high-level diagram flow may be described as follows: A high-level diagram means that the diagram may not include all the details and information required e.g. to implement the procedure e.g. a subscription step shown in the high-level diagram flow may show only a subscription request while a detailed diagram flow may include also a response indicating whether the subscription was successful or not.

This means that in the second example embodiments, provide a way of separating the RAN insights for the trusted and untrusted domains by using two or more different message bus instances. The the RAN function node <NUM> publishes the one or more RAN insights on the relevant message bus depending on which domains the respective one or more RAN insights should be delivered to. In this example the network node is trusted.

In these second example embodiments the Actions <NUM>-<NUM> corresponds to respective Actions <NUM>-<NUM> as described above.

Action <NUM>. The RAN function node <NUM> then publishes the generated one or more RAN insights. The generated one or more RAN insights to be exposed in an untrusted domain are published through the first message bus <NUM> and the generated one or more RAN insights to be exposed in a trusted domain are published through the second message bus <NUM>. The published one or more RAN insights then reaches the relevant network entities such as in this scenario the network node <NUM>. When reached through the first message bus <NUM>, this indicates to the network node <NUM> that the one or more RAN insights are to be exposed in an untrusted domain and when reached through the second message bus <NUM>, this indicates to the network node <NUM> that the one or more RAN insights are to be exposed in a trusted domain.

In this way, the published one or more RAN insights indicates to the network node <NUM>, whether to expose the generated one or more RAN insights in the trusted domain or in the untrusted domain.

Action <NUM>. When one or more RAN insights according to the first subscription is generated and published by the RAN function node <NUM>, network node <NUM> discovers the one or more RAN insights. The published one or more RAN insights comprises the indication that indicates which domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in as explained above.

Thus, when reached through the first message bus <NUM>, this indicates to the network node <NUM> that the one or more RAN insights are to be exposed in an untrusted domain and when reached through the second message bus <NUM>, this indicates to the network node <NUM> that the one or more RAN insights are to be exposed in a trusted domain.

The network node <NUM> thus receives the one or more RAN insight associated to the metadata it subscribed to. The one or more RAN insights are finally processed for exposure to trusted or untrusted application accordingly, and eventually translated, for the final exposure to the application.

Action <NUM>. The network node <NUM> then exposes the one or more RAN insights accordingly to be reached by the application <NUM> in a trusted or untrusted domain in
Please note that, according to embodiments herein, the RAN may be extended with a RAN insight Application Programming Interfaces (API) provided to offer RAN insights to external applications and/or network functions, i.e., provide RAN insights outside RAN domain. The API may be implemented e.g. in the the RAN function node <NUM>, and e.g. support the procedures for subscription to the one or more RAN insights and publication of the one or more RAN insights.

The RAN insight API may be implemented and offered to consumers outside the RAN <NUM> domain in several ways: The RAN directly using the RAN insight API to provide RAN insights to consumers, e.g., network functions, external applications, one or more message buses using the RAN insight API for handling subscription/publishing of the one or more RAN insights from other network functions or applications, other network functionalities, such as e.g., API GW, providing support of RAN insight API to external applications.

In some third embodiments, the one or more RAN insights may be exposed to external applications. In these embodiments the network node <NUM> may subscribe to one or more RAN insights generated by the the RAN function node <NUM> considering the case of exposure to external application through the network node when e.g. being an API-GW and using a message for the one or more RAN insights subscription and/or publish. In these embodiments, it may be considered that hat message buses used for subscription and/or publishing of data handles the process of subscription and publishing of data, as well as relevant nodes are aware of which data they can subscribe to, i.e. the RAN function node <NUM> is aware of which data can subscribe to from the RAN node, the network node <NUM> is aware of which RAN insights it can subscribe to from the the RAN function node <NUM>. In these embodiments an external application sends an exposure request to the network node <NUM>. The exposure request may e.g. be either a service defined by 3GPP, e.g., subscription to QoS Sustainability Analytics offered by NWDAF through NEF, or a network-specific service. The exposure request may include information of required exposure information, application-specific information such as UE IDs, 5QIs, QFls, geographical area of relevance, time windows of relevance, etc..

To perform the action as mentioned above, the RAN function node <NUM> may comprise the arrangement as shown in <FIG> a and b. The RAN function node <NUM> is configured to handle connectivity in the RAN <NUM> of the wireless communications network <NUM>.

The RAN function node <NUM> may comprise a respective input and output interface <NUM> configured to communicate with e.g. the network node <NUM>, see <FIG>. The input and output interface <NUM> may comprise a wireless receiver (not shown) and a wireless transmitter (not shown).

The RAN function node <NUM> may further be configured to, e.g. by means of a receiving unit <NUM> in the RAN function node, receive from the network node <NUM>, a first subscription request for one or more RAN insights relating to the connectivity, requested for an application related to the wireless device <NUM>.

The RAN function node <NUM> may further be configured to, e.g. by means of the receiving unit <NUM> in the RAN function node, receive from the RAN node <NUM>, published RAN data according to the second subscription request, when RAN data according to the second subscription request is available.

The RAN function node <NUM> may further be configured to, e.g. by means of the receiving unit <NUM> in the RAN function node, receive the first subscription request for one or more RAN insights relating to the connectivity from any one out of:.

The RAN function node <NUM> may further be configured to, e.g. by means of an identifying unit <NUM> in the RAN function node, identify RAN data needed to fulfil the subscription request for the one or more RAN insights.

The RAN function node <NUM> may further be configured to, e.g. by means of a sending unit <NUM> in the RAN function node, send to the RAN node <NUM>, a second subscription request for the identified RAN data.

The RAN function node <NUM> may further be configured to, e.g. by means of a generating unit <NUM> in the RAN function node, generate the one or more RAN insights according to the first subscription request based on the received RAN data.

The RAN function node <NUM> may further be configured to, e.g. by means of a establishing unit <NUM> in the RAN function node, establish which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights are to be exposed in.

The RAN function node <NUM> may further be configured to, e.g. by means of the establishing unit <NUM> in the RAN function node, establish which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights shall be exposed in based on whether the application is trusted or untrusted.

The RAN function node <NUM> may further be configured to, e.g. by means of the establishing unit <NUM> in the RAN function node, establish which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights shall be exposed in, by establishing that:.

The RAN function node <NUM> may further be configured to, e.g. by means of a publishing unit <NUM> in the RAN function node, publish the generated one or more RAN insights according to the first subscription request to reach the network node <NUM>. The publishing is adapted to comprise an indication indicating to the network node <NUM>, the established domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in.

In some embodiments, the indication is arranged to comprise any one out of:.

In some embodiments, the network node <NUM> is adapted to be a trusted network node.

In some embodiments, the RAN function node <NUM>, the network node <NUM>, and the RAN node <NUM> are arranged to operate in the same trusted domain.

The embodiments herein may be implemented through a processor or one or more processors, such as a processor <NUM> of a processing circuitry in the RAN function node <NUM> in <FIG>, together with 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 RAN function node <NUM>. 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 RAN function node <NUM>.

The RAN function node <NUM> may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> comprises instructions executable by the processor <NUM> in the RAN function node <NUM>. The memory <NUM> is arranged to be used to store, e.g. indications, information, data, configurations, and applications, to perform the methods herein when being executed in the RAN function node <NUM>.

In some embodiments, a computer program <NUM> comprises instructions, which when executed by the at least one processor <NUM>, cause the at least one processor <NUM> of the RAN function node <NUM> to perform the actions above.

In some embodiments, a carrier <NUM> comprises the computer program <NUM>, wherein the carrier <NUM> 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.

Those skilled in the art will also appreciate that the units in the units 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 RAN function node <NUM>, that when executed by the one or more processors such as the processors or processor circuitry 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).

To perform the action as mentioned above, the network node <NUM> may comprise the arrangement as shown in <FIG> a and b. The network node <NUM> is configured to handle connectivity in the RAN <NUM> of the wireless communications network <NUM>.

The network node <NUM> may comprise a respective input and output interface <NUM> configured to communicate with e.g. the RAN function node115, see <FIG>. The input and output interface <NUM> may comprise a wireless receiver (not shown) and a wireless transmitter (not shown).

The network node <NUM> may further be configured to, e.g. by means of an receiving unit <NUM> in the network node <NUM>, receive the first subscription request for one or more RAN insights relating to the connectivity from any one out of:.

The network node <NUM> may further be configured to, e.g. by means of an sending unit <NUM> in the network node <NUM>, send to the RAN function node <NUM> a first subscription request for one or more RAN insights relating to the connectivity, requested for an application related to a wireless device <NUM>.

The network node <NUM> may further be configured to, e.g. by means of an discovering unit <NUM> in the network node <NUM>, discover the one or more RAN insights when one or more RAN insights according to the first subscription is generated and published by the RAN function node <NUM>. The published one or more RAN insights are arranged to comprise an indication adapted to indicate a domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in.

In some embodiments, the indicated domain out of a trusted domain or an untrusted domain the generated one or more RAN insights shall be exposed in, is arranged to be based on whether the application is trusted or untrusted.

In some embodiments, the indication is adapted to indicate any one or more out of:.

The network node <NUM> may further be configured to, e.g. by means of an exposing unit <NUM> in the network node <NUM>, expose the published one or more RAN insights in the indicated domain.

In some embodiments, the RAN function node <NUM>, the network node <NUM> are arranged to operate in the same trusted domain.

The embodiments herein may be implemented through a processor or one or more processors, such as a processor <NUM> of a processing circuitry in the network node <NUM> in <FIG>, together with 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 network node <NUM>. 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 network node <NUM>.

The network node <NUM> may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> comprises instructions executable by the processor <NUM> in the network node <NUM>. The memory <NUM> is arranged to be used to store, e.g. indications, information, data, configurations, and applications, to perform the methods herein when being executed in the network node <NUM>.

In some embodiments, a computer program <NUM> comprises instructions, which when executed by the at least one processor <NUM>, cause the at least one processor <NUM> of the network node <NUM> to perform the actions above.

Those skilled in the art will also appreciate that the units in the units 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 network node <NUM> that when executed by the one or more processors such as the processors or processor circuitry described above. One or more of these processors, as well as the other digital hardware, may be included in a single ASIC, or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into an SoC.

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM> such as the wireless communications network <NUM>, e.g. an loT network, or a WLAN, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a radio access network, e.g. RAN <NUM>, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 3212a, 3212b, 3212c, such as the network node <NUM>, access nodes, AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first UE e.g. the UE <NUM> such as a Non-AP STA <NUM> located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE <NUM> such as a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a.

The telecommunication network <NUM> is itself connected to a host computer <NUM>, which may be embodied in the hardware and/or software of a standalone server, a cloudimplemented server, e.g. cloud <NUM>, a distributed server or as processing resources in a server farm. The intermediate network <NUM> may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network <NUM>, if any, may be a backbone network or the Internet; in particular, the intermediate network <NUM> may comprise two or more subnetworks (not shown).

The hardware <NUM> may include a communication interface <NUM> for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system <NUM>, as well as a radio interface <NUM> for setting up and maintaining at least a wireless connection <NUM> with a UE <NUM> located in a coverage area (not shown) served by the base station <NUM>.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the applicable RAN effect: data rate, latency, power consumption, and thereby provide benefits such as corresponding effect on the OTT service: e.g. reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime.

The communication system includes a host computer, a base station such as the central node <NUM>, and a UE such as the UE <NUM>, which may be those described with reference to <FIG> and <FIG>. In a first action <NUM> of the method, the host computer provides user data. In an optional subaction <NUM> of the first action <NUM>, the host computer provides the user data by executing a host application. In a second action <NUM>, the host computer initiates a transmission carrying the user data to the UE. In an optional third action <NUM>, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth action <NUM>, the UE executes a client application associated with the host application executed by the host computer.

The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>. In a first action <NUM> of the method, the host computer provides user data. In an optional subaction (not shown) the host computer provides the user data by executing a host application. In a second action <NUM>, the host computer initiates a transmission carrying the user data to the UE. In an optional third action <NUM>, the UE receives the user data carried in the transmission.

The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>. In an optional first action <NUM> of the method, the UE receives input data provided by the host computer. Additionally, or alternatively, in an optional second action <NUM>, the UE provides user data. In an optional subaction <NUM> of the second action <NUM>, the UE provides the user data by executing a client application. In a further optional subaction <NUM> of the first action <NUM>, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third subaction <NUM>, transmission of the user data to the host computer. In a fourth action <NUM> of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Claim 1:
A method performed by a Radio Access Network, RAN, function node (<NUM>), for handling connectivity in a RAN (<NUM>) of a wireless communications network (<NUM>), the method comprising:
receiving (<NUM>) from a network node (<NUM>), a first subscription request for one or more RAN insights relating to the connectivity, requested for an application related to a wireless device (<NUM>),
identifying (<NUM>) RAN data needed to fulfil the subscription request for the one or more RAN insights,
sending (<NUM>) to a RAN node (<NUM>), a second subscription request for the identified RAN data, wherein the RAN data comprise measurements collected by the RAN node, wherein the RAN insights are processed RAN data comprising statistical or predicted information,
when RAN data according to the second subscription request is available, receiving (<NUM>) from the RAN node (<NUM>), published RAN data according to the second subscription request,
generating (<NUM>) the one or more RAN insights according to the first subscription request based on the received RAN data, and
establishing (<NUM>) which domain out of a trusted domain or an untrusted domain the generated one or more RAN insights are to be exposed in, and
publishing (<NUM>) the generated one or more RAN insights according to the first subscription request to reach the network node (<NUM>), wherein the published one or more RAN insights comprises an indication, indicating to the network node (<NUM>) the established domain out of a trusted domain or an untrusted domain, that the generated one or more RAN insights are to be exposed in.