Data transfer management in networks

A dual storage system for O-RAN networks manages data transfer efficiently by using separate read and write storage, reducing interface overload and improving scalability by minimizing signaling and latency.

JP7883070B2Active Publication Date: 2026-06-30RAKUTEN SYMPHONY INC

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
RAKUTEN SYMPHONY INC
Filing Date
2023-12-04
Publication Date
2026-06-30

AI Technical Summary

Technical Problem

Existing data transfer methods in O-RAN networks face issues with unnecessary signaling load, bandwidth overhead, and latency due to simultaneous read and write requests from multiple rApps, leading to potential interface overload and delays.

Method used

Implementing a dual storage system comprising read and write storage devices to manage data transfer independently, allowing rApps to use read storage for data retrieval and write storage for updates, thereby reducing direct communication with network elements.

Benefits of technology

This approach minimizes signaling load, bandwidth overhead, and latency, enhancing network scalability by enabling efficient data transfer without overwhelming the interfaces.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007883070000001
    Figure 0007883070000001
  • Figure 0007883070000002
    Figure 0007883070000002
  • Figure 0007883070000003
    Figure 0007883070000003
Patent Text Reader

Abstract

An apparatus, method, and device for automatically managing data transfer in a network are provided. According to an embodiment, the apparatus may be configured to receive, from an rApp or other SMO function, at least one of a request to obtain configuration data of an O-RAN network element and a request to update the configuration of the O-RAN network element, and in response to receiving the request to obtain the configuration data of the O-RAN network element, to obtain the configuration data using a read storage, and in response to receiving the request to update the configuration of the O-RAN network element, to update the configuration of the O-RAN network element using a write storage different from the read storage based on the configuration provided in the request, wherein the write storage and the read storage may be included in the apparatus.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application claims the priority of U.S. Provisional Patent Application No. 63 / 448,893, filed on February 28, 2023, entitled "A DUAL CACHE AND ASYNCHRONIZED APPROACH FOR SMO / NON-RT RIC CM READ AND WRITE CONFIGURATION DATA OPERATIONS", the disclosure of which is incorporated herein by reference in its entirety.

[0002] Systems, methods, and computer programs consistent with exemplary embodiments of the present disclosure relate to telecommunications networks, and more particularly, to the management of data transfer in telecommunications networks.

Background Art

[0003] A radio access network (RAN) is an important component in a telecommunications system for connecting end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various O-RAN network elements (NEs) that connect end-users to the core network. Conventionally, the hardware and / or software of a particular RAN is vendor-specific.

[0004] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the types of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on a particular service, the NEs may be virtualized in software form (e.g., virtual machine (VM)-based) or in physical hardware form (e.g., non-VM-based).

[0005] To this end, O-RAN divides the RAN functions into centralized units (CUs), distributed units (DUs), and radio units (RUs). A CU may be a logical node hosting the RAN's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. A DU may be a logical node hosting the RAN's Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers. A RU may be a physical node that converts radio signals from antennas into digital signals that can be transmitted to the DU via fronthaul. These entities may be developed by different vendors because they share open protocols and interfaces.

[0006] Figure 1 shows an O-RAN architecture in related technologies. In an O-RAN architecture, RAN functionality can be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC can be a software-defined component that implements modular applications to facilitate the multi-vendor operability required in an O-RAN system, and to automate and optimize RAN operations. As shown in Figure 1, RICs can be divided into two types: non-real-time RICs (Non-RT RICs) and near-real-time RICs (Near-RT RICs).

[0007] Non-RT RIC120 may be a control point in a non-real-time control loop and may operate on a timescale of more than one second within the Service Management and Orchestration (SMO) framework110. Its functionality may be implemented via a modular application called rApp, which may include: providing policy-based guidance and enrichment across the A1 interface, which is an interface enabling communication between non-RT RIC and quasi-RT RIC; performing data analysis; training and inference of artificial intelligence / machine learning (AI / ML) for RAN optimization; and / or recommending configuration management actions via the O1 interface, which may be an interface connecting the SMO to RAN managed elements (e.g., quasi-RT RIC130, O-RAN Centralized Unit (O-CU)140, 150, O-RAN Distributed Unit (O-DU)170, etc.).

[0008] The quasi-RT RIC130 can operate on a timescale between 10 milliseconds and 1 second and can be coupled via the E2 interface to the O-DU170, the O-CU (divided into the O-CU control plane (O-CU-CP)140 and the O-CU user plane (O-CU-UP)150), and the open evolved node B (O-eNB)160. The quasi-RT RIC130 can use the E2 interface to control underlying RAN elements (E2 nodes / network functions (NFs)) via a quasi-real-time control loop. The quasi-RT RIC130 can monitor, suspend / stop, override, and control the E2 nodes (O-CU140, 150, O-DU170, and O-eNB160) via policies. For example, the quasi-RT RIC130 may set policy parameters regarding the activated functions of the E2 nodes. Furthermore, the quasi-RT RIC130 can host xApps to implement features such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security.

[0009] Here, O-CU-CP140 and O-CU-UP150 may be coupled to each other via the E1 interface, and may be coupled to O-DU170 via the F1-c interface and F1-u interface, respectively. Furthermore, O-RU180 may be coupled to O-DU170 via the Open Fronthaul (OF) Control (C) plane, User (U) plane, Synchronization (S) plane, and Management (M) plane, and may be coupled to SMO110 via the OF M plane.

[0010] The two types of RICs work together to optimize O-RAN. For example, a non-RT RIC120 can provide policies, data, and AI / ML models that are implemented and used by a quasi-RT RIC130 for RAN optimization, and the quasi-RT RIC130 can return policy feedback (i.e., how the policies set by the non-RT RIC120 are performing).

[0011] As described above, the non-RT RIC120 may be located within the SMO framework 110, which manages and orchestrates RAN elements. Specifically, the SMO110 can manage and orchestrate what is called an O-RAN Cloud (O-Cloud) 190. The O-Cloud 190 may be a collection of RICs, O-CUs and O-DUs, supporting software components (e.g., operating systems and runtime environments), and physical RAN nodes hosting the SMO110 itself. In other words, the SMO110 can manage the O-Cloud 190 from within. An O2 interface may be an interface between the SMO110 and the O-Cloud 190 in which it resides. Through the O2 interface, the SMO110 can provide infrastructure management services (IMS) and deployment management services (DMS). [Overview of the project] [Problems that the invention aims to solve]

[0012] The exemplary embodiments of this disclosure automatically manage data transfer using at least two storage devices. Thus, the exemplary embodiments of this disclosure enable data transfer within a network while avoiding unnecessary signaling load, bandwidth overhead, and latency, thereby improving network scalability. [Means for solving the problem]

[0013] According to the embodiment, a device is provided. The device may be configured to receive at least one of the following from rApp or other SMO functions: a request to obtain configuration data for an O-RAN network element and a request to update the configuration of an O-RAN network element; to obtain the configuration data using read storage in response to receiving a request to obtain configuration data for an O-RAN network element; and to update the configuration of an O-RAN network element using write storage different from the read storage, based on the configuration provided in the request, in response to receiving a request to update the configuration of an O-RAN network element, wherein the write storage and read storage may be provided in the device.

[0014] According to the embodiment, an apparatus is provided. The apparatus may be configured to receive at least one of the following from rApp or other SMO functions: a request to obtain configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; in response to receiving a request to obtain configuration data of an O-RAN network element, it obtains the configuration data using a first digital twin; and in response to receiving a request to update the configuration of an O-RAN network element, it updates the configuration of the O-RAN network element using a second digital twin different from the first digital twin, based on the configuration provided in the request, wherein the first and second digital twins may be provided in the apparatus, and the first and second digital twins may include complete digital replicas of the O-RAN network element.

[0015] According to embodiments, a method is provided. The method may include receiving at least one of a request from rApp or other SMO function to retrieve configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; in response to receiving a request to retrieve configuration data of an O-RAN network element, retrieving the configuration data using read storage; and in response to receiving a request to update the configuration of an O-RAN network element, updating the configuration of the O-RAN network element using write storage different from the read storage, based on the configuration provided in the request, wherein the write storage and read storage may be provided in the device performing the method.

