Method and device for policing network management write operations

Abstract

A method and network node for implementing write policies for network management write operations are disclosed. According to one aspect, a method implemented in a network node includes implementing a write policy for each of a plurality of async requests made by an rAPP. The method includes associating the write policy with a corresponding async request and with a patch operation.

Description

[0001] METHOD AND DEVICE FOR POLICING NETWORK MANAGEMENT WRITE OPERATIONS

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to wireless communications, and in particular, to write policies for network management write operations.

[0004] BACKGROUND

[0005] The Third Generation Partnership Project (3GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile user equipment (UE) or wireless devices (WD), as well as communication between network nodes and between UEs. The 3GPP is also developing standards for Sixth Generation (6G) wireless communication networks.

[0006] In Open Radio Access Network (O-RAN) non real time (Non-RT) RAN intelligent controller (RIC) architecture specification version 07, the workflow in stage 1 and stage 2 are specified. Writing the configuration management (CM) configuration causes changes to the network elements. CM configurations in the RAN nodes terminating the 01 interface are typically managed by the service management and orchestration (SMO) via the 01 interface. Configuration information is consolidated by the SMO / Non-RT RIC framework and may be modified by rApps via the R1 interface. The write configuration changes request that is initiated by rApps may contain bundled write requests for multiple RAN nodes in order to save bandwidth on the R1 interface.

[0007] The write configuration changes request is handled asynchronously. When the rApp initiates the Write configuration changes procedure, the RAN operations, administration and maintenance (OAM)-related functions authenticate and authorize the request with short message entity (SME), validate the request, store the request as job and acknowledge the request. The request is acknowledged by sending a write configuration changes response indicating that the request has been accepted for processing, but the processing job has not been completed. An assigned requested identifying the created processing job is included in the response. The actual processing job for the write configuration changes request includes, e.g., conflict detection, conflict mitigation and writing the configuration changes to each RAN node as requested via the 01 interface. The actual processing, happens asynchronously. If the rApp has subscribed for the notification of the write configuration changes job status, the RAN OAM-related functions send a notification to the rApp once the write configuration changes job is complete, indicating the completion of the job and providing information about success, partial success, or failure result with failure reasons. Otherwise, the rApp may query for the write configuration changes job status and result with query procedures.

[0008] In the R1 UE Capabilities Requirement (UCR), the use case is captured in stage 2 for Write configuration changes.

[0009] In data required for this use case is specified by the R1 UCR. As specified below: The request for writing configuration changes information contains the rAppId and write configuration information for one or more managed entities (e.g., a list of attributes and desired values).

[0010] RAN OAM-related functions respond to the rApp with created configuration job information, e.g., a job identifier. The rApp may use this job information for querying or receiving notifications about the status or result of the requested configuration change, which may include, e.g.:

[0011] • a success result if all the requested configuration changes were written in the related managed entities;

[0012] • a partial success result if some but not all requested configuration changes were written in the related mentioned managed entities, optionally with further information about the reason for the errors; or

[0013] • a failure result if one of the requested configuration changes were written in the related managed entities, optionally with further information about the reason for the errors.

[0014] As explained above, although the requirement for the Async solution and high level sequence flows has been specified, a solution for achieving this requirement has not been specified. Examples of such high level sequence flows are shown in FIGS. 1 and 2.

[0015] SUMMARY

[0016] Some embodiments advantageously provide methods and network nodes for implementation of write policies for network management write operations.

[0017] Some embodiments include using the Write policy, for every async request made by the rApp. A write policy may be associated with the request along with the Patch operations. Some embodiments provide for managing the Async request with respect to aspects including priority, retry, validation, conditions and rollback.

[0018] According to one aspect, a network node includes processing circuitry configured to implement a write policy for each of a plurality of async requests made by an rAPP. The processing circuitry is also configured to associate the write policy with a corresponding async request and with a patch operation.

[0019] According to this aspect, in some embodiments, the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback. In some embodiments, a write policy relates to terminating a process when a failure occurs. In some embodiments, a write policy relates to rolling back a process when a failure occurs. In some embodiments, the processing circuitry is configured to simulate a write operation. In some embodiments, the write policy relates to a condition for performing or not performing a write operation. In some embodiments, the write policy relates to a schedule of write operations. In some embodiments, the write policy relates to an approval requirement for execution of a write operation. In some embodiments, the processing circuitry is configured to authorize a request that includes patch operations. In some embodiments, the processing circuitry is configured to perform radio access network (RAN) operation and management (0AM) related functions when the request is validated. In some embodiments, the network node is configured to communicate with a wireless device (WD) in an Open Radio Access Network (0-RAN).

[0020] According to another aspect, a method in a network node is provided. The method includes implementing a write policy for each of a plurality of async requests made by an rAPP. The method includes associating the write policy with a corresponding async request and with a patch operation.

[0021] According to this aspect, in some embodiments, the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback. In some embodiments, a write policy relates to terminating a process when a failure occurs. In some embodiments, a write policy relates to rolling back a process when a failure occurs. In some embodiments, the process includes simulating a write operation. In some embodiments, the write policy relates to a condition for performing or not performing a write operation. In some embodiments, the write policy relates to a schedule of write operations. In some embodiments, the write policy relates to an approval requirement for execution of a write operation. In some embodiments, the process includes authorizing a request that includes patch operations. In some embodiments, the process includes performing radio access network (RAN) operation and management (0AM) related functions when the request is validated. In some embodiments, the process includes communicating with a wireless device (WD) in an Open Radio Access Network (O-RAN).

[0022] BRIEF DESCRIPTION OF THE DRAWINGS

[0023] A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

[0024] FIG. 1 is a flow diagram for example RAN configurations;

[0025] FIG. 2 is another flow diagram for example RAN configurations;

[0026] FIG. 3 is a schematic diagram of an example network architecture illustrating a communication system connected via an intermediate network to a host computer according to the principles in the present disclosure;

[0027] FIG. 4 is a block diagram of a host computer communicating via a network node with a wireless device over an at least partially wireless connection according to some embodiments of the present disclosure;

[0028] FIG. 5 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized;

[0029] FIG. 6 is a flowchart illustrating example methods implemented in a communication system including a host computer, a network node and a wireless device according to principles of the present disclosure;

[0030] FIG. 7 is a flowchart of an example process in a network node for implementing write policies for network management write operations;

[0031] FIG. 8 is a block diagram of a DataJobWriteRequest;

[0032] FIG. 9 is a flow diagram for Async Read DataJob;

[0033] FIG. 10 is a flow diagram for Async Write DataJob;

[0034] FIG. 11 illustrates one example of a data model for CM Read DataJob according to principles disclosed herein;

[0035] FIG. 12 illustrates a data model for CM Write DataJob according to principles disclosed herein;

[0036] FIG. 13 illustrates a DataJob REST Request Summary;

[0037] FIG. 14 illustrates an overall resource URI structure defined for an Async configuration application program interface (API); and FIG. 15 illustrates operation of a Create configuration plan.

[0038] DETAILED DESCRIPTION

[0039] Before describing in detail example embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to implementation of write policies for network management write operations. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Like numbers refer to like elements throughout the description.

[0040] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0041] In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

[0042] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0043] The term “network node” used herein may be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multistandard radio (MSR) radio node such as MSR BS, multi-cell / multicast coordination entity (MCE), integrated access and backhaul (IAB) node, relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, anode external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a wireless device (WD) such as a wireless device (WD) or a radio network node.

[0044] In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The WD herein may be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as wireless device (WD). The WD may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and / or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device, etc.

[0045] Also, in some embodiments the generic term “radio network node” is used. It may be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell / multicast Coordination Entity (MCE), IAB node, relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

[0046] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure. Note further, that functions described herein as being performed by a wireless device or a network node may be distributed over a plurality of wireless devices and / or network nodes. In other words, it is contemplated that the functions of the network node and wireless device described herein are not limited to performance by a single physical device and, in fact, may be distributed among several physical devices.

