PRIORITY CLAIM

[0001] This application claims the benefit of priority to United States Provisional Patent Application 63/138,237, filed January 15, 2021, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] Aspects pertain to wireless communications. Some aspects relate to wireless networks including 3GPP (Third Generation Partnership Project) networks, 3GPP LTE (Long Tenn Evolution) networks, 3GPP LTE-A (LTE Advanced) networks, (MulteFire, LTE-IJ ), and fifth-generation (5G) networks including 5G new radio (NR) (or 5G-NR.) networks, 5G networks such as 5G NR unlicensed spectrum (NR-U) networks and other unlicensed networks including Wi-Fi, CBRS (OnGo), etc. Other aspects are directed to Open RAN (O-RAN) architectures and, more specifically, techniques for providing data management sendees where the data management services may be for artificial intelligence (Al) and machine learning (ML) in a non-real-time (Non-RT) radio access network (RAN) intelligent controller (RIC) (Non-RT RIC).

BACKGROUND

[0003] Mobile communications have evolved significantly from early voice systems to today’s highly sophisticated integrated communication platform. With the increase in different types of devices communicating with various network devices, usage of 3GPP LTE systems has increased. The penetration of mobile devices (user equipment or UEs) in modern society has continued to drive demand for a wide variety of networked devices in many disparate environments. Fifth-generation (5G) wireless systems are forthcoming and are expected to enable even greater speed, connectivity, and usability. Next generation 5G networks are expected to increase throughput, coverage, and robustness and reduce latency and operational and capital expenditures. 5G new radio (5G-NR) networks will continue to evolve based on 3GPP LTE- Advanced with additional potential new radio access technologies (RATs) to enrich people’s lives with seamless wireless connectivity solutions delivering fast, rich content and services. As current cellular network frequency is saturated, higher frequencies, such as millimeter wave (mmWave) frequency, can be beneficial due to their high bandwidth,

[0004] Potential LTE operation in the unlicensed spectrum includes (and is not limited to) the LTE operation in the unlicensed spectrum via dual connectivity (DC), or DC-based LAA, and the standalone LTE system in the unlicensed spectrum, according to which LTE-based technology solely operates in the unlicensed spectrum without requiring an “anchor” in the licensed spectrum, called MuiteFire. MuiteFire combines the performance benefits of LTE technology with the simplicity of Wi-Fi-like deployments.

[0005] Further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems. Such enhanced operations can include techniques for Al and ML for O-RAN networks.

BRIEF DESCRIPTION OF TH E FIGURES

[0006] In the figures, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The figures illustrate generally, by way of example, but not by way of limitation, various aspects discussed in the present document.

[0007] FIG. 1 illustrates an example Open RAN (O-RAN) system architecture. [0008] FIG, 2 illustrates a logical architecture of the O-RAN system of FIG. 1. [0009] FIG. 3 illustrates a system for a Non-RT RIC, in accordance with some embodiments.

[0010] FIG. 4 illustrates a system for data policy administration function (DPAF) 402, in accordance with some embodiments.

[0011] FIG. 5 illustrates a method for data policy establishment, in accordance with some embodiments.

[0012] FIG. 6 illustrates a method for data policy modification, in accordance with some embodiments.

[0013] FIG, 7 illustrates a method for data policy modification, in accordance with some embodiments.

[0014] FIG. 8 illustrates a method for data policy termination, in accordance with some embodiments.

[0015] FIG. 9 illustrates a method for data policy termination, in accordance with some embodiments.

[0016] FIG. 10 illustrates a method for data policy type query/, in accordance with some embodiments.

[0017] FIG. 11 illustrates a method of queryring for all supported data policy types, in accordance with some embodiments.

[0018] FIG. 12 illustrates a method of querying for a data policy, in accordance with some embodiments.

[0019] FIG. 13 illustrates a method of querying the status of a data policy, in accordance with some embodiments.

[0020] FIG. 14 illustrates a resource Uniform Resource Identifier (URI) structure, in accordance with some embodiments. DETAILED DESCRIPTION

[0022] The following description and the drawings sufficiently illustrate aspects to enable those skilled in the art to practice them. Other aspects may incorporate structural, logical, electrical, process, and other changes. Portions and features of some aspects may be included in or substituted for, those of other aspects. Aspects outlined in the claims encompass all available equivalents of those claims.

[0023] FIG. 1 provides a high-level view of an Open RAN (O-RAN) architecture 100. The O-RAN architecture 100 includes four O-RAN defined interfaces --- namely, the Al interface, the OI interface, the 02 interface, and the Open Fronthaul Management (M)-plane interface --- which connect the Sendee Management and Orchestration (SMO) framework 102 to O-RAN network functions (NTs) 104 and the O-Cloud 106. The SMO 102 (described in Reference [R13]) also connects with an external system 110, which provides enrichment data to the SMO 102. FIG. 1 also illustrates that the Al interface terminates at an O- RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 112 in or at the SMO 102 and at the O-RAN Near-RT RIC 1 14 in or at the O-RAN NFs 104. The O- RAN NFs 104 can be virtual network functions (VNFs) such as virtual machines (VMs) or containers, sitting above the O-Cloud 106 and/or Physical Network Functions (PNFs) utilizing customized hardware. All O-RAN NFs 104 are expected to support the 01 interface when interfacing with the SMO framework 102. The O-RAN NFs 104 connect to the NG-Core 108 via the NG interface (which is a 3 GPP defined interface). The Open Fronthaul M-plane interface between the SMO 102 and the O-RAN Radio Unit (O-RU) 116 supports the O- RU 116 management in the O-RAN hybrid model as specified in Reference [R 16] . The Open Fronthaul M-plane interface is an optional interface to the SMO 102 that is included for backward compatibility purposes as per Reference [R16] and is intended for management of the O-RU 1 16 in hybrid mode only. The management architecture of flat mode (see Reference [R12]) and its relation to the 01 interface for the O-RU 116 is in development. The O-RU 116 termination of the 01 interface towards the SMO 102 as specified in Reference [R12].

[0024] FIG. 2 shows an O-RAN logical architecture 200 corresponding to the O- RAN architecture 100 of FIG. 1. In FIG. 2, the SMO 202 corresponds to the SMO 102, O-Cloud 206 corresponds to the O-Cloud 106, the non-RT RIC 212 corresponds to the non-RT RIC 1 12, the near-RT RIC 214 corresponds to the near- RT RIC 114, and the 0-RU 216 corresponds to the 0-RU 116 of FIG. 2, respectively. The O-RAN logical architecture 200 includes a radio portion and a management portion.