[0016] According to embodiments, a method is provided. The method may include receiving at least one of a request from rApp or other SMO function to obtain configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; obtaining configuration data using a first digital twin in response to receiving a request to obtain configuration data of an O-RAN network element; and updating the configuration of an O-RAN network element using a second digital twin different from the first digital twin, based on the configuration provided in the request, in response to receiving a request to update the configuration of an O-RAN network element, wherein the first and second digital twins may be provided in an apparatus performing the method, and the first and second digital twins may include complete digital replicas of the O-RAN network element.

[0017] According to the embodiment, a non-temporary computer-readable recording medium is provided. The non-temporary computer-readable recording medium can record instructions executable by a device, and the instructions cause the device to perform a method including receiving at least one of a request from rApp or other SMO function to obtain configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; in response to receiving the request to obtain configuration data of an O-RAN network element, obtaining the configuration data using read storage; and in response to receiving the request to update the configuration of an O-RAN network element, updating the configuration of the O-RAN network element using write storage different from the read storage, based on the configuration provided in the request, wherein the device may be provided with write storage and read storage.

[0018] Additional embodiments are partially described below, partially evident from the description, or may be realized by implementing the embodiments presented in this disclosure.

[0019] The features, advantages, and importance of exemplary embodiments of this disclosure will be described below with reference to the attached drawings, where similar reference numerals indicate similar elements. [Brief explanation of the drawing]

[0020] [Figure 1] This shows the O-RAN architecture in related technologies.

[0021] [Figure 2] This document outlines the architecture of service management and orchestration frameworks in related technologies.

[0022] [Figure 3A] This shows an exemplary data flow in a system for managing data transfer in a network, according to one or more embodiments.

[0023] [Figure 3B]Illustrates an exemplary flow of data in a system for managing data transfer in a network according to one or more embodiments.

[0024] [Figure 4] Shows a flowchart of an exemplary method for managing data transfer according to one or more embodiments.

[0025] [Figure 5] Shows a block diagram of an exemplary interaction between an rApp or other SMO function and RAN OAM-related functions according to one or more embodiments.

[0026] [Figure 6A] Illustrates an exemplary flow of data in a system for managing data transfer in a network according to one or more embodiments.

[0027] [Figure 6B] Illustrates an exemplary flow of data in a system for managing data transfer in a network according to one or more embodiments.

[0028] [Figure 7] Shows a flowchart of an exemplary method for obtaining configuration data using a read storage according to one or more embodiments.

[0029] [Figure 8A] Discloses a call flow for an rApp to obtain configuration data using a read storage within a RAN OAM-related function according to one or more embodiments.

[0030] [Figure 8B] Discloses a call flow for other SMO functions (SMO Functions: SMOFs) to obtain configuration data using a read storage within a RAN OAM-related function according to one or more embodiments.

[0031] [Figure 9A] This discloses a call flow for rApp to retrieve configuration data without using read storage.

[0032] [Figure 9B] Other SMO functions (SMOFs) disclose call flows for retrieving configuration data without using read storage.

[0033] [Figure 10] A flowchart shows an exemplary method for updating the configuration of O-RAN network elements using write storage, according to one or more embodiments.

[0034] [Figure 11A] One or more embodiments disclose a call flow for an rApp to update the configuration of an O-RAN network element using write storage.

[0035] [Figure 11B] One or more embodiments disclose a call flow for other SMO functions (SMOFs) to update the configuration of O-RAN network elements using write storage.

[0036] [Figure 12A] This discloses a call flow for rApp to update the configuration of O-RAN network elements without using write storage.

[0037] [Figure 12B] Other SMO functions (SMOFs) disclose call flows for updating the configuration of O-RAN network elements without using write storage.

[0038] [Figure 13] This specification shows a diagram of an exemplary environment in which the system and / or method described herein can be implemented. [Modes for carrying out the invention]

[0039] A detailed description of exemplary embodiments follows with reference to the accompanying drawings. Identical reference numerals in different drawings may identify the same or similar elements.

[0040] The foregoing disclosures provide examples and explanations, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures, or such modifications and variations may be derived from the practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into another embodiment (or one or more features of another embodiment), or combined with another embodiment (or one or more features of another embodiment). In addition, it should be understood that in the descriptions of operation provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

[0041] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to any specific implementation. Therefore, the operation and behavior of the systems and / or methods have been described herein without reference to any specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0042] Even if certain combinations of features are disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically disclosed herein.

[0043] Any element, action, or command used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, the term “one” or similar language is used. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be non-restrictive. Additionally, the phrase “based on” is intended to mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0044] Figure 2 shows the architecture of the service management and orchestration framework in the related technologies. As shown in Figure 2, the service management and orchestration framework (SMO) 210 can include a non-real-time RIC (Non-RT RIC) 220 and RAN operation and maintenance (OAM) related functions 240. The non-RT RIC 220 provides a software framework for running applications, rApps.

[0045] rApp230 may refer to a software application configured to run on a non-RT RIC220. RAN OAM-related functions240 may refer to functions within SMO210 related to operation and maintenance. One or more O-RAN network elements250 may refer to O-RAN network elements within the O-RAN architecture. For example, one or more O-RAN network elements250 may include an O-RAN centralized unit control plane (O-CU-CP), an O-RAN centralized unit user plane (O-CU-UP), an O-RAN distributed unit (O-DU), and the like.

[0046] One or more rApp230 may be configured to perform read operations (data retrieval operations) and write operations (data update operations) for Configuration Management (CM) configuration data to or from one or more O-RAN network elements 250. For example, one or more rApp230 can read / write CM configuration data to or from one or more O-RAN network elements 250 via the R1 Service API of the R1 Service 250, which exposes the Configuration Management (CM) service provided by the RAN OAM-related functions 240 within the SMO210.

[0047] In related technologies, one or more rApps 230 can send requests to RAN OAM-related functions 240 via the R1 interface to perform read and write operations, and the RAN OAM-related functions 240 can simply forward requests directly to one or more O-RAN network elements 250 via the O1 or Open Fronthaul (O-FH) interface to retrieve (read) or modify (write) Managed Object Instance (MOI) attributes from / to one or more O-RAN network elements 250 as requested.

[0048] In this regard, the above-mentioned methods for performing read and write operations in related technologies may have the following problems: The RAN OAM-related functions 240 within the SMO210 simply and transparently transfer information to and from the rApp, so one or more rApps 230 essentially have direct access to one or more O-RAN network elements 250 for each MOI read and write request using a stateless direct mediation method. Accordingly, as the system scales up and the number of rApps and O-RAN network elements increases, many rApps may attempt to read and write CM configuration data simultaneously, which can easily overload the R1, O1, and O-FH interfaces, potentially resulting in significant message drops and unacceptable signaling delays.

[0049] Accordingly, the systems, methods, devices, etc., provided in exemplary embodiments of this disclosure automatically manage data transfer using at least two storage devices.

[0050] According to the embodiment, in order to perform a read operation to obtain configuration data for an O-RAN network element, the system may use read storage to obtain the configuration data. Furthermore, in order to perform a write operation to update the configuration of an O-RAN network element, the system may use write storage, which is different from the read storage, to update the configuration of the O-RAN network element based on the configuration provided in the request.

[0051] Ultimately, exemplary embodiments of this disclosure use at least two storage devices to automatically manage data transfer, thereby enabling data to be transferred within a network while avoiding unnecessary signaling load, bandwidth overhead, and latency, and improving network scalability.

[0052] The features, advantages, and importance of the exemplary embodiments described above are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure.

[0053] Further descriptions of the features, components, configuration, operation, and embodiments of the threshold adjustment system of the present disclosure, according to one or more embodiments, are provided below.

[0054] System Architecture Figure 3A shows an exemplary data flow in a system 300A for managing data transfer in a network, according to one or more embodiments.

[0055] As shown in Figure 3A, system 300A may include RAN OAM-related functions 320, including SMO360, non-RT RIC350, R1 service 340, rApp310, read storage 322 and write storage 324, and O-RAN network elements 330.

[0056] In step 1, in order to perform a write operation to update the O-RAN network element 330, rApp310 can send configuration data (hereinafter referred to as "write data") indicating that the O-RAN network element 330 should be updated based on the R1 configuration change write operation to the RAN OAM-related function 320, and the write data may be stored in the write storage 324.

[0057] In step 2, once the write data is received and stored in the write storage 324, the RAN OAM-related function 320 retrieves the write data and updates the O-RAN network element 330 based on the write data stored in the write storage 324 so that the write data is taken into the O-RAN network element 330.