[0047] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0048] Some embodiments provide policies for network management of write operations.

[0049] Returning now to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 3 a schematic diagram of a communication system 10, according to an embodiment, such as a 3 GPP-type cellular network that may support standards such as LTE and / or NR (5G), which comprises an access network 12, such as a radio access network, and a core network 14. Communication system 10 may be O-RAN based. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 14 over a wired or wireless connection 20. A first wireless device (WD) 22a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second WD 22b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of WDs 22a, 22b (collectively referred to as wireless devices 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole WD is in the coverage area or where a sole WD is connecting to the corresponding network node 16. Note that although only two WDs 22 and three network nodes 16 are shown for convenience, the communication system may include many more WDs 22 and network nodes 16.

[0050] Also, it is contemplated that a WD 22 may be in simultaneous communication and / or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a WD 22 may have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, WD 22 may be in communication with an eNB for LTE / E-UTRAN and a gNB for NR / NG-RAN.

[0051] The communication system 10 may itself be connected to a host computer 24, which may be embodied in the hardware and / or software of a standalone server, a cloud- implemented server, a distributed server or as processing resources in a server farm. The host computer 24 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 26, 28 between the communication system 10 and the host computer 24 may extend directly from the core network 14 to the host computer 24 or may extend via an optional intermediate network 30. The intermediate network 30 may be one of, or a combination of more than one of, a public, private or hosted network. The intermediate network 30, if any, may be a backbone network or the Internet. In some embodiments, the intermediate network 30 may comprise two or more sub-networks (not shown).

[0052] The communication system of FIG. 3 as a whole enables connectivity between one of the connected WDs 22a, 22b and the host computer 24. The connectivity may be described as an over-the-top (OTT) connection. The host computer 24 and the connected WDs 22a, 22b are configured to communicate data and / or signaling via the OTT connection, using the access network 12, the core network 14, any intermediate network 30 and possible further infrastructure (not shown) as intermediaries. The OTT connection may be transparent in the sense that at least some of the participating communication devices through which the OTT connection passes are unaware of routing of uplink and downlink communications. For example, a network node 16 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 24 to be forwarded (e.g., handed over) to a connected WD 22a. Similarly, the network node 16 need not be aware of the future routing of an outgoing uplink communication originating from the WD 22a towards the host computer 24.

[0053] A network node 16 is configured to include a virtualization environment 32 which is configured to implement a write policy for each of a plurality of async requests made by an rAPP, and associate the write policy with a corresponding async request with a patch operation. The virtualization environment 32 may be configured to implement RAN 0AM related functions and interface with and / or implement an API consumer and / or 01 network elements, as disclosed herein. Example implementations, in accordance with an embodiment, of the WD 22, network node 16 and host computer 24 discussed in the preceding paragraphs will now be described with reference to FIG. 4. In a communication system 10, a host computer 24 comprises hardware (HW) 38 including a communication interface 40 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 10. The host computer 24 further comprises processing circuitry 42, which may have storage and / or processing capabilities. The processing circuitry 42 may include a processor 44 and memory 46. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 42 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 44 may be configured to access (e.g., write to and / or read from) memory 46, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0054] Processing circuitry 42 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by host computer 24. Processor 44 corresponds to one or more processors 44 for performing host computer 24 functions described herein. The host computer 24 includes memory 46 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 48 and / or the host application 50 may include instructions that, when executed by the processor 44 and / or processing circuitry 42, causes the processor 44 and / or processing circuitry 42 to perform the processes described herein with respect to host computer 24. The instructions may be software associated with the host computer 24.

[0055] The software 48 may be executable by the processing circuitry 42. The software 48 includes a host application 50. The host application 50 may be operable to provide a service to a remote user, such as a WD 22 connecting via an OTT connection 52 terminating at the WD 22 and the host computer 24. In providing the service to the remote user, the host application 50 may provide user data which is transmitted using the OTT connection 52. The “user data” may be data and information described herein as implementing the described functionality. In one embodiment, the host computer 24 may be configured for providing control and functionality to a service provider and may be operated by the service provider or on behalf of the service provider. The processing circuitry 42 of the host computer 24 may enable the host computer 24 to observe, monitor, control, transmit to and / or receive from the network node 16 and or the wireless device 22.

[0056] The communication system 10 further includes a network node 16 provided in a communication system 10 and including hardware 58 enabling it to communicate with the host computer 24 and with the WD 22. The hardware 58 may include a communication interface 60 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 10, as well as a radio interface 62 for setting up and maintaining at least a wireless connection 64 with a WD 22 located in a coverage area 18 served by the network node 16. The radio interface 62 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The communication interface 60 may be configured to facilitate a connection 66 to the host computer 24. The connection 66 may be direct or it may pass through a core network 14 of the communication system 10 and / or through one or more intermediate networks 30 outside the communication system 10.

[0057] In the embodiment shown, the hardware 58 of the network node 16 further includes processing circuitry 68. The processing circuitry 68 may include a processor 70 and a memory 72. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 68 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 70 may be configured to access (e.g., write to and / or read from) the memory 72, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0058] Thus, the network node 16 further has software 74 stored internally in, for example, memory 72, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 74 may be executable by the processing circuitry 68. The processing circuitry 68 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by network node 16. Processor 70 corresponds to one or more processors 70 for performing network node 16 functions described herein. The memory 72 is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 74 may include instructions that, when executed by the processor 70 and / or processing circuitry 68, causes the processor 70 and / or processing circuitry 68 to perform the processes described herein with respect to network node 16. For example, processing circuitry 68 of the network node 16 may include a virtualization environment 32 which is configured to implement a write policy for each of a plurality of async requests made by an rAPP, and associate the write policy with a corresponding async request with a patch operation.

[0059] The communication system 10 further includes the WD 22 already referred to. The WD 22 may have hardware 80 that may include a radio interface 82 configured to set up and maintain a wireless connection 64 with a network node 16 serving a coverage area 18 in which the WD 22 is currently located. The radio interface 82 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers.

[0060] The hardware 80 of the WD 22 further includes processing circuitry 84. The processing circuitry 84 may include a processor 86 and memory 88. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 84 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 86 may be configured to access (e.g., write to and / or read from) memory 88, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0061] Thus, the WD 22 may further comprise software 90, which is stored in, for example, memory 88 at the WD 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the WD 22. The software 90 may be executable by the processing circuitry 84. The software 90 may include a client application 92. The client application 92 may be operable to provide a service to a human or non-human user via the WD 22, with the support of the host computer 24. In the host computer 24, an executing host application 50 may communicate with the executing client application 92 via the OTT connection 52 terminating at the WD 22 and the host computer 24. In providing the service to the user, the client application 92 may receive request data from the host application 50 and provide user data in response to the request data. The OTT connection 52 may transfer both the request data and the user data. The client application 92 may interact with the user to generate the user data that it provides.

[0062] The processing circuitry 84 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by WD 22. The processor 86 corresponds to one or more processors 86 for performing WD 22 functions described herein. The WD 22 includes memory 88 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 90 and / or the client application 92 may include instructions that, when executed by the processor 86 and / or processing circuitry 84, causes the processor 86 and / or processing circuitry 84 to perform the processes described herein with respect to WD 22.

[0063] In some embodiments, the inner workings of the network node 16, WD 22, and host computer 24 may be as shown in FIG. 4 and independently, the surrounding network topology may be that of FIG. 3.

[0064] In FIG. 3, the OTT connection 52 has been drawn abstractly to illustrate the communication between the host computer 24 and the wireless device 22 via the network node 16, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the WD 22 or from the service provider operating the host computer 24, or both. While the OTT connection 52 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

