Method for generating and distributing software binary for radio access network node, and apparatus for performing same

Abstract

Disclosed are a method for generating and distributing a software binary for a radio access network node, and an apparatus for performing same. The method according to an embodiment of the present disclosure may comprise the steps of: acquiring operation information and state information of a first base station; determining a compiling technique on the basis of the operation information of the first base station and the state information of the first base station; generating a first software binary for the first base station on the basis of the compiling technique; distributing the first software binary to the first base station; acquiring updated state information from the first base station; and determining whether to distribute a software binary, which is different from the first software binary, to the first base station, on the basis of the updated state information.

Description

Method for generating and distributing software binaries for wireless access network nodes and device for performing the same

[0001] The present disclosure relates to a method for generating a software binary for a wireless access network node and an apparatus for performing the same, and more specifically, to a method for generating and distributing a software binary for a wireless access network node and an apparatus for performing the same.

[0002] Conventionally, base stations providing wireless communication services were installed at cell sites as an integrated unit comprising a data processing unit or digital unit (or distributed unit, DU) and a radio unit or remote unit (or radio unit, RU). Conventional base stations were not suitable for deploying multiple cell sites as the number of users and traffic increased. To address this, a base station structure was developed in which the DU is concentrated in a single physical location, leaving only the RU at the cell site that transmits and receives wireless signals to and from actual terminals. In this case, the DU and RU can be connected via optical or coaxial cables. This base station structure is being standardized by the 3GPP (3rd Generation Partnership Project), and O-RAN (Open Radio Access Network), an open network standard applicable to 5G systems, is being researched.

[0003] A compiler can be a computer program that translates computer code written in a specific programming language into another programming language. Compilers can be used to translate source code from a high-level programming language into a low-level programming language, such as machine code or assembly language, in order to generate an executable program. Compilers can analyze source code, perform optimizations based on the analysis, and generate target code. To minimize the execution time, memory usage, storage capacity, and power consumption of the program generated by the compiler, compilers can employ various optimization techniques. Through optimized compilation, optimized semantic equivalent code can be generated for certain aspects or scenarios.

[0004] A method according to one embodiment of the present disclosure may include: acquiring operational information and status information of a first base station; determining a compiling technique based on the operational information of the first base station and the status information of the first base station; generating a first software binary for the first base station based on the compiling technique; distributing the first software binary to the first base station; acquiring updated status information from the first base station; and determining whether to distribute a software binary different from the first software binary to the first base station based on the updated status information.

[0005] An electronic device according to one embodiment of the present disclosure may include at least one processor comprising a processing circuit; and a memory comprising one or more storage media for storing one or more instructions. When the one or more instructions are executed individually or in combination by the at least one processor, the electronic device may: acquire operational information and status information of a first base station; determine a compiling technique based on the operational information of the first base station and the status information of the first base station; generate a first software binary for the first base station based on the compiling technique; distribute the first software binary to the first base station; acquire updated status information from the first base station; and determine whether to distribute a software binary different from the first software binary to the first base station based on the updated status information.

[0006] A recording medium according to one embodiment of the present disclosure may be a computer-readable recording medium having a program recorded thereon for performing any combination of the methods, steps, or operations provided in the present disclosure on a computer.

[0007] FIG. 1 illustrates a wireless access network according to one embodiment of the present disclosure.

[0008] FIG. 2 illustrates an open wireless access network according to one embodiment of the present disclosure.

[0009] FIG. 3 illustrates an exemplary block diagram of a binary warehouse according to one embodiment of the present disclosure.

[0010] FIG. 4 illustrates, by way of example, the distribution of software binaries for a base station according to one embodiment of the present disclosure.

[0011] FIG. 5 illustrates, in an exemplary manner, the generation of a software binary for a base station according to one embodiment of the present disclosure.

[0012] FIG. 6 exemplarily illustrates a flowchart of a method for distributing a first software binary to a first base station according to one embodiment of the present disclosure.

[0013] FIG. 7 illustrates an exemplary flowchart of a method for determining a compiling technique according to one embodiment of the present disclosure.

[0014] FIG. 8 illustrates an exemplary flowchart of a method for determining a compiling technique associated with logic for generating a PRACH (Physical Random Access Channel) signal according to one embodiment of the present disclosure.

[0015] FIG. 9 exemplarily illustrates a flowchart of a method for determining a compiling technique associated with Low Density Parity Check Code (LDPC) channel coding according to one embodiment of the present disclosure.

[0016] FIG. 10 illustrates an exemplary flowchart of a method for determining whether to distribute a software binary different from a first software binary to a first base station according to one embodiment of the present disclosure.

[0017] FIG. 11 illustrates an exemplary flowchart of a method for distributing a second software binary, which is different from a first software binary, to a first base station according to one embodiment of the present disclosure.

[0018] FIG. 12 illustrates an exemplary flowchart of a method for distributing a second software binary different from a first software binary to a first base station based on the software profile of a first base station according to one embodiment of the present disclosure.

[0019] FIG. 13 illustrates an exemplary flowchart of a method for distributing a second software binary different from a first software binary to a first base station based on the software profile of the first base station according to one embodiment of the present disclosure.

[0020] FIG. 14 illustrates an exemplary block diagram of a software binary warehouse according to one embodiment of the present disclosure.

[0021] The present disclosure is capable of various modifications and may have various embodiments, and specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the present disclosure to specific embodiments, and it should be understood that it includes all modifications, equivalents, and substitutions that fall within the spirit and scope of the present disclosure.

[0022] In describing the embodiments, detailed descriptions of related prior art are omitted if it is determined that such descriptions would unnecessarily obscure the gist of the matter. Furthermore, numbers used in the description of the embodiments (e.g., First, Second, etc.) are merely identifiers to distinguish one component from another.

[0023] The terms used in the embodiments of this specification have been selected to be as widely used as possible, taking into account the functions of the present disclosure; however, these terms may vary depending on the intent of those skilled in the art, case law, the emergence of new technologies, etc. Additionally, in specific cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the description section of the relevant embodiments. Therefore, terms used in this specification should be defined not merely by their names, but based on their meanings and the overall content of the present disclosure.

[0024] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

[0025] Terms referring to signals used in the following description (e.g., message, information, preamble, signal, signaling, sequence, stream), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), occasion), terms for operation states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to control information (e.g., DCI (downlink control information), MAC CE (medium access control element), RRC (radio resource control) signaling), terms referring to network entities, terms referring to device components, etc. are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.

[0026] Singular expressions may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art as described in this specification.

[0027] Throughout this disclosure, unless specifically stated otherwise, “or” is inclusive and not exclusive. Accordingly, “A or B” may mean “A, B, or both” unless clearly indicated otherwise in the context. In this disclosure, the phrases “at least one of” or “one or more of” may mean that different combinations of one or more of the listed items may be used, or that only any one of the listed items is required. For example, “at least one of A, B, and / or C” may include any of the following combinations: A, B, C, A and B, A and C, B and C, or A and B and C. In this disclosure, the expression “at least one of A, B, or C” may refer to “A”, “B”, “C”, “A and B”, “A and C”, “B and C”, “A, B, and C all”, or variations thereof.

[0028] Throughout this disclosure, when a part is described as "comprising" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components. Furthermore, terms such as "part," "module," etc., as used in this specification refer to a unit that processes at least one function or operation, and this may be implemented in hardware or software, or as a combination of hardware and software. Components expressed as "part (unit)," "module," etc., in this disclosure may consist of two or more components combined into a single component, or a single component may be divided into two or more components according to more detailed functions. Additionally, each component described below may additionally perform some or all of the functions performed by other components in addition to its own primary function, and it is understood that some of the primary functions performed by each component may be exclusively handled by other components.

[0029] As used in this disclosure, the expression “configured to” may be replaced, depending on the context, with, for example, “suitable for,” “having the capacity to,” “designed to,” “adapted to,” “made to,” or “capable of.” The term “configured to” may not necessarily mean only “specifically designed to” in hardware. Instead, in some situations, the expression “system configured to” may mean that the system is “capable of” in conjunction with other devices or components. For example, the phrase “processor configured to perform A, B, and C” may mean a dedicated processor for performing the said operations (e.g., an embedded processor), or a generic-purpose processor (e.g., a CPU or an application processor) capable of performing said operations by executing one or more software programs stored in memory.

[0030] All functions or operations described in this disclosure may be processed individually by a single processor and / or collectively by a plurality of processors. A single processor or a combination of a plurality of processors may include circuitry that performs processing, such as an Application Processor (AP), Communication Processor (CP), Graphical Processing Unit (GPU), Neural Processing Unit (NPU), Microprocessor Unit (MPU), System on Chip (SoC), Integrated Chip (IC), etc.

[0031] It should be understood that the blocks and combinations of flowcharts in the flowcharts illustrated in the present disclosure may be performed by one or more computer programs comprising computer-executable instructions. The one or more computer programs may be stored all in a single memory or may be divided and stored in multiple different memories.

[0032] In addition, when a component is described in the present disclosure as being "connected" or "connected" to another component, it should be understood that the component may be directly connected to or directly connected to the other component, but unless otherwise specifically stated, it may also be connected or connected through another component in between.

[0033] In one embodiment of the present disclosure, "connection relationship" may include the meanings of "connection relationship," "inclusion relationship," "attachment relationship," or "matching relationship." For example, "connected" may include the meanings of "connected," "included," "attached," or "matched." In one embodiment of the present disclosure, "connection" may include the meaning that data communication is possible via wired or wireless means. For example, "A and B are connected" may include the meaning that A and B are capable of data communication, that is, capable of transmitting and receiving data to and from each other.

[0034] Additionally, in this disclosure, expressions of "greater than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled; however, this is merely for the purpose of expressing an example and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" may be replaced with "less than," and conditions described as "greater than and less than" may be replaced with "greater than and less than."

[0035] Additionally, the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3GPP (3rd Generation Partnership Project), xRAN (extensible radio access network), O-RAN (open-radio access network), but this is merely illustrative. Various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0036] For convenience of explanation, the present disclosure uses terms and names defined in the 3GPP LTE (Long Term Evolution) or NR (New Radio) standards, or terms and names modified therefrom. However, the present disclosure is not limited to the terms and names described above and may be applied equally to systems conforming to other standards. In the present disclosure, eNB (eNode B) may be used interchangeably with gNB (gNode B) for convenience of explanation. For example, a base station referred to as eNB may be understood as a gNB. In the present disclosure, the term terminal may refer to User Equipment (UE), Mobile Station (MS), mobile phones, NB-IoT (narrowband-internet of things) devices, sensors, as well as various wireless communication devices.

[0037] In the present disclosure, the term "compiler" may be a computer program that translates computer code written in a specific programming language into another programming language. A compiler may be used to translate source code from a high-level programming language into a low-level programming language, such as machine code or assembly language, in order to generate an executable program. A compiler may analyze source code, perform optimizations based on the analysis, and generate target code. For example, a compiler may generate software binaries from source code.

[0038] In the present disclosure, the term "source code" may be a plain text computer program written in a programming language. To control the behavior of a computer, a programmer may write human-readable source code. The source code may be converted into computer-readable machine code through a compiler.

[0039] In this disclosure, the term "software binary" may mean an executable file or library file converted into machine code by compiling source code. According to this disclosure, a software binary suitable for the operational purpose of a specific base station may be provided. For example, in some embodiments of this disclosure, a suitable software binary may be distributed to the equipment of a corresponding base station. Based on the software binary, a corresponding base station may be installed, established, set up, initiated, or configured. In this disclosure, the terms "software binary" and "binary" may be used interchangeably.

[0040] Embodiments of the present disclosure are described below with reference to the attached drawings so that those skilled in the art can easily implement them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein.

[0041] FIG. 1 illustrates an exemplary radio access network (Radio Access Network, RAN) (10) according to one embodiment of the present disclosure.

[0042] Referring to FIG. 1, a wireless access network (10) may include a control platform (102) including a software binary warehouse (100), RAN nodes (104, 106), and base stations (108, 110). The control platform (102) may communicate with a telecommunications operator (11) and RAN nodes (104, 106). A RAN node (104) may communicate with base stations (108) including a base station (12), and a RAN node (106) may communicate with base stations (110). Each of the base stations (108) and base stations (110) may communicate with one or more user terminals, for example, one or more user equipment (UE) within a corresponding cell. A user terminal can communicate with a core network (not shown) of a wireless access network (10) via a base station of the cell to which the user terminal belongs, a RAN node of the base station, and a control platform. In the following, each component constituting the wireless access network (10) may be referred to as a network entity.