[0058] The above process using the write storage 324 allows the rApp 310 to simply provide the write data to the RAN OAM-related function 320 via the R1 service API of the R1 service 340 without having to wait for the update to complete, and allows other tasks to be freely performed while the O-RAN network element 330 is being updated based on the write data while the write data is being taken in by the O-RAN network element 330. As a result, the above process prevents a situation where too many rApps or other SMO functions are held simultaneously waiting for their respective update requests to complete, which could lead to platform overload in the event of a signaling spike.

[0059] In step 3, when the O-RAN network element 330 is updated based on the written data, the RAN OAM-related function 320 can update the read storage 322 so that the data stored in the read storage 322 correctly reflects the data in the updated O-RAN network element 330. In this regard, since the written data (which was the basis for updating the O-RAN network element 330) has already been stored in the write storage 324, the RAN OAM-related function 320 can update the read storage 322 based on the written data stored in the write storage 324.

[0060] The above process allows the read storage 322 to be updated so that the data stored in the read storage 322 correctly reflects the configuration within the O-RAN network element 330, without the need to communicate directly with the O-RAN network element 330 and retrieve the configuration again from the O-RAN network element 330. This avoids the unnecessary signaling load, bandwidth overhead, and delay associated with direct communication with the O-RAN network element 330. As a result, the above process reduces the processing and memory load on the SMO and RIC platforms and improves network scalability.

[0061] According to one embodiment, in addition to step 3, in step 3.5, the RAN OAM-related function 320 may further update the read storage 322 if there are any configuration updates within the O-RAN network element by another entity outside the SMO 360, in order to ensure that the data stored in the read storage 322 correctly reflects the configuration within the O-RAN network element 330. According to one embodiment, the RAN OAM-related function 320 may update the read storage 322 by periodically checking the latest configuration within the O-RAN network element 330, or by being notified by the O-RAN network element when there are configuration changes by another entity outside the SMO.

[0062] In step 4, in order to perform a read operation to acquire data from the O-RAN network element 330, the rApp 310 can acquire data (hereinafter referred to as "read data") from the read storage 322 in the RAN OAM-related function 320 based on the R1 configuration data read operation.

[0063] The above process using read storage 322 allows rApp 310 to obtain read data from RAN OAM-related functions 320 without needing to communicate with O-RAN network elements 330 and fetch data directly from them. This avoids the unnecessary signaling load, bandwidth overhead, and delay associated with communicating with O-RAN network elements 330. As a result, the above process reduces processing and memory load on the SMO and RIC platforms and improves network scalability.

[0064] According to one embodiment, in step 4.5, if the read data that rApp310 intends to acquire is not stored in the read storage 322, rApp310 can directly acquire the read data from the O-RAN network element 330.

[0065] According to one embodiment, when an rApp attempts to retrieve current configuration data from an O-RAN network element based on an R1 configuration data read operation, the RAN OAM-related function determines whether the read data is provided from read storage within the RAN OAM-related function or is newly fetched from the O-RAN network element via the O1 / O-FH interface by the RAN OAM-related function. An rApp that sends an R1 configuration data read request simply retrieves the current configuration data in the O-RAN network element after sending the R1 configuration read request, regardless of whether the configuration data is obtained from read storage within the RAN OAM-related function or retrieved from the O-RAN network element by the RAN OAM-related function via the O1 / O-FH interface.

[0066] From the above, it can be understood that the above process involving two separate storage devices (read storage 322 and write storage 324) allows for the acquisition of read data from the O-RAN network element 330 and the transmission of write data to the network element 330 without interfering with each other.

[0067] For example, the first rApp can send write data to the write storage 324 during step 1. However, the second rApp can retrieve read data from the read storage 322 during step 4 before the read storage is updated during steps 2 and 3 based on the write data.

[0068] In this regard, the read data acquired by the second rApp is data stored in the read storage 322, not data stored in the write storage 324. Therefore, the read data acquired by the second rApp is not write data that has not yet been applied to the O-RAN network element 330, but rather data that correctly reflects the actual configuration data within the (currently active) O-RAN network element 330.

[0069] Furthermore, since the written data is sent to and stored in the write storage 324 rather than the read storage 322, the written data will not inadvertently overwrite the data in the read storage 322 (which correctly reflects the data in the O-RAN network element 330). Accordingly, it will be understood that rApp310 may not have access rights to write (send) data to the read storage 322.

[0070] It should be understood that the configuration shown in Figure 3A is simplified for illustrative purposes and does not limit the scope of this disclosure. Specifically, the number of rApp310s and O-RAN network elements 330s can be any number. Furthermore, the number labels for steps 1-4 are for labeling purposes only and do not limit the order. For example, an rApp310 may first perform a read operation and step 4, and then perform a write operation and step 1. In addition, the arrows depicted in Figure 3A do not represent actual O-RAN interfaces (virtual / physical) between different elements in the figure, but rather represent the flow of configuration data, i.e., read / write data, across different elements in the figure. Actual O-RAN interfaces are represented by dotted boxes surrounding the O-RAN interface names.

[0071] Furthermore, although the examples described in this disclosure are provided in relation to non-RT RICs, they are also applicable to quasi-RT RICs, in which case the R1 interface becomes the quasi-RT RIC API and the O1 / O-FH interface becomes the E2 interface.

[0072] Figure 3B shows an exemplary data flow in System 300B for managing data transfer in a network, according to one or more embodiments.

[0073] As shown in Figure 3B, the configuration of system 300B may be the same as the configuration of system 300A in Figure 3A, and operations related to read and write data are performed by other SMO functions 370 via the RAN OAM-related service API / RAN NF CM / PM / FM service API instead of rApp310 via the R1 interface / R1 service API and R1 service 340.

[0074] Accordingly, it will be understood that other SMO functions 370 can perform write operations to update the O-RAN network elements 330, or read operations to retrieve data from the O-RAN network elements 330, in a similar manner to rApp 310.

[0075] Exemplary actions for managing data transfers in this disclosure The following describes some exemplary operations of this disclosure with reference to Figures 4 to 12.

[0076] Figure 4 shows a flowchart of an exemplary method 400 for managing data transfer according to one or more embodiments. One or more operations in method 400 may be performed by at least one processor.

[0077] As shown in Figure 4, in operation S410, at least one processor may be configured to receive at least one of the following: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element. It will be understood that the request to retrieve configuration data for an O-RAN network element may refer to a request to perform a read operation. Similarly, it will be understood that the request to update the configuration of an O-RAN network element may refer to a request to perform a write operation. According to the embodiment, the request to retrieve configuration data for an O-RAN network element and the request to update the configuration may be received from rApp or other SMO functions.

[0078] According to one embodiment, the configuration data may include configuration data of an O-RAN network element that rApp or another SMO function attempts to acquire for a read operation. For example, the configuration data may include CM configuration data of the O-RAN network element that rApp attempts to read. According to another embodiment, a request to update the configuration of an O-RAN network element may include the configuration that forms the basis for rApp or another SMO function attempting to update the O-RAN network element for a write operation. For example, this request may include CM configuration data that rApp attempts to write to the O-RAN network element. The method then proceeds to operation S420.

[0079] In operation S420, in response to receiving a request to acquire configuration data for an O-RAN network element, at least one processor may be configured to acquire the configuration data using read storage. According to one embodiment, the read storage may be included in the SMO. According to another embodiment, the read storage may be configured to store data of an O-RAN network element to be acquired for a read operation. For example, the read storage may be configured to store CM configuration data of an O-RAN network element that can be acquired for a read operation. An example of an operation to acquire configuration data using read storage will be described later with reference to Figure 7. The method then proceeds to operation S430.

[0080] In operation S430, in response to receiving a request to update the configuration of an O-RAN network element, at least one processor may be configured to update the configuration of the O-RAN network element using write storage based on the configuration provided in the request. According to one embodiment, the write storage may be included in the SMO. According to one embodiment, the write storage may be different from the read storage. According to one embodiment, the write storage may be configured to store data on which the O-RAN network element is updated for a write operation. For example, the write storage may be configured to store CM configuration data to be written to the O-RAN network element. An example of an operation for updating the configuration of an O-RAN network element using write storage based on the configuration provided in the request will be described later with reference to Figure 10.

[0081] Method 400 may terminate after performing operations S420 and / or S430. Alternatively, Method 400 may return to operation S410, so that at least one processor is configured to repeatedly perform receiving at least one of the requests (in operation S410), acquiring configuration data (in operation S420), and / or updating the configuration of the O-RAN network element (in operation S430) for at least a predetermined period of time. For example, at least one processor may continuously (or periodically) receive requests to acquire configuration data and then resume receiving at least one of the requests (operation S410) and acquiring configuration data (operation S420).