[0025] The management portion/ side of the architectures 200 includes the SMO Framework 202 containing the non-RT RIC 212, and may include the O-Cloud 206. The O-Cloud 206 is a cloud computing platform including a collection of physical infrastructure nodes to host the relevant O-RAN functions (e.g., the near- RT RIC 214, 0-RAN Central Unit-Control Plane (O-CU-CP) 221, 0-RAN Central Unit-User Plane O-CU-UP 222, and the O-RAN Distributed Unit (O-DU) 215, supporting software components (e.g., OSs, VMMs, container runtime engines, ML engines, etc,), and appropriate management and orchestration functions.

[0026] The radio portion/ side of the logical architecture 200 includes the near-RT RIC 214, the O-DU 215, the O-RAN Radio Unit (O-RU) 216, the O-CU-CP 221, and the O-CU-UP 222 functions. The radio portion/ side of the logical architecture 200 may also include the O-e/gNB 210.

[0027] The O-DU 215 is a logical node hosting Radio Link Control (RLC), media access control (MAC), and higher physical (PHY) layer entities/elements (High- PHY layers) based on a lower layer functional split. The 0-RU 216 is a logical node hosting lower PHY layer entities/elements (Low-PHY layer) (e.g., FFT/iFFT, PRACH extraction, etc.) and RF processing elements based on a lower layer functional split. Virtualization of O-RU 216 is FFS. The O-CU-CP 221 is a logical node hosting the RRC and the control plane (CP) part of the PDCP protocol. The O-CU-UP 222 is a logical node hosting the user plane part of the PDCP protocol and the SDAP protocol .

[0028] An E2 interface terminates at a plurality of E2 nodes. The E2 nodes are logical nodes/entities that terminate the E2 interface. For NR/5G access, the E2 nodes include the O-CU-CP 221, O-CU-UP 222, O-DU 215, or any combination of elements as defined in Reference [R15], For E-UTRA access the E2 nodes include the O-e/gNB 210. As shown in FIG. 2, the E2 interface also connects the O-e/gNB 210 to the Near-RT RIC 214. The protocols over E2 interface are based exclusively on Control Plane (CP) protocols. The E2 functions are grouped into the following categories: (a) near-RT RIC 214 services (REPORT, INSERT, CONTROL and POLICY, as described m Reference [R15]); and (b) near-RT RIC 214 support functions, which include E2 Interface Management (E2 Setup, E2 Reset., Reporting of General Error Situations, etc.) and Near-RT RIC Service Update (e.g., capability exchange related to the list of E2 Node functions exposed over E2).

100291 FIG. 2 shows the Uu interface between a UE 201 and O-e/gNB 210 as well as between the UE 201 and O-RAN components. The Uu interface is a 3GPP defined interface (see e.g., sections 5.2 and 5.3 of Reference [R07]), which includes a complete protocol stack from LI to L3 and terminates in the NG-RAN or E-UTRAN. The O-e/gNB 210 is an LTE eNB (see Reference [R04]), a 5GgNB or ng-eNB (see Reference [R06]) that supports the E2 interface. The O-e/gNB 210 may be the same or similar as discussed in FIGS. 3-14. The UE 201 may correspond to UEs discussed with respect to FIGS. 3-14 and/or the like. There may be multiple UEs 201 and/or multiple O-e/gNB 210, each of which may be connected to one another the via respective Uu interfaces. Although not shown in FIG. 2, the O-e/gNB 210 supports 0-DU 215 and O-RU 216 functions with an Open Fronthaul interface between them.

[0030] The Open Fronthaul (OF) interface(s) is/are between 0-DU 215 and O- RU 216 functions (see References [R16] and [R17],) The OF interface(s) includes the Control User Synchronization (CUS) Plane and Management (M) Plane. FIGS. 1 and 2 also show that the O-RU 216 terminates the OF M-Plane interface towards the O-DU 215 and optionally towards the SMO 202 as specified in Reference [R16], The O-RU 216 terminates the OF CUS-Plane interface towards the O-DU 215 and the SMO 202.

[0031] The Fl-c interface connects the O-CU-CP 221 with the 0-DU 215. As defined by 3 GPP, the Fl-c interface is between the gNB-CU-CP and gNB-DU nodes (see References [R07] and [R10].) However, for purposes of O-RAN, the Fl-c interface is adopted between the O-CU-CP 221 with the O-DU 215 functions while reusing the principles and protocol stack defined by 3GPP and the definition of interoperability profile specifications.

[0032] The Fl-u interface connects the O-CU-UP 222 with the O-DU 215. As defined by 3 GPP, the Fl-u interface is between the gNB-CU-UP and gNB-DU nodes (see References [R07] and [R10]). However, for purposes of O-RAN, the Fl-u interface is adopted between the O-CU-UP 222 with the O-DU 215 functions while reusing the principles and protocol stack denned by 3GPP and the definition of interoperability profile specifications.

[0033] The NG-c interface is defined by 3GPP as an interface between the gNB- CU-CP and the AMF in the 5GC (see Reference [R06]). The NG-c is also referred as the N2 interface (see Reference [R06]). The NG-u interface is defined by 3GPP, as an interface between the gNB-CU-UP and the UPF in the 5GC (see Reference [R06]). The NG-u interface is referred as the N3 interface (see Reference [R06]). In O-RAN, NG-c and NG-u protocol stacks defined by 3GPP are reused and may be adapted for O-RAN purposes.

[0034] The X2-c interface is defined in 3GPP for transmitting control plane information between eNBs or between eNB and en-gNB in EN-DC. The X2-u interface is defined in 3GPP for transmitting user plane information between eNBs or between eNB and en-gNB in EN-DC (see e.g., [005], [006]). In O-RAN, X2- c and X2-u protocol stacks defined by 3 GPP are reused and may be adapted for O-RAN purposes.

[0035] The Xn-c interface is defined in 3GPP for transmitting control plane information between gNBs, ng-eNBs, or between an ng-eNB and gNB. The Xn-u interface is defined in 3GPP for transmitting user plane information between gNBs, ng-eNBs, or between ng-eNB and gNB (see e.g.. References [R06] and [R08]). In O-RAN, Xn-c and Xn-u protocol stacks defined by 3GPP are reused and may be adapted for O-RAN purposes

[0036] The El interface is defined by 3GPP as being an interface between the gNB-CU-CP (e.g., gNB-CU-CP 3728) and gNB-CU-UP (see e.g., [007], [009]). In O-RAN, El protocol stacks defined by 3GPP are reused and adapted as being an interface between the O-CU-CP 221 and the O-CU-UP 222 functions.

[0037] The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 212 is a logical function within the SMO framework 102, 202 that enables non-real- time control and optimization of RAN elements and resources, Al/machine learning (ML) rvorkflow(s) including model training, inferences, and updates; and policy -based guidance of applications/features in the Near-RT RIC 214.

[0038] The O-RAN near-RT RIC 214 is a logical function that enables near-realtime control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. The near-RT RIC 214 may include one or more AI/ML workflows including model training, inferences, and updates.

[0039] The non-RT RIC 212 can be an ML training host to host the training of one or more ML models. The ML data can be collected from one or more of the following: the Near-RT RIC 214, O-CU-CP 221, O-CU-UP 222, O-DU 215, O- RU 216, external enrichment source 110 of FIG. 1, and so forth. For supervised learning, and the ML training host and/or ML inference host/actor can be part of the non-RT RIC 212 and/or the near-RT RIC 214. For unsupervised learning, the ML training host and ML inference host/actor can be part of the non-RT RIC 212 and/or the near-RT RIC 214. For reinforcement learning, the ML training host and ML inference host/actor are co-located as part of the near-RT RIC 214. In some implementations, the non-RT RIC 212 may request or trigger ML model training in the training hosts regardless of where the model is deployed and executed. ML models may be trained and not currently deployed.

[0040] In some implementations, the non-RT RIC 212 provides a query-able catalog for an ML design er/developer to publish/install trained ML models (e.g., executable software components). In these implementations, the non-RT RIC 212 may provide discovery echanism if a particular ML model can be executed in a target ML inference host (MF), and what number and type of ML models can be executed in the target ML inference host. The Near-RT RIC 214 is a managed function (MF). For example, there may be three types of ML catalogs made discoverable by the non-RT RIC 212: a design-time catalog (e.g., residing outside the non-RT RIC 212 and hosted by some other ML platform(s)), a training/deployment-time catalog (e.g., residing inside the non-RT RIC 212), and a run-time catalog (e.g., residing inside the non-RT RIC 212). The non-RT RIC 212 supports necessary' capabilities for ML model inference in support of ML assisted solutions running in the non-RT RIC 212 or some other MI, inference host. These capabilities enable executable software to be installed such as VMs, containers, etc. The non-RT RIC 212 may also include and/or operate one or more ML engines, which are packaged software executable libraries that provide methods, routines, data types, etc,, used to run ML models. The non-RT RIC 212 may also implement policies to switch and activate ML model instances under different operating conditions.

[0041] The non-RT RIC 212 is able to access feedback data (e.g., FM, PM, and network KPI statistics) over the 01 interface on ML model performance and perform necessary evaluations. If the ML model fails during runtime, an alarm can be generated as feedback to the non-RT RIC 212. How well the ML model is performing in terms of prediction accuracy or other operating statistics it produces can also be sent to the non-RT RIC 212 over 01. The non-RT RIC 212 can also scale ML model instances running in a target MF over the 01 interface by observing resource utilization in MF. The environment where the ML model instance is running (e.g., the MF) monitors resource utilization of the running ML model. This can be done, for example, using an ORAN-SC component called ResourceMonitor in the near-RT RIC 214 and/or in the non-RT RIC 212, which continuously monitors resource utilization. If resources are low or fall below a certain threshold, the runtime environment in the near-RT RIC 214 and/or the non- RT RIC 212 provides a scaling mechanism to add more ML instances. The scaling mechanism may include a scaling factor such as an number, percentage, and/or other like data used to scale up/down the number of ML instances. ML model instances running in the target ML inference hosts may be automatically scaled by observing resource utilization in the MF. For example, the Kubemetes® (K8s) runtime environment typically provides an auto-scaling feature.

[0042] The Al interface is between the non-RT RIC 212, which is within - the SMO 202, and the near-RT RIC 214. The Al interface supports three types of sendees as defined in Reference [R14], including a Policy Management Sendee, an Enrichment Information Service, and ML Model Management Sendee, Al policies have the following characteristics compared to persistent configuration as defined in Reference [RI 4] : Al policies are not critical to traffic; Al policies have temporary validity, Al policies may handle individual UH or dynamically defined groups of UEs; Al policies act within and take precedence over the configuration; and Al policies are non-persistent, i.e., do not survive a restart of the near-RT RIC.

[0043] FIG. 3 illustrates a system 300 for a Non-RT RIC, in accordance with some embodiments. The arrows with circles, e.g., 02 between 02 termination 336 and 02 cloud 356, are O-RAN defined interfaces. The regular arrows, e.g., Human-Machine interface 360, except SMO internal interface 366, are external interfaces. SMO internal interface 366 is a proprietary interface, e.g., outside O- RAN specification scope. [0044] The rApps 301 include rApp 1 302,1 , rApp 2 302.2, rApp N 302.N. The R1 310 interface is between rApps 301 and Non-RT RIC framework 308 which is used to support third-party applications deployed in the Non-RT RIC 306 for open and intelligent RAN operation. rApps 301 are modular applications that leverage the functionality exposed by the Non-RT RIC 306 to provide added value services, including Al/ML-assisted solutions. The R1 interface 310 collects performance measurements and provide management instructions for rApps 301. rApps 301 use the AI/ML services provided by the Non-RT RIC framework 308 for AI/ML training, monitoring, and management. [0045] Non-RT RIC 306 AI/ML services are provided to rApps 301. Non-RT RIC framework provides one or more of the following AI/ML services over the R1 310 interface: AI/ML model training; AI/ML model monitoring; and/or, AI/ML model management. AI/ML service function, which is an inherent function of Non-RT RIC, trains, monitors, and manages AI/ML models in rApps 301. In addition, an ALML model repository is provided to store trained AI/ML models in Non-RT RIC.

[0046] The SMO framework 304, the Non-RT RIC framework functionality 312, the SMO service exposure function 314, the rAPP sendee exposure functions 316, the Non-RT RIC framework service exposure function 318, the other Non-RT RIC framework functions 320, the rAPP management functions 322, the Al policy functions 324, the Al El functions 326, the Al ML functions 328, the Al termination 330, the Near-RT RIC 332, the E2 nodes 334, the Al 335 interface, the 02 termination 336, the 01 termination 338, the Implementation variability 340, the Function 1 342. 1, function 2 342.2, . . ., function N 342.N, the external El termination 344, the external AI/ML termination 346, the human-machine termination 348, external AI/ML servers 350, the external El sources 352, the RAN intent injection 354, the 02 cloud 356, the inherent SMO framework functionality 358, the other SMO framework functions 359, the Human-Machine interface 360, the external AI/ML interface 362, the external enrichment information (El) interface 364, the SMO internal interface 366, and any undisclosed module or function are as disclosed herein and in the References.

[0047] A technical problem is how to provide data sendees. Some examples address this technical problem by providing a data policy administration function m the Non-RT RIC for data policy management. Registered rApps 301 interact with the Non-RT RIC framework 308 as data producers and/or data consumers, using the data policy administration sendees via the R1 310 interface. Data policy administration function manages data delivery, collection, retention, sharing, processing, and disposal policy. A plane design to enable data as a sendee (DaaS) is disclosed. In some embodiments, data policy administration functions operate within Non-RT RIC 306. rApps 301 utilize data policy administration sendees over the R1 310 interface to specify desired data policies for delivery', collection, retention, sharing, processing, and disposal of data. [0048] FIG. 4 illustrates a system 400 for data policy administration function (DPAF) 402, in accordance with some embodiments. Data policy administration function (DPAF) 400 manages various data policies, including data delivery policy, data collection policy, data retention policy, data sharing policy, data processing policy, and data disposal policy. In the Non-RT RIC functional architecture, the DPAF 402 is part of Non-RT RIC framework 308.

[0049] DPAF 402 provides data policy administration services to rApps 301 via the R1 310 interface. The data policy administration services of the DPAF 402 include data delivery policy administration, data collection policy administration, data retention policy administration, data sharing policy administration, data processing policy administration, and data disposal policy administration. The DPAF 402 is configured to maintain data policies and ensure the data delivery between rApps 301 and other Non-RT RIC framework functions 320 follow the data policies,

[0050] The DPAF 402 is used by other Non-RT RIC framework 308 functions via the Non-RT RIC internal services, which may be termed Rdpaf. For example, the data repository 404 can request to change/ adj ust/update retention policy due to insufficient storage capacity.

[0051] Data policies can be applied to wide range of data types rApp 301 needed from the SMO framework 304 and/or Non-RT RIC framework 308. For example, it can be applied to data exchanged over the R 1 310 interface, i.e., data generated by rApps 301 as well as data produced by rApps 301 for intelligent RAN operation and optimization. For example, rApps 301 generated data used by Al policy functions 324 to from Al policies, rApps 301 required data collected from 01 interface, and so forth. [0052] The data delivery policy specifies how the subscnbed/requested data is delivered from the Non-RT RIC framework 308 to a registered data consumer rApp 301 , A data consumer rApp 301 can specify how often the Non-RT RIC framework 308 delivers the subscribed/requested data, and how many data points/samples should be bundled into a patch for delivery,

[0053] The data collection policy specifies how the data is collected from a registered data producer rApp 301 to the Non-RT RIC framework 308. A data producer rApp 301 can specify the time interval between two data patch collections to the Non-RT RIC framework 308.

[0054] The data retention policy specifies how long the collected data is to be kept inside the Non-RT RIC framework 308 before deletion. A data producer rApp 301 can specify how long the produced data can be retained in the framework (e.g., in a data repository 404). A data consumer rApp 301 can also specify how long the requested data can be retained,

[0055] The data sharing policy specifies what kind of information about the produced data type can be exposed to other rApps 301. A data producer rApp 301 can also specify filtering information about which rApps 301 or other non- RT RIC framework functions 320 can or cannot access the shared information about its production data.

[0056] The data processing policy specifies how the data is pre-processed before delivering to the data consumer rApps 301 (e.g., whether the Non-RT RIC 306 sends raw data or quantified data to the rApp 301 ). It specifies how the data is post-processed after data is collected from the data producer rApps 301. It also specifies how to correlate data (based on temporal, spatial, data source information, etc.) and how to label/attach attributes to the data (e.g. adding time stamps to data).

[0057] The data disposal policy specifies the event-trigger conditions under which rApps 301 are ought to delete certain type of data. For example, UE 201 context information needs to be removed/deleted from rApps 301 after a UE 201 is deleted. In another example, time-sensitive data should be removed/deleted if it obsoletes (lost timeliness). The obsoleted data is useless, or even harmful, for analysis.

Table 1 DPAF 402 Services over Rl 310 Interface

[0058] DPAF service, procedures, and flows are disclosed herein. Table 1 illustrates the proposed DPAF services over the R1 interface. In some embodiments, “data consumer rApps” are the consumer of the data, e.g., this rApp 301 takes some data as input to perform value added sendee. “Data producer rApps” are the producer of the data, e.g., this rApp 301 generates some data as output for Non-RT RIC 306 framework or other rApps 301. Both “data consumer rApps” and “data producer rApps” can be consumers of the data policy administration sendees. The following data policy procedures focus on the interaction between Non-RT RIC framework 308 and rApp 301 via the R1 310 interface.

[0059] FIG. 5 illustrates a method 500 for data policy establishment, in accordance with some embodiments. The method 500 of establishing a data policy is illustrated. The service consumer rApp 301 initiates the data policy establishment by sending 504 a create request 505, which may be an Rl_DataPolicyAdmin_Create service operation, e.g.

RI DataPolicyAdmin Create request (POST . . ./policies (XxxPolicyObject). In some embodiments, the rAPP 301 sends an HTTP POST request to the target URI, and the message body carries the corresponding data policy object.

[0060] The DPAF 402 in the Non-RT RIC framework 308 makes data policy decision 506 about the policy establishment request. If the request is accepted, then the DPAF 402 sends 508 a create response 507, which may be an HTTP “201 Created” response to the rApp 301, e.g., R1 DataPolicy Admin Create response (“201 Created” (XxxPolicyObject.)).

[0061] The message body carries the established data policy object. A policy ID (policyld) is generated by the DPAF 402 to identify the new data policy which is requested to be established or created. If the requested policy fails to be created, then an appropriate error code is returned with proper error information m the message body. The message body carries the established data policy object.

[0062] The notation “XxxPolicyObject” is a placeholder for all six data policy resource objects. The phrase “Xxx” can be replaced by “Delivery”, “Collection”, “Retention”, “Sharing”, “Processing”, and “Disposal” for each individual data policy types. For example, “XxxPolicyObject” can be interpreted as “DeliveryPolicyObject” in the method of the establishment of a data delivery' policy.

[0063] FIG. 6 illustrates a method 600 for data policy modification, in accordance with some embodiments. The method 600 is a method to perform a data policy modification by an rAPP 301. A data policy can be modified by the rApp 301, which created the data policy.

[0064] Method 600 illustrates the data policy modification procedure initiated by the rApp 301 . The service consumer rAPP 301 determines to update a data policy 602. The sendee consumer rApp 301 initiates the data policy modification by sending 604 an update request 605, which may be invoking the Rl__DataPolicyAdmin__Update service operation. The rApp 301 sends the HTTP PUT request to the target URI with the policy ID (policy Id), e.g., “PUT

. . . /policies/{policy Id} (XxxPolicyObject))” where the message body carries the updated data policy object.

[0065] The DPAF 402 makes a data policy decision 606 about the policy modification update request 605. If the request is accepted, then DPAF 402 sends 608 an update response 607 to the rApp 301 , e.g., HTTP “200 OK. (XxxPolicyObject)”. The message body carries the updated data policy object. If the requested policy modification is failed, then appropriate error code is returned with proper error information in the message body.

[0066] Other rApps 301 or Non-RT RIC framework 308 functions can cause changes to the existing data policies.

[0067] For example, a data consumer rApp 1 302.1 (A) can request to create a data retention policy about data type M produced by another data producer rApp 2 302.2 (B). The established data retention policy of data type M can be modified by rApp 1 302. 1 A, for example, rApp 1 302. 1 A does not need to consume data type M anymore. [0068] .Additionally, rApp 2 302,2 B can request the modification of the retention policy, due to authentication or security concerns. For example, rApp 2 302.2 B’s vendor can adjust the maximum retention time of data type M to protect its business interests, which leads to the change of the data retention policy about data type M.

[0069] Moreover, the Non-RT RIC framework 308 can also make modification of the retention policy. For example, if the rApp 2 302.2 B crashes, then the Non-RT RIC framework 308 can modify (pause or even terminate) the data retention policy.

[0070] FIG. 7 illustrates a method 700 for data policy modification, in accordance with some embodiments. The method 700 is a method of a data policy change notification to the rApp 301 (modification due to other rApps or Non-RT RIC framework functions). The data policy modification method is initiated by other rApps 301 or Non-RT RIC framework 308 functions as illustrated. Other rApps, or the Non-RT RIC framework, or certain scenarios can modify or impact the existing data policy as well.

[0071] An action impacts existing data policy(s) 702 occurs as disclosed herein. The DPAF 402 makes a data policy decision 704 as to whether to modify the data policy. If the DPAF 402 decides to modify the data policy, then it sends 706 an update notify request 708, e.g., by invoking the Rl_DataPolicy- Admin_UpdateNotify (request) sendee operation, e.g., by sending 706 an HTTP POST request to the target URI ({notificationUri}/update), e.g., (POST {notifi cati onUri } /update (XxxPolicy Obj ect)).

[0072] The “notifi cati onUri” is contained in the original data policy object provided by the original rApp 301, and there are two operation URIs for notifications. Here {notifi cati onUri} /update is for policy update, and

{ notificationUri}/status is later used for policy status notification. The message body carries the updated data policy object.

[0073] The service consumer rApp 301 sends 710 an HTTP “204 No content” response to the DPAF 402 with empty message body, e.g., R1 DataPolicy- Admin_UpdateNotify response with “204 No Content”.

[0074] FIG. 8 illustrates a method 800 for data policy termination, in accordance with some embodiments. Similar to data policy modification, a data policy can be terminated by the rApp 301, which created the data policy, or it can be terminated due to the action/status of other rApps 301 or Non-RT RIC framework 308 functions.

[0075] The rApp 301 makes a decision to terminate a data policy 802. The data policy termination method 800 is initiated by the rApp 301 as illustrated. The service consumer rApp 301 initiates the data policy termination by sending 804 a delete request 805, e.g., it invokes the Rl__DataPolicyAdmin__Delete service ( DELETE . . ./policies/{policyld}) operation. And it sends the HTTP DELETE request to the target URI with the policy ID (policyId). The message body is empty.

The DPAF 402 sends 808 a delete response 807, e.g., an HTTP “204 No Content” response to the rApp 301 with an empty message body. For example, R1 DataPolicy Admin Delete response (“204 No Content”).

[0076] FIG. 9 illustrates a method 900 for data policy termination, in accordance with some embodiments. In FIG. 9, the data policy termination procedure is initiated by other rApps 301 or Non-RT RIC framework 308 functions is illustrated. Other rApps 301, or the Non-RT RIC framework 308, or certain scenarios can lead to an action that invalidates existing data policy(s) 902.

[0077] If DPAF 402 makes a data policy decision 904 to end the data policy, then it inactivates the policy first. Subsequently, the DPAF 402 sends 906 n update notify request 908, e.g., it invokes the Rl_DataPolicy- AdminJUpdateNotify service operation and it. sends the HTTP POST request to the target URI ({notificationUriJ/status). For example, Rl DataPolicy- Admin UpdateNotify request. ( POST {notificationUri [/status (XxxPolicy StatusObj ect)).

[0078] The sendee consumer rApp 301 (or other senice consumer) sends 910 an update notify response 912, e.g., an HTTP “204 No content” response to the DPAF 402 with empty message body. For example, R1 DataPolicy- Admin UpdateNotify response (“204 No Content”). The DPAF 402 and/or rAPP 301 invokes control delete request and response 914, e.g.,

R1 DataPolicy Admin Delete service operation. The message body carries the data policy status object, telling the rApp 301 that the corresponding data policy is invalidated (or cannot be enforced any more).

[0079] FIG. 10 illustrates a method 1000 for data policy type query, in accordance with some embodiments. An rApp 301 can query the supported data policies in the Non-RT RIC framework 308 such as by querying the DPAF 402. The rApp 301 can also query a particular policy type.

[0080] In FIG. 10, the method 1000 of querying a data policy type is illustrated. The service consumer rApp 301 sends 1004 a data policy type query' 1005. For example, the rApp 301 invokes the R1 DataPolicy Admin Query service operation. It sends the HTTP GET request to the target URI with the policy type ID (policyTypeld). The message body is empty. For example, R1 DataPolicy- Admin_Query request ( GET . . ./policy Types/ {policyTypeld} ). The DPAF 402 sends 1006 a data policy type response 1007, R1 DataPolicy Admin Query-, to the rApp 301 . For example, the DPA I 402 sends an HTTP “200 OK” (Policy TypeObject) response to the rApp 301.

[0081] If the query fails (e.g., unknown policy type ID), then appropriate error code is returned with proper error information in the message body. The message body carries the corresponding data policy type object for query'.

[0082] FIG. 1 1 illustrates a method 1100 of querying for all supported data policy types, in accordance with some embodiments. FIG. 11 illustrates the method 1 100 of querying all supported data policy types in the Non-RT RIC framework 308. The service consumer rApp 301 sends 1104 an all-supported data policies type query 1105, e.g., the rApp 301 invokes the Rl_DataPolicyAdmin_Query service operation. It sends the HTTP GET request to the target URI (policyTypes). The message body is empty. For example, R1 DataPolicy- Admin_Query request} GET .../policyTypes).

[0083] The DPAF 402 sends 1 106 an all-supported data policies type response 1107 such as an HTTP “200 OK” response to the rApp 301. The message body carries an array of policy type identifications (IDs) representing all supported data policy types in the Non-RT RIC 306 or an appropriate subset of the policy type IDs. For example, DPAF 402 sends R1 DataPolicy Admin Query/ response (“200 OK” (anay(PolicyTypeId) ).

[0084] FIG. 12 illustrates a method 1200 of querying for a data policy, in accordance with some embodiments. An rApp 301 can make queries about, the established data policies, with the policy ID is available. The rAPP 301 can query’ the policy itself or it can query' the status of a policy.

[0085] The service consumer rApp 301 sends 1204 a data policy query 1205. For example, the rApp 301 invokes the R1 DataPolicy Admin Query service operation. It sends the HTTP GET request to the target URI with the policy ID (policyld). The message body is empty. For example, the rApp 301 sends RI DataPolicyAdmin Query/ request (GET . . ./policies/{policyld}).

The DPAF 402 sends 1206 a data policy response 1207. For example, the DPAF 402 sends an HTTP “200 OK” response to the rApp 301 . The message body carries the corresponding data policy object for query'. If the query fails (e.g., unknown policy ID), then appropriate error code is returned with proper error information in the message body. For example, the DPAF 402 sends R1 DataPolicy Admin Query response ( “200 OK” (XxxPolicyObject)).

[0086] FIG. 13 illustrates a method 1300 of querying the status of a data policy, in accordance with some embodiments. FIG. 13 illustrates the method 1300 of querying the status of a data policy. The service consumer rApp 301 sends 1304 a query/ status of data policy 1305. For example, the rAPP 301 invokes the R1 DataPolicy Admin Query service operation. It sends the HTTP GET request to the target URI ( { xxxPolicy Id [/status). The message body is empty. For example, the rAPP 301 sends R1 DataPolicy Admin Query request (GET . . ./policies/{policyld}/status).

[0087] The DPAF 402 sends 1306 a response status of a data policy 1307. For example, the DPAF 402 sends an HTTP “200 OK” response to the rApp 301. The message body carries the data policy status object. For example, the DPAF 402 sends R1 DataPolicy Admin Query response (“200 OK” (XxxPoli cy StatusObj ect)) .

[0088] The status of a data policy can be “ENFORCED”, “NOT ENFORCED”, “INVALID”, or “UNDEFINED”. A data policy can specify time period for it to be enforced, for example, one policy can require it to be enforced on every weekday. Thus, the status of this policy is “ENFORCED” on Friday and it is “NOT -ENFORCED” on Saturday. Status “INVALID” means the policy cannot be enforced any more for some reasons not related to the rApp, for example, due to the data producer rApp 301 crushed. If a data policy is invalidated (or cannot be enforced), the rApp 301 can choose to modify or terminate the policy. If the query' fails (e.g., unknown policy ID), then appropriate error code is returned with proper error information in the message body.

[0089] FIG. 14 illustrates a resource Uniform Resource Identifier (URI ) structure 1400, in accordance with some embodiments. Application program interface examples are provided herein. The data policy administration services use the RI DataPolicy Admin API, and, in some embodiments, the API URI is: [0090] {apiRoot}/<apiName>/{apiVersion}/<apiSpecificResour ceUriPart>. For example, (i.e., https://rl-data-policy-admin/vl/...). The notation “xxx” in the following context can be replaced by “Delivery”, “Collection”, “Retention”, “Sharing”, “Processing”, and “Disposal” for each six data policy types.

[0091] The resource URI structure 1400 for the RI DataPolicy Admin API is illustrated in FIG. 14. The data policy type ID is a string, which can be constructed by data policy type label and the version number of that data policy type. For example, “delivery _policy_v2” and “retention_policy_vl”, etc. If more data policy types get defined in the future, the API is extended. The data policy type resource object specifies schema of data policy object and data policy status object for this data policy type. An overview of the resource and applicable HTTP methods is summarized in Table 2 Resource and methods overview.

[0092] Resource objects are disclosed herein. The DeliveryPolicy Object and CollectionPolicyObject are shown in Tables 3 and 4, respectively. A data consumer rApp can create a delivery policy, and a data producer rApp 301 can create a collocation policy. A data consumer rApp 301 cannot create a collection policy, and a data producer rApp 301 cannot create a delivery policy, in accordance with some embodiments.

[0093] In one embodiment, the policy resource object contains data type identifier for delivery/collection, notification target address, and mode for delivery/ coll ection. The resource object may indicate a time period for data delivery/collection policy to be enforced. It can specify exact start and end time, or it can specify the statement such as “every weekday morning from 7am to 9am”, or other times periods and specifications.

[0094] Data delivery/collection can be periodic, and the policy object specified the time interval between delivery/collection. Delivery/collection can also be event -triggered, so the policy object indicates the condition for triggering event. Policy object can indicate the maximum number of patches delivered/collected within the time period. It can also indicate the number of data samples within each data patches.

[0095] There are various data delivery/collection modes. “Online” mode is used to allow runtime data delivery/collection. Once the data is available/generated, then it is delivered/collected following the policy. “Offline” mode is used to reduce signaling overhead in data delivery/collection. The pace of data delivery/collection does not follow the pace of data collection/generation. It can also be used to deliver/collect past or historical data. Table 4 illustrates a collection policy object.

[0096] Table 4 illustrates a collection policy object.

[0097] The Ret entionPolicy Object is shown in Table 5. Both data consumer rApp 301 and data producer rApp 301 can create retention policy. It contains data type identifier and notification target address. The resource object indicates time period for the policy to be enforced. It specified the maximum allowed retention time for stored data samples.

[0098] The SharingPolicy Object is s rown in Table 6. A data producer rApp 301 can create a sharing policy, and a data consumer rApp 301 cannot create a sharing policy, in accordance with some embodiments. The sharing point object contains data type identifier and notification target address. The resource object indicates time period for the policy to be enforced. It specified the sharing configuration for the produced data type. The configuration can specify (1) Blocked list (or allowed list) of data consumer rApps 301 (e.g., based on rApp vendor) and/or (2) Data exposure level for different data consumer rApps 301 (for example, standardized data model is shared with all rApps 301 , but proprietary' data model can only be exposed to rApps 301 of the same vendor).

0099] The ProcessingPolicyObject is shown in Table 7. Both data consumer rApp 301 and data producer rApp 301 can create processing policy. It contains data type identifier and notification target address. The resource object indicates time period for the policy to be enforced. It specified the processing configuration for the specified data type. The configuration can specify one or more of the following: (1) Pre-processing algorithm (e.g., normalization, quantification) for data consumer rApps; (2) Post-processing algorithm for data producer rApps; (3) Data labelling algorithm (e.g., how to time-stamp data); and/or (4) Data correlation methods (e.g., correlate/ aggregate UE information based on various UE ids).

00100] The DisposalPolicyObject is shown in Table 8, A data producer rApp

301 can create a disposal policy, and a data consumer rApp 301 cannot create a disposal policy. It contains data type identifier and notification target address. The resource object indicates time period for the policy to be enforced. It specifies event-trigger conditions for data disposal of the specified data type.

[00101] XxxPolicyStatusObject: The data policy status object contains policyStatus attribute and optionally xxxInactiveReason attribute, as shown in Table 9. The status of a data policy can be “ENFORCED”,

“NOT ENFORCED”, “INVALID”, or “UNDEFINED”, in accordance with some embodiments. Possible reasons for an “INVALID” data policy may include one or more of the following: (1) Delivery policy is invalid due to data consumed is no longer available (e.g., data production rApp crushes or deregistered); (2) Collection policy is invalid due to data produced is no longer needed (e.g., data consumer rApp crushes or no longer need the data input), (3) Retention policy is invalid due to the stored data is no longer needed (e.g., data consumer rApp crushes or de-registered); and/or, (4) Retention policy is invalid due to security concern (the stored data need to be removed immediately to protect user/vendor information), and so forth.

[00102] Table 10 below discloses enumerate policy status type.

[00103] The methods described in conjunction with FIGS. 4-14 may include one or more additional operations. The operations of the methods described in conjunction with FIGS. 4-14 may be performed in a different order. One or more of the operations of the methods described in conjunction with FIGS. 4-14 may be optional. In some embodiments, an indication that a message is being sent to a directory' may indicate the message is being sent to the DPAF 402. The names used throughout the disclosure are example names. The names may be changed where words are separated or combined, hyphens are added/deleted, underscores are added/deleted, and so forth.

[00104] The following further examples are disclosed. Example 1 is data policy administration sendees that manage data policies for rApps via the RI interface, wherein the data policies include one or more of the following: Data delivery policy, Data collection policy, Data retention policy, Data sharing policy, Data processing policy, and Data disposal policy.

[00105] In Example 2, the subject matter of Example 1 includes, where the RI DataPolicy Admin sendees are used to support one or more of the following service operations: Establish a data policy, Update a data policy, Delete a data policy, Notify the modification of a data policy, Notify the termination of a data policy, Query a data policy, Query the status of a data policy, Query' all data policy types supported in the Non-RT RIC, and/or Query a data policy type.

[00106] In Example 3, the subject matter of Examples 1 or 2 includes, where the RI DataPolicy Admin services is exposed over RI interface to rApps. [00107] In Example 4, the subject matter of Examples 1 -3 includes, where the DPAF service consumer rApp invokes the RI DataPolicy Admin Create service operation to establish a data policy. It sends the HTTP POST request to (. . ./policies) via RI with a XxxPolicyObject in the message body. The DPAF creates a new XxxPolicyObject with a new policyld, and it sends HTTP “2.01 created” response back to DPAF service consumer rApp via RI with the created XxxPolicyObject. in the message body.

[00108] In Example 5, the subject matter of Examples 1-3 includes, where the DPAF sendee consumer rApp invokes the RI DataPolicy Admin Update sendee operation to update a data policy. It sends the HTTP PUT request to (. . ./policies/{policyld}) via RI with the updated XxxPolicyObject in the message body. DPAF sends HTTP “200 OK” response back to the DPAF sendee consumer rApp via RI wdth updated XxxPolicyObject in the message body.

[00109] In Example 6, the subject matter of Examples 1-5 includes, where the DPAF sendee consumer rApp invokes the RI DataPolicy Admin Delete service operation to terminate a data policy. It sends the HTTP DELETE request to (. . ./policies/{policyld}) via RI with empty message body. DPAF sends HTTP “204 no content” response back to the DPA1 service consumer rApp via R1 with empty message body.

[00110] In Example 7, the subject matter of Examples 1-6 includes, where the DPAF service consumer rApp invokes the Rl_DataPolicyAdmin__Query service operation to query' a data policy. It sends the HTTP GET request to (. . ./policies/{policyld}) via R1 with empty message body. DPAF sends HTTP “200 OK” response back to the DPAF service consumer rApp via R1 with XxxPolicy Object in the message body.

[00111] In Example 8, the subject matter of Examples 1-7 includes, where the DPAF service consumer rApp invokes the Rl_DataPolicyAdmin_Query sendee operation to query' the status of a data policy. It sends the HTTP GET request to (. . ,/po1icies/{policy!d}/status) via R1 with empty message body.

DPAF sends HTTP “200 OK” response back to the DPAF sendee consumer rApp via R1 with XxxPolicy StatusObject in the message body.

[00112] In Example 9, the subject matter of Examples 1-8 includes, where the DPAF service consumer rApp invokes the R1 DataPolicy Admin Query' sendee operation to query all supported data policy types in DPAF. It sends the HTTP GET request to (. . ,/policyTypes) via R1 with empty message body. DPAF sends HTTP “200 OK” response back to the DPAF sendee consumer rApp via R1 with an array of all supported data policy type IDs in the message body.

[00113] In Example 10, the subject matter of Examples 1 -9 includes, where DPAF sendee consumer rApp invokes the Rl_DataPolicyAdmin_Query sendee operation to query' a data policy type. It sends the HTTP GET request to (. . ./policyTypes/fpolicyTypeld] ) via R1 with empty message body. DPAF sends HTTP “200 OK” response back to the DPAF service consumer rApp via R1 with Policy TypeObject in the message body.

[00114] In Example 11, the subject matter of Examples 1-10 includes, where the DPAF invokes the R1 DataPolicy Admin UpdateNotify sendee operation to notify the DPAF sendee consumer rApp via R1 about the modification of a data policy. It sends the HTTP POST request to service consumer specified notificationUri(/update) with updated XxxPolicyObject in the message body.

The DPAF sendee consumer rApp sends HTTP “204 no content” response back to the DPAF via Rl with empty message body. [00115] In Example 12, the subject matter of Examples 1-11 includes, where the DPAF invokes the R1 DataPolicy Admin UpdateNotify service operation to notify the DPAF sendee consumer rApp via R1 about the termination of a data policy. It sends the HTTP POST request to service consumer specified notificationUri (/status) with XxxPolicy StatusObject in the message body. The status of the delivery policy is changed to “INVALID”. The DPAF service consumer rApp sends HTTP “204 no content” response back to the DPAF via R1 with empty message body, and it invokes the Rl_DataPolicyAdmin_Delete service operation to delete the data policy.

[00116] In Example 13, the subject matter of Examples 1-12 includes, where “Xxx” in stands for one or more of the following: “Delivery”, “Collection”, “Retention”, “Sharing”, “Processing”, “Disposal” for six data policy types, respectively.

[00117] In Example 14, the subject matter of Examples 1-13 includes, where the DeliveryPolicyObject policy resource object contains one or more of the following: data type identifier, time period for the delivery policy to be enforced time interval between two data patch delivery (for periodic delivery), eventtrigger conditions (for event-trigger based delivery), maximum number of delivery patches within the time period, number of data samples within each data patch, notification target address, and/or delivery mode.

[00118] In Example 15, the subject matter of Examples 1 -14 includes, the CollectionPolicyObject policy resource object contains one or more of the following: data type identifier, time period for the collection policy to be enforced, time interval between two data patch collection (for periodic collection), event-trigger conditions (for event-trigger based collection), maximum number of patches collected within the time period, number of data samples within each data patch, notification target address, and/or collection mode.

[00119] In Example 16, the subject matter of Examples 1-15 includes, where the RetentionPolicyObject policy resource object contains one or more of the following: data type identifier, time period for the delivery’ policy to be enforced, maximum retention time of data samples, and/or notification target address. [00120] In Example 17, the subject matter of Examples 1-16 includes, where the SharingPolicyObject policy resource object contains one or more of the following: data type identifier, time period for the sharing policy to be enforced, sharing configuration, Blocked list (or allowed list) of data consumers, Data exposure level for different data consumers, and/or notification target address. [00121] In Example 18, the subject matter of Examples 1-17 includes, where the Processing? olicy Object policy resource object contains one or more of the following: data type identifier, time period for the processing policy to be enforced, processing configuration, Pre-processing algorithm (e.g., normalization), Post-processing algorithm, Data labelling algorithm, Data correlation methods, and/or notification target address.

[00122] In Example 19, the subject matter of Examples 1-18 includes, where the DisposalPolicyObject policy resource object contains one or more of the following: data type identifier, time period for the processing policy to be enforced, event-trigger conditions when the data needs to be removed/deleted, and/or notification target address.

[00123] In Example 20, the subject matter of Examples 1-19 includes, where the data policy status resource object contains policy status type and/or status changes.

[00124] In Example 21, the subject matter of Examples 1-20 includes, where the data policy type ID is a string constructed by data policy type label and the version number of that data policy type.

[00125] In Example 22, the subject matter of Examples 1 -21 includes, where the data policy type resource object contains schema for data policy object and schema for data policy status object.

REFERENCES

[00126] [R01] O-RAN WG1 , “O-RAN Architecture Description”

[00127] [R02] O-RAN WG2, “Non-RT RIC: Functional Architecture”, vOl.OO. [00128] [R04] 3GPP TS 36.401 vlS. l .O (2019-01-09).

[00129] [R06] 3GPP TS 38.300 v!6.0.0 (2020-01-08).

[00130] [R07] 3GPP TS 38.401 vl 6.0.0 (2020-01-09). [00131] [R08] 3GPP TS 38.420 vl5.2.0 (2019-01-08). [00132] [R10] 3GPP TS 38.470 vlb.O.O (2020-01-09). [00133] [ R 12 ] O-RAN Alliance Working Group 1, O-RAN Operations and Maintenance Architecture Specification, version 2.0 (Dec 2019) (“O-RAN- WG1.0AM-Architecture-v02,00”).

[00134] [R13] O-RAN Alliance Working Group 1, O-RAN Operations and Maintenance Interface Specification, version 2.0 (Dec 2019) (“O-RAN- WG1.01-Interface-v02.00”).

[00135] [R14] O -RAN Alliance Working Group 2, O-RAN Al interface: General .Aspects and Principles Specification, version 1.0 (Oct 2019) (“ORAN- WG2.A1.GA&P-vOl .00”).

[00136] [R15] O -RAN Alliance Working Group 3, Near- Real -time RAN Intelligent Controller Architecture & E2 General Aspects and Principles (“OR AN-WG3.E2G.AP.0-v0. 1”).

[00137] [R16] O-RAN Alliance Working Group 4, O-RAN Fronthaul Management Plane Specification, version 2.0 (July 2019) (“ORAN-WG4.MP.O- v02.00.00”).

[00138] [R17] O-RAN Alliance Working Group (WG) 4, O-RAN Fronthaul Control, User and Synchronization Plane Specification, version 2.0 (July 2019) (“ORAN-WG4.CUS.0-v02.00”).

TERMINOLOGY

[00139] The term “application” may refer to a complete and deployable package, environment to achieve a certain function in an operational environment. The term “AI/MI. application” or the like may be an application that contains some AJ/ML models and application-level descriptions.

[00140] The term “machine learning” or “ML” refers to the use of computer systems implementing algorithms and/or statistical models to perform specific task(s) without using explicit instructions, but instead relying on patterns and inferences. ML algorithms build or estimate mathematical model(s) (referred to as “ML models” or the like) based on sample data (referred to as “training data,” “model training information,” or the like) in order to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with respect to some task and some performance measure, and an ML model may be any object or data structure created after an ML algorithm is trained with one or more training datasets. After framing, an ML model may be used to make predictions on new datasets. Although the term “ML algorithm” refers to different concepts than the term “ML. model,” these terms as discussed herein may be used interchangeably for the purposes of the present disclosure.

[00141] The term “machine learning model,” “ML model,” or the like may also refer to ML methods and concepts used by an ML-assisted solution. An “ML- assisted solution” is a solution that addresses a specific use case using ML algorithms during operation. ML models include supervised learning (e.g., linear regression, k-nearest neighbor (KNN), descision tree algorithms, support machine vectors, Bayesian algorithm, ensemble algorithms, etc.) unsupervised learning (e.g., K-means clustering, principle component analysis (PCA), etc.), reinforcement learning (e.g., Q-leaming, multi-armed bandit learning, deep RL, etc.), neural networks, and the like. Depending on the implementation a specific ML model could have many sub-models as components and the ML model may train all sub-models together. Separately trained ML models can also be chained together in an ML pipeline during inference. An “ML pipeline” is a set of functionalities, functions, or functional entities specific for an ML-assisted solution; an ML pipeline may include one or several data sources in a data pipeline, a model training pipeline, a model evaluation pipeline, and an actor. The “actor” is an entity that hosts an ML assisted solution using the output of the ML model inference). The term “ML. training host” refers to an entity, such as a network function, that hosts the training of the model. The term “ML inference host” refers to an entity, such as a network function, that hosts model during inference mode (which includes both the model execution as well as any online learning if applicable). The ML-host informs the actor about the output of the ML algorithm, and the actor takes a decision for an action (an “action” is performed by an actor as a result of the output of an ML assisted solution). The term “model inference information” refers to information used as an input to the ML model for determining inference(s); the data used to train an ML model and the data used to determine inferences may overlap, however, “training data” and “inference data” refer to different concepts.

[00142] Although an aspect has been described with reference to specific exemplary aspects, it will be evident, that various modifications and changes maybe made to these aspects without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various aspects is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.