[0043] In one embodiment, the wireless access network (10) is 5G (5 thIt may be a wireless access network under Generation. In such a wireless access network (10), base stations (108, 110) may be referred to as gNBs (nest Generation Node B). A gNB is a node that provides terminations of NR (New Radio) user plane and control plane protocols toward a user terminal and may be connected to a 5G core network via an NG interface. For the processing of data transmission and reception of a user terminal, control signal processing and data signal processing may be performed at the base station. The base station may be divided into a Central Unit (CU) and a Distributed Unit (DU). In one embodiment, the base station may include one CU and a plurality of DUs.

[0044] A CU may be a logical node that manages one or more DUs. For example, a CU can control the operation of one or more DUs. A CU can perform functions of higher layers. For example, a CU can perform at least some of the functions of some layer(s) of network protocol layers (e.g., the Radio Resource Control (RRC) layer, the SDAP layer, and / or the Packet Data Convergence Protocol (PDCP) layer). A CU can perform functions such as processing various control messages for connection control between a base station and a user terminal and handover between terminals, functions to connect between two clients to transmit data from one client to another and transmit a response from one client to another, QoS (Quality of Service) settings, functions to reorder packets, and security / authentication-related functions.

[0045] In one embodiment, the CU may be separated into a CU-CP (Control Plane) and a CU-UP (User Plane). The CU-CP may be a logical node hosting the control plane portion of the RRC layer and PDCP layer of the CU. The CU-UP may be a logical node hosting the user plane portion of the PDCP layer and / or SDAP layer of the CU. The CU-CP and CU-UP may be connected via an E1 interface. The CU may be connected to a DU via an F1 interface. The CU-CP may be connected to a DU via an F1-C interface, and the CU-UP may be connected to a DU via an F1-U interface. A single CU-CP may be connected to multiple DUs. A single CU-CP may be connected to multiple CU-UPs. A single DU may be connected to only one CU-CP. A single CU-UP may be connected to only one CU-CP. For resiliency, DU and / or CU-CP may be connected to multiple CU-CPs.

[0046] A DU may be an entity that performs the functions of some of the network protocol layers, excluding some layers performed by a CU. For example, a DU may perform at least some of the network functions of the RLC (Radio Link Control) layer, MAC (Medium Access Control) layer, or PHY (Physical) layer (e.g., baseband functions), but is not limited thereto. At least some of the operations of a DU may be controlled by a CU. A DU may share network data processing between a CU and an RU. For example, a DU may perform buffer functions, radio resource scheduling functions, data reprocessing functions, radio signal resource allocation functions, or transmission scheduling functions. A single DU may support one or more cells, and a single cell may be supported by a single DU.

[0047] RAN nodes (104, 106) may be network entities that share some network functions with base stations (108, 110). For example, RAN nodes (104, 106) may perform at least partially the network functions of the DU and / or CU. Each of the base stations (108, 110) may perform the remaining functions that the RAN nodes (104, 106) do not perform. For example, base station (12) may perform the functions of the DU, and the RAN node (104) connected to base station (12) may perform at least some functions of the CU.

[0048] In one embodiment, the network functions of the base station may be separated into a CU, a DU, and a Radio Unit (RU). The RU can process physical signals for a user terminal. For example, the RU can perform direct wireless communication with the user terminal. The RU can convert an analog signal received from the user terminal into a digital signal and transport the converted digital signal to the DU. In one embodiment, the base station (12) can perform the functions of the RU, and the RAN node (104) can perform the functions of the CU and the DU. In one embodiment, the base station (12) can perform the functions of the RU and the DU, and the RAN node (104) can perform the functions of the CU.

[0049] The control platform (102) can control at least some of the operations of the RAN nodes (104, 106) and base stations (108, 110). For example, the control platform (102) can collect data from the RAN nodes (104, 106) and base stations (108, 110) and optimize the operations of each network entity based on the collected data. The control platform (102) can distribute and manage software, software binaries, program code, and / or instructions for each network entity. In one embodiment, the control platform (102) can manage one or more network entities in response to a request from the telecommunications operator (11).

[0050] The control platform (102) may include a software binary warehouse (100). The software binary warehouse (100) may generate software binaries for configuring (or implementing, setting up) network entities within a wireless access network (10), store the generated binaries, distribute the binaries, and manage the distributed binaries. For example, the software binary warehouse (100) may acquire information associated with a network entity, generate a software binary suitable for the network entity based on the acquired information, and distribute the generated software binary to the network entity. Additionally or alternatively, the software binary warehouse (100) may store one or more software binaries, select a software binary suitable for the network entity from among the stored software binaries based on information associated with the network entity, and distribute the selected software binary to the network entity. Additionally or alternatively, the software binary warehouse (100) can monitor the performance of the network entity and replace the software binary of the network entity. In one embodiment, the software binary warehouse (100) may be implemented as a module attached to or combined with the control platform (102). The operation of the software binary warehouse (100) will be described in detail later.

[0051] In some embodiments, the wireless access network (10) may be virtualized. The virtualized wireless access network may be referred to as a virtualized RAN. In the vRAN, the CU, DU, and / or RU may be virtualized. For example, the CU, DU, and / or RU may be virtualized based on software running on one or more processor(s) (or server(s)) within a general-purpose server, and may each be composed of a virtualized DU (vDU) and a virtualized CU (vCU). The vRAN may be implemented through the installation / removal / updating of software on a general-purpose server without dependency limited to a specific network equipment manufacturer (or vendor). Thus, the vRAN has high equipment compatibility. In addition, vRAN is a cloud-native network that offers scalability and flexibility, which can also reduce capital expenditures (CAPEX) and operating expenditures (OPEX).

[0052] To virtualize a network entity, the control platform (102) may distribute software binaries stored in the software binary warehouse (100) or software binaries generated by the software binary warehouse (100) on a general-purpose server. As the software binaries distributed on the general-purpose server are installed, a vRAN network entity may be implemented. For example, the software binary warehouse (100) may generate software binaries that enable a base station (12) to perform vCU, vDU, and / or vRU functions, and may distribute the generated software binaries to the base station (12).

[0053] FIG. 2 illustrates an open wireless access network (Open-RAN, O-RAN) (20) according to one embodiment of the present disclosure.

[0054] Referring to FIG. 2, the O-RAN (20) may include a Service Management and Orchestration (SMO) framework (202), a near-Real-Time (RT) RAN Intelligent Controller (RIC, 206), consumers (208), an O-eNB (evolved Node B, 210), an O-CU-CO (212), an O-CU-UP (214), an O-DU (216), an O-RU (218), and an O-cloud (220). However, the components of the O-RAN (20) according to one embodiment of the present disclosure are not limited thereto, and the O-RAN (20) illustrated in FIG. 2 may omit unnecessary components and connections for describing the embodiments of the disclosure. Additionally, at least some of the components and connections illustrated in FIG. 2 may not be essential components of the O-RAN (20). Accordingly, some components in the structure of the O-RAN (20) shown in FIG. 2 may be modified, omitted, replaced, or added. For example, the O-RAN (20) may be modified according to at least one standard specification. Additionally, operations in the O-RAN (20) may be performed according to at least one standard specification.

[0055] O-RAN (20) can be implemented according to the standards of the O-RAN standardization organization (O-RAN alliance). Each component of O-RAN (20) can be referred to as an O-RAN node, an O-RAN network function (NF), or an O-RAN network entity. An O-RAN NF can be a network function having O-RAN defined operations and interfaces. Through O-RAN (20), an environment can be provided in which equipment from different vendors can be integrated and operated by defining an integrated interface by opening up existing vendor-specific RAN interfaces.

[0056] The SMO framework (202) may be an entity that provides various management services and network management functions. The SMO framework (202) may have one or more SMO functions (SMO Functions, SMOFs). Each SMO function may provide one or more SMO services. SMO services may be a cohesive set of standardized and integrated management, orchestration, and automation capabilities provided by the SMO functions.

[0057] The SMO framework (202) may include a non-real-time RIC (204). The non-real-time RIC (204) may be a functionality within the SMO that includes a non-real-time RIC framework and non-real-time RIC applications (rApps) that manage content carried through the A1 interface. The non-real-time RIC framework may be a functionality within the non-real-time RIC that logically terminates the A1 interface and supports rApps that include R1 services through the R1 interface. An rApp may be a modular application that consumes and / or produces non-real-time management and automation services. The R1 interface may be a service-based interface between the rApp and the non-real-time RIC framework through which R1 services can be produced and consumed.

[0058] The SMO framework (202) can be connected to O-RAN NFs (e.g., O-Near-Real-Time RIC (206), eNB (210), O-CU-CP (212), O-CU-UP (214), and / or O-DU (216)) through an O1 interface. The O1 interface may be an interface used by the SMO framework (202) for the operation and management of O-RAN NFs as specified in the OAM (Operations, Administration and Maintenance) interface specification. The O1 interface may expose management services for O-RAN NFs managed individually or together, as specified in the OAM structure specification.

[0059] The near-real-time RIC (206) may be an O-RAN NF comprising a near-real-time RIC platform and near-real-time RIC applications (xApps). The near-real-time RIC (206) may control and optimize the services and resources of the E2 node in near real-time through fine-grained data collection and tasks via the E2 interface using control loops in the order of 10 ms to 1 s. The near-real-time RIC platform may support A1, E1, Y1, and O1 interfaces and provide a set of services via the near-real-time RIC APIs (Application Programming Interfaces) required for xApp functionality. An xApp may be an application that consumes and / or produces near-RT RIC services via the application near-real-time RIC APIs to provide value-added control or guidance to the E2 node. Near-real-time RIC APIs may be a set of service-based interfaces produced and consumed by the near-real-time RIC platform and xApps according to the O-RAN specification. The near-real-time RIC (206) may be connected to the O-eNB (210), O-CU-CP (212), O-CU-UP (214), and O-DU (216) via an E2 interface.

[0060] The near-real-time RIC (206) may include a software binary warehouse (100). Additionally or alternatively, the software binary warehouse (100) may be implemented as a module attached to or combined with the near-real-time RIC (206). The software binary warehouse (100) may generate software binaries for each O-RAN NF and distribute the generated software binaries to a server, base station, or network device. By installing the software binaries generated by the software binary warehouse (100) on the server, base station, or network device, the server, base station, or network device may operate as an O-RAN NF.

[0061] Y1 consumers (208) may be roles performed by entities inside or outside the Public Land Mobile Network (PLMN) trust domain that consume Y1 services produced by the near-real-time RIC (206). Y1 consumers (208) outside the PLMN may use Y1 services in a secure manner through an exposure function (e.g., according to 3GPP TS 23.501 Section 5.20). Y1 consumers (208) may be connected to the near-real-time RIC (206) via a Y1 interface. The Y1 interface may be an interface through which RAN analytics services are exposed by the near-real-time RIC (206) so that they can be consumed by the Y1 consumers (208). RAN analysis services can be consumed by Y1 consumers (208) after mutual authentication and authorization by subscribing to or requesting RAN analysis information through the Y1 service interface.

[0062] The O-eNB (210) may be an eNB or ng (next generation)-eNB conforming to the O-RAN specification. The O-eNB (210) may be connected to a near-real-time RIC (206) via an E2 interface. Although not illustrated, the O-eNB (210) may support the O-DU (216) and O-RU (218) as an open fronthall interface between the O-DU (216) and O-RU (218).

[0063] O-CU-CP (212) may be a CU-CP that conforms to the O-RAN specification. O-CU-CP (212) may be a logical node that hosts the control plane portion of the PDCP protocol and the RRC. O-CU-CP (212) may be connected to a near-real-time RIC (206) via an E2 interface. O-CU-CP (212) may be managed by the SMO framework (202) via an O1 interface. O-CU-CP (212) may be connected to a 5G Core (5G Core, 5GC) via an NG-c interface. O-CU-CP (212) may be connected to an eNB (210) or to an en-gNB of the EN-DC (Evolved Universal Terrestrial Radio Access Network (E-UTRAN) New Radio - Dual Connectivity) via an O-X2-2 interface. O-CU-CP (212) can be connected to O-CU-UP (214), O-eNB (210), gNB, or ng-eNB via an Xn-c interface.

[0064] O-CU-UP (214) may be a CU-UP conforming to the O-RAN specification. O-CU-UP (214) may be a logical node hosting the user plane portion of the SDAP protocol and the PDCP protocol. O-CU-CP (212) and O-CU-UP (214) may be connected via an E1 interface. O-CU-UP (214) may be managed by the SMO framework (202) via an O1 interface. O-CU-UP (214) may be connected to 5GC via an NG-u interface. O-CU-UP (214) may be connected to O-eNB (210) or en-gNB of EN-DC via an X2-u interface. O-CU-UP (214) may be connected to O-CU-UP, O-eNB, gNB, or ng-eNB via an Xn-u interface.

[0065] O-DU (216) may be a DU that conforms to O-RAN specifications. O-DU (216) may be a logical node that hosts RLC / MAC / upper-PHY layers based on lower-layer functional splitting. O-DU (216) may be combined with one or more O-RUs connected to O-DU (216) to support the functions of a gNB-DU according to 3GPP specifications. O-DU (216) may be connected to O-CU-CP (212) via an F1-c interface and to O-CU-UP (214) via an F1-u interface. O-DU (216) may be managed by the SMO framework (202) via an O1 interface. O-DU (216) may support O-RU (218) management via an open fronthaul (FH) management plane (M-plane) interface.

[0066] The O-RU (218) may be a logical node hosting RF processing and lower-PHY layers based on lower-layer functional separation. The O-RU (218) may be similar to a 3GPP standard TRP or RRF, but more specifically may include lower-PHY layers such as FFT / iFFT and PRACH extraction. In one embodiment, the O-RU (218) may be connected to the SMO framework (202) via an open FH management plane. The open FH management plane is a management interface that controls the O-RU and is typically run on the O-DU, but in a hybrid topology, it may also be run on the SMO framework (202). The O-RU (218) may be connected to the O-DU (216) via an open FH Control, User, Synchronization (CUS) plane and an open FH management plane.

[0067] The O-Cloud (220) may be a cloud platform that provides an O-RAN standardized interface hosting O-RAN defined software components. O-RAN network functions may be hosted on the O-Cloud (220) or on customized hardware. For example, the O-Cloud (220) may be a cloud computing platform composed of a collection of physical infrastructure nodes that meet O-RAN requirements for hosting relevant O-RAN NFs (e.g., near-real-time RIC (206), O-CU-CP (212), O-CU-UP (214), O-DU (216), etc.), supporting software components (e.g., operating system (OS), virtual machine monitor, container runtime, etc.), and appropriate management and orchestration functions. The O-Cloud (220) may be connected to the SMO framework (202) via an O2 interface. In one embodiment, the O-cloud (220) may include an O-cloud notification interface for related O-RAN NFs (e.g., near-real-time RIC (206), O-CU-CP (212), O-CU-UP (214), and / or O-DU (216)) to receive notifications related to the O-cloud. O-RAN NFs instantiated on the O-cloud (220) may utilize APIs exposed by the Accelerator Abstraction Layer (AAL).

[0068] The A1 interface may be an interface between a non-real-time RIC (204) and a near-real-time RIC (206) within the SMO framework (202). The A1 interface may support policy management services, enrichment information services, and machine learning (ML) management services. The O1 interface may be used by the SMO framework (202) to manage O-RAN NFs. The O2 interface may be an interface between the SMO framework (202) and the O-cloud (220).

[0069] The E2 interface may be a logical interface connecting a near-real-time RIC (206) to E2 nodes. An E2 node may be connected to only one near-real-time RIC. A near-real-time RIC may be connected to multiple E2 nodes. The E2 interface may be a control plane interface that provides support for near-real-time RIC services using E2 application protocols and E2 service models. In one embodiment, the E2 interface may be associated with the SCTP protocol.

[0070] The open FH interface may be an interface between the O-DU (216) and the O-RU (218). The open FH interface may include the CUS plane and the M plane. The E1 interface may refer to an interface between the O-CU-CP (212) and the O-CU-UP (214). The F1-c interface may refer to an interface between the O-CU-CP (212) and the O-DU (216). The F1-u interface may refer to an interface between the O-CU-UP (214) and the O-DU (216). The NG-c interface may refer to an interface between the O-CU-CP (212) and the 5GC. The NG-u interface may refer to an interface between the O-CU-UP (214) and the 5GC. The X2-c interface may refer to an interface for transmitting control plane information between the eNBs in the EN-DC or between the eNB and the en-gNB. The X2-u interface may refer to an interface for transmitting user plane information between eNBs in EN-DC or between an eNB and an en-gNB. The Xn-c interface may refer to an interface for transmitting control plane information between gNBs, between ng-eNBs, or between an ng-ENB and gNBs. The Xn-c interface may refer to an interface for transmitting user plane information between gNBs, between ng-eNBs, or between an ng-ENB and gNBs.

[0071] In the embodiment illustrated in FIG. 2, the O-RAN (20) is illustrated with O-RAN NFs (near-real-time RIC (206), O-CU-CP (212), O-CU-UP (214), O-DU (216), and O-RU (218)) as separate O-RAN structural elements, but an implementation in which some or all of these O-RAN NFs are aggregated is also possible. For example, as illustrated in FIG. 2, the O-RAN NFs may be disaggregated according to the O-RAN structure; O-CU-CP and O-CU-UP may be aggregated; O-CU-CP, O-CU-UP, and O-DU may be aggregated; near-real-time RIC, O-CU-CP, and O-CU-UP may be aggregated; O-CU-CP, O-CU-UP, O-DU, and O-RU may be aggregated; Alternatively, near-real-time RIC, O-CU-CP, O-CU-UP, O-DU, and O-RU can be aggregated.

[0072] In one embodiment, the wireless access network (10) illustrated in FIG. 1 may be configured based on the O-RAN standard as illustrated in FIG. 2, and accordingly, the software binary warehouse (100) and the base station (12) may communicate with each other using one or more messages defined in the O-RAN standard. The base station (12) may correspond to an E2 node defined in the O-RAN standard. The software binary warehouse (100) and the base station (12) may communicate with each other using at least one of one or more procedures defined in Section 8 of O-RAN.WG3.E2AP.

[0073] FIG. 3 illustrates an exemplary block diagram of a software binary warehouse (100) according to one embodiment of the present disclosure.

[0074] Referring to FIG. 3, the software binary warehouse (100) may include a warehouse management module (302), an intelligent binary selection module (304), a software distribution module (306), a binary database (DB) (308), a binary build module (310), and a statistics database (312). Each component of the software binary warehouse (100) may communicate with other components via an internal bus. The software binary warehouse (100) may receive a request from a telecommunications operator (11) to distribute software binaries for a base station (12) to the base station (12). In response to the request from the telecommunications operator (11), the software binary warehouse (100) may select one of the stored software binaries or create a new software binary. The software binary warehouse (100) may distribute the selected software binary or the new software binary to the base station (12).

[0075] A software binary warehouse (100) can manage one or more base stations. A software binary warehouse (100) can manage the device (or equipment) and / or software binaries of each of one or more base stations. In one embodiment, the equipment of one or more base stations may include at least one part of the equipment of at least one of a DU, CU, or RU. The equipment of one or more base stations may include not only hardware equipment but also virtualized software equipment.

[0076] The warehouse management module (302) can control the operations of elements within the software binary warehouse (100). For example, the warehouse management module (302) can send a binary selection request to the intelligent binary selection module (304) to control the intelligent binary selection module (304) to select the optimal software binary and the software distribution module (306) to distribute the selected software binary to the base station (12). The warehouse management module (302) can manage a list of software binaries stored in the binary database (308) and information on each software binary. The warehouse management module (302) can send a binary build request to the binary build module (310) to control the binary build module (310) to create (or build) a new software binary. The warehouse management module (302) can store information or data input from external devices or external users, such as a telecommunications operator (11) and a base station (12), in a statistical database (312).

[0077] The intelligent binary selection module (304) can select a software binary for the base station (12) from among the binaries stored in the binary database (308). The intelligent binary selection module (304) can execute one or more algorithms for selecting the software binary. The operation of the intelligent binary selection module (304) will be described in detail later with reference to FIG. 4.

[0078] The software distribution module (306) can distribute a software binary selected by the intelligent binary selection module (304) to the base station (12). The software distribution module (306) can distribute a software binary generated by the binary build module (310) to the base station (12). Based on the software binary distributed by the software distribution module (306), the base station (12) may be initially configured or reconfigured. By executing the distributed software binary, the base station (12) may perform desired network function(s) (or module(s) that perform the desired network function(s) may be installed, configured, or established in the base station (12). In one embodiment, the process of distributing the software binary by the software distribution module (306) may be based on an O-RAN interface defined in the O-RAN specification. In one embodiment, the method of distributing the software binary by the software distribution module (306) may be (pre-)defined by being implemented in the form of software.

[0079] The binary database (308) may store one or more software binaries generated by the binary build module (310). The binary database (308) may store a list of software binaries stored in the binary database (308). The binary database (308) may store binary information for each of the software binaries stored in the binary database (308). The binary information may include information indicating the optimization goal of the corresponding software binary. For example, information associated with software binary A1 may include information indicating that software binary A1 is optimized for operating a network device with a coverage of 5 km. Information associated with software binary A2 may include information indicating that software binary A2 is optimized for maximum throughput operation. Additionally or alternatively, the binary information may include information necessary for the distribution of the software binary. For example, the binary information may include information related to the distribution process of the software binary. Based on binary information, the software binary can be distributed to the base station (12) by the software distribution module (306). The binary database (308) can be managed by the warehouse management module (302).

[0080] The binary build module (310) can generate (or build) a software binary for the base station (12) based on information associated with the base station (12). To generate the software binary, the binary build module (310) can run a compiler capable of compiling source code. The binary build module (310) can determine a compilation technique for generating a software binary for the base station (12) based on information associated with the base station (12). "Determining a compilation technique" can be understood as optimizing the compiler. For example, the binary build module (310) can predict a communication policy to be applied to the base station (12) and optimize a compilation technique for generating a software binary based on the predicted communication policy. By running the compiler based on the optimized compilation technique, the binary build module (310) can translate the source code into a binary file. The operation of the binary build module (310) will be described in detail later with reference to FIG. 5.

[0081] The statistical database (312) can store information associated with the base station (12). The base station (12) can periodically report (or transmit) to the software binary warehouse (100) status information indicating the status of the base station (12) and software profiles associated with software binaries running on the base station (12). Information periodically acquired regarding the base station (12) can be stored in the statistical database (312). The statistical database (312) can be managed by the warehouse management module (302).

[0082] FIG. 4 illustrates, in accordance with one embodiment of the present disclosure, the distribution of software binaries for a base station (12).

[0083] Referring to FIG. 4, a software binary warehouse (100) can obtain operational information of a base station (12) from a telecommunications operator (11) (or network operator), select a software binary suitable for the base station (12) based on the obtained operational information, and distribute the selected software binary to the base station (12).

[0084] The warehouse management module (302) can obtain operational information of the base station (12) along with a request for binary distribution to the base station (12) from the telecommunications operator (11). The operational information of the base station (12) may include information used for the installation (or establishment, setup) or operation of the base station (12). In one embodiment, the operational information of the base station (12) may include at least one of standardized information for wireless communication associated with software binary distribution according to the equipment of the base station (12) (or information associated with standard specifications for wireless communication) (e.g., operating frequency band or duplex mode), the minimum number of terminals supported by the base station (12), the maximum number of terminals supported by the base station (12), the coverage of the base station (12), the maximum throughput supported by the base station (12), information associated with the highest performance mode of the base station (12), or information associated with the low-power mode of the base station (12). For example, the operational information of the base station (12) may include information indicating the purpose of operation of the base station (12), such as information indicating that the coverage of the base station (12) is 5 km, information indicating that the current throughput of the base station (12) is the maximum throughput, information indicating that the base station (12) is operating in a maximum performance mode, information indicating one or more parameters associated with the maximum performance mode of the base station (12), information indicating that the base station (12) is operating in a low-power mode, and information indicating one or more parameters associated with the low-power mode of the base station (12).

[0085] The warehouse management module (302) can obtain information for selecting a software binary that corresponds to the operational information of the base station (12). For example, in response to a request for binary distribution to the base station (12), the warehouse management module (302) can obtain a list of software binaries applicable to the base station (12) and binary information of each software binary from the binary database (308). The binary database (308) can store one or more software binaries, binary information of each software binary, and a list of one or more software binaries stored in the binary database (308).

[0086] The warehouse management module (302) can obtain status information of the base station (12) from the statistical database (312). The status information of the base station (12) may include information representing the current status of the base station (12). For example, the status information of the base station (12) may include the most recent (or current) Key Performance Indicator (KPI) of the base station (12). The KPI of the base station (12) is an indicator used to measure and manage network performance, and may include, for example, signal strength, signal-to-noise ratio (SNR), data transmission rate, latency, frequency efficiency, packet loss rate, etc. However, this is merely an example, and the KPI is not limited to the examples described above. In addition, in one embodiment, the KPI of the base station (12) may include at least some of the measurements or KPIs required for the DU, CU, or RU defined in the O-RAN standard. In one embodiment, the statistical database (312) can periodically receive status information of the base station (12) from the base station (12).

[0087] The warehouse management module (302) can obtain the software profile of the base station (12) from the statistical database (312). The software profile of the base station (12) may include information related to the operation of the software binary currently running on the base station (12). The software profile may include information related to the code included in the software binary and / or information related to the hardware on which the software binary is executed. For example, the software profile of the base station (12) may include information related to the execution of the code included in the software binary, such as the frequency of calls to function(s) included in the current software binary, branch prediction statistics for branch(s) included in the current software binary (e.g., branch prediction failure rate, specific code path(s) where prediction failed, etc.), the number of executions and time taken for loop(s) included in the current software binary, information related to code path(s) that were frequently executed during the execution of the current software binary, or the number of executions per code line included in the current software binary during a predefined time interval.For example, the software profile of the base station (12) may include information related to the memory bounds of the base station (12), information related to the processor usage pattern (e.g., average CPU usage rate, maximum CPU usage rate, whether it is concentrated on a specific core, etc.), information related to the cache usage pattern of the base station (12) (e.g., cache hit / miss rate of each cache, usage pattern per cache, etc.), memory access pattern of the first base station of the base station (12) (e.g., access frequency per memory area, access time interval per memory area, memory locality, etc.), data input / output (I / O) waiting time of the base station (12), information related to network communication of the base station (12) (e.g., data transmission / reception frequency, network traffic, etc.), information related to the power of the base station (12) (e.g., power consumption pattern, power limit, etc.), or information related to the hardware on which the software binary is executed, such as the usage rate of hardware resources included in the base station (12). In one embodiment, the statistical database (312) can periodically receive the software profile of the base station (12) from the base station (12).

[0088] The warehouse management module (302) can transmit a binary selection request for the base station (12) to the intelligent binary selection module (304). For example, the warehouse management module (302) may request the intelligent binary selection module (304) to select the software binary most suitable for the base station (12) from among the binaries stored in the binary database (308), together with at least one of the operation information of the base station (12), the status information of the base station (12), or the software profile of the base station (12). In one embodiment, the binary selection request may include information indicating that the target device is the base station (12), a list of software binaries stored in the binary database (308), and information associated with each of the software binaries applicable to the base station (12).

[0089] In response to a binary selection request, the intelligent binary selection module (304) can select a software binary for the base station (12) from among the binaries stored in the binary database (308). For example, the intelligent binary selection module (304) can input information associated with the base station (12), such as operational information of the base station (12), status information of the base station (12), or software profile of the base station (12), into at least one of one or more algorithms for selecting a software binary. In one embodiment, the intelligent binary selection module (304) may use various algorithms configured to select a software binary based on given information, such as an algorithm based on machine learning, an algorithm based on Bayesian optimization, or a predetermined rule-based algorithm.

[0090] One or more algorithms for selecting a software binary executed by the intelligent binary selection module (304) can each output a software binary based on given information. The intelligent binary selection module (304) can select any one of the software binaries output from the algorithms. In one embodiment, the intelligent binary selection module (304) can select a software binary for the base station (12) based on voting. For example, the intelligent binary selection module (304) can select the software binary that is output with the highest frequency among the binaries output from each of the multiple algorithms as the binary for the base station (12). If two or more binaries are output with the highest frequency among the binaries output from the multiple algorithms, the intelligent binary selection module (304) can randomly select one of the two or more binaries.

[0091] The intelligent binary selection module (304) can use one or more algorithms to identify whether the selected binary is identical to the current binary of the base station (12). For example, the intelligent binary selection module (304) can identify whether the selected binary is identical to a binary previously distributed to the base station (12) or a binary currently operating at the base station (12). Based on whether the selected binary is different from the current binary of the base station (12), the intelligent binary selection module (304) can use one or more algorithms to transmit the selected software binary to the software distribution module (306). For example, the intelligent binary selection module (304) can request the software distribution module (306) to distribute the selected software binary to the base station (12).

[0092] In response to a request from the intelligent binary selection module (304), the software distribution module (306) can distribute the software binary selected by the intelligent binary selection module (304) to the base station (12). For example, the software distribution module (306) may receive a request to distribute the selected software binary to a specific cell associated with the base station (12), and in response to this request, the software distribution module (306) may distribute the selected software binary to the requested cell. In one embodiment, based on the completion of the distribution of the selected binary to the base station (12), the software distribution module (306) may notify the warehouse management module (302) of the completion of the binary distribution. Based on a notification from the software distribution module (306), the warehouse management module (302) can identify that a binary suitable for the current operation information of the base station (12), the current status information of the base station (12), and the current software profile of the base station (12) obtained from the telecommunications operator (11) has been distributed to the base station (12).

[0093] In one embodiment, based on the fact that the selected binary is the same as the current binary of the base station (12), the intelligent binary selection module (304) may not transmit the selected software binary to the software distribution module (306). Additionally or alternatively, the intelligent binary selection module (304) may notify the warehouse management module (302) that the binary selected by the intelligent binary selection module (304) is the same as the current binary of the base station (12). Based on the notification from the intelligent binary selection module (304), the warehouse management module (302) may identify that the binary suitable for the current operational information of the base station (12), the current status information of the base station (12), and the current software profile of the base station (12) obtained from the telecommunications operator (11) is the binary of the current base station (12).

[0094] In one embodiment, at least one of the status information of the base station (12) or the software profile of the base station (12) may be updated periodically. For example, the base station (12) may periodically provide at least one of the status information of the base station (12) or the software profile of the base station (12) according to the binary of the base station (12) to the software binary warehouse (100). In one embodiment, the warehouse management module (302) may periodically or non-periodically obtain changed operational information of the base station (12) from the telecommunications operator (11).

[0095] In one embodiment, the warehouse management module (302) can identify that any one of the operation information of the base station (12), the status information of the base station (12), or the software profile of the base station (12) obtained from the telecommunications operator (11) is updated (or changed). For example, the warehouse management module (302) can monitor the update or change of any one of the operation information of the base station (12), the status information of the base station (12), and the software profile of the base station (12) obtained from the telecommunications operator (11) until a request for a new binary is received from the telecommunications operator (11) or the base station (12). In response to the update (or change) of any one of the operation information of the base station (12), the status information of the base station (12), and the software profile of the base station (12) obtained from the telecommunications operator (11), the warehouse management module (302) may request the intelligent binary selection module (304) to select a software binary suitable for the updated information.

[0096] In response to a request from the warehouse management module (302), the intelligent binary selection module (304) may re-select a software binary suitable for the updated information. Based on the fact that the re-selected binary is different from the current binary of the base station (12), the intelligent binary selection module (304) may request the software distribution module (306) to distribute the re-selected binary. In response to a request from the intelligent binary selection module (304), the software distribution module (306) may distribute the re-selected software binary to the base station (12). Based on the fact that the re-selected binary is the same as the current binary of the base station (12), the intelligent binary selection module (304) may not request the software distribution module (306) to distribute the re-selected binary.

[0097] In one embodiment, the intelligent binary selection module (304) may have an AI / ML algorithm based on machine learning or artificial intelligence (AI / Machine Learning). The intelligent binary selection module (304) may obtain updated status information and software profiles of base stations (12) based on distributed binaries from a statistical database (312). The intelligent binary selection module (304) may update (or retrain) the AI / ML algorithm using the updated status information and software profiles of base stations (12). For example, the intelligent binary selection module (304) may retrain the AI / ML algorithm to output the current software binary of base stations (12) as the binary best suited to the updated status information and software profiles of base stations (12). A software binary warehouse (100) can retrain an AI / ML algorithm based on evaluation metrics for the binary (e.g., KPI, power consumption, number of serving terminals, number of cells, etc.) included in the software profile or state information periodically received from a base station. Accordingly, the accuracy of the inference of the AI / ML algorithm can be improved.

[0098] FIG. 5 illustrates, in an exemplary manner, the generation of a software binary for a base station (22) according to one embodiment of the present disclosure.

[0099] Referring to FIG. 5, the warehouse management module (302) may request the binary build module (310) to build a new software binary for the base station (22). In one embodiment, the warehouse management module (302) may determine that the base station (22) requires a new binary based on at least one of the status information of the base station (22) or the software profile of the base station (22). Based on the determination that the base station (22) requires a new binary, the warehouse management module (302) may send a binary build request for the base station (22) to the binary build module (310).

[0100] For example, the warehouse management module (302) can monitor the status information and software profile of the base station (22) that have been updated (or changed) and stored in the statistical database (312). For example, the base station (22) can periodically provide the status information and software profile of the base station (22) to the binary warehouse (200). The information and profile received from the base station (22) can be stored in the statistical database (312). Based on the updated status information or software profile of the base station (22), the warehouse management module (302) can determine whether the performance of the binary distributed to the base station (22) meets the expected performance. Based on the determination that the performance of the binary distributed to the base station (22) does not meet the expected performance, the warehouse management module (302) can determine that a new binary is required for the base station (22). Accordingly, the warehouse management module (302) may request the binary build module (310) to generate a new software binary for the base station (22). In one embodiment, the warehouse management module (302) may transmit operational information of the base station (22) to the binary build module (310).

[0101] In one embodiment, the warehouse management module (302) may determine that the performance of a binary distributed to the base station (22) does not meet the expected performance based on at least one KPI included in the updated status information or updated software profile of the base station (22). For example, the warehouse management module (302) may determine that the performance of a binary distributed to the base station (22) does not meet the expected performance based on at least one performance indicator included in the updated status information or updated software profile of the base station (22) being smaller or larger than a predetermined threshold value, or based on the difference between the value of the performance indicator and the corresponding expected value (or target value) being larger than a predetermined threshold value.

[0102] In one embodiment, the warehouse management module (302) identifies memory bound information included in the updated software profile of the base station (22) and, based on the fact that the current memory bound of the base station (22) is greater than a predetermined threshold value, may determine that the performance of the binary distributed to the base station (22) does not meet the expected performance. In one embodiment, the warehouse management module (302) identifies branch prediction information included in the updated software profile of the base station (22) and, based on the fact that the branch prediction information of the base station (22) differs from a predetermined expected prediction, may determine that the performance of the binary distributed to the base station (22) does not meet the expected performance. In the present disclosure, the branch prediction information may include information related to how the processor of the base station (22) predicted that a branch (e.g., a conditional statement) may occur during the execution of the software binary. For example, the branch prediction information may include at least one of the branch prediction result of the processor of the base station (22), parameters or data used for prediction for each branch, results of branches that actually occurred, branch prediction accuracy, or comparison statistics of the branch prediction result of the base station (22) and the actual branch result. However, this is merely an example, and the branch prediction information is not limited to the example described above.

[0103] In one embodiment, the warehouse management module (302) can identify whether a binary applicable to the base station (12) is stored in the binary database (308). For example, based on information associated with each software binary stored in the binary database (308), the warehouse management module (302) can identify that there is no software binary in the binary database (308) suitable for at least one of the status information of the base station (12) or the software profile of the base station (12). Based on identifying that there is no binary applicable to the base station (12) stored in the binary database (308), the warehouse management module (302) can determine that a new binary is needed for the base station (22). Accordingly, the warehouse management module (302) can request the binary build module (310) to create a new software binary for the base station (12).

[0104] In one embodiment, the warehouse management module (302) of the software binary warehouse (100) may request the intelligent binary selection module (304) to select a software binary for the base station (22) from among the software binaries stored in the binary database (308) based on at least one of the operation information of the base station (22), the status information of the base station (12), or the software profile of the base station (12). In response to the request of the warehouse management module (302), the intelligent binary selection module (304) may determine that no software binary suitable for the base station (22) is stored in the binary database (308) and may notify the warehouse management module (302) of this decision. Based on the decision of the intelligent binary selection module (304), the warehouse management module (302) may determine that a new binary is needed for the base station (22). Accordingly, the warehouse management module (302) may request the binary build module (310) to generate a new software binary for the base station (12).

[0105] In response to a binary generation request from the warehouse management module (302), the binary build module (310) can obtain current status information and software profiles of the base station (22) from the statistics database (312). The binary build module (310) can obtain operational information of the base station (22) from the warehouse management module (302). Based on at least one of the status information, software profiles, or operational information of the base station (22), the binary build module (310) can determine (or optimize) a compilation technique suitable for the situation of the base station (22).

[0106] In one embodiment, the binary build module (310) may optimize the compilation technique to generate a software binary suitable for the base station (22) by taking into account the state information, software profile, or operational information of the base station (22) (or may optimize the compiler of the binary build module (310)). For example, based on the state information, software profile, or operational information of the base station (22), the binary build module (310) may enable or disable some of the one or more features (or functions) available in the base station (22), or optimize the compilation technique so that the base station (22) executes a specific binary code or instruction(s) in certain situations.

[0107] In one embodiment, based on the state information, software profile, or operation information of the base station (22), the binary build module (310) can identify that the base station (22) is operating in a low-power mode. Accordingly, the binary build module (310) can optimize the compilation technique so that the base station (22) does not execute instructions that consume high power (or minimizes the execution of high-power instructions).

[0108] In one embodiment, based on the state information, software profile, or operational information of the base station (22), the binary build module (310) can identify that a specific function must be implemented in the base station (22). For example, based on the operational coverage of the base station (22), the binary build module (310) can identify that a function related to coverage expansion must be implemented in the base station (22). Accordingly, the binary build module (310) can optimize the compilation technique so that the base station (22) can execute the function related to coverage expansion (or so that the computation or power required to execute the function related to coverage expansion is minimized). For example, based on the state information, software profile, or operational information of the base station (22), the binary build module (310) can identify that the base station (22) requires a precise coding / decoding algorithm. Accordingly, the binary build module (310) can optimize the compilation technique to improve the accuracy of the decoding of the base station (22).

[0109] In one embodiment, to optimize the compilation technique, the binary build module (310) may change the layout of the source code of the binary for the base station (22) or adjust the prediction probability of each branch of the source code. For example, the binary build module (310) may determine at least one of the following: whether to change the location of at least one basic block included in the source code; whether to apply dead code elimination to at least one code block included in the source code; whether to apply loop unrolling (or loop unwinding) to at least one loop included in the source code; or whether to apply tail merge or in-lining to at least one function included in the source code.

[0110] Based on the determined compiling technique, the binary build module (310) can generate a software binary for the base station (22). The binary build module (310) can store the generated software binary in the binary database (308). In one embodiment, the binary build module (310) can notify the warehouse management module (302) that the build of the new binary has been completed. Based on the notification of the completion of the build, the warehouse management module (302) can identify that a new binary suitable for the base station (22) has been generated. Accordingly, the warehouse management module (302) can request the software distribution module (306) to distribute the new binary. The software distribution module (306) can distribute the new software binary to the base station (22).

[0111] In one embodiment, the warehouse management module (302) can control the intelligent binary selection module (304) to select a new software binary. The intelligent binary selection module (304) can request the software distribution module (306) to distribute the selected binary (i.e., the new binary generated by the binary build module (310)) to the base station (22). In response to the distribution request, the software distribution module (306) can distribute the new software binary to the base station (22).

[0112] FIG. 6 illustrates an exemplary flowchart of a method (600) for distributing a first software binary to a first base station according to one embodiment of the present disclosure.

[0113] Referring to FIG. 6, the method (600) may include steps (602 to 612). In one embodiment, the method (600) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and the steps (602 to 612) may be performed individually or in combination by any electronic device. A method for distributing a first software binary to a first base station according to one embodiment of the present disclosure is not limited to that shown in FIG. 6, any one of the steps shown in FIG. 6 may be omitted, and additional steps not shown in FIG. 6 may be included. In some embodiments, the order of at least some of the steps (602 to 612) may be changed.

[0114] In step (602), the software binary warehouse (100) can obtain operational information and status information of the first base station. For example, the warehouse management module (302) of the software binary warehouse (100) can receive operational information of the first base station (e.g., base station (12)) from a telecommunications operator (e.g., telecommunications operator (11) of FIG. 1). The warehouse management module (302) can receive status information of the first base station from the first base station. The operational information of the first base station may include information used for the installation or operation of the first base station. The status information of the first base station may include information expressing the current status of the first base station. For example, the status information of the first base station may include the most recent (or current) KPI of the first base station.

[0115] In one embodiment, the first base station may report the status information and / or software profile of the first base station to the software binary warehouse (100) based on an RIC indication procedure according to the O-RAN specification. The first base station may initiate the procedure by sending a RIC INDICATION message to a near-RT RIC (including or combined with the software binary warehouse (100)) that includes an associated RIC request identifier (ID) information element (IE), a RAN function ID IE, and / or a RAN action ID IE. Upon receiving the RIC INDICATION message, the near-RT RIC may use the RIC request ID to route the indication to a near-RT RIC function originating from a corresponding RIC subscription procedure.

[0116] In step (604), the software binary warehouse (100) may determine a compiling technique for generating the first software binary. For example, based on at least one of the status information, software profile, or operational information of the first base station, the binary build module (310) may determine a compiling technique suitable for the conditions of the first base station or optimize a compiler for generating the first software binary. Step (604) will be described in detail later with reference to FIGS. 7 through 9.

[0117] Additionally or alternatively, prior to step (604), based on at least one of the operation information of the first base station, the status information of the first base station, or the software profile of the first base station, the software binary warehouse (100) may determine to generate a first software binary for the first base station. The warehouse management module (302) may identify that there is no binary applicable to the first base station among the software binaries stored in the binary database (308). Based on identifying that there is no binary applicable to the first base station among the software binaries stored in the binary database (308), the warehouse management module (302) may determine to generate a first software binary for the first base station. In one embodiment, the warehouse management module (302) can identify that there are no software binaries applicable to the first base station among the software binaries stored in the binary database (308) based on at least one of the operation information of the first base station, the status information of the first base station, or the software profile of the first base station. In one embodiment, the intelligent binary selection module (304) can determine that there are no software binaries suitable for the first base station stored in the binary database (308) based on at least one of the operation information of the first base station, the status information of the first base station, or the software profile of the first base station. The intelligent binary selection module (304) can notify the warehouse management module (302) of this decision. In response to the notification from the intelligent binary selection module (304), the warehouse management module (302) can identify that there are no software binaries applicable to the first base station among the software binaries stored in the binary database (308).

[0118] In step (606), the software binary warehouse (100) can generate a first software binary for the first base station based on a compilation technique. The binary build module (310) of the software binary warehouse (100) can generate the first software binary using the compilation technique determined in step (608). The binary build module (310) can store the generated first software binary in the binary database (308). In one embodiment, the first software binary may be stored in the binary database (308) along with information representing a situation in which the first software binary is suitable.

[0119] In step (608), the software binary warehouse (100) can distribute the first software binary to the first base station. The software distribution module (306) of the software binary warehouse (100) can distribute the first software binary generated by the binary build module (310) to the first base station. The binary build module (310) can distribute the first software binary to the first base station using an API supported by the first base station. For example, based on the first base station operating according to O-RAN specifications, the binary build module (310) can distribute the first software binary to the first base station using the RIC interface of O-RAN.

[0120] In step (610), the software binary warehouse (100) can obtain updated status information from the first base station. The first base station may report status information of the first base station based on the first software binary to the software binary warehouse (100) periodically, non-periodically, or based on satisfying specific conditions. The statistics database (312) can store status information of the first base station that is periodically received from the first base station. Accordingly, the software binary warehouse (100) can identify the real-time status of the first base station.

[0121] In step (612), based on the updated status information, the software binary warehouse (100) may determine whether to distribute a software binary different from the first software binary to the first base station. The warehouse management module (302) of the software binary warehouse (100) may monitor the updated status information of the first base station. The warehouse management module (302) may request the intelligent binary selection module (304) to select a new software binary suitable for the updated status information of the first base station. Additionally or alternatively, based on the fact that the updated status information of the first base station satisfies certain conditions, the warehouse management module (302) may determine to generate a second software binary different from the first software binary. Step (612) will be described in detail later with reference to FIGS. 10 and FIGS. 11.

[0122] In one embodiment, the software binary warehouse (100) and the first base station may operate based on O-RAN specifications. To establish the first base station, an E2 setup procedure may be performed to exchange application-level data necessary for the base station and the near-real-time RIC (206) of FIG. 2 associated with the software binary warehouse (100) to properly interoperate over the E2 interface. The purpose of the E2 setup procedure may be to establish a signaling connection between the base station (12) and the near-real-time RIC (206). The base station (12) may initiate the E2 setup procedure by transmitting an E2 setup request to the near-real-time RIC (206). The E2 setup request may include initialization information. For example, the E2 setup request may include information indicating the message type, a global E2 node identifier (ID), a list of added RAN functions, and a list of E2 node component configuration updates. If the E2 configuration is acceptable, the near-real-time RIC (206) can transmit an E2 configuration response message to the base station (12). If the E2 configuration is not acceptable, the near-real-time RIC (206) can transmit an E2 configuration failure message to the base station (12). The E2 configuration response message may include information for initializing the first base station. The E2 configuration response message may be used to distribute an initial software binary to the first base station.

[0123] In one embodiment, an RIC subscription procedure may be performed to provide a software binary to a first base station. A near-real-time RIC (206) may initiate the RIC subscription procedure by sending a RIC subscription request message containing a unique RIC request ID to the first base station (target E2 node). The RIC subscription procedure may be used to establish RIC subscriptions on the E2 node, which includes an event trigger and a sequence of RIC service actions. The RIC subscription request message may include information indicating RIC subscription details. The information indicating RIC subscription details may include information indicating a RIC event trigger definition, a sequence of actions, an action ID, and / or an action type. If the RIC subscription is acceptable, the first base station may send a response message to the near-real-time RIC (206). In one embodiment, the RIC subscription request message may be used to distribute a new software binary to the first base station.

[0124] Additionally or alternatively, the first base station may periodically report at least one of the software profiles of the first base station based on the first software binary to the software binary warehouse (100). Based on the software profile of the first base station, the software binary warehouse (100) may determine whether to distribute a software binary different from the first software binary to the first base station. Distributing a software binary different from the first software binary to the first base station based on the software profile of the first base station will be described in detail later with reference to FIGS. 12 and 13.

[0125] Additionally or alternatively, after step (602), the software binary warehouse (100) may select any one of the software binaries stored in the binary database (308) based on the acquired operational information and status information of the first base station. For example, the intelligent binary selection module (304) may select any one of the binaries stored in the binary database (308) based on the operational information and status information of the first base station in a manner similar to the method described above with reference to FIG. 4. Each of the binaries stored in the binary database (308) may have a target scenario (or optimization goal). The intelligent binary selection module (304) may infer the binary most suitable for the first base station based on the operational information and status information of the first base station.

[0126] FIG. 7 illustrates an exemplary flowchart of a method (700) for determining a compiling technique according to one embodiment of the present disclosure.

[0127] Referring to FIG. 7, the method (700) may include steps (702, 704). Steps (702, 704) may be included in step (604) of FIG. 6. In one embodiment, the method (700) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and steps (702, 704) may be performed individually or in combination by any electronic device. A method for determining a compiling technique according to one embodiment of the present disclosure is not limited to that shown in FIG. 7, any one of the steps shown in FIG. 6 may be omitted, and additional steps not shown in FIG. 7 may be included. In some embodiments, the order of at least some of the steps (702, 704) may be changed.

[0128] In step (702), the software binary warehouse (100) can predict a communication policy to be applied to the first base station based on the operational information and / or status information of the first base station. The binary build module (310) of the software binary warehouse (100) can obtain the operational information and status information of the first base station. The binary build module (310) can predict a communication policy suitable for the operational information and status information of the first base station. "Communication policy" may mean a policy that the first base station is predicted to use for wireless communication according to one or more communication standards followed by the first base station (e.g., various standards for wireless communication such as O-RAN standards or 3GPP standards). According to some communication standards, under certain target scenarios, some communication methods, techniques, policies, or parameters may be used or not used (e.g., may be enabled). The binary build module (310) can determine one or more communication policies suitable for the operation scenario of the first base station based on the operation information of the first base station and the status information of the first base station. For example, the communication policy may include at least one of a policy for determining one or more sets of one or more parameters to be used for the first base station to generate a specific signal, or a policy for determining one or more sets of one or more parameters to be used for the first base station to process a signal received from another terminal.

[0129] For example, the operational information of the first base station may include information indicating that the coverage of the first base station is 5 km. Accordingly, the binary build module (310) can predict one or more communication policies suitable for wireless communication of 5 km coverage based on the communication standards followed by the first base station (e.g., various standards for wireless communication such as O-RAN standards or 3GPP standards). The status information of the first base station may include information indicating that the throughput of the first base station is equal to or close to the current maximum throughput. Accordingly, the binary build module (310) can predict one or more communication policies suitable for wireless communication of maximum throughput based on the communication standards followed by the first base station.

[0130] In step (704), based on the predicted communication policy, the software binary warehouse (100) may determine whether to apply a first compilation optimization technique to the source code for the first software binary. Based on the predicted communication policy in step (702), the binary build module (310) may determine to apply one or more of the various compilation optimization techniques. As described above, under a specific target scenario, some communication methods, techniques, policies, or parameters may be used or not used (e.g., may be enabled). Based on the predicted communication policy, the binary build module (310) may optimize the compiler with the goal of lowering the cost required for executing code that is expected to be used essentially or relatively frequently when running a program for wireless communication at the first base station. Based on the predicted communication policy, the binary build module (310) may remove or disable code that is expected not to be used.

[0131] A binary build module (310) of a software binary warehouse (100) may utilize one or more techniques to optimize the compiler. Compiling optimization techniques may include at least one of changing the layout of the source code or adjusting the prediction probability of each branch of the source code. Changing the layout of the source code may include various compiling techniques such as changing the location of at least one basic block included in the source code, applying dead code removal to at least one code block included in the source code, applying loop unrolling to at least one loop included in the source code, applying tail merging to at least one function included in the source code, or applying inlining to at least one function included in the source code.

[0132] FIG. 8 illustrates an exemplary flowchart of a method (800) for determining a compiling technique associated with logic for generating a PRACH (Physical Random Access Channel) signal according to one embodiment of the present disclosure.

[0133] Referring to FIG. 8, the method (800) may include steps (802 to 810). Step (702) of FIG. 7 may include step (802), and step (704) of FIG. 7 may include steps (804, 806, 808, 810) of FIG. 8. In one embodiment, the method (800) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and steps (802 to 810) may be performed individually or in combination by any electronic device. According to one embodiment of the present disclosure, a method for determining a compiling technique associated with logic for generating a PRACH signal is not limited to that shown in FIG. 8, any one of the steps shown in FIG. 8 may be omitted, and additional steps not shown in FIG. 8 may be included. For example, the method (800) may not include at least one of the steps (804 to 810). In some embodiments, the order of at least some of the steps (802 to 810) may be changed.

[0134] In step (802), the software binary warehouse (100) may select logic for the first base station to generate a PRACH signal (sequence) based on the operation information of the first base station and the status information of the first base station. PRACH may be an uplink channel for a terminal (e.g., user terminal or user equipment) to access the base station. The terminal may obtain a Synchronization Signal Block (SSB) of the downlink from a nearby base station. Based on the information contained in the SSB, the terminal may generate a PRACH signal and transmit the generated PRACH signal to the base station. The PRACH signal may be generated based on information associated with the base station based on the SSB. The PRACH signal may include information for identifying the terminal (e.g., a terminal identifier). The base station may identify the connection of the terminal based on the PRACH signal.

[0135] In one embodiment, the PRACH sequence may be generated in accordance with Section 6.3.3.1 of 3GPP Technical Specification (TS) 38.211. For example, when generating the PRACH sequence, no frequency restrictions may be applied (unrestricted set), the frequency of the signal may be restricted (restricted set A), or the repetition of the signal may be restricted (restricted set B). By applying restricted set A or restricted set B, interference that may occur from a terminal moving at high speed may be eliminated. Restricted set B may be used when the terminal moves at a relatively higher speed than when using restricted set A. The restrictions applied to the generation of the PRACH sequence may be set when establishing (or expanding) the base station. For each set, one or more parameters (e.g., signal length) used to generate the PRACH sequence may be predefined. For example, depending on the selected set, the formula for generating the PRACH signal, the length of the signal, and / or the number of repetitions of the signal may change.

[0136] In step (802), the binary build module (310) of the software binary warehouse (100) can obtain operational information of the first base station. The operational information of the first base station may include environmental information of the first base station indicating the environment in which the equipment of the first base station is located. For example, the operational information of the first base station may include information indicating that the first base station is located near a railway, information indicating that it is located at a concert venue, information indicating that it is included in a network of a private space, or information indicating that it is located in a logistics warehouse. In one embodiment, the operational information of the first base station may be obtained from a telecommunications operator or directly from the first base station. The binary build module (310) can select a PRACH signal generation logic suitable for the operational information of the first base station. Selecting the PRACH signal generation logic may include selecting any one of the aforementioned unrestricted set, restricted set A, or restricted set B for the first base station, and selecting a PRACH signal generation logic corresponding to the selected set.

[0137] In steps (804 to 810), the binary build module (310) of the software binary warehouse (100) may determine whether to apply each of the various compiling techniques to the first software binary. Based on the PRACH signal generation logic selected in step (802), the binary build module (310) may optimize the compiler. For example, for each compiling optimization technique, the binary build module (310) may determine whether to apply the corresponding compiling optimization technique based on the selected PRACH signal generation logic. Additionally or alternatively, the binary build module (310) may obtain the software profile of the first base station and / or the status information of the first base station from the statistical database (312). For example, the binary build module (310) may obtain the software profile of the first base station based on the execution of the software binary previously distributed to the first base station. The binary build module (310) can obtain real-time status information of the first base station including KPIs of the first base station. For example, the KPIs of the first base station may include measurements of the base station or terminal defined in one or more communication standards, such as Mobility Management according to O-RAN.WG3.E2SM-KPM or 3GPP TS 28.552. Based on at least one of the operational information of the first base station, the status information of the first base station, or the software profile of the first base station, the binary build module (310) can optimize a compiler for generating the first software binary.

[0138] In step (804), the binary build module (310) may determine whether to move the location of a basic block associated with selected logic, included in the source code for the first software binary, adjacent to a dominant block. A "basic block" may refer to a sequence of code units that are not branched. For example, a basic block may have one entry point and one exit point, and there may be no conditional statements or loops within the basic block. Thus, the code within the basic block may be executed sequentially from beginning to end. At any branch or loop point, a new basic block may begin. To analyze the source code, the compiler may break the source code into multiple basic blocks. When graphing the source code, the basic blocks may form vertices or nodes in a control-flow graph (CFG). A CFG may be a graph representing all paths that a program can traverse during execution. A "dominant block" can refer to a basic block that must be visited in a CFG, such as the starting point of a program. If all paths from the entry node to basic block A pass through basic block B, basic block B can be said to dominate basic block A. A dominant block can also be referred to as a dominator.

[0139] The binary build module (310) can analyze the source code used to generate the first software binary. The source code can be broken down into one or more basic blocks. The binary build module (310) can identify one or more dominant blocks included in the source code. Based on the PRACH signal generation logic selected in step (802), for each basic block, the binary build module (310) can determine whether to place its position adjacent to the dominant block during compilation. If multiple basic blocks are placed adjacent to the dominant block through compilation, the efficiency of the instruction cache can be increased, and consequently, the operation of the processor can be optimized when the first software binary is executed at the first base station. Accordingly, the binary build module (310) can place one or more basic blocks associated with the PRACH signal generation logic selected in step (802) adjacent to the dominant block.

[0140] For example, in step (802), the binary build module (310) can identify that the terminals of the first base station tend to have low mobility based on the mobility management parameters included in the operation information and status information of the first base station. Accordingly, the binary build module (310) predicts that an unrestricted set is applied when generating a PRACH signal for the first base station, and based on this prediction, can select logic for generating an unrestricted set of PRACH signals. In step (804), the binary build module (310) can optimize the compiler so that the basic blocks associated with the logic for generating an unrestricted set of PRACH signals are located adjacent to the dominant block.

[0141] In step (806), the binary build module (310) may determine whether to apply dead code elimination to code included in the source code for the first software binary that is not associated with selected logic. Dead code elimination may be a compilation optimization technique to remove dead code that does not affect the program. Accordingly, the binary size may be reduced, memory usage including the instruction cache may be reduced, and the execution of tasks not associated with the running program may be prevented. Additionally, branches and implementations for dead code may be removed, so the structure of the program may be simplified and branch prediction performance may be improved.

[0142] For example, the binary build module (310) may induce dead code removal for some codes based on the communication policy predicted in step (802). The unrestricted set and the restricted set for the PRACH signal may be used exclusively from each other. Accordingly, the binary build module (310) may directly or indirectly instruct the compiler not to build code for the set not selected in step (802) when compiling the first software. For example, if logic associated with restricted set A is selected for PRACH generation in step (802), in step (804), the binary build module (310) may optimize the compiler so that code associated with the unrestricted set is disabled during compilation.

[0143] In one embodiment, the binary build module (310) may induce the removal of dead code for specific code using a preprocessor or enumerated parameters, but is not limited thereto. The binary build module (310) may define specific variables used in the preprocessor as arbitrary constants or use conditional statements to selectively compile code. The binary build module (310) may at least partially prevent the compilation of specific code by defining specific variables as enumerated parameters and restricting the values ​​of said variables. For example, the binary build module (310) may use a preprocessor to induce code associated with an unrestricted set to be disabled during compilation. The binary build module (310) may restrict the values ​​of variables associated with an unrestricted set to induce code associated with an unrestricted set to be disabled during compilation.

[0144] In step (808), the binary build module (310) may determine whether to apply loop unrolling to loops included in the source code for the first software binary based on the length of the PRACH signal and the number of repetitions of the PRACH signal according to the generated logic. Loop unrolling may be a compiler optimization technique that unpacks and lists the implementation of a loop. Through loop unrolling, a single loop in the source code can be broken down into multiple code sequences during compilation. For example, instead of the loop, a sequence of instructions corresponding to the loop can be inserted into the binary file. Accordingly, branching statements (e.g., termination conditions, etc.) caused by the loop may be reduced, but there is a trade-off in that the size of the binary increases due to loop unrolling.

[0145] For at least one loop in the source code, the compiler of the binary build module (310) may calculate a loop unrolling score (or loop unrolling factor) based on the number of iterations of the loop and the number of codes inside the loop. The loop unrolling score may be an evaluation metric for determining whether to apply unrolling. The loop unrolling score may be a value that evaluates the potential for performance improvement through unrolling. If the calculated score satisfies a critical condition, the compiler may decide to apply unrolling to the loop. For example, the critical condition may correspond to the calculated score being equal to or greater than a predefined threshold. Based on the calculated unrolling score being equal to or greater than the threshold, the compiler may apply unrolling to the loop.

[0146] Additionally or alternatively, the binary build module (310) may determine whether to apply in-lining to a function containing a loop. In-lining may refer to replacing a function call with the function body code. For example, if a specific function is implemented with specific code within the source code, the entire code of the function may be directly inserted within the binary file instead of calling the function. For at least one function within the source code, the compiler of the binary build module (310) may calculate an in-lining score based on the number of codes inside the function. If the calculated score satisfies a critical condition, the compiler may decide to apply in-lining to the function. For example, the critical condition may correspond to the calculated score being equal to or greater than a predefined threshold value. Based on the calculated score being equal to or greater than the threshold value, the compiler may apply in-lining to the function. For functions containing loops, whether to apply unrolling to the loop can affect whether to apply inlining to the function.

[0147] For example, the binary build module (310) may determine whether to apply unrolling to at least one loop included in the source code based on the communication policy predicted in step (802). The length of the PRACH sequence and the number of repetitions of the PRACH signal may be determined according to the PRACH signal generation logic determined in step (802). The binary build module (310) may calculate an unrolling score (or unrolling factor) for at least one loop included in the source code based on the length of the PRACH sequence and the number of repetitions of the PRACH signal according to the determined PRACH signal generation logic. For example, based on the length of the PRACH sequence and the number of repetitions of the PRACH signal, the binary build module (310) may calculate an unrolling score for at least one loop associated with PRACH signal generation included in the source code. The length of the PRACH sequence and the number of repetitions may be relatively more correlated with the length of the loop and the number of repetitions of the loop, and thus the accuracy of the unrolling score may be increased. As a result, the accuracy of the decision on whether to apply unrolling to the loop can be improved, and the performance of compilation optimization can also be improved.

[0148] Additionally or alternatively, the binary build module (310) may determine whether to apply inlining to at least one function included in the source code based on the communication policy predicted in step (802). The binary build module (310) may calculate an inlining score for at least one function included in the source code based on the length of the PRACH sequence according to the determined PRACH signal generation logic. For example, based on the length of the PRACH sequence, the binary build module (310) may calculate an inlining score for at least one function associated with the PRACH signal generation included in the source code. The length of the PRACH sequence may be relatively more correlated with the length of the function, and thus the accuracy of the inlining score may be increased. Consequently, the accuracy of the decision on whether to apply inlining to the corresponding function may be improved, and the performance of compilation optimization may also be improved.

[0149] In step (810), based on selected logic, the binary build module (310) may determine whether to apply tail-merge to at least one function included in the source code for the first software binary. Tail-merge may refer to merging the common parts when the last tail parts of different code paths are identical. For example, if the last N codes of function A and function B are identical (N is a natural number), the common codes may be separated into separate regions. When function A and function B are called, a jump to the separated regions may be induced at the end. Tail-merge may reduce code size and improve memory usage efficiency, but at the same time, unnecessary jumps may occur. For at least two functions in the source code, the compiler of the binary build module (310) may calculate a tail-merge score based on the length of the common code between the functions. If the calculated score satisfies a critical condition, the compiler may decide to apply tail-merge to the corresponding functions. For example, a critical condition may correspond to a calculated score being equal to or greater than a predefined threshold. Based on whether the calculated score is equal to or greater than the threshold, the compiler may apply tail merging to the corresponding functions. To prevent unnecessary jumps, the binary build module (310) may adjust the threshold for tail merging. The adjusted threshold may be applied to only a part of the source code as well as the whole. For at least two functions in a first part of the source code, the binary build module (310) may calculate a first score based on a first threshold and a second score based on a second threshold. The binary build module (310) may compare the performance of tail merging based on the first score with the performance of tail merging based on the second score.Based on the comparison result, the binary build module (310) can derive a threshold value suitable for the first part.

[0150] For example, the binary build module (310) may determine whether to apply tail merging to at least two functions included in the source code based on the communication policy predicted in step (802). If only one of the unrestricted set and the restricted set for the PRACH signal is used, tail merging may result in unnecessary branches. For example, the first function associated with the unrestricted set and the second function associated with the restricted set may actually be used exclusively (i.e., only one of them). Therefore, if tail merging is applied to the first function and the second function, unnecessary branches or jumps may occur. The binary build module (310) may determine an optimal threshold for tail merging to prevent unnecessary jumps from occurring.

[0151] In the embodiment illustrated in FIG. 8, code layout modification, loop unrolling, dead code removal, and tail merging are exemplified as compilation optimization techniques, but the embodiments of the present disclosure are not limited thereto. A person skilled in the art will understand that various compilation optimization techniques may be applied additionally or alternatively in the embodiments of the present disclosure, taking into account the predicted communication policy.

[0152] A first software binary can be generated based on a compiling technique determined according to method (800). The generated first software binary can be stored in a binary database (308). Subsequently, the software binary warehouse (100) can distribute the stored first software binary to base stations suitable for operational conditions (e.g., base stations where it is determined that the first software binary is needed). For example, if the first software binary is a binary suitable for an unrestricted set, the intelligent binary selection module (304) can select the first software binary for base stations where frequency restrictions are predicted not to apply to PRACH signal generation. Accordingly, the first software binary can be distributed to such base stations.

[0153] According to method (800), a software binary warehouse (100) can predict a communication policy associated with a PRACH to be used at a base station and optimize a compiler based on the predicted communication policy. Based on the predicted communication policy, the software binary warehouse (100) can place codes predicted to be frequently used adjacently within a binary file. Based on the predicted communication policy, the software binary warehouse (100) can remove or disable codes predicted not to be used (e.g., dead codes) within the binary file. Based on parameters associated with the predicted communication policy, the software binary warehouse (100) can determine whether to apply compilation techniques such as loop unrolling, inlining, or tail merging. By predicting the communication policy of a base station based on the base station's operational information, status information, or software profile, and optimizing the compiler in consideration of the predicted communication policy, the performance of the compiler optimization can be improved, and a software binary optimized for a specific operational scenario can be provided.

[0154] FIG. 9 illustrates an exemplary flowchart of a method (900) for determining a compiling technique associated with Low Density Parity Check (LDPC) channel coding according to one embodiment of the present disclosure.

[0155] Referring to FIG. 9, the method (900) may include steps (902 to 906). Step (702) of FIG. 7 may include step (902), and step (704) of FIG. 7 may include steps (904, 906) of FIG. 9. In one embodiment, the method (900) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and steps (902 to 906) may be performed individually or in combination by any electronic device. A method for determining a compiling technique associated with LDPC coding according to one embodiment of the present disclosure is not limited to that shown in FIG. 9, any one of the steps shown in FIG. 9 may be omitted, and additional steps not shown in FIG. 9 may be included. For example, the method (900) may not include at least one of steps (904, 906). In some embodiments, the order of at least some of the steps (902 to 906) may be changed.

[0156] In step (902), the software binary warehouse (100) can predict an LDPC base graph for the first base station based on the signal quality information of the first base station and / or the environment information of the first base station included in the status information of the first base station. To transmit uplink data to the base station, the terminal can perform channel coding on the data. Depending on some communication standards, the terminal can perform channel coding using LDPC coding. LDPC coding may refer to a technique that uses a low-density parity check matrix to detect errors in data and correct errors. To perform LDPC coding, a code rate and a base graph may be determined.

[0157] The code rate may refer to the ratio of information to total data, including the data to be transmitted by the terminal and the redundancy required for error correction. For example, the code rate may refer to the ratio of the number of information bits to the total number of codeword bits encoded through LDPC coding. A higher code rate may improve transmission efficiency because it contains more information bits and fewer parity bits; however, since it lowers error correction performance, it may not be suitable for environments with weak signals or high noise. The code rate may be determined based on the signal quality of the terminal. For example, the code rate may be determined based on information indicating signal quality, such as the Channel Quality Indicator (CQI) or the Modulation and Coding Scheme (MCS). The better the signal quality, the closer the code rate can be to 1. Information indicating the signal quality of the terminal, such as the CQI or MCS, may be provided to the base station through an interface between the base station and the terminal (e.g., an O-RAN E2 interface). The base station can include information indicating the signal quality of the terminal in its status information.

[0158] An LDPC base graph may be a structure representing a basic parity check matrix that defines an LDPC code. An LDPC code may be constructed based on the base graph. For example, each code block of a transport block may be encoded into an LDPC base graph. According to the 3GPP NR specification, either Base Graph 1 or Base Graph 2 may be selected as the base graph for LDPC coding. The base graph may be determined based on the code rate (or coding rate) and the transport block size (or payload size). In one embodiment, the selection of the LDPC base graph may be based on Section 6.2.2 or Section 7.2.2 of 3GPP TS 38.212.

[0159] In step (902), the binary build module (310) of the software binary warehouse (100) can predict a base graph of an LDPC code for the first base station based on the signal quality information of the first base station included in the status information of the first base station and / or the environment information of the first base station included in the operation information of the first base station. The signal quality information of the first base station may include information for determining the code rate. For example, the signal quality information of the first base station may include CQI defined in O-RAN.WG3.E2SM-KPM or 3GPP TS 38.214. Based on the signal quality information of the first base station, the binary build module (310) can identify that the signal quality of a number of terminals connected to the first base station is good. Accordingly, the binary build module (310) can predict that the first base station will use base graph 2 for LDPC coding. Otherwise, the binary build module (310) can predict that the first base station will use base graph 1 for LDPC coding. Additionally or alternatively, the binary build module (310) can identify, based on the environment information of the first base station, that the first base station is located in an environment where it is predicted to be noisy (e.g., an environment where a large number of users exist, such as a concert hall, or an environment where there are many radio interferences, such as walls or trees). Accordingly, the binary build module (310) can predict (or identify) that the signal quality of many terminals connected to the first base station will not be good, and also predict that the first base station will use base graph 1 for LDPC coding.

[0160] In steps (904, 906), the binary build module (310) of the software binary warehouse (100) can determine whether to apply each of the various compiling techniques to the first software binary. Based on the LDPC base graph predicted in step (902), the binary build module (310) can optimize the compiler. For example, for each compiling optimization technique, the binary build module (310) can determine whether to apply the corresponding compiling optimization technique based on the predicted LDPC base graph.

[0161] In step (904), the binary build module (310) may determine whether to move the location of a basic block associated with a predicted base graph included in the source code for the first software binary to be adjacent to a dominant block. The binary build module (310) may determine that, for one or more basic blocks associated with the implementation of the predicted LDPC base graph in step (902), they will be moved to be adjacent to a dominant block during compilation. Accordingly, when the part of the first software binary associated with LDPC coding is executed at the first base station, the memory usage and CPU (Central Processing Unit) usage of the first base station may be optimized.

[0162] In step (906), the binary build module (310) may determine whether to apply loop unrolling for at least one loop included in the source code for the first software binary based on the length of the predicted base graph. Depending on the LDPC base graph, the length (or size) of the matrix required for LDPC coding may vary. LDPC base graph 1 may support a longer transmission block (or LDPC code) than LDPC base graph 2. The binary build module (310) may provide the length of the predicted base graph as the number of iterations of the loop to the compiler to calculate the loop unrolling score (or loop unrolling factor). Accordingly, the application of unrolling may be determined by considering the predicted base graph.

[0163] In the embodiment illustrated in FIG. 9, code layout modification and loop unrolling are exemplified as compilation optimization techniques, but the embodiments of the present disclosure are not limited thereto. A person skilled in the art will understand that in the embodiments of the present disclosure, various compilation optimization techniques may be applied additionally or alternatively in consideration of a predicted communication policy (e.g., LDPC base graph).

[0164] A first software binary can be generated based on a compiling technique determined according to the method (900). The generated first software binary can be stored in a binary database (308). Subsequently, the software binary warehouse (100) can distribute the stored first software binary to base stations suitable for operational conditions (e.g., base stations where it is determined that the first software binary is needed). For example, if the first software binary is a binary suitable for LDPC base graph 1, the intelligent binary selection module (304) can select the first software binary for base stations predicted to use LDPC base graph 1. Accordingly, the first software binary can be distributed to such base stations.

[0165] According to method (900), a software binary warehouse (100) can predict a communication policy associated with LDPC to be used at a base station and optimize a compiler based on the predicted communication policy. Based on the predicted communication policy, the software binary warehouse (100) can place codes predicted to be frequently used adjacently within a binary file. Based on parameters associated with the predicted communication policy, the software binary warehouse (100) can determine whether to apply compilation techniques such as loop unrolling. By predicting the communication policy of a base station based on the base station's operational information, status information, or software profile, and optimizing the compiler in consideration of the predicted communication policy, the performance of the compiler optimization can be improved, and a software binary optimized for a specific operational scenario can be provided.

[0166] FIG. 10 illustrates an exemplary flowchart of a method (1000) for determining whether to distribute a software binary different from a first software binary to a first base station according to one embodiment of the present disclosure.

[0167] Referring to FIG. 10, the method (1000) may include steps (1002 to 1008). In one embodiment, the method (1000) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and the steps (1002 to 1008) may be performed individually or in combination by any electronic device. According to one embodiment of the present disclosure, the method for determining whether to distribute a software binary different from the first software binary to the first base station is not limited to that shown in FIG. 10, any one of the steps shown in FIG. 10 may be omitted, and additional steps not shown in FIG. 10 may be included. In some embodiments, the order of at least some of the steps (1002 to 1008) may be changed.

[0168] In step (1002), the software binary warehouse (100) may select a software binary for the first base station from among one or more software binaries stored in the software binary database based on updated status information. The first base station may periodically report its status information to the software binary warehouse (100). The status information of the first base station may be stored in the statistics database (312). The warehouse management module (302) may identify that the status information of the first base station has been updated. Based on the status information of the first base station, the warehouse management module (302) may determine whether replacement or updating of the software binary of the first base station is required. For example, the warehouse management module (302) may detect that the status information of the first base station has changed and, based on the change in the status information of the first base station, decide to select a software binary for the first base station.

[0169] The warehouse management module (302) may request the intelligent binary selection module (304) to select a software binary for the first base station, along with updated status information of the first base station. Accordingly, the intelligent binary selection module (304) may select a software binary for the first base station from among the binaries stored in the binary database (308) in a manner similar to the method described above with reference to FIG. 4.

[0170] In step (1004), the software binary warehouse (100) can determine whether the selected software binary and the first software binary are different. For example, the intelligent binary selection module (304) can transmit the software binary selected in step (1002) to the software distribution module (306). The software distribution module (306) can determine whether the software binary selected by the intelligent binary selection module (304) and the software binary previously distributed to the first base station (i.e., the first software binary) are different from each other. Based on the updated status information of the first base station, and based on the fact that the software binary selected in step (1002) is different from the first software binary, in step (1006), the software distribution module (306) of the software binary warehouse (100) can determine to distribute the selected software binary to the first base station. Accordingly, the software distribution module (306) can distribute the software binary selected in step (1002) to the first base station. The first base station can execute the redistributed software binary.

[0171] Based on the updated status information of the first base station, and based on the fact that the software binary selected in step (1002) is different from the first software binary, in step (1008), the software distribution module (306) of the software binary warehouse (100) may decide not to distribute the selected software binary to the first base station. In one embodiment, the software distribution module (306) may notify the warehouse management module (302) that it has decided not to distribute the software binary selected in step (1002) to the first base station.

[0172] The first base station may report the status information of the first base station to the software binary warehouse (100) periodically, non-periodically, and / or when certain conditions are met. The software binary warehouse (100) may detect that the status information of the first base station has been updated. In response to the update of the status information of the first base station, the software binary warehouse (100) may re-select a software binary for the first base station based on the updated status information of the first base station. If the re-selected software binary is different from the current software binary of the first base station, the software binary warehouse (100) may distribute the re-selected software binary to the first base station. If the re-selected software binary is the same as the current software binary of the first base station, the software binary warehouse (100) may not distribute the re-selected software binary to the first base station.

[0173] FIG. 11 illustrates an exemplary flowchart of a method (1100) for distributing a second software binary different from a first software binary to a first base station according to one embodiment of the present disclosure.

[0174] Referring to FIG. 11, the method (1100) may include steps (1102 to 1108). In one embodiment, the method (1100) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and steps (1102 to 1108) may be performed individually or in combination by any electronic device. A method for distributing a second software binary different from a first software binary to a first base station according to one embodiment of the present disclosure is not limited to that shown in FIG. 11, any one of the steps shown in FIG. 11 may be omitted, and additional steps not shown in FIG. 11 may be included. In some embodiments, the order of at least some of the steps (1102 to 1108) may be changed.

[0175] In step (1102), based on updated status information, the software binary warehouse (100) may decide to generate a second software binary for the first base station that is different from the first software binary. The first base station may periodically report status information of the first base station to the software binary warehouse (100). The status information of the first base station may be stored in a statistical database (312). The warehouse management module (302) may identify that the status information of the first base station has been updated. Based on the updated status information of the first base station, the warehouse management module (302) may decide whether to generate a second software binary for the first base station. Based on the decision of the warehouse management module (302) to generate a second software binary for the first base station, the warehouse management module (302) of the software binary warehouse (100) may request the binary build module (310) to generate the second software binary based on the updated status information of the first base station.

[0176] In one embodiment, the warehouse management module (302) may determine that the performance of the first software binary previously distributed to the first base station does not meet the expected performance based on at least one KPI included in the updated status information of the first base station. Based on the determination that the performance of the first software binary does not meet the expected performance, the warehouse management module (302) may determine to generate a second software binary for the first base station.

[0177] For example, based on the fact that the real-time KPI of the first base station included in the updated status information of the first base station is different from the expected KPI based on the operation of the first software binary, the warehouse management module (302) may determine that the performance of the first software binary does not meet the expected performance. Based on the fact that at least one performance indicator included in the updated status information of the first base station is smaller or larger than a predefined threshold value, or based on the fact that the difference between the value of the performance indicator and the corresponding expected value (or target value) is greater than a predefined threshold value, the warehouse management module (302) may determine that the performance of the first software binary does not meet the expected performance.

[0178] Additionally or alternatively, the warehouse management module (302) may compare the value of at least one index included in the updated state information of the first base station with the corresponding value included in the previous (e.g., immediate) state information. Based on whether the amount of change of the latest value relative to the previous value is equal to or greater than a predefined threshold, the warehouse management module (302) may determine to generate a new second software binary for the first base station. Based on whether the difference between the previous value and the latest value is equal to or greater than a predefined threshold, the warehouse management module (302) may determine to generate a new second software binary for the first base station.

[0179] For example, the previous state information of the first base station (e.g., state information obtained in step (602)) may include coverage with a value of 5 km. The updated state information may include coverage with a value of 10 km. The warehouse management module (302) may compare the coverage value included in the updated state information of the first base station with the coverage value included in the previous state information. The difference between the previous value, i.e., 5 km, and the latest value, i.e., 10 km, may be 5 km. In one embodiment, a predefined threshold value for coverage may be 5 km. Accordingly, based on the fact that the difference between the previous coverage value and the latest coverage value is equal to the predefined threshold value for coverage, the warehouse management module (302) may decide to generate a new second software binary for the first base station.

[0180] In step (1104), the software binary warehouse (100) may determine a compilation technique for generating a second software binary based on updated state information of the first base station. For example, based on updated state information of the first base station, the binary build module (310) may determine a compilation technique suitable for the current situation of the first base station or optimize a compiler for generating the second software binary. The binary build module (310) may determine to apply all or some of the various compilation optimization techniques to generate the second software binary.

[0181] In step (1106), the software binary warehouse (100) may generate a second software binary based on a compiling technique for generating a second software binary. The binary build module (310) of the software binary warehouse (100) may generate the second software binary using the compiling technique determined in step (1104). Additionally or alternatively, the binary build module (310) may store the generated second software binary in a binary database (308). In one embodiment, the second software binary may be stored in the binary database (308) along with information representing a situation in which the second software binary is suitable (e.g., information associated with updated status information of the first base station).

[0182] In step (1108), the software binary warehouse (100) can distribute the second software binary to the first base station. The binary build module (310) of the software binary warehouse (100) can distribute the second software binary generated in step (1106) to the first base station using an API supported by the first base station. For example, based on the first base station operating according to O-RAN specifications, the binary build module (310) can distribute the second software binary to the first base station using the RIC interface of the O-RAN.

[0183] According to the method (1000) illustrated in FIG. 10 and the method (1100) illustrated in FIG. 11, a software binary warehouse (100) may obtain real-time status information from a network device (e.g., a base station device) within a RAN and, based on the real-time status information, replace the binary of the device with a software binary optimized for the device. In response to obtaining real-time status information of the base station, the software binary warehouse (100) may re-select a software binary for the base station according to the method (1000) and distribute the re-selected software binary to the base station. If the real-time status information of the base station satisfies one or more predefined conditions (e.g., significantly different from previous status information or the current performance of the base station does not meet expected performance), the software binary warehouse (100) may regenerate a software binary for the base station according to the method (1100) and distribute the regenerated software binary to the base station. Otherwise, the software binary warehouse (100) may re-select a software binary for a base station according to the method (1000), and distribute the re-selected software binary to the base station based on the fact that the re-selected software binary is different from the base station's current software binary. Accordingly, the base station can maintain the software binary best suited for the current base station.

[0184] FIG. 12 illustrates an exemplary flowchart of a method (1200) for distributing a second software binary different from a first software binary to a first base station based on the software profile of the first base station according to one embodiment of the present disclosure.

[0185] Referring to FIG. 12, the method (1200) may include steps (1202, 1204, 1206). In one embodiment, the method (1200) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and the steps (1202, 1204, 1206) may be performed individually or in combination by any electronic device. According to one embodiment of the present disclosure, a method of distributing a second software binary different from a first software binary to a first base station based on the software profile of a first base station is not limited to that shown in FIG. 12, any one of the steps shown in FIG. 12 may be omitted, and additional steps not shown in FIG. 12 may be included. In some embodiments, the order of at least some of the steps (1202, 1204, 1206) may be changed.

[0186] In step (1202), the software binary warehouse (100) may obtain the software profile of the first base station. The first base station may periodically report (or transmit) the software profile associated with the software binary running on the first base station to the software binary warehouse (100). The software profile of the first base station may be stored in the statistical database (312) of the software binary warehouse (100). The software profile of the first base station may include information related to the operation of the software binary currently running on the first base station. The software profile may include information related to the code itself within the software binary and information related to hardware resources associated with the execution of the software binary.

[0187] In step (1204), the software binary warehouse (100) may decide to distribute a second software binary different from the first software binary to the first base station based on the software profile of the first base station. The warehouse management module (302) may identify that the software profile of the first base station has been updated. Based on the updated software profile of the first base station, the warehouse management module (302) may decide to reselect the software binary for the first base station or regenerate the software binary for the first base station.

[0188] In one embodiment, based on at least one index included in the updated software profile of the first base station satisfying one or more predefined conditions for said index, the warehouse management module (302) may decide to generate a second software binary for the first base station. Otherwise, the warehouse management module (302) may re-select the software binary for the first base station and request the intelligent binary selection module (304) to re-select the software binary based on the updated software profile of the first base station. Based on the selection of a second software binary different from the first software binary by the intelligent binary selection module (304), the software distribution module (306) may decide to distribute the second software binary to the first base station. Based on the re-selection of the first software binary by the intelligent binary selection module (304), the software distribution module (306) may decide not to distribute the re-selected software binary to the first base station.

[0189] One or more predefined conditions for a specific index may include the specific index increasing or decreasing by a change amount equal to or greater than a threshold compared to a previous value, the specific index falling out of a predefined normal range, the specific index exceeding a predefined threshold, the specific index falling below a predefined threshold, and / or the specific index differing from an expected value. For example, based on the memory bound of the first base station falling out of a predefined normal range, the power consumption of the first base station exceeding the expected consumption, and / or the branch prediction failure rate of the first base station exceeding a predefined threshold, the warehouse management module (302) may decide to regenerate the software binary for the first base station.

[0190] Based on the decision to generate a second software binary for the first base station, the warehouse management module (302) may request the binary build module (310) to generate a second software profile based on the updated software profile of the first base station. The binary build module (310) may optimize the compiler based on the updated software profile of the first base station and generate the second software binary based on the optimized compiler. For example, the binary build module (310) may decide to apply one or more compilation techniques for the second software binary based on information indicating code included in the updated software profile of the first base station and / or information indicating hardware resources. Additionally or alternatively, the binary build module (310) may generate the second software binary based on current status information of the first base station and / or operational information of the first base station. The binary build module (310) may decide to distribute the second software binary to the first base station.

[0191] In step (1206), the software binary warehouse (100) can distribute the second software binary to the first base station. The binary build module (310) of the software binary warehouse (100) can distribute the second software binary to the first base station using an API supported by the first base station. For example, based on the first base station operating according to O-RAN specifications, the binary build module (310) can distribute the second software binary to the first base station using the RIC interface of the O-RAN.

[0192] FIG. 13 illustrates an exemplary flowchart of a method for distributing a second software binary different from a first software binary to a first base station based on the software profile of the first base station according to one embodiment of the present disclosure.

[0193] Referring to FIG. 13, the method (1300) may include steps (1302, 1304, 1306). Step (1204) of FIG. 12 may include steps (1302, 1304, 1306). In one embodiment, the method (1300) may be performed by the software binary warehouse (100) of FIG. 1. However, the present disclosure is not limited thereto, and steps (1302, 1304, 1306) may be performed individually or in combination by any electronic device. According to one embodiment of the present disclosure, a method of distributing a second software binary different from a first software binary to a first base station based on the software profile of a first base station is not limited to that shown in FIG. 13, any one of the steps shown in FIG. 13 may be omitted, and additional steps not shown in FIG. 13 may be included. In some embodiments, the order of at least some of the steps (1302, 1304, 1306) may be changed.

[0194] In step (1302), the software binary warehouse (100) can identify the code most frequently used to generate a specific signal by the first base station based on the software profile of the first base station. The binary build module (310) of the software binary warehouse (100) can receive a request from the warehouse management module (302) to generate a new software binary based on the updated software profile of the first base station. In response to the request from the warehouse management module (302), the binary build module (310) can analyze the updated software profile of the first base station. The binary build module (310) can detect one or more codes frequently used by the first base station (e.g., codes having an execution count equal to or greater than a predefined threshold). For example, the binary build module (310) can identify the execution count of a specific signal generation logic included in the current software binary code of the first base station and branch information of said logic.

[0195] In step (1304), based on the identified code, the software binary warehouse (100) can predict the communication policy currently being used by the first base station. For example, the binary build module (310) of the software binary warehouse (100) can predict one or more communication policies currently being used by the first base station based on the number of executions of a specific signal generation logic identified in step (1302) and branch information of said logic.

[0196] In one embodiment, the binary build module (310) can predict the PRACH signal generation logic currently in use at the first base station based on codes frequently executed at the first base station. The binary build module (310) can identify the number of executions of the PRACH signal generation logic and branch statistics of the logic (e.g., branch prediction failure rate and branch execution result for each branch) by analyzing the software profile of the first base station. Based on the identified number of executions of the PRACH signal generation logic and the branch statistics of the logic, the binary build module (310) can predict (or specify) the limit for generating the PRACH sequence currently in use at the first base station. For example, based on information indicating the number of executions of code(s) associated with the PRACH signal generation logic and the branches included in the PRACH signal generation logic, the binary build module (310) can predict whether there is no restriction applied to the current PRACH signal generation at the first base station (e.g., using an unrestricted set) or whether a specific restriction is applied (e.g., using a restricted set A or a restricted set B).

[0197] In step (1306), based on the predicted communication policy, the software binary warehouse (100) may decide to distribute the second software binary to the first base station. The binary build module (310) may optimize the compiler based on the predicted communication policy in step (1304), generate the second software binary using the optimized compiler, and decide to distribute the second software binary to the first base station. The binary build module (310) may decide whether to apply one or more of various compiler optimization techniques based on the predicted communication policy in step (1306).

[0198] In one embodiment, the binary build module (310) can optimize the compiler in a manner similar to the method described above with reference to FIG. 8, based on the PRACH signal generation logic of the base station predicted in step (1304). For example, the binary build module (310) can improve instruction cache efficiency by positioning the PRACH signal generation logic predicted in step (1304) adjacent to the dominant block. For at least one loop included in the PRACH signal generation logic predicted in step (1304), the binary build module (310) can obtain the number of iterations of the loop from the first software profile and determine whether to apply unrolling to the loop based on the obtained number of iterations. For at least one function included in the PRACH signal generation logic predicted in step (1304), the binary build module (310) can obtain the number of executions of the function from the first software profile and determine whether to apply inlining to the function based on the obtained number of executions. The binary build module (310) can place codes associated with predicted PRACH signal generation logic and exclusive logic (e.g., PRACH signal generation logic not predicted to be used at the first base station) relatively far from the dominant block. The binary build module (310) can apply dead code removal to the codes associated with predicted PRACH signal generation logic and exclusive logic.

[0199] In step (1306), the software binary warehouse (100) can distribute the second software binary to the first base station. The binary build module (310) of the software binary warehouse (100) can distribute the second software binary to the first base station using an API supported by the first base station. For example, based on the first base station operating according to O-RAN specifications, the binary build module (310) can distribute the second software binary to the first base station using the RIC interface of O-RAN. Additionally or alternatively, the binary build module (310) can store the second software binary in the binary database (308). The software binary warehouse (100) can distribute the second software binary to other base stations that are similar in situation to the first base station.

[0200] FIG. 14 illustrates an exemplary block diagram of a software binary warehouse (100) according to one embodiment of the present disclosure.

[0201] Referring to FIG. 14, the software binary warehouse (100) may be an electronic device comprising a processor (1402), memory (1404), and a transceiver (1406). The configuration of the software binary warehouse (100) shown in FIG. 14 is merely an example, and the examples of DUs performing an embodiment of the present disclosure are not limited to the configuration shown in FIG. 14. Depending on the embodiment, some configurations may be added, deleted, or changed.

[0202] The processor (1402) can control the overall operations of the software binary warehouse (100). For example, the processor (1402) transmits and receives signals through the transceiver (1406). The processor (1402) can write data to memory (1404) and read data written to memory (1404). The processor (1402) can perform the functions of the protocol stack required by the communication standard. In one embodiment, the processor (1402) may include at least one processor including processing circuitry.

[0203] In one embodiment, the processor (1402) may optimize a compiler to suit a specific network device connected to a software binary warehouse (100), generate a software binary using the optimized compiler, and distribute the generated software binary to the specific network device using a transceiver (1406). Based on at least one of the operational purpose, current state, or characteristics associated with the software and / or hardware of the specific network device, the processor (1402) may select one of one or more software binaries stored in memory (1404) and distribute the selected software binary to the specific network device using a transceiver (1406). The processor (1402) may periodically monitor the state of the specific network device or at least one of the characteristics associated with the software and / or hardware, and replace or update the software binary of the specific network device based on the monitoring. Additionally or alternatively, the processor (1402) can control the software binary warehouse (100) to perform at least some of the operations according to the aforementioned embodiment.

[0204] Additionally or alternatively, the processor (1402) may execute one or more instructions of a program stored in memory (1404). The processor (1402) may be composed of hardware components that perform arithmetic, logic, and input / output operations and image processing. Although the processor (1402) is depicted as a single element in FIG. 3, it is not limited thereto. In one embodiment of the present disclosure, the processor (1402) may be composed of one or more elements. The processor (1402) may be implemented as a general-purpose processor such as a CPU (Central Processing Unit), AP (Application Processor), DSP (Digital Signal Processor), a graphics-dedicated processor such as a GPU (Graphic Processing Unit) or VPU (Vision Processing Unit), or an artificial intelligence-dedicated processor such as an NPU (Neural Processing Unit).

[0205] The processor (1402) may include various processing circuits and / or multiple processors. For example, the term 'processor' as used in the disclosure, including in the claims, may include at least one processor and, additionally or alternatively, may include various processing circuits. One or more processors may be configured to perform the various functions described in the disclosure individually and / or collectively in a distributed manner (e.g., any combination of the operations of the warehouse management module (302) of FIG. 3, the operations of the intelligent binary selection module (304), the operations of the software distribution module (306), or the operations of the binary build module (310) as described above with reference to FIG. 3 through FIG. 13). As used herein, 'processor', 'at least one processor', and 'one or more processors' may be configured to perform various functions. However, these terms cover, without limitation, situations where one processor performs part of the functions and other processor(s) perform other parts of the functions, and situations where a single processor can perform all functions. Additionally, at least one processor may include a combination of processors that perform various functions of the functions initiated in a distributed manner. At least one processor may execute program instructions individually or in combination to achieve or perform various functions.

[0206] The memory (1404) can store instructions, data structures, and program code that can be read by the processor (1402). For example, the memory (1404) can store data such as a basic program, an application program, and configuration information for the operation of the software binary warehouse (100). In one embodiment, the memory (1404) can store instructions that can cause the software binary warehouse (100) to perform at least some of the operations of the software binary warehouse (100) described below by being executed individually or in combination by the processor (1402). For example, the processor (1402) can perform at least some of the operations of the software binary warehouse (100) described in this disclosure by executing one or more instructions or codes stored in the memory (1404).

[0207] The memory (1404) can store one or more software binaries generated by the processor (1402) and information associated with each binary. The memory (1404) can store information received by the software binary warehouse (100) (e.g., operation information, status information, and / or software profile of a specific network device). The memory (1404) may include one or more storage media. The memory (1404) may include flash memory type, hard disk type, multimedia card micro type, and card type memory, and may include non-volatile memory such as DRAM (Dynamic Random Access Memory) or SRAM (Static Random Access Memory), and / or volatile memory such as ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), PROM (Programmable Read-Only Memory), magnetic memory, magnetic disk, and optical disk, at least one of. In one embodiment, the memory (1404) may include the binary database (308) and the statistical database (312) of FIG. 3.

[0208] The transceiver (1406) can perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (1406) may include a wired interface for controlling a direct connection between devices through a transmission medium (e.g., copper wire or optical fiber). For example, the transceiver (1406) can transmit an electrical signal to another device through a copper wire or perform conversion between an electrical signal and an optical signal. The transceiver (1406) can communicate with other components within the control platform (102) of FIG. 1. The transceiver (1406) can communicate with other network devices within a communication operator (11) or a wireless access network (10).

[0209] The transceiver (1406) may include an antenna section. The transceiver (1406) may include at least one antenna array composed of a plurality of antenna elements. In terms of hardware, the transceiver (1406) may be composed of digital circuits and / or analog circuits (e.g., a radio frequency integrated circuit (RFIC)). Here, the digital circuits and / or analog circuits may be implemented in a single package. Additionally, the transceiver (1406) may include a plurality of RF chains. The transceiver (1406) may perform beamforming. The transceiver (1406) may apply beamforming weights to a signal to impart directionality to the signal to be transmitted or received according to the settings of the processor (1402). According to one embodiment, the transceiver (1406) may include a radio frequency (RF) block (or RF section). The transceiver (1406) can transmit a synchronization signal, a reference signal, system information, a message, a control message, a stream, control information, or data.

[0210] Software deployed to base stations may need to be replaced or updated over time. The software deployed to base stations and the base station's configuration may need to be updated periodically for management, maintenance, and repair. As the surrounding environment of a base station changes over time, one or more parameters related to wireless communication, such as coverage, power consumption, or throughput, or one or more wireless communication policies may need to be modified in real time. For example, a base station adjacent to a subway station may experience a rapid increase in the number of users or traffic volume during rush hour. A base station adjacent to a stadium, concert hall, or theater may experience a rapid increase in the number of users due to a game or performance. For base stations included in a private network for a specific location or a large-scale closed network such as a smart factory or logistics warehouse, the conditions of the location or the status of IoT (Internet of Things) equipment located there may change. To cover the changed communication environment, the parameters and / or policies used for wireless communication may be modified by the base station. Accordingly, the base station software may need to be replaced with software optimized to target the modified parameters and / or policies.

[0211] To configure network nodes included in a traditional RAN, a virtualized RAN (vRAN), or a RAN according to O-RAN specifications, telecommunications operators providing network services via software and device manufacturers providing network devices may need to collaborate. For example, software program code used to configure a base station may constitute a trade secret of the base station device manufacturer; therefore, telecommunications operators and device manufacturers may need to prepare for software replacement together to (re)distribute the base station software. For instance, the device manufacturer may perform the software binaryization, while the telecommunications operator may perform the actual software distribution.

[0212] According to one embodiment of the present disclosure, a software binary warehouse (100) may receive information from a telecommunications operator indicating the purpose of operation of a network device. The software binary warehouse (100) may receive from a network device at least one of information indicating the current state of the network device, characteristics of software running on the network device, or hardware characteristics of the network device. Based on at least one of the purpose of operation of the network device (e.g., base station), the current performance of the network device, characteristics of software running on the network device, or hardware characteristics of the network device, the software binary most suitable for the network device may be distributed in real time. Accordingly, the software of the base station may be replaced in real time with software optimized to target modified parameters and / or policies.

[0213] For example, a software binary warehouse (100) can generate and distribute software binaries optimized for the operational purposes of a network device (e.g., maximum supportable throughput, low power / high power mode, etc.) based on real-time status information of a network device obtained from a network device (e.g., one or more KPIs, throughput information, cell coverage information, etc.) and / or a software profile of a network device. Among one or more software binaries, the software binary warehouse (100) can select and distribute software binaries optimized for the operational purposes of a network device based on real-time status information of a network device obtained from a network device and / or a software profile of a network device.

[0214] The software binary warehouse (100) can store and manage software binaries optimized for various operation scenarios. The software binary warehouse (100) can select the software binary most suitable for the base station based on the base station's operation purpose, current status, and / or software profile, and distribute the selected software binary to the base station. The software binary warehouse (100) can retrain the software binary selection algorithm based on status information periodically received from the base station or evaluation indicators for the binary (e.g., KPI, power consumption, number of serving terminals, number of cells, etc.) included in the software profile.

[0215] At least some of the methods according to one embodiment of the present disclosure may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium (or recording medium). The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the present disclosure, or may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

[0216] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, "non-transitory storage medium" simply means a tangible device that does not contain a signal (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily. For example, a "non-transitory storage medium" may include a buffer in which data is stored temporarily.

[0217] According to one embodiment, the method according to the various embodiments disclosed herein may be provided by being included in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or distributed online (e.g., download or upload) through an application store or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product (e.g., downloadable app) may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0218] Although the embodiments have been described above with reference to limited examples and drawings, those skilled in the art can make various changes and modifications from the description above. For example, appropriate results can be achieved even if the described techniques are performed in a different order than described, and / or components such as the described computer system or module are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

Claims

1. A step of obtaining operation information and status information of the first base station (602); A step (604) of determining a compiling technique based on the operation information of the first base station and the status information of the first base station; A step (606) of generating a first software binary for the first base station based on the above compiling technique; Step (608) of distributing the first software binary to the first base station; Step (610) of obtaining updated status information from the first base station; and A method comprising the step (612) of determining whether to distribute a software binary different from the first software binary to the first base station based on the updated status information above.

2. In Paragraph 1, A method comprising at least one of the following: operational information of the first base station, the number of minimum supported terminals of the first base station, the number of maximum supported terminals of the first base station, the coverage of the first base station, the maximum supported throughput of the first base station, information associated with the highest performance mode of the first base station, or information associated with the low power mode of the first base station.

3. In Paragraph 1 or 2, A method comprising at least one of the status information of the first base station, the Key Performance Indicator (KPI) of the first base station, the throughput of the first base station, or the cell coverage of the first base station.

4. In any one of paragraphs 1 through 3, The step of determining the above compiling technique is based on the operation information of the first base station and the status information of the first base station: A step of determining whether to change the location of at least one basic block included in the source code for the first software binary; A step of determining whether to apply dead code elimination to at least one code block included in the source code; A step of determining whether to apply loop unrolling to at least one loop included in the source code; or A method comprising at least one step of determining whether to apply tail merge or in-lining to at least one function included in the source code.

5. In any one of paragraphs 1 through 4, The method further includes the step of storing the above-mentioned first software binary in a software binary database, and The above software binary database is a method for storing one or more software binaries.

6. In Paragraph 5, The step of determining whether to distribute a software binary different from the first software binary to the first base station is: A step of selecting a software binary for the first base station from among the one or more software binaries stored in the software binary database based on the updated status information above; A step of determining to distribute the selected software binary to the first base station based on the fact that the selected software binary and the first software binary are different; and A method comprising the step of determining not to distribute the selected software binary to the first base station based on the fact that the selected software binary and the first software binary are identical.

7. In Paragraph 5 or 6, A step of acquiring operational information and status information of the second base station; A step of selecting a software binary for the second base station from among the one or more software binaries stored in the software binary database based on the operation information and status information of the second base station; and A method further comprising the step of distributing the selected software binary to the second base station.

8. In any one of paragraphs 1 through 7, The step of determining whether to distribute a software binary different from the first software binary to the first base station includes the step of determining to generate a second software binary different from the first software binary for the first base station based on updated state information of the first base station. The above method is: A step of determining a compilation technique for generating the second software binary based on updated state information of the first base station; A step of generating the second software binary based on a compiling technique for generating the second software binary; and A method further comprising the step of distributing the second software binary to the first base station.

9. In any one of paragraphs 1 through 8, The step of determining a compiling technique based on the operation information of the first base station and the status information of the first base station is: A step of selecting a logic for the first base station to generate a PRACH (Physical Random Access Channel) signal based on the operation information of the first base station; A step of determining whether to move the position of a basic block associated with the selected logic, included in the source code for the first software binary, to be adjacent to a dominant block; A step of determining whether to apply dead code removal to code included in the source code that is not associated with the selected logic; For a loop included in the source code, a step of determining whether to apply loop unrolling based on the length of the PRACH signal according to the selected logic and the number of repetitions of the PRACH signal; and A method comprising the step of determining whether to apply tail merging to a function included in the source code based on the logic selected above.

10. In any one of paragraphs 1 through 9, The step of determining a compiling technique based on the operation information of the first base station and the status information of the first base station is: A step of predicting a Low Density Parity Check (LDPC) base graph for the first base station based on signal quality information of the first base station and environment information of the first base station included in the status information of the first base station; A step of determining whether to move the position of a basic block associated with the predicted base graph, included in the source code for the first software binary, to be adjacent to a dominant block; and A method comprising the step of determining whether to apply loop unrolling based on the length of the predicted base graph for a loop included in the source code.

11. In any one of paragraphs 1 through 10, A step of obtaining the software profile of the first base station; A step of determining to distribute a second software binary different from the first software binary to the first base station based on the software profile of the first base station; A step of determining a compiling technique for generating the second software binary based on the software profile of the first base station; A step of generating the second software binary based on a compiling technique for generating the second software binary; and A method further comprising the step of distributing the second software binary to the first base station.

12. In Paragraph 10 or 11, A method wherein the software profile of the first base station comprises at least one of the following: the number of executions of each line of each code of the first software binary during a specific time period, the number of repetitions of each loop of the first software binary, statistical information of each branch of the first software binary, the number of calls to each function of the first software binary, or cache bound information of the processor of the first base station.

13. A computer-readable recording medium having a program recorded thereon for performing the method of any one of paragraphs 1 through 12 on a computer.

14. In an electronic device (100), At least one processor (1402) including a processing circuit; and It includes a memory (1404) comprising one or more storage media for storing one or more instructions, and When the above one or more instructions are executed individually or in combination by the above at least one processor (1402), the electronic device (100) causes: Acquire operational information and status information of the first base station; Based on the operation information of the first base station and the status information of the first base station, a compiling technique is determined; Based on the above compiling technique, a first software binary for the first base station is generated; Distribute the above-mentioned first software binary to the above-mentioned first base station; Obtaining updated status information from the first base station; and An electronic device that determines whether to distribute a software binary different from the first software binary to the first base station based on the above-mentioned updated status information.

15. In Paragraph 14, The above one or more instructions are executed individually or in combination by the at least one processor, thereby enabling the electronic device to additionally, based on the operation information of the first base station and the status information of the first base station: Determining whether to change the location of at least one basic block included in the source code for the first software binary; Determining whether to apply dead code elimination to at least one code block included in the above source code; Determining whether to apply loop unrolling to at least one loop included in the source code above; or An electronic device that performs at least one of determining whether to apply tail merge or in-lining to at least one function included in the source code above.

Images