[0082] Furthermore, for example, at least one processor can receive a request to acquire configuration data (in operation S410) and acquire the configuration data (in operation S420). Then, at least one processor can receive a request to update the configuration of the O-RAN network element (in operation S410) and update the configuration of the O-RAN network element (in operation S430).

[0083] According to the embodiment, in addition to receiving a request to acquire configuration data for an O-RAN network element, at least one processor may be configured to receive another request to acquire configuration data for another O-RAN network element. For example, at least one processor may be configured to receive a request to acquire configuration data for a first O-RAN network element and a request to acquire configuration data for a second O-RAN network element different from the first O-RAN network element. Similarly, according to the embodiment, in addition to receiving a request to update the configuration of an O-RAN network element, at least one processor may be configured to receive another request to update the configuration of another O-RAN network element. For example, at least one processor may be configured to receive a request to update the configuration of a first O-RAN network element and a request to update the configuration of a second O-RAN network element different from the first O-RAN network element. The above requests may be received from the same or different rApp or other SMO functions.

[0084] According to one embodiment, two or more of the above requests to different O-RAN network elements may be bundled into a single Application Programming Interface (API) call.

[0085] For example, as shown in Figure 5, which illustrates an exemplary block diagram of interaction between rApp or other SMO functions and RAN OAM-related functions, according to one or more embodiments, a request to retrieve configuration data for a first O-RAN network element (request 1) and a request to retrieve configuration data for a second O-RAN network element (request 2) may be bundled into a single application programming interface (API) call (API call 1). Similarly, a request to update the configuration of a first O-RAN network element (request 3) and a request to update the configuration of a second O-RAN network element (request 4) may be bundled into a single application programming interface (API) call (API call 2).

[0086] The above configuration allows for further reduction of the signaling load on the interface between rApp or other SMO functions and RAN OAM-related functions. For example, the signaling load on the R1 interface between rApp and non-RT RIC can be further reduced.

[0087] According to one embodiment, the read and write storage may be configured to store all CM configuration data (managed object instance (MOI) attributes) of all O-RAN network elements in the network. According to another embodiment, the read and write storage may be configured to store at least the CM configuration data (MOI attributes) most frequently accessed by rApps in the network in order to reduce size and improve efficiency. According to another embodiment, the read and write storage may be replaced by digital twins (DTs), which are complete digital replicas of the O-RAN network element, including not only the O-RAN network element configuration but also all other running states in the protocol stack of the O-RAN network element / function. In this case, the read storage is replaced by DT1, which replicates the current state of the O-RAN network element, and the write storage is replaced by DT2, which represents the future state of the O-RAN network element in a digital domain assuming a given configuration change is applied.

[0088] For example, see Figure 6A, which shows another exemplary flow of data in system 600A for managing data transfer in a network according to one or more embodiments. As shown in Figure 6A, the configuration and steps related to system 600A may be the same as those related to system 300A described above in relation to Figure 3A. However, the read storage 322 is replaced here by DT1 622, which is a replica of O-RAN network element 630 for configuration data read operations. Similarly, the write storage 324 is replaced here by DT2 624, which represents a future state of O-RAN network element 630 (assuming a given configuration is applied) for configuration change write operations. DT1 622, which represents a replica of the current state of O-RAN network element 630, is still updated to represent the true current configuration of O-RAN network element 630 based on steps 3 and 3.5 described above in relation to Figure 3A. The configuration within DT2 624, which represents the future state of the O-RAN network element 630, is still incorporated into the O-RAN network element 630 based on step 2 described above in relation to Figure 3A.

[0089] Figure 6B shows an exemplary data flow in System 600B for managing data transfer in a network, according to one or more embodiments.

[0090] As shown in Figure 6B, the configuration of system 600B may be the same as that of system 600A in Figure 6A, and operations related to read and write data are performed by other SMO functions 670 via the RAN OAM related service API / RAN NF CM / PM / FM service API instead of rApp610 via the R1 interface / R1 service API and R1 service 640.

[0091] Accordingly, it will be understood that other SMO functions 670 can perform write operations to update the O-RAN network elements 630, or read operations to retrieve data from the O-RAN network elements 630, in a similar manner to rApp 610.

[0092] Exemplary operation of retrieving configuration data using read storage in this disclosure Figure 7 shows a flowchart of an exemplary method 700 for acquiring configuration data using read storage, according to one or more embodiments. One or more operations of method 700 may be part of operations S410 and S420 of method 400 and may be performed by at least one processor.

[0093] As shown in Figure 7, in operation S710, at least one processor may be configured to receive a request to retrieve configuration data for an O-RAN network element. It will be understood that the request to retrieve configuration data for an O-RAN network element may be received from an rApp or other SMO function in a manner similar to that described above in relation to method 400. According to the embodiment, the read storage may be synchronized with the network before operation S710 so that the read storage correctly reflects the current configuration of the O-RAN network element. The method then proceeds to operation S720.

[0094] In operation S720, at least one processor may be configured to determine whether configuration data is stored in read storage. Accordingly, based on the determination that configuration data is stored in read storage, at least one processor may determine that it is not necessary to retrieve configuration data from the O-RAN network element, and the method proceeds to operation S730. On the other hand, based on the determination that configuration data is not stored in read storage, at least one processor may determine that it is necessary to retrieve configuration data from the O-RAN network element, and the method proceeds to operation S740.

[0095] In operation S730, at least one processor may be configured to send configuration data from read storage to rApp or other SMO functions. For example, at least one processor may be configured to send CM configuration data from read storage to rApp via the R1 interface without needing to acquire CM configuration data from O-RAN network elements via the O1 or O-FH interface.

[0096] In operation S740, at least one processor may be configured to acquire configuration data from an O-RAN network element and send it to rApp or another SMO function. For example, at least one processor may be configured to acquire CM configuration data from an O-RAN network element via the O1 or O-FH interface and send the CM configuration data to rApp via the R1 interface.

[0097] Accordingly, the above process for acquiring configuration data using read storage allows rApp or other SMO functions to acquire configuration data without needing to communicate with O-RAN network elements, thereby avoiding unnecessary signaling load, bandwidth overhead, and delay associated with communicating with O-RAN network elements. As a result, the above process reduces processing and memory load on the SMO and RIC platforms and improves network scalability.

[0098] O-RAN interface message flow for reading configuration data Figure 8A discloses a call flow for rApp to retrieve configuration data using read storage within RAN OAM-related functions, in one or more embodiments.

[0099] As shown in Figure 8A, the RAN-OAM related function 802 may first synchronize the read storage with the O-RAN network element in order to obtain the current MOI attribute (i.e., CM configuration data) of the network element 803. To synchronize the read storage with the network, the RAN-OAM related function 802 can communicate with the O-RAN network element 803 via the O1 interface using the network management protocol NETCONF read-config, edit-config create, and replace or delete. Once the current MOI attribute of the O-RAN network element 803 is obtained, the RAN-OAM related function 802 may store the retrieved configuration data in the read storage so that the configuration data of the O-RAN network element 803 stored in the read storage correctly reflects the current configuration of the O-RAN network element 803.

[0100] Next, the RAN-OAM related function 802 may receive a configuration read request from rApp 801 requesting to obtain (read) the configuration of the O-RAN network element 803. The configuration read request may include data such as rAppid and queryCriteria related to the request and is received via the R1 interface.

[0101] In response, the RAN-OAM related function 802 can perform authentication (authorization:AuthZ) and validation on the received request.

[0102] Once the received request is authenticated and validated, the RAN-OAM related function 802 can determine whether the configuration data for the requested O-RAN network element 803 is stored in the read storage.

[0103] If the requested configuration data for the O-RAN network element 803 is stored (exists) in read storage, the RAN-OAM related function 802 may send a configuration read response to rApp 801 that provides the requested configuration data for the target O-RAN network element 803. The configuration read response may include data such as ConfigurationData related to the request and may be sent via the R1 interface.

[0104] If the requested configuration data for the target O-RAN network element 803 is not stored in the read storage, the RAN-OAM related function 802 can retrieve the requested configuration of the O-RAN network element 803 from the O-RAN network element 803. To retrieve the requested configuration data for the O-RAN network element 803 from the O-RAN network element 803, the RAN-OAM related function 802 can communicate with the O-RAN network element 803 via the O1 interface using the network management protocol NETCONF read-config. Once the requested configuration data for the O-RAN network element 803 has been retrieved from the O-RAN network element 803, the RAN-OAM related function 802 can send a Read Configuration Response to rApp801 in the same manner as described above.