[0065] The wireless connection 64 between the WD 22 and the network node 16 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 WD 22 using the OTT connection 52, in which the wireless connection 64 may form the last segment. More precisely, the teachings of some of these embodiments may improve the data rate, latency, and / or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc. In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 52 between the host computer 24 and WD 22, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection 52 may be implemented in the software 48 of the host computer 24 or in the software 90 of the WD 22, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 52 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 48, 90 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 52 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the network node 16, and it may be unknown or imperceptible to the network node 16. Some such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary WD signaling facilitating the host computer’s 24 measurements of throughput, propagation times, latency and the like. In some embodiments, the measurements may be implemented in that the software 48, 90 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 52 while it monitors propagation times, errors, etc.

[0066] Thus, in some embodiments, the host computer 24 includes processing circuitry 42 configured to provide user data and a communication interface 40 that is configured to forward the user data to a cellular network for transmission to the WD 22. In some embodiments, the cellular network also includes the network node 16 with a radio interface 62. In some embodiments, the network node 16 is configured to, and / or the network node’s 16 processing circuitry 68 is configured to perform the functions and / or methods described herein for preparing / initiating / maintaining / supporting / ending a transmission to the WD 22, and / or preparing / terminating / maintaining / supporting / ending in receipt of a transmission from the WD 22.

[0067] In some embodiments, the host computer 24 includes processing circuitry 42 and a communication interface 40 that is configured to a communication interface 40 configured to receive user data originating from a transmission from a WD 22 to a network node 16. In some embodiments, the WD 22 is configured to, and / or comprises a radio interface 82 and / or processing circuitry 84 configured to perform the functions and / or methods described herein for preparing / initiating / maintaining / supporting / ending a transmission to the network node 16, and / or preparing / terminating / maintaining / supporting / ending in receipt of a transmission from the network node 16.

[0068] Although FIGS. 3 and 4 show various “units” such as virtualization environment 32 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

[0069] In some embodiments, the communication system 10 includes one or more Open- RAN (ORAN) network nodes 16. An ORAN network node 16 is a node in the communication system 10 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication system 10, including one or more network nodes 16 in the access network 12 and / or core network nodes 14.

[0070] Examples of an ORAN network node 16 include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near- real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes 16 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 22a, 22b, 22c, and 22d (one or more of which may be generally referred to as UEs 22) to the core network 14 over one or more wireless connections. FIG. 5 is a block diagram illustrating one example of the virtualization environment 32 in which functions implemented by some embodiments may be virtualized. Although shown as part of network node 16 in FIGS. 3 and 4, it is understood that virtualization environment 32 can be implemented in other nodes. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization may be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtualization environments 32 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node 16, UE 22, core network node (in core network 14), or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 32 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0071] In some embodiments, the virtualization environment(s) 32 may be configured to implement a write policy for each of a plurality of async requests made by an rAPP, and associate the write policy with a corresponding async request with a patch operation.

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

[0073] Hardware 98 includes processing circuitry (such as processing circuitry 68 in cases where virtualization environment 32 is part of a network node 16), memory (such as memory 72) that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 100 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 102a and 102b (one or more of which may be generally referred to as VMs 102), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 100 may present a virtual operating platform that appears like networking hardware to the VMs QQ508.

[0074] The VMs 102 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 100. Different embodiments of the instance of a virtual appliance 96 may be implemented on one or more of VMs 102, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which may be located in data centers, and customer premise equipment.

[0075] In the context of NFV, a VM 102 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 102, and that part of hardware 98 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 102 on top of the hardware 98 and corresponds to the application 96.

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

[0077] FIG. 6 is a flowchart illustrating an example method implemented in a communication system, such as, for example, the communication system of FIGS. 3 and 4, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIG. 4. In a first step of the method, the host computer 24 provides user data (Block S100). In an optional substep of the first step, the host computer 24 provides the user data by executing a host application, such as, for example, the host application 50 (Block S102). In a second step, the host computer 24 initiates a transmission carrying the user data to the WD 22 (Block SI 04). In an optional third step, the network node 16 transmits to the WD 22 the user data which was carried in the transmission that the host computer 24 initiated, in accordance with the teachings of the embodiments described throughout this disclosure (Block SI 06). In an optional fourth step, the WD 22 executes a client application, such as, for example, the client application 92, associated with the host application 50 executed by the host computer 24 (Block SI 08). In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 22. Regardless of the specific manner in which the user data was provided, the UE 22 initiates, in Block SI 10, transmission of the user data towards the host computer 24 via the network node 16. In Block SI 12, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 16 receives user data from the UE 22 and initiates transmission of the received user data towards the host computer 24. In Block SI 14, the host computer 24 receives the user data carried in the transmission initiated by the UE 22.

[0078] FIG. 7 is a flowchart of an example process in a network node 16 for implementation of policies for network management write operations. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the virtualization environment 32), processor 70, radio interface 62 and / or communication interface 60. Network node 16 such as via processing circuitry 68 and / or processor 70 and / or radio interface 62 and / or communication interface 60 is configured to implement a write policy for each of a plurality of async requests made by an rAPP (Block SI 16). The process also includes associating the write policy with a corresponding async request and with a patch operation (Block SI 18).

[0079] In some embodiments, the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback. In some embodiments, a write policy relates to terminating a process when a failure occurs. In some embodiments, a write policy relates to rolling back a process when a failure occurs. In some embodiments, the process includes simulating a write operation. In some embodiments, the write policy relates to a condition for performing or not performing a write operation. In some embodiments, the write policy relates to a schedule of write operations. In some embodiments, the write policy relates to an approval requirement for execution of a write operation. In some embodiments, the process includes authorizing a request that includes patch operations. In some embodiments, the process includes performing radio access network (RAN) operation and management (0AM) related functions when the request is validated. In some embodiments, the process includes communicating with a wireless device (WD) in an Open Radio Access Network (0-RAN).

[0080] Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for policies for network management write operations.

[0081] In some embodiments, methods disclosed herein may be implemented in one or more network nodes in an 0-RAN. One or more of these network nodes may include one or more radio base stations that are configured to communicate with a plurality of UEs. Some embodiments include hardware and / or software to implement the functions and logical entities disclosed herein. This hardware and / or software may be performed entirely within a network node and / or may be distributed among a plurality of network nodes.

[0082] Some embodiments include methods that make use of the Write policy where, for every async request made by the rApp, a write policy may be associated with the request along with the Patch operations.

[0083] The write policy may have the following parameters and structure:

[0084] "write_policy": {

[0085] "execution" : ROLLBACK ON FAIL, / / or EXIT ON FAIL, ROLLBACK ON FAIL. DRY RUN, BEST EFFORT

[0086] "lock_policy" {

[0087] "lock" : LOCK ALL, / / Lock out other applications from attempted changes to the same data set, other may be LOCK PER NE, LOCK PER SUBNETWORK, etc

[0088] "lock_timer" : 300 / / Lock out other applications for 5 minutes

[0089] "retry" : {

[0090] "reason" : SERVER BUSY, retry_attempts" : 3

[0091] "prioritization" : {

[0092] "desired_priority" : 2 / / execute as a #2 priority request

[0093] "rollback" : {

[0094] / / some rollback based policy parameters specific to this request, example, may be that rollback is never required in future for this call so would be no need to record any rollback history.

[0095] "to version" : ORIGINAL WITH DELTA / / or ORIGINAL, etc

[0096] "conditions" : {

[0097] / / some potential pre-requisite write conditions

[0098] "approval" : {

[0099] / / some approval based policies

[0100] Example Write Policies may include one or more of the following:

[0101] 1. Best Effort: Attempt to write the configuration changes, but if any failures occur, continue with the remaining changes without halting the process;

[0102] 2. Exit on Failure: If any failure occurs during the write operation, immediately terminate the process and do not proceed with any further changes;

[0103] 3. Rollback on Failure: If a failure occurs during the write operation, revert any changes that were made and return the system to its previous state;

[0104] 4. Dry Run: Simulate the write operation without actually making any changes to the system. This is useful for testing the impact of proposed changes without risking unintended consequences;

[0105] 5. Conditional Write: Perform the write operation only if certain conditions are met. If the conditions are not satisfied, do not proceed with the write;

[0106] 6. Scheduled Write: Specify a schedule for when the write operation should occur, such as daily, weekly, or monthly; and / or 7. Approval-based Write: Require approval from authorized personnel before the write operation may be executed, ensuring changes are reviewed before implementation.

[0107] Further examples and implementation arrangements may include one or more of the following as shown and described in the following drawing figures

[0108] FIG. 8 is a block diagram of a DataJobWriteRequest 108. The DataJobWriteRequest 108 may be configured to include a Write Policy 110 and a plurality of patch operations 112.

[0109] FIGS. 9 and 10 are flow diagrams for Async ReadDataJob and Async Write DataJob processes. The processes of FIGS. 9 and 10 may be implemented by a network node 16 and / or other nodes of an O-RAN. The network node 16 may provide RAN 0AM related functions 114 and interface with an application program interface (API) consumer 116 and 01 network elements 118, as follows. The RAN 0AM related functions 114, the API consumer 116 and the 01 network elements 118 may be implemented in a single network node 16 or may be distributed among a plurality of network nodes.

[0110] FIG. 9 is a flow diagram for performing an Async Read DataJob by RAN 0AM related functions 114 in a network node 16 that is configured to interface with an API consumer 116 and 01 network elements 118. The API consumer 116 may send a DataJobReadRequest. The RAN 0AM related functions 114 include authorizing and validating the DataJobWriteRequest and creating the DataJob (Steps S120). The RAN 0AM related functions 114 perform the job execution in the Execute DataJob procedures (Steps S122). Steps S122 may include updating DataJob status, reading and / or querying network element data, and writing results to a data store. The process also includes notifying the API consumer 116 of job status and reading DataJob results and finishing the DataJob (Steps SI 24). As an example:

[0111] • The API Consumer 116 may want to issue an async read request with simple to complex read / query criteria resulting in small medium or large volumes of response data;

[0112] • The async request may be issued in the form of a DataJob;

[0113] • The DataJob may allow for long running read requests avoiding request timeouts;

[0114] • The DataJob may also support scheduled read requests; and / or

[0115] • The DataJob may support multiple result transport delivery methods including streaming / obj ectstore / file store.

[0116] FIG. 10 is a flow diagram for performing an Async Write DataJob by RAN 0AM related functions 114 in a network node 16 that is configured to interface with an API consumer 116 and 01 network elements 118. The API consumer 116 may send a DataJobWriteRequest. The RAN 0AM related functions 114 include authorizing and validating the DataJobWriteRequest and creating the DataJob (Steps S126). The RAN 0AM related functions 114 perform the job execution in the Execute DataJob procedures (Steps S128). Steps 128 may include updating DataJob status, writing network element data, and writing results to a data store. The process also includes notifying the API consumer 116 of job status and reading DataJob results (Steps S130). As an example:

[0117] • The API Consumer 116 may issue an async write configuration request across a small medium or large volume of Network Elements;

[0118] • The async request may be issued in the form of a DataJob;

[0119] • The DataJob may allow for long running write requests avoiding request timeouts;

[0120] • The API consumer 116 may specify write policy:

[0121] BEST EFFORT (Default);

[0122] EXIT ON FAILURE; and / or

[0123] ROLLBACK ON FAILURE; and / or

[0124] • Multiple result transport delivery methods may include:

[0125] - streaming / objectstore / file store.

[0126] In existing 0-RAN specifications, the non-RT RIC architecture has specified the bundled write request for multiple RAN nodes in chapter 10.3.4. in Async approach. R1 UCR specifications specify the async behavior and requirements of the used case in chapter 8.6. The behavior of sync n R1 AP specifications (referring to 3GPP Technical Standard (TS) 28.532 MnSProv API representational state transfer (REST) based solutions set for read and write operations), may be specified for async behavior for large volumes of read and write operations.

[0127] FIG. 11 illustrates one example of a data model for CM Read DataJob according to principles disclosed herein. The data model includes a DataJob Read Request 120 that includes ReadOperations 122. ReadOperations 122 may include or specify an identifier, a scope, a filter, attributes and fields. The data model includes a DataJob Response 124 that provide DataJob Results 126. The DataJob Response may include DataJob identifier, status and / or links. The status may be based on 3GPP ProcessMonitor (3GPP TS 32.158) The DataJobResults 126 may be written as events to kafka in Event 128 and / or ObjectStore or File 130. A ReadOperation 122 may be based on a query definition in 3GPP TS 28.532. See, e.g., Table 12.1.1.3.2.1.3.2-1 reproduced in FIG. 11. An Event 128 may include header parameters, an operation request and operation results. An Object / file 130 may include an identifier, an operation request and operation results. Operation results may be constructed based on 3GPP ‘Resource’ according to the object-tree-flat response construction method in 3GPP TS 32.158. Example computer code for the object-tree-flat response construction method is shown in FIG. 11.

[0128] FIG. 12 illustrates another example of a data model for CM Write DataJob according to principles disclosed herein. The data model includes a DataJob Write Request 132 that includes a Write Policy 134 and Patch Operations 136. Patch Operations 136 may include an operation, a path, a value and an identifier. Example computer code for an object-tree-flat construction method is shown in FIG. 12. The data model includes a DataJobResponse 138 that provides DataJob Results 140. The DataJobResults 140 may be written as events to Kafka Event 142 and / or to an ObjectStore / File 144. The DataJobResponse 138 may include a DataJob identifier, status and links. The status included in the DataJobResponse 138 may be based on 3GPP ProcessMonitor (3GPP TS 32.158). A Patch Operation may be based on a Patchitem definition in 3GPP TS 28.532. Example computer code for Patchitem is depicted in FIG. 12. An Event 142 may include header parameters, an operation request and operation results. An Object / file 144 may include a jobidentifier, an operation request and operation results. The operation results may indicate what operations succeeded and / or what operations failed and whey they failed.

[0129] FIG. 13 illustrates a DataJob REST Request Summary for different use cases and their associated methods, uniform resource locator (URL) and payloads.

[0130] Some embodiments include the introduction of the dataJob API as part of R1 AP specifications (RAN 0AM APIs).

[0131] The Async application program interface (API) Consumer 116 may issue an async write configuration request across a small, medium or large volume of Network Elements. Once the Async request is accepted, the RAN 0AM functions would Authorize the request that contains the Patch operations to an array of Patchitem from 3GPP Technical Standard (TS) 28.532. If the request is validated, RAN 0AM related functions may create a Data Job and send a reply to the application program interface (API) consumer 116 with the Data job ID.

[0132] The RAN 0 AM functions may start the data job internally from moving the state from Created to Running, e.g., as specified by 3GPP TS 28.623, to the Process Monitor state machine process. Reference is made to O-RAN.WGIO.OI-Interface: “O-RAN Operations and Maintenance Interface Specification”.

[0133] Some example embodiments may include one or more of the following:

[0134] Example 1. A network node configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to: implement a write policy for each of a plurality of async requests made by an rAPP; and associate the write policy with a corresponding async request with a patch operation.

[0135] Example 2. The network node of Example 1, wherein the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback.

[0136] Example 3. The network node of any of Examples 1 and 2, wherein a write policy relates to terminating a process when a failure occurs.

[0137] Example 4. The network node of any of Examples 1-3, wherein a write policy relates to rolling back a process when a failure occurs.

[0138] Example 5. The network node of any of Examples 1-4, wherein the network node is configured to simulate a write operation.

[0139] Example 6. The network node of any of Examples 1-5, wherein the write policy relates to a condition for performing or not performing a write operation.

[0140] Example 7. The network node of any of Examples 1-6, wherein the write policy relates to a schedule of write operations.

[0141] Example 8. The network node of any of Examples 1-7, wherein the write policy relates to an approval requirement for execution of a write operation.

[0142] Example 9. The network node of any of Examples 1 -8, wherein the network node is configured to authorize a request that includes the patch operation.

[0143] Example 10. The network node of Example 9, wherein the network node is configured to perform radio access network (RAN) operation and management (0AM) related functions when the request is validated.

[0144] Example 11. The network node of any of Examples 1-10 configured to communicate with a wireless device (WD).

[0145] Example 12. A method implemented in a network node, the method comprising: implementing a write policy for each of a plurality of async requests made by an rAPP; and associating the write policy with a corresponding async request with a patch operation.

[0146] Example 13. The method of Example 12, wherein the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback.

[0147] Example 14. The method of any of Examples 12 and 13, wherein a write policy relates to terminating a process when a failure occurs.

[0148] Example 15. The method of any of Examples 12-14, wherein a write policy relates to rolling back a process when a failure occurs.

[0149] Example 16. The method of any of Examples 12-15, further comprising simulating a write operation.

[0150] Example 17. The method of any of Examples 12-16, wherein the write policy relates to a condition for performing or not performing a write operation.

[0151] Example 18. The method of any of Examples 12-17, wherein the write policy relates to a schedule of write operations.

[0152] Example 19. The method of any of Examples 12-18, wherein the write policy relates to an approval requirement for execution of a write operation.

[0153] Example 20. The method of any of Examples 12-19, further comprising authorizing a request that includes the patch operation.

[0154] Example 21. The method of Example 20, further comprising performing radio access network (RAN) operation and management (0AM) related functions when the request is validated.

[0155] STANDARDIZING THE PROPOSED SOLUTIONS

[0156] Below are non-limiting examples of how certain aspects of the proposed solutions could be implemented within the framework of a specific communication standard. In particular, the description below provides non-limiting examples of how the proposed solutions could be implemented within the framework of a 3GPP TSG RAN standard. The changes described below are merely intended to illustrate how certain aspects of the proposed solutions could be implemented in a particular standard. However, the proposed solutions could also be implemented in other suitable manners, both in the 3GPP Specification and in other specifications or standards.

[0157] Some of the proposed changes are set forth below: x.1 Async write configuration API x.1.1 Introduction This API allows the API Consumer 116 to request managing configuration data based on the procedures for “Configuration management (CM) service“ defined in R1GAP [5]. x.1.2 API version For the Async write configuration API as specified in the present document, the

[0158] MAJOR version field shall be 1, the MINOR version field shall be 0 and the PATCH version field shall be 0 (see clause 4.3.1.1 of 3GPP TS 29.501 [1] for a definition of the version fields). Consequently, the <apiVersion> URI variable shall be set to “vl“.

[0159] The Async configuration API is under development and consequently the API version shall include the pre-release version “alpha.1 “ x.1.3 Resource structure and methods

[0160] The request URIs used in HTTP requests from the API Consumer 116 towards the API Producer shall have the resource URI structure as defined in clause 5.2. The <apiName> resource URI variable shall be “ran-oam-cm“. The <apiSpecificResourceUriPart> for each resource shall be set as described in clause 7.3.5.

[0161] FIG. 14 shows the overall resource URI structure defined for the Async configuration API.

[0162] Table x.1.3-1 lists the individual resources defined for the API, the applicable HTTP methods, and the associated service operations.

[0163] Table x.1.3-1: Resources and methods overview of the Async write configuration API x.1.4 Service Operations x.1.4.1 Create configuration plan job x.1.4.1.1 Operation definition

[0164] The API Consumer 116 uses Create configuration plan job operation to create the plan activation job for performing the async write configurations with the API Producer.

[0165] The operations are based on HTTP POST. @startuml

[0166] ; autonumber

[0167] : Participant “API Consumer“ as Consumer

[0168] : Participant “API Producer“ as Producer

[0169] ; Consumer -» Producer: 1 POST ... / plan-management / plan-activation- : jobs\n(PlanActivationJobInfo)

[0170] : alt 201 Job created and has finished execution Producer — » Consumer: 2a 201 Created (PlanActivationJoblnfoResponse) else 202 : job created but has not finished

[0171] Producer — » Consumer: 2b 202 Accepted(PlanActivationJoblnfoResponse) end

[0172] @enduml

[0173] The service operation is as follows:

[0174] 1. The API Consumer 116 shall send an HTTP POST request to the API Producer. The target URI shall identify the resource (... / plan-management / plan- activati on-jobs) under which the new plan activation job is to be created. The message content shall carry a PlanActivationJoblnfo.

[0175] 2. The API Producer shall return the HTTP POST response with the following response codes : a. “201 Created“ shall be returned if the job was created and has finished the plan activation lifecycle b. “202 Accepted“ shall be returned if the job was created but has not finished the plan activation lifecycle

[0176] The Location header shall be present and shall carry the URI of the new plan activation job resource with jobld assigned by the API producer 146. The message content shall carry a PlanActivationJoblnfoResponse representing the created plan activation job. On failure, the appropriate error code shall be returned, and the message content may contain additional error information. x.1.4.1.2 Referenced procedures x. 1.4. 1.2. 1 Request data procedure

[0177] The Create configuration plan operation illustrated in FIG. 15 is based on the write configuration procedure defined for the O-RAN TS R1 GAP Error! Reference source not found.. x.1.5 Resources x.1.5.1 Overview

[0178] This clause defines the resources for the Async configuration API. x.1.5.2 Resource: "Plan activation jobs " x. 1.5.2. 1 Description

[0179] The resource plan activation jobs represent the activation job created by a particular consumer 116.

[0180] Only the methods defined in clause x. 1.5.2.3 shall be supported by these resources. x. 1.5.2.2 Resource Definition

[0181] Resource URI: {apiRoot} / ran-oam-cm / <apiVersion> / plan-management / plan- activation-jobs

[0182] The resource URI variables supported by the resource are defined in Table x. 1.5.2.2- 1.

[0183] Table x.1.5.2.2-1: Resource URI variables for the resource x.1.5.2.3 Resource Standard Methods x.1.5.2.3.1 POST

[0184] This method shall support the request data structure specified in the table x.1.5.2.3. 1- 1, and the response data structure and response code specified in the table x.1.5.2.3. 1-2.

[0185] Table x.1.5.2.3.1-1: Data structures supported by the POST request body on this resource.

[0186] Table x.1.5.2.3.1-2: Data structures supported by the POST response body on this resource.

[0187] Table x.1.5.2.3.1-3: Headers supported by the 201-response code this resource. x.1.5.3 Resource: "Plan activation job" x.1.5.3.1 Description The resource plan activation job represents the activation job created by a particular consumer 116.

[0188] Only the methods defined in clause x.1.5.3.3 shall be supported by these resources. x.1.5.3.2 Resource Definition

[0189] Resource URI: {apiRoot} / ran-oam-cm / <apiVersion> / plan-management / plan- activation-jobs / { jobld }

[0190] The resource URI variables supported by the resource are defined in Table

[0191] 5 x.1.5.3.2-1.

[0192] Table x.1.5.3.2-1: Resource URI variables for the resource x. 1.5.3.3 Resource Standard Methods

[0193] This method shall support the response data structure and response code specified

[0194] 10 in the table x. l.5.3.3.2-1.

[0195] Table x.1.5.3.3.21: Data structures supported by the GET request body on this resource. x.1.5.4 Resource: " Plan Descriptor" x. 1.5.4. 1 Description

[0196] The resource plan descriptor represents the configuration plan descriptor (associated with the activation job created by a particular consumer). Only the methods defined in clause x. 1.5.4.3 shall be supported by these resources. x. 1.5.4.2 Resource Definition

[0197] Resource URI: {apiRoot} / ran-oam-cm / <apiVersion> / plan-management / plan- activation-jobs / { jobld { / plan-descriptor

[0198] The resource URI variables supported by the resource are defined in Table x.1.5.4.2-1.

[0199] Table x.1.5.4.2-1: Resource URI variables for the resource x.1.5.4.3 Resource Standard Methods x.1.5.4.3.1 GET

[0200] This method shall support the response data structure and response code specified in the table x. l.5.3.3.2-1.

[0201] Table x.1.5.3.3.21: Data structures supported by the GET request body on this resource. x. 1.5.5 Resource: "Plan Activation Job Status" x.1.5.5.1 Description

[0202] The resource plan activation job status represents the status of the configuration activation job created by a particular consumer.

[0203] Only the methods defined in clause x.1.5.5.3 shall be supported by these resources. x.1.5.5.2 Resource Definition

[0204] Resource URI: {apiRoot} / ran-oam-cm / <apiVersion> / plan-management / plan- activation-j ob s / { j obld } / status

[0205] The resource URI variables supported by the resource are defined in Table x.1.5.5.2-1.

[0206] Table x.1.5.5.2-1: Resource URI variables for the resource x. 1.5.5.3 Resource Standard Methods x.1.5.5.3.1 GET

[0207] This method shall support the response data structure and response code specified in the table x.1.5.5.3.2-1.

[0208] Table x.1.5.5.3.2-1: Data structures supported by the GET request body on this resource. x. 1.5.6 Resource: " Plan Activation Job Results" x.1.5. 6.1 Description

[0209] The resource plan activation job results represents the results of the execution of the configuration activation job created by a particular consumer.

[0210] Only the methods defined in clause x.1.5.6.3 shall be supported by these resources. x.1.5. 6.2 Resource Definition

[0211] Resource URI: {apiRoot} / ran-oam-cm / <apiVersion> / plan-management / plan- activation-j ob s / { j obld } / results

[0212] The resource URI variables supported by the resource are defined in Table x.1.5.6.2-1.

[0213] Table x.1.5.6.2-1: Resource URI variables for the resource x. 1.5. 6.3 Resource Standard Methods x.1.5.6.3.1 GET

[0214] This method shall support the response data structure and response code specified in the table x.1.5.6.3.2-1.

[0215] Table x.1.5.6.3.2-1: Data structures supported by the GET request body on this resource. x.1.5.6.4 Resource Standard Query Parameters x.1.5.6.4.1 verbose

[0216] This method shall support the query parameters as specified in the table x.1.5.6.4.1-1.

[0217] Table x.1.5.6.4.11: Query parameters supported by the GET request on this resource. x.1.6 Custom operation without associated resources. None. x.1.7 Notifications

[0218] None. x.1.8 Data Model x.1.8.1 Structured data types x.1.8.1.1 Overview

[0219] The following clauses define the data type and attributes to be used in the resource representation. x.1.8.1.2 Data type: PlanActivationJoblnfo

[0220] The PlanActivationJoblnfo contains the attributes defined in table x.1.8.1.2-1.

[0221] Table x.1.8.1.2-1: Definition of type PlanActivationJoblnfo x.1.8.1.3 Datatype: PlanDescriptor The PlanDescriptor contains the attributes defined in table x.1.8.1.3-1.

[0222] Table x.1.8.1.3-1: Definition of type PlanDescriptor x.1.8.1.4 Data type: PlanConfiguration

[0223] The PlanConfiguration contains the attributes defined in table x.1.8.1.4-1. It is as per section 2.2 of [X], Table x.1.8.1.4-1: Definition of type PlanConfiguration x.1.8.1.5 Datatype: Edit

[0224] The Edit contains the attributes defined in table x.1.8.1.5-1.

[0225] Table x.1.8.1.5-1: Definition of type Edit x.1.8.1.6 Data type: PlanActivationJoblnfoResponse

[0226] The PlanActivationJoblnfoResponse contains the attributes defined in table x.1.8.1.6-1. Table x.1.8.1.6-1: Definition of type PlanActivationJoblnfoResponse x. 1.8.1.7 Data type: Links

[0227] The Links contains the attributes defined in table x.1.8.1.7-1.

[0228] Table x.1.8.1.7-1: Definition of type Links x.1.8.1.8 Datatype: Results

[0229] The Results contains the attributes defined in table x.1.8.1.8-1.

[0230] Table x.1.8.1.8-1: Definition of type Results x.1.8.1.9 Data type: ExecutionSummary

[0231] The ExecutionSummary contains the attributes defined in table x.1.8.1.9-1. Table x.1.8.1.9-1: Definition of type ExecutionSummary x.1.8.1.10 Data type: PatchStatus

[0232] The PatchStatus contains the attributes defined in table x.1.8.1.10-1. Table x.1.8.1.10-1: Definition of type PatchStatus x.1.8.1.11 Data type: EditStatus

[0233] The EditStatus contains the attributes defined in table x.1.8.1.11-1. Table x.1.8.1.11-1: Definition of type EditStatus x.1.8.1.12 Data type: EditResult

[0234] The EditResult contains the attributes defined in table x.1.8.1.12-1. Table x.1.8.1.12-1: Definition of type EditResult x.1.8.2 Simple datatypes and enumerations x.1.8.2.1 Introduction

[0235] This clause defines simple data types and enumerations that can be referenced from data structures defined in the previous clauses. x.1.8.2.2 Simple data types

[0236] None. x.1.8.2.3 Enumerations x.1.8.2.3.1 Enumeration: ApplyMode

[0237] Table x.1.8.2.3.1-1: Enumeration type of Operation x.1.8.2.3.3 Enumeration: PlanActivationState Table x.1.8.2.3.1-1: Enumeration type of PlanActivationState x.1.8.2.4 Media Types

[0238] New O-RAN media types are described in this section x.1.8.2.4.1 Media Type application / o-ran-yang-patch+json Table x.1.8.2.4.1-1: application / o-ran-yang-patch+json Media Type

[0239] x.1.8.2.3 Enumerations x.1.8.2.3.1 Enumeration: ApplyMode

[0240] Table x.1.8.2.3.1-1: Enumeration type of Operation x.1.8.2.3.3 Enumeration: PlanActivationState Table x.1.8.2.3.1-1: Enumeration type of PlanActivationState

[0241] Annex C (informative): examples

[0242] C.l Async Configuration API

[0243] C.1.1 Create Plan-activation-job

[0244] The example of Create Plan-activation-job is as below

[0245] Create plan-activation-job

[0246] # Create plan-activation-job

[0247] POST {root} / ran-oam-cm / vl / plan-management / plan-activation-jobs HTTP / 1.1

[0248] Host: example.org

[0249] Content-Type: application / json

[0250] Accept : application / json,application / problem+json

[0251] "jobld" : "myjob-111,

[0252] "name" : "job-xyz",

[0253] "description" : "optimize the Dubin area network",

[0254] "enableFallback" : "TRUE",

[0255] "planDescriptor" : {

[0256] "activationMode" : "BEST EFFORT", # Execute in a best effort manner trying all operations

[0257] "additionalProperties" : {

[0258] "operator-property-1" : "prop- value-1",

[0259] "operator-property-2" : "prop-value-2"

[0260] "configuration": {

[0261] "patch" : {

[0262] "patch-id" : "NRCellDU-changes-001",

[0263] "edit" : [

[0264] "operation": "create",

[0265] "edit-id" : "opld-001", "comment" : "This changes is a result of network tuning"

[0266] "target" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp-common- mecontext:MeContext=Dublin-l / 3gpp-common-managed- element: ManagedElement=Dublin- l / 3gpp-nr-nrm-gnbdufunction: GNBDUFunction=l " ,

[0267] "value": {

[0268] "NRCellDU": [

[0269] "id": "1",

[0270] "attributes": {

[0271] "typelSinglePanelRiRestriction": "15",

[0272] "ailgDIPrbLoadLevel": "0",

[0273] "drxOnDurationTimer" : "ONDURATIONTIMER 8MS", "trsResourceShifting" : "DEACTIVATED",

[0274] "ulStartCrb": "0",

[0275] ]

[0276] "operation": "merge",

[0277] "edit-id" : "opld-002",

[0278] "target" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp-common- mecontext:MeContext=Dublin-l / 3gpp-common-managed- element:ManagedElement=Dublin-l / 3gpp-nr-nrm- gnbdufunction:GNBDUFunction=l / 3gpp-nr-nrm-nrcelldu:NRCellDU=2",

[0279] "value": {

[0280] "attributes": {

[0281] "trsResourceShifting" : "ACTIVATED"

[0282] "operation": "merge", "edit-id" : "opld-003", "target" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp-common- mecontext:MeContext=Dublin-l / 3gpp-common-managed- element:ManagedElement=Dublin-l / 3gpp-nr-nrm- gnbdufunction:GNBDUFunction=l / 3gpp-nr-nrm-nrcelldu:NRCellDU=3",

[0283] "value": {

[0284] "attributes": {

[0285] "trsResourceShifting" : "ACTIVATED"

[0286] ]

[0287] Response :

[0288] "jobld": "myjob-111",

[0289] "name" : "job-xyz",

[0290] "description" : "optimize the Dubin area network",

[0291] "enableFallback" : "TRUE",

[0292] "state" : "RUNNING",

[0293] "Jinks" : {

[0294] "self1: { "href1: "{apiRoot} / ran-oam-cm / vl / plan-management / plan- activation-j obs / myj ob- 111"}

[0295] "planDescriptor" : { "{apiRoot} / ran-oam-cm / vl / plan-management / plan- activation-j obs / myj ob-111 / plan-descriptor"},

[0296] "results": { "href1: "{apiRoot} / ran-oam-cm / vl / plan-management / plan- activation-j obs / myj ob-111 / results"},

[0297] "status": { "href1: "{apiRoot} / ran-oam-cm / vl / plan-management / plan- activation-j obs / myj ob-111 / status"} ,

[0298] "fallbackjob": { "href1: " {apiRoot} / ran-oam-cm / vl / plan-management / plan- activation-j obs / myj ob-111 / fallback-job" }

[0299] C.1.2 GET Plan-descriptor Response :

[0300] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob- 111 / plan-descriptor

[0301] "id" : "myjob-111",

[0302] "activationMode" : "BEST EFFORT", # Execute in a best effort manner trying all operations

[0303] "additionaProperties" : {

[0304] "operator-property-1" : "prop- value-1",

[0305] "operator-property-2" : "prop-value-2"

[0306] "configurationContentType" : "application / o-ran-patch+json"

[0307] "configuration": {

[0308] "patch" : {

[0309] "patch-id" : "NRCellDU-changes-001",

[0310] "edit" : [

[0311] "operation": "create",

[0312] "edit-id" : "opld-001",

[0313] "target" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp-common- mecontext:MeContext=Dublin-l / 3gpp-common-managed- element: ManagedElement=Dublin- l / 3gpp-nr-nrm-gnbdufunction: GNBDUFunction=l " ,

[0314] "value": {

[0315] "NRCellDU": [

[0316] "id": "1",

[0317] "attributes": {

[0318] "typelSinglePanelRiRestriction": "15",

[0319] "ailgDIPrbLoadLevel": "0",

[0320] "drxOnDurationTimer" : "ONDURATIONTIMER 8MS",

[0321] "trsResourceShifting" : "DEACTIVATED",

[0322] "ulStartCrb": "0",

[0323] "operation": "merge",

[0324] "edit-id" : "opld-002",

[0325] "target" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp-common- mecontext:MeContext=Dublin-l / 3gpp-common-managed- element:ManagedElement=Dublin-l / 3gpp-nr-nrm- gnbdufunction:GNBDUFunction=l / 3gpp-nr-nrm-nrcelldu:NRCellDU=2",

[0326] "value": {

[0327] "attributes": {

[0328] "trsResourceShifting" : "ACTIVATED"

[0329] "operation": "merge",

[0330] "edit-id" : "opld-003",

[0331] "comment" : “Change to NRCellDU using a 'relaxed' target",

[0332] "target" : " / SubNetwork=Irl / MeContext=Dublin-

[0333] 1 / ManagedElement=Dublin- l / GNBDUFunction= l / NRCellDU=3 ", "value": {

[0334] "attributes": {

[0335] "trsResourceShifting" : "ACTIVATED"

[0336] C.1.3 GET Plan-activation-job status (complete)

[0337] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob-

[0338] 111 / status "state": "COMPLETE",

[0339] "startTime": "2024-12-02T13:16:54.088Z",

[0340] "finishTime": "2024-12-02T13:16:58.088Z",

[0341] "executionSummary": {

[0342] "totalOperations": 3,

[0343] "totalExecuted": 3,

[0344] "successfulOperations": 2,

[0345] "fail edOperations": 1

[0346] C.1.4 GET Plan-activation-job results (all successful)

[0347] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob- l / results?verbose=true

[0348] "executionSummary" : {

[0349] "totalOperations" : 3,

[0350] "totalExecuted" : 3

[0351] "successfulOperations" : 3,

[0352] "failedOperations" : 0,

[0353] # If all edits applied successfully without errors, the server MUST

[0354] # return a "status" message with a "global-status" choice set to

[0355] # "ok" (as specified in RFC 8072).

[0356] "patch-status" : {

[0357] "patch-id" : "NRCellDU-changes-001",

[0358] "ok" : [null],

[0359] "edit-status" : {

[0360] "edit" : [

[0361] "edit-id" : "opld-001",

[0362] "ok" : [null] edit-id" : "opld-002", "ok" : [null]

[0363] "edit-id" : "opld-003",

[0364] "ok" : [null]

[0365] ]

[0366] C.1.5 GET Plan-activati on-job results (with failure)

[0367] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob-

[0368] 11 l / results?verbose=true

[0369] "executionSummary" : {

[0370] "totalOperations" : 3,

[0371] "totalExecuted" : 3

[0372] "successfulOperations" : 2,

[0373] "failedOperations" : 1,

[0374] "status" : {

[0375] "patch-id" : "NRCellDU-changes-001",

[0376] "edit-status" : {

[0377] "edit" : [

[0378] "edit-id" : "opld-001",

[0379] "errors" : {

[0380] "error" : [

[0381] "error-type": "application",

[0382] "error-tag": "data-exists",

[0383] "error-path": " / _3gpp-common- subnetwork:SubNetwork[id=Irl] / 3gpp-common-mecontext:MeContext[id=Dublin- l] / 3gpp-common-managed-element:ManagedElement[id=Dublin-l] / 3gpp-nr-nrm- gnbdufunction:GNBDUFunction[id=l] / 3gpp-nr-nrm-nrcelldu:NRCellDU[id=l]",

[0384] "error-message":

[0385] "Data already exists; cannot be created"

[0386] ]

[0387] "edit-id" : "opld-002",

[0388] "ok" : [null]

[0389] "edit-id" : "opld-003", "ok" : [null]

[0390] ]

[0391] C.1.6 GET Plan-activation-job (O-RU)

[0392] POST {root} / ran-oam-cm / vl / plan-management / plan-activation-jobs HTTP / 1.1

[0393] Host: example.org

[0394] Content-Type: application / json

[0395] Accept : application / json,application / problem+json

[0396] "jobld" : "myjob-111,

[0397] "name" : "job-xyz",

[0398] "description" : "Configure delay in 0-RU",

[0399] "enableFallback" : "TRUE",

[0400] "planDescriptor" : {

[0401] "activationMode" : "BEST EFFORT", # Execute in a best effort manner trying all operations "additionaProperties" : {

[0402] "operator-property-1" : "prop- value-1",

[0403] "operator-property-2" : "prop-value-2"

[0404] "configuration": {

[0405] "patch-id": "delay -management-patch",

[0406] "edit": [

[0407] "edit-id": "editl",

[0408] "operation": "merge",

[0409] "target": "" / _3gpp-common-subnetwork:SubNetwork[id=Irl] / 3gpp-common- mecontext:MeContext[id=Dublin-4] / o-ran-delay: delay-management",

[0410] "value": {

[0411] "o-ran-delay: delay -management": {

[0412] "bandwidth-scs-delay-state": [

[0413] "bandwidth": 20000,

[0414] "subcarrier-spacing": 30000,

[0415] "ru-delay-profile": {

[0416] "t2a-min-up" : 100000,

[0417] "t2a-max-up": 200000,

[0418] "t2a-min-cp-dl": 50000,

[0419] "t2a-max-cp-dl": 150000,

[0420] "tcp-adv-dl": 75000,

[0421] "ta3-min": 80000,

[0422] "ta3-max": 180000,

[0423] "t2a-min-cp-ul": 60000,

[0424] "t2a-max-cp-ul": 160000

[0425] ],

[0426] "adaptive-delay-configuration" : {

[0427] "bandwidth-scs-delay-state": [ "bandwidth": 20000,

[0428] "subcarrier-spacing": 30000,

[0429] "o-du-delay-profile": {

[0430] "tla-max-up": 250000,

[0431] "tx-max": 300000,

[0432] "ta4-max": 350000,

[0433] "rx-max": 400000,

[0434] "tla-max-cp-dl": 200000

[0435] ],

[0436] "transport-delay": {

[0437] "tl2-min": 50000,

[0438] "tl2-max": 100000,

[0439] "t34-min": 55000,

[0440] "t34-max": 110000

[0441] "beam-context-gap-period": 1000

[0442] C.1.6.1 Read results successful basic

[0443] GET { apiRoot} / ran-oam-cm / v 1 / plan-management / plan-activation-j obs / myj ob- 111 / results executionsummary" : { "totalOperations" : 3, "totalExecuted" : 3 "successfulOperations" : 3,

[0444] "failedOperations" : 0,

[0445] "status" : {

[0446] "patch-id" : "NRCellDU-changes-001",

[0447] "ok" : [null]

[0448] C.1.6.2 Read results successful verbose

[0449] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob- l / results?verbose=true

[0450] "executionSummary" : {

[0451] "totalOperations" : 3,

[0452] "totalExecuted" : 3

[0453] "successfulOperations" : 3,

[0454] "failedOperations" : 0,

[0455] "status" : {

[0456] "patch-id" : "NRCellDU-changes-001",

[0457] "ok" : [null]

[0458] "edit-status" : {

[0459] "edit" : [

[0460] "edit-id" : "opld-001",

[0461] "ok" : [null]

[0462] "edit-id" : "opld-002", "ok" : [null]

[0463] "edit-id" : "opld-003", "ok" : [null]

[0464] ]

[0465] C.l.6.3 Read results with failure basic

[0466] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob- 111 / results

[0467] "executionSummary" : {

[0468] "totalOperations" : 3,

[0469] "totalExecuted" : 3

[0470] "successfulOperations" : 2,

[0471] "failedOperations" : 1,

[0472] "status" : {

[0473] "patch-id" : "NRCellDU-changes-001",

[0474] "edit-status" : {

[0475] "edit" : [

[0476] "edit-id" : "opld-001",

[0477] "errors" : {

[0478] "error" : [

[0479] "error-type": "application",

[0480] "error-tag": "data-exists",

[0481] "error-path" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp- common-mecontext:MeContext=Dublin-l / 3gpp-common-managed- element:ManagedElement=Dublin-l] / 3gpp-nr-nrm- gnbdufunction:GNBDUFunction=l / 3gpp-nr-nrm-nrcelldu:NRCellDU=l",

[0482] "error-message":

[0483] "Data already exists; cannot be created"

[0484] ]

[0485] "additionalProperties" : {

[0486] "some-additional properties" : "some-additional-property-value",

[0487] ]

[0488] C.1.6.4 Read results with Failure verbose

[0489] GET {apiRoot} / ran-oam-cm / vl / plan-management / plan-activation-jobs / myjob-

[0490] 11 l / results?verbose=true

[0491] "executionSummary" : {

[0492] "totalOperations" : 3,

[0493] "totalExecuted" : 3

[0494] "successfulOperations" : 2,

[0495] "failedOperations" : 1,

[0496] "status" : {

[0497] "patch-id" : "NRCellDU-changes-001",

[0498] "edit-status" : {

[0499] "edit" : [

[0500] "edit-id" : "opld-001",

[0501] "errors" : {

[0502] "error" : [

[0503] "error-type": "application",

[0504] "error-tag": "data-exists",

[0505] "error-path" : " / _3gpp-common-subnetwork: SubNetwork=Irl / 3gpp- common-mecontext:MeContext=Dublin-l / 3gpp-common-managed- element:ManagedElement=Dublin-l] / 3gpp-nr-nrm- gnbdufunction:GNBDUFunction=l / 3gpp-nr-nrm-nrcelldu:NRCellDU=l",

[0506] "error-message":

[0507] "Data already exists; cannot be created"

[0508] ]

[0509] "additionalProperties" : {

[0510] "some-additional properties" : "some-additional-property-value",

[0511] "edit-id" : "opld-002",

[0512] "ok" : [null]

[0513] "edit-id" : "opld-003",

[0514] "ok" : [null]

[0515] ]

[0516] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that may be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0517] Some embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0518] These computer program instructions may also be stored in a computer readable memory or storage medium that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0519] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0520] It is to be understood that the functions / acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0521] Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0522] Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments may be combined in any way and / or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

[0523] It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings without departing from the scope of the following claims.

Claims

What is claimed is:

1. A network node (16) comprising processing circuitry (68) configured to: implement a write policy for each of a plurality of async requests made by an rAPP; and associate the write policy with a corresponding async request and with a patch operation.

2. The network node (16) of Claim 1, wherein the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback.

3. The network node (16) of any of Claims 1 and 2, wherein a write policy relates to terminating a process when a failure occurs.

4. The network node (16) of any of Claims 1-3, wherein a write policy relates to rolling back a process when a failure occurs.

5. The network node (16) of any of Claims 1-4, wherein the processing circuitry (68) is configured to simulate a write operation.

6. The network node (16) of any of Claims 1-5, wherein the write policy relates to a condition for performing or not performing a write operation.

7. The network node (16) of any of Claims 1-6, wherein the write policy relates to a schedule of write operations.

8. The network node (16) of any of Claims 1-7, wherein the write policy relates to an approval requirement for execution of a write operation.

9. The network node (16) of any of Claims 1-8, wherein the processing circuitry (68) is configured to authorize a request that includes the patch operation.

10. The network node (16) of Claim 9, wherein the processing circuitry (68) is configured to perform radio access network (RAN) operation and management (0AM) related functions when the request is validated.

11. The network node (16) of any of Claims 1-10, wherein the network node (16) is configured to communicate with a wireless device (WD) in an Open Radio Access Network (O-RAN).

12. A method implemented in a network node (16), the method comprising: implementing (SI 16) a write policy for each of a plurality of async requests made by an rAPP; and associating (SI 18) the write policy with a corresponding async request with a patch operation.

13. The method of Claim 12, wherein the async request is configured to include at least one of a priority, a retry, validations, conditions and rollback.

14. The method of any of Claims 12 and 13, wherein a write policy relates to terminating a process when a failure occurs.

15. The method of any of Claims 12-14, wherein a write policy relates to rolling back a process when a failure occurs.

16. The method of any of Claims 12-15, further comprising simulating a write operation.

17. The method of any of Claims 12-16, wherein the write policy relates to a condition for performing or not performing a write operation.

18. The method of any of Claims 12-17, wherein the write policy relates to a schedule of write operations.

19. The method of any of Claims 12-18, wherein the write policy relates to an approval requirement for execution of a write operation.

20. The method of any of Claims 12-19, further comprising authorizing a request that includes the patch operation.

21. The method of Claim 20, further comprising performing radio access network (RAN) operation and management (0AM) related functions when the request is validated.

22. The method of any of Claims 12-21, further comprising communicating with a wireless device (WD) in an Open Radio Access Network (0-RAN).

Images