[0105] Figure 8B discloses a call flow in one or more embodiments for other SMO functions (SMOFs) to retrieve configuration data using read storage within RAN OAM-related functions.

[0106] As shown in Figure 8B, the call flow shown in Figure 8B may be the same as the call flow shown in Figure 8A, and the operations related to obtaining configuration data are performed by another SMOF804 via the RAN NF CM service API instead of rApp801 via the R1 interface.

[0107] Accordingly, it will be understood that other SMOF804s can perform read operations to retrieve configuration data from O-RAN network elements 803 in a similar manner to rApp801.

[0108] Figure 9A discloses a call flow for rApp to retrieve configuration data without using read storage.

[0109] As shown in Figure 9A, the disclosed call flow for retrieving configuration data without using read storage (in certain implementations of RAN OAM-related functions, read storage may not exist at all) may be similar to the call flow for retrieving configuration data using read storage described above in relation to Figure 8A.

[0110] However, as shown in Figure 9A, in this case, when the RAN-OAM related function 902 receives, authenticates, and validates the Read Configuration Request, the RAN-OAM related function 902 directly obtains the requested configuration data of the target O-RAN network element 903 from the O-RAN network element 903 and sends a Read Configuration Response to rApp 901 using the configuration data retrieved from the O-RAN network element.

[0111] In the process described above, when rApp901 attempts to retrieve the requested configuration data for O-RAN network element 903, the requested configuration data may need to be fetched from the O1 interface by RAN OAM-related functions each time. It will be understood that this will increase the signaling load, bandwidth overhead, and latency as the network scales up and more rApps and O-RAN network elements operate within the network.

[0112] Figure 9B discloses the call flow for other SMO functions (SMOFs) to retrieve configuration data without using read storage.

[0113] As shown in Figure 9B, the call flow shown in Figure 9B may be the same as the call flow shown in Figure 9A, and the operations related to obtaining configuration data are performed by another SMOF904 via the RAN NF CM service API instead of rApp901 via the R1 interface.

[0114] Accordingly, it will be understood that other SMOF904s can perform read operations to retrieve configuration data from O-RAN network elements 903 in a similar manner to rApp901.

[0115] Exemplary operation of updating the configuration of O-RAN network elements using the write storage of this disclosure. Figure 10 shows a flowchart of an exemplary method 1000 for updating the configuration of an O-RAN network element using write storage, according to one or more embodiments. One or more operations of method 1000 may be part of operations S410 and S430 of method 400 and may be performed by at least one processor.

[0116] As shown in Figure 10, in operation S1010, at least one processor may be configured to receive a request to update the configuration of an O-RAN network element. It will be understood that the request to update the configuration of an O-RAN network element may be received from an rApp or other SMO function in a manner similar to that described above in relation to method 400. The method then proceeds to operation S1020.

[0117] In operation S1020, at least one processor may be configured to receive a configuration. According to one embodiment, a request received from an rApp or other SMO function may include a configuration on which the configuration of an O-RAN network element is updated. For example, CM configuration data may be received from an rApp via the R1 interface. The method then proceeds to operation S1030.

[0118] In operation S1030, at least one processor may be configured to store the received configuration in write storage. The method then proceeds to operation S1040.

[0119] In operation S1040, at least one processor may be configured to send a first write response to the rApp or other SMO function. According to one embodiment, at least one processor may be configured to send the first write response to the rApp or other SMO function after storing the received configuration in write storage. According to another embodiment, the first write response may be configured to notify the rApp or other SMO function that the received configuration has been stored in write storage. The method then proceeds to operation S1050.

[0120] In operation S1050, at least one processor may be configured to update the configuration of an O-RAN network element based on a received configuration stored in write storage. For example, the CM configuration data of an O-RAN network element may be updated based on CM configuration data stored in write storage via the O1 or O-FH interface (i.e., CM configuration data received from rApp) so that the CM configuration data stored in write storage is written to the O-RAN network element via the O1 or O-FH interface.

[0121] As a further example, to update the configuration of an O-RAN network element based on a received configuration (write the received configuration to the O-RAN network element), at least one processor may perform a ModifyMOI operation on the O1 or O-FH interface. Once the ModifyMOI operation is complete and the O-RAN network element has been updated, at least one processor may receive a ModifyMOI response from the O-RAN network element indicating that the configuration change has been successfully received and applied to the O-RAN network element. The method then proceeds to operation S1060.

[0122] In operation S1060, at least one processor may be configured to send a second write notification to rApp or other SMO function. According to one embodiment, at least one processor may be configured to send a second write notification to rApp or other SMO function after the configuration of the O-RAN network element has been updated based on the received configuration stored in write storage. For example, at least one processor may be configured to send a second write notification to rApp after receiving a ModifyMOI response from the O-RAN network element.

[0123] According to one embodiment, the second write notification may be configured to notify rApp or other SMO function that the configuration of the O-RAN network element has been updated based on the received configuration stored in the write storage. The method then proceeds to operation S1070.

[0124] In operation S1070, at least one processor may be configured to update the read storage. According to one embodiment, at least one processor may be configured to update the read storage based on a received configuration stored in the write storage. For example, the CM configuration data of an O-RAN network element stored in the read storage may be updated based on the CM configuration data stored in the write storage (the configuration of the O-RAN network element has already been updated based on it) so that the CM configuration data stored in the read storage is updated to correctly reflect the updated O-RAN network element without the need to communicate with the O-RAN network element via the O1 and O-FH interfaces.

[0125] According to one embodiment, at least one processor may be configured to update read storage based on the received configuration stored in write storage after the configuration of the O-RAN network element has been updated based on the received configuration stored in write storage. For example, at least one processor may be configured to update read storage based on the received configuration stored in write storage after receiving a ModifyMOI response from the O-RAN network element.

[0126] According to one embodiment, at least one processor may be configured to further update the read storage based on updated O-RAN network elements. According to another embodiment, the read storage may be periodically updated based on updated O-RAN network elements to ensure that the data stored in the read storage correctly reflects the data in the O-RAN network elements. For example, the read storage may be periodically updated based on updated O-RAN network elements via the O1 or O-FH interface.

[0127] Accordingly, the above process for updating O-RAN network elements using write storage allows rApp or other SMO functions to simply send their configurations without having to wait for the update to complete, and to freely perform other tasks while the configuration of the O-RAN network elements is being updated based on the sent configuration. As a result, the above process prevents a situation where too many rApp or other SMO functions are held simultaneously, waiting for their respective update requests to complete, which could lead to platform overload in signaling spike scenarios.

[0128] Furthermore, the process described above, which updates the read storage based on the configuration stored in the write storage, enables the data stored in the read storage (used for read operations) to correctly reflect the data within the O-RAN network elements without direct communication with the O-RAN network elements, thereby avoiding the unnecessary signaling load, bandwidth overhead, and delay associated with direct communication with the O-RAN network elements. As a result, the process described above further reduces the processing and memory load on the SMO and RIC platforms and improves network scalability.

[0129] Furthermore, the above process of retrieving configuration data and updating the configuration of O-RAN network elements using two separate storage devices allows for data retrieval and transmission to / from O-RAN network elements without interfering with each other.

[0130] O-RAN interface message flow for writing configuration data Figure 11A discloses a call flow for an rApp to update the configuration of an O-RAN network element using write storage, according to one or more embodiments.

[0131] As shown in Figure 11A, the RAN-OAM related function 1102 may receive a configuration change write request from rApp 1101 requesting to update (write) the configuration attributes of the target O-RAN network element 1103. This request may include the rAppid and configuration change information related to the request and may be received via the R1 interface.

[0132] In response, the RAN-OAM related function 1102 can perform authentication (AuthZ) and validation on the received request.

[0133] Once the received request is authenticated (authorized) and validated, the RAN-OAM related function 1102 can modify the write storage so that the configuration attributes of the O-RAN network element 1103 to be updated are stored in the write storage.

[0134] Once the write storage is modified, the RAN-OAM related function 1102 may send a configuration change write response to rApp1101 indicating that the request has been accepted and the configuration change has been stored in the write storage, but the actual process of updating the O-RAN network element 1103 is still pending. The configuration change write response may include a return code 202:ACCEPTED in the case of HTTP / REST API operation.

[0135] Next, the RAN-OAM related function 1102 performs the network management protocol NETCONF edit-config create, replace, or delete, and rpc-reply <ok>or<rpc.error> By using the O1 interface to communicate with the O-RAN network element 803, the O-RAN network element 1103 can be updated based on stored configuration attributes. Accordingly, the configuration / MOI attributes of the network element 1103 can be modified (updated) based on the configuration attributes stored in the write storage.

[0136] When the O-RAN network element 1103 is updated, the RAN-OAM related function 1102 may send a configuration change notification to rApp 1101 indicating that the O-RAN network element 1103 has been successfully updated and that the provided configuration changes are effective on the network. The configuration change notification may include a status indicating that the operation on the O1 interface is complete, along with result information indicating which configuration attributes have been successfully configured in the O-RAN network element 1103, which is not configured in the partial success scenario.

[0137] Figure 11B discloses a call flow in one or more embodiments for other SMO functions (SMOFs) to update the configuration of an O-RAN network element using write storage.

[0138] As shown in Figure 11B, the call flow shown in Figure 11B may be the same as the call flow shown in Figure 11A, and the operations related to updating the configuration of O-RAN network elements are performed by other SMOF1104 via the RAN NF CM service API instead of rApp1101 via the R1 interface.

[0139] Accordingly, it will be understood that other SMOF1104s can perform write operations to update the configuration of the O-RAN network element 1103 in a similar manner to rApp1101.

[0140] Figure 12A discloses the call flow for rApp to update the configuration of O-RAN network elements without using write storage.

[0141] As shown in Figure 12A, the call flow for updating the configuration of the O-RAN network element 1203 without using write storage may be similar to the call flow for updating the configuration of the O-RAN network element using write storage, as described above in relation to Figure 11A. However, as shown in Figure 12A, in this case, once the RAN-OAM related function 1202 receives, authenticates, and validates the request for a configuration change write, the RAN-OAM related function 1202 may directly update the O-RAN network element 1203 based on the received configuration attributes. Once the O-RAN network element 1203 is updated, the RAN-OAM related function 1202 can send a configuration change write response to rApp 1201 indicating that the O-RAN network element 1203 has been successfully updated and that the provided configuration attributes are valid on the network. The configuration change write response may include a response code 200:OK in the case of HTTP / REST API operation.

[0142] In the process described above, it will be understood that the RIC may block rApp1201 and hold the context of the configuration write request until all O-RAN network elements 1203 are updated. Furthermore, rApp1201 may not be aware of the update process of O-RAN network elements 1203 until the update is complete and it receives a configuration change write response. Accordingly, as the network scales up and more rApps and O-RAN network elements operate within the network, the RIC may block and hold too many rApps and contexts simultaneously while waiting for the update process to complete on the O1 and O-FH interfaces, which could lead to platform overload and signaling spikes.

[0143] Figure 12B discloses the call flow for other SMO functions (SMOFs) to update the configuration of O-RAN network elements without using write storage.

[0144] As shown in Figure 12B, the call flow shown in Figure 12B may be similar to the call flow shown in Figure 12A, and the operations related to updating the configuration of O-RAN network elements are performed by other SMOF1204 via the RAN NF CM service API instead of rApp1201 via the R1 interface.

[0145] Accordingly, it will be understood that other SMOF1204s can perform write operations to update the configuration of O-RAN network element 1203 in a similar manner to rApp1201.

[0146] Exemplary Implementation Environment Figure 13 shows a diagram of an exemplary environment 1300 in which the system and / or method described herein may be implemented. As shown in Figure 13, the environment 1300 may include a device 1310, a platform 1320, and a network 1330. The devices in environment 1300 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In some embodiments, any of the functions and operations described with reference to Figures 3 to 12 above may be performed by any combination of the elements shown in Figure 13.

[0147] According to embodiments, the system described herein can be stored, hosted, or deployed on a cloud computing platform 1320. In this regard, device 1310 may include devices, systems, equipment, etc., that are used by users (e.g., users of the marketing team, users of the network planning team, etc.) to access the system. In this case, device 1310 may include one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 1320.

[0148] Platform 1320 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 1320 may include a cloud server or a group of cloud servers. In some implementations, Platform 1320 may be designed to be modular so that certain software components can be swapped in or swapped out as needed. Thus, Platform 1320 may be easily and / or quickly reconfigured for different uses.

[0149] In some implementations, as shown in the figures, platform 1320 may be hosted in a cloud computing environment 1322. In particular, the implementations described herein describe platform 1320 as being hosted within the cloud computing environment 1322, but in some implementations, platform 1320 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment), or it may be partially cloud-based.

[0150] The cloud computing environment 1322 includes an environment that hosts platform 1320. The cloud computing environment 1322 can provide services such as compute, software, data access, and storage, which do not require the end user's (e.g., user device 1310) knowledge of the physical location and configuration of the system and / or device hosting platform 1320. As shown in the figure, the cloud computing environment 1322 may include a group of computing resources 1324 (collectively referred to as “computing resources 1324” and individually referred to as “computing resources 1324”).

[0151] Computing resource 1324 includes one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resource 1324 can host platform 1320. Cloud resources may include computing instances running within computing resource 1324, storage devices located within computing resource 1324, data transfer devices provided by computing resource 1324, and so on. In some implementations, computing resource 1324 can communicate with other computing resources 1324 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0152] As further shown in Figure 13, the computing resource 1324 includes a group of cloud resources such as one or more applications ("APPs") 1324-1, one or more virtual machines ("VMs") 1324-2, virtualized storage ("VSs") 1324-3, and one or more hypervisors ("HYPs") 1324-4. While the current exemplary embodiment relates to virtualized networking functionality, it is understood that one or more other embodiments may be implemented in at least one of the following: containers, cloud-native services, one or more container platforms, etc. For example, in one or more other exemplary embodiments, any of the above components may be software-based components deployed or hosted on a server cluster, such as a hybrid cloud server or data center server. Software-based components may be containerized, and the containerized O-RAN network elements may be deployed and controlled by one or more machines called “nodes” that operate or run and are addressable. In this regard, a server cluster may include at least one master node and several worker nodes, where the master node(s) control and manage the associated set of worker nodes.

[0153] Application 1324-1 includes one or more software applications that may be provided to or accessed by the user device 1310. Application 1324-1 eliminates the need to install and run software applications on the user device 1310. For example, Application 1324-1 may include software related to platform 1320 and / or any other software that can be provided via the cloud computing environment 1322. In some implementations, one application 1324-1 may send and receive information to and from one or more other applications 1324-1 via a virtual machine 1324-2.

[0154] A virtual machine 1324-2 includes a machine (e.g., a computer) in the form of a software implementation that runs programs like a physical machine. Depending on its application and the degree to which the virtual machine 1324-2 corresponds to an actual machine, the virtual machine 1324-2 may be either a system virtual machine or a process virtual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can run a single program and can support a single process. In some implementations, the virtual machine 1324-2 may run on behalf of a user (e.g., a user device 1310) and may manage the infrastructure of a cloud computing environment 1322, such as data management, synchronization, or long-duration data transfer.

[0155] Virtualized storage 1324-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of the computing resource 1324. In some implementations, in the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to extracting (or separating) logical storage from physical storage so that the storage system can be accessed regardless of the physical storage or heterogeneous structure. Separation may give the storage system administrator flexibility in how the administrator manages the storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This can enable optimization of storage usage, server consolidation, and / or performance for non-disruptive file migration.

[0156] Hypervisor 1324-4 can provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as computing resource 1324. Hypervisor 1324-4 can provide a virtual operating platform to guest operating systems and can manage the execution of guest operating systems. Multiple instances of various operating systems can share virtualized hardware resources.

[0157] Network 1330 may include one or more wired and / or wireless networks. For example, Network 1330 may include cellular networks (e.g., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LAN), wide area networks (WAN), metropolitan area networks (MAN), telephone networks (e.g., public switched telephone networks (PSTN)), private networks, ad hoc networks, intranets, the Internet, fiber optic-based networks, etc., and / or combinations of these or other types of networks.

[0158] The number and arrangement of devices and networks shown in Figure 13 are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements compared to those shown in Figure 13. Furthermore, two or more devices shown in Figure 13 may be implemented within a single device, or a single device shown in Figure 13 may be implemented as multiple distributed devices. In addition, or instead, a set of devices in environment 1300 (e.g., one or more devices) may perform one or more functions that are described as being performed by another set of devices in environment 1300.

[0159] Various embodiments The foregoing disclosures are provided as examples and explanations, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures, or such modifications and variations may be derived from the practice of implementations.

[0160] Some embodiments may relate to systems, methods, and / or computer-readable media in integration at any possible level of technical detail. Furthermore, one or more of the above-described components may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or include at least one processor). The computer-readable medium may include computer-readable non-temporary storage media (or more) having computer-readable program instructions for causing a processor to perform an operation.

[0161] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punched cards or grooved raised structures on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage media used herein should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0162] The computer-readable program instructions described herein may be downloaded from computer-readable storage media to each computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network, transfers the computer-readable program instructions, and stores them in computer-readable storage media within each computing / processing device.

[0163] The computer-readable program code / instructions for performing an operation may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. Computer-readable program instructions can run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by personalizing the electronic circuit using state information of computer-readable program instructions in order to perform an action or operation.

[0164] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine such that instructions executed by the processor of the computer or other programmable data processing device form means for implementing functions / operations specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can be instructed to function in a particular manner, thereby including a product in which the computer-readable storage medium internally storing the instructions includes instructions that implement modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0165] Computer-readable program instructions may also be instructions that are loaded into a computer, another programmable data processing device, or another device so that the instructions executed on the computer, another programmable device, or other device implement a function / operation specified in one or more blocks of a flowchart and / or block diagram, thereby generating a computer implementation process by causing the computer, another programmable device, or other device to execute a series of operational steps.

[0166] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media in various embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice(s) module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function(s). Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in a different order than shown in the figures. For example, two consecutively shown blocks may actually be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or action, or a combination of dedicated hardware and computer instructions.

[0167] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0168] Various further embodiments and features of the embodiments of this disclosure can be defined by the following items. Item 1: A device that may be configured to receive at least one of the following from rApp or other SMO functions: a request to retrieve configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; in response to receiving a request to retrieve configuration data of an O-RAN network element, retrieve the configuration data using read storage; and in response to receiving a request to update the configuration of an O-RAN network element, update the configuration of the O-RAN network element using write storage different from the read storage, based on the configuration provided in the request, wherein the write storage and read storage may be provided in the device. Item 2: The device described in Item 1, which may be configured to retrieve configuration data using read storage by determining whether configuration data is stored in read storage; and, in response to determining that configuration data is stored in read storage, transmitting the configuration data from read storage to rApp or other SMO function. Item 3: The device described in Item 1 or Item 2, which may be configured to update the configuration of an O-RAN network element using write storage based on a configuration provided in a request, by receiving a configuration from rApp or other SMO function; storing the received configuration in write storage; and updating the configuration of the O-RAN network element based on the received configuration stored in write storage. Item 4: The apparatus described in Item 3, which may be further configured to update the configuration of an O-RAN network element using the write storage based on a configuration provided in the request, by updating the read storage based on the received configuration stored in the write storage, after the apparatus has updated the configuration of the O-RAN network element based on the received configuration stored in the write storage. Item 5: The device described in Item 3 or 4, which may be further configured to update the configuration of an O-RAN network element using write storage based on a configuration provided in a request, by sending a first response which may be configured to notify rApp or other SMO functions that the received configuration has been stored in write storage after the device has stored the received configuration in write storage; and sending a second notification which may be configured to notify rApp or other SMO functions that the configuration of the O-RAN network element has been updated based on the received configuration stored in write storage after the device has updated the configuration of the O-RAN network element based on the received configuration stored in write storage. Item 6: The device described in any one of items 1 through 5, wherein the O-RAN network element may be a first O-RAN network element; the device may be further configured to receive requests from rApp or other SMO functions to retrieve configuration data for a second O-RAN network element different from the first O-RAN network element; and the requests to retrieve configuration data for the first O-RAN network element and the requests to retrieve configuration data for the second O-RAN network element may be bundled into a single Application Programming Interface (API) call. Item 7: The apparatus described in any one of Items 1 to 6, wherein the O-RAN network element may be a first O-RAN network element; and the apparatus may be further configured to receive requests from rApp or other SMO functions to update the configuration of a second O-RAN network element different from the first O-RAN network element, based on a configuration provided in a request to update the configuration of the second O-RAN network element, and the requests to update the configuration of the first O-RAN network element and the requests to update the configuration of the second O-RAN network element may be bundled into a single Application Programming Interface (API) call. Item 8: A device that may be configured to receive at least one of the following from rApp or other SMO functions: a request to retrieve configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; in response to receiving a request to retrieve configuration data of an O-RAN network element, retrieve the configuration data using a first digital twin; and in response to receiving a request to update the configuration of an O-RAN network element, update the configuration of the O-RAN network element using a second digital twin different from the first digital twin, based on the configuration provided in the request, wherein the first digital twin and the second digital twin may be provided in the device, and the first digital twin and the second digital twin may include a complete digital replica of the O-RAN network element. Item 9: A method which may include receiving at least one of the following from rApp or other SMO functions: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; in response to receiving a request to retrieve configuration data for an O-RAN network element, retrieving the configuration data using read storage; and in response to receiving a request to update the configuration of an O-RAN network element, updating the configuration of the O-RAN network element using write storage different from the read storage, based on the configuration provided in the request, wherein the write storage and the read storage may be provided in the device performing the method. Item 10: The method of Item 9, which may include: retrieving configuration data using read storage; determining whether configuration data is stored in read storage; and, in response to determining that configuration data is stored in read storage, sending the configuration data from read storage to rApp or other SMO function. Item 11: Updating the configuration of an O-RAN network element using write storage based on a configuration provided in a request; the method described in Item 9 or Item 10, which may include: receiving a configuration from rApp or other SMO function; storing the received configuration in write storage; and updating the configuration of the O-RAN network element based on the received configuration stored in write storage. Item 12: The method of Item 11, further comprising updating the configuration of an O-RAN network element using write storage based on a configuration provided in a request, updating the configuration of the O-RAN network element based on a received configuration stored in write storage, and then updating read storage based on a received configuration stored in write storage. Item 13: Updating the configuration of an O-RAN network element using write storage based on a configuration provided in a request, further comprising: storing the received configuration in write storage, then sending a first response which may be configured to notify rApp or other SMO functions that the received configuration has been stored in write storage; updating the configuration of the O-RAN network element based on the received configuration stored in write storage, then sending a second notification which may be configured to notify rApp or other SMO functions that the configuration of the O-RAN network element has been updated based on the received configuration stored in write storage, the method described in Item 11 or Item 12. Item 14: The method of any one of Items 9 to 13, wherein the O-RAN network element may be a first O-RAN network element; the method may further include receiving a request from rApp or other SMO function to obtain configuration data for a second O-RAN network element different from the first O-RAN network element; and the requests to obtain configuration data for the first O-RAN network element and the requests to obtain configuration data for the second O-RAN network element may be bundled into a single Application Programming Interface (API) call. Item 15: The method of any one of Items 9 to 14, wherein the O-RAN network element may be a first O-RAN network element; the method may further include receiving a request from rApp or other SMO function to update the configuration of a second O-RAN network element, which is different from the first O-RAN network element, based on a configuration provided in a request to update the configuration of the second O-RAN network element; and the requests to update the configuration of the first O-RAN network element and the requests to update the configuration of the second O-RAN network element may be bundled into a single Application Programming Interface (API) call. Item 16: A method which may include receiving at least one of the following from rApp or other SMO functions: a request to obtain configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; in response to receiving a request to obtain configuration data for an O-RAN network element, obtaining the configuration data using a first digital twin; and in response to receiving a request to update the configuration of an O-RAN network element, updating the configuration of the O-RAN network element using a second digital twin different from the first digital twin, based on the configuration provided in the request, wherein the first digital twin and the second digital twin may be included in an apparatus performing the method, and the first digital twin and the second digital twin may include a complete digital replica of the O-RAN network element. Item 17: A non-temporary computer-readable recording medium on which instructions executable by a device are recorded, wherein the instructions cause the device to perform a method including: receiving at least one of the following from rApp or other SMO functions: a request to obtain configuration data of an O-RAN network element and a request to update the configuration of an O-RAN network element; obtaining the configuration data using read storage in response to receiving the request to obtain configuration data of an O-RAN network element; and updating the configuration of an O-RAN network element using write storage different from the read storage, based on the configuration provided in the request, in response to receiving the request to update the configuration of an O-RAN network element, wherein the write storage and read storage are provided in the device. Item 18: Using read storage to retrieve configuration data; determining whether configuration data is stored in read storage; and, in response to determining that configuration data is stored in read storage, transmitting the configuration data from read storage to rApp or other SMO function, the non-temporary computer-readable recording medium described in Item 17. Item 19: A non-temporary computer-readable recording medium as described in Item 17 or Item 18, which may include updating the configuration of an O-RAN network element using write storage based on a configuration provided in a request; receiving a configuration from rApp or other SMO function; storing the received configuration in write storage; and updating the configuration of an O-RAN network element based on the received configuration stored in write storage. Item 20: A non-temporary computer-readable recording medium as described in Item 19, wherein updating the configuration of an O-RAN network element using write storage based on a configuration provided in the request may further include updating the read storage based on the received configuration stored in the write storage after updating the configuration of the O-RAN network element based on a received configuration stored in the write storage.

[0169] In light of the above teachings, it can be seen that many modifications and variations of this disclosure are possible. It will be apparent that, within the scope of the appended clauses, this disclosure may be implemented in ways other than those specifically described herein.< / ok>

Claims

1. The system receives at least one of the following requests from rApp or other SMO functions: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; In response to receiving the request to obtain the configuration data of the O-RAN network element, the configuration data is obtained using read storage; and, A device configured to update the configuration of an O-RAN network element using a write storage different from the read storage, based on a configuration provided in the request, in response to receiving a request to update the configuration of the O-RAN network element, The write storage and the read storage are provided in the device. Device.

2. The aforementioned device Determine whether the configuration data is stored in the read storage; and, In response to determining that the configuration data is stored in the read storage, the configuration data is transmitted from the read storage to the rApp or other SMO function. The system is configured to acquire the configuration data using the aforementioned read storage. The apparatus according to claim 1.

3. The device receives the configuration from the rApp or other SMO function; The received configuration is stored in the write storage; and, By updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, Based on the configuration provided in the request, the configuration of the O-RAN network element is configured to update using the write storage. The apparatus according to claim 1.

4. The device updates the configuration of the O-RAN network element based on the received configuration stored in the write storage, and then updates the read storage based on the received configuration stored in the write storage, Based on the configuration provided in the above request, further configured to update the configuration of the O-RAN network element using the write storage, The apparatus according to claim 3.

5. The device, after storing the received configuration in the write storage, transmits a first response to the rApp or other SMO function, which is configured to notify the rApp or other SMO function that the received configuration has been stored in the write storage; and, After updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, a second notification is sent to the rApp or other SMO function, which is configured to notify the rApp or other SMO function that the configuration of the O-RAN network element has been updated based on the received configuration stored in the write storage, Based on the configuration provided in the above request, further configured to update the configuration of the O-RAN network element using the write storage, The apparatus according to claim 3.

6. The aforementioned O-RAN network element is the first O-RAN network element; The device is further configured to receive requests from rApp or other SMO functions to obtain configuration data for a second O-RAN network element different from the first O-RAN network element; and, The request to obtain the configuration data of the first O-RAN network element and the request to obtain the configuration data of the second O-RAN network element are bundled into a single application programming interface (API) call. The apparatus according to claim 1.

7. The aforementioned O-RAN network element is the first O-RAN network element; The device is further configured to receive the request from rApp or other SMO function to update the configuration of the second O-RAN network element, which is different from the configuration of the first O-RAN network element, based on the configuration provided in the request to update the configuration of the second O-RAN network element; and, The request to update the configuration of the first O-RAN network element and the request to update the configuration of the second O-RAN network element are bundled into a single application programming interface (API) call. The apparatus according to claim 1.

8. The system receives at least one of the following requests from rApp or other SMO functions: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; In response to receiving the request to acquire the configuration data of the O-RAN network element, the first digital twin is used to acquire the configuration data; and, A device configured to update the configuration of an O-RAN network element using a second digital twin different from the first digital twin, based on a configuration provided in the request, in response to receiving a request to update the configuration of the O-RAN network element, The first digital twin and the second digital twin are provided in the apparatus, The first digital twin and the second digital twin include complete digital replicas of the O-RAN network elements. Device.

9. Receiving at least one of the following requests from rApp or other SMO functions: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; In response to receiving the request to obtain the configuration data of the O-RAN network element, to obtain the configuration data using read storage; and, A method comprising, in response to receiving the request to update the configuration of the O-RAN network element, updating the configuration of the O-RAN network element using a write storage different from the read storage, based on the configuration provided in the request, The write storage and the read storage are provided in the device that performs the method. method.

10. The configuration data can be obtained using the aforementioned read storage: Determining whether the configuration data is stored in the read storage; and, This includes transmitting the configuration data from the read storage to the rApp or another SMO function in response to determining that the configuration data is stored in the read storage. The method according to claim 9.

11. Based on the configuration provided in the request, the configuration of the O-RAN network element may be updated using the write storage: Receiving the above configuration from the aforementioned rApp or other SMO function; The received configuration is stored in the write storage; and, This includes updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, The method according to claim 9.

12. Based on the configuration provided in the request, updating the configuration of the O-RAN network element using the write storage is: The further includes updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, and then updating the read storage based on the received configuration stored in the write storage, The method according to claim 11.

13. Based on the configuration provided in the request, the configuration of the O-RAN network element may be updated using the write storage: After storing the received configuration in the write storage, a first response is sent to the rApp or other SMO function, which is configured to notify the rApp or other SMO function that the received configuration has been stored in the write storage; and, The further includes updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, and then sending a second notification to the rApp or other SMO function that is configured to inform the rApp or other SMO function that the configuration of the O-RAN network element has been updated based on the received configuration stored in the write storage, The method according to claim 11.

14. The aforementioned O-RAN network element is the first O-RAN network element; The method further includes receiving a request from rApp or another SMO function to obtain configuration data for a second O-RAN network element different from the first O-RAN network element; and, The request to obtain the configuration data of the first O-RAN network element and the request to obtain the configuration data of the second O-RAN network element are bundled into a single application programming interface (API) call. The method according to claim 9.

15. The aforementioned O-RAN network element is the first O-RAN network element; The method further includes receiving the request from rApp or another SMO function to update the configuration of the second O-RAN network element, which is different from the configuration of the first O-RAN network element, based on the configuration provided in the request to update the configuration of the second O-RAN network element; and, The request to update the configuration of the first O-RAN network element and the request to update the configuration of the second O-RAN network element are bundled into a single application programming interface (API) call. The method according to claim 9.

16. Receiving at least one of the following requests from rApp or other SMO functions: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; In response to receiving the request to acquire the configuration data of the O-RAN network element, acquire the configuration data using the first digital twin; and, A method comprising: updating the configuration of the O-RAN network element using a second digital twin different from the first digital twin, based on a configuration provided in the request, in response to receiving the request to update the configuration of the O-RAN network element, The first digital twin and the second digital twin are provided in the apparatus for performing the method, The first digital twin and the second digital twin include complete digital replicas of the O-RAN network elements. method.

17. A computer program for causing one or more computers to perform a method performed by a device, wherein the method is: Receiving at least one of the following requests from rApp or other SMO functions: a request to retrieve configuration data for an O-RAN network element, and a request to update the configuration of an O-RAN network element; In response to receiving the request to obtain the configuration data of the O-RAN network element, to obtain the configuration data using read storage; and, In response to receiving the request to update the configuration of the O-RAN network element, the update of the configuration of the O-RAN network element using a write storage different from the read storage, based on the configuration provided in the request, includes: The write storage and the read storage are provided in the device. Computer program.

18. The configuration data can be obtained using the aforementioned read storage: Determining whether the configuration data is stored in the read storage; and, The process includes, in response to determining that the configuration data is stored in the read storage, transmitting the configuration data from the read storage to the rApp or another SMO function. The computer program according to claim 17.

19. Based on the configuration provided in the request, the configuration of the O-RAN network element may be updated using the write storage: Receiving the above configuration from the aforementioned rApp or other SMO function; The received configuration is stored in the write storage; and, This includes updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, The computer program according to claim 17.

20. Based on the configuration provided in the request, updating the configuration of the O-RAN network element using the write storage is: The further includes updating the configuration of the O-RAN network element based on the received configuration stored in the write storage, and then updating the read storage based on the received configuration stored in the write storage, The computer program according to claim 19.