Inference using inline real-time machine learning models in applications

Abstract

Examples are described for inferring results based on application data using code segments executing within an application with a machine learning (ML) model. Code segments may be dynamically loaded into an application during execution. The controller verifies that the code segment meets security requirements for execution within the application based on an extended Berkelike Packet Filter (eBPF) bytecode of the code segment. A computing device executing an application loads the validated code segment into a library of the application. The application executes the validated code segment to apply the application data to the machine learning model to infer a result. The ML machine learning model may be implemented by eBPF code of a code segment, or the code segment may include a call to the machine learning model, the type of which is supported by a controller of the application, and a mapping of serialized representations for the machine learning model. The computing device may reconstruct an ML model based on the serialized representation.

Description

Background Art

[0001] A radio access network (RAN) can provide wireless access to a network to multiple user devices. User devices can communicate wirelessly with a base station, which forwards the communication to the core network. Typically, a base station in a RAN is implemented by dedicated processing hardware (e.g., an embedded system) located near a radio unit including an antenna. A base station can perform low-level processing including physical (PHY) layer and media access control (MAC) layer processing for one or more cells. There may be associated costs for deploying dedicated processing hardware for each base station in a RAN, particularly for a RAN that includes small cells with relatively small coverage areas. In addition, the dedicated processing hardware may be a single point of failure for a cell.

[0002] The virtualized radio access network can utilize an edge data center with general computing resources to perform RAN processing for one or more cells. That is, instead of performing PHY and MAC layer processing locally on dedicated hardware, the virtualized radio access network can forward radio signals from the radio unit to the edge data center for processing, and similarly forward signals from the edge data center to the radio unit for wireless transmission. In a specific example, a cloud computing environment can be used to provide mobile edge computing (MEC), where certain functions of the mobile network can be provided as workloads on nodes in a cloud computing environment. In the MEC, a centralized unit (CU) can be implemented in a backend node, one or more distributed units (DU) can be implemented in an intermediate node, and various remote units RU (which can provide at least the PHY and / or MAC layers of a base station or other RAN node of a mobile network) can be deployed at an edge server. The RU can communicate with the CU via one or more DUs. In the example, the DU can provide higher network layer functions for the RAN, such as radio link control (RLC) or packet data convergence protocol (PDCP) layer functions. The RU can facilitate access to the CU for various downstream devices (e.g., user equipment (UE), Internet of Things (IoT) devices, etc.).

[0003] Because edge data centers utilize general-purpose computing resources, virtualized RAN can provide scalability and fault tolerance for base station processing. For example, an edge data center can allocate a variable number of computing resources (e.g., multiple servers) to perform PHY layer processing for radio units associated with the edge data center based on workload. In addition, virtualized RAN can implement multi-layer RAN processing at the data center, enabling the collection of multiple data feeds. Summary of the invention

[0004] A simplified overview of one or more aspects is given below to provide a basic understanding of these aspects. This overview is not an extensive overview of all contemplated aspects, and is intended to neither identify key elements of all aspects nor identify the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to a more detailed description that is presented later.

[0005] In some aspects, the technology described herein relates to a method for executing a machine learning model within an application, comprising: verifying that the code segment meets security requirements for execution within the application based on an extended Berkeley Packet Filter (eBPF) bytecode of a code segment; loading the verified code segment into a hook point of the application; and executing the verified code segment to apply application data to the machine learning model to infer a result.

[0006] In some aspects, the technology described herein relates to a method in which a code segment includes code that implements a pre-trained machine learning model.

[0007] In some aspects, the technology described herein relates to a method in which a code segment includes a call to a machine learning model and a mapping to a serialized representation of the machine learning model, where the type of the machine learning model corresponds to one of multiple machine learning model types supported by a controller of an application.

[0008] In some aspects, the techniques described herein relate to a method in which loading a validated code segment includes determining that a serialized representation of a machine learning model is parsable based on a type.

[0009] In some aspects, the technology described herein relates to a method in which the multiple machine learning model types supported by the controller include two or more of the following: a random forest model, a long short-term memory (LSTM) model, a convolutional neural network (CNN), or a recurrent neural network (RNN) model.

[0010] In some aspects, the technology described herein relates to a method in which loading a validated code segment includes rebuilding a machine learning model within a memory allocated to an application based on a serialized representation of the machine learning model.

[0011] In some aspects, the techniques described herein relate to a method in which a call to a machine learning model includes a mapping to a serialized representation and a data structure that includes application data as an input parameter and returns a result.

[0012] In some aspects, the techniques described herein relate to a method that also includes storing, by the code segment, the result for access outside of the application.

[0013] In some aspects, the techniques described herein relate to a method that also includes making a decision, by the application, based on the result.

[0014] In some aspects, the techniques described herein relate to a method in which the application is a virtualized radio access network (vRAN) function.

[0015] In some aspects, the technology described herein relates to an apparatus for executing a machine learning model within an application, comprising: a memory storing computer-executable instructions; and at least one processor configured to execute instructions to: receive a compiled and verified code segment, wherein an extended Berkeley Packet Filter (eBPF) of the code segment has been verified to meet security requirements for execution within the application; load the verified code segment into a hook point of the application; and execute the verified code segment to apply application data to the machine learning model to infer a result.

[0016] In some aspects, the technology described herein relates to an apparatus in which a code segment includes code to implement a pre-trained machine learning model.

[0017] In some aspects, the technology described herein relates to an apparatus wherein a code segment includes a call to a machine learning model and a mapping to a serialized representation of the machine learning model, where the type of the machine learning model corresponds to one of a plurality of machine learning model types supported by a controller of an application.

[0018] In some aspects, the techniques described herein relate to an apparatus in which at least one processor is configured to determine that a serialized representation of a machine learning model is parsable based on a type.

[0019] In some aspects, the technology described herein relates to an apparatus wherein the multiple machine learning model types supported by a controller include two or more of the following: a random forest model, a long short-term memory (LSTM) model, a convolutional neural network (CNN), or a recurrent neural network (RNN) model.

[0020] In some aspects, the technology described herein relates to an apparatus in which at least one processor is configured to: reconstruct a machine learning model within a memory allocated to an application based on a serialized representation of the machine learning model.

[0021] In some aspects, the techniques described herein relate to an apparatus in which a call to a machine learning model includes a mapping and a data structure for a serialized representation, the data structure including application data as an input parameter and returning a result.

[0022] In some aspects, the techniques described herein relate to an apparatus in which at least one processor executing a code segment is configured to store results in an output schema map for access outside of an application.

[0023] In some aspects, the techniques described herein relate to an apparatus in which a processor executing an application is configured to make a decision based on a result.

[0024] In some aspects, the techniques described herein relate to an apparatus in which the application is a virtualized radio access network (vRAN) function.

[0025] To accomplish the foregoing and related ends, one or more aspects include features fully described below and particularly pointed out in the claims. The following description and the accompanying drawings set forth in detail certain illustrative features of one or more aspects. However, these features are indicative of only some of the various ways in which the principles of the various aspects may be employed, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a diagram of an example virtualized radio access network vRAN connecting a user equipment (UE) to a core network.

[0027] Figure 2 is a diagram of an example gate system that provides a code execution framework that allows for secure dynamic loading of custom code, including machine learning models, in a sandbox environment.

[0028] Figure 3 An example architecture for loading code segments in a container orchestration system is shown.

[0029] Figure 4 is an example code listing for code snippets that may be executed in a vRAN using the example gate system.

[0030] Figure 5 is a diagram illustrating the use of code snippets to execute a machine learning model within an application.

[0031] Figure 6 is a schematic diagram of an example of an apparatus for implementing a door device.

[0032] Figure 7 is a flowchart of an example of a method for executing a code segment including a machine learning model in an application.

[0033] Figure 8 is a flow diagram of an example of a method for loading a code segment into an application executing in a container.

[0034] Fig. 9 An example of a device is shown, the device comprising Figure 6 Additional optional component details are shown. DETAILED DESCRIPTION

[0035] The detailed description set forth below in conjunction with the accompanying drawings is intended as a description of various configurations and is not intended to represent the only configuration in which the concepts described herein may be practiced. The detailed description includes specific details for providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some cases, well-known components are shown in block diagram form to avoid obscuring such concepts.

[0036] The present disclosure describes various examples related to using code segments for analysis and control. In particular, code segments can be limited to runtime thresholds that can be set at the microsecond level to provide fine-grained, real-time, preemption of code segments. For example, such preemption is useful in real-time environments such as virtualized radio access networks (vRANs) that have strict timing control over network functions.

[0037] A key shift in the radio access network (RAN) in 5G is the migration to an open RAN architecture, which enables 5G RAN to be virtualized and disaggregated across multiple open interfaces. This approach promotes innovation by allowing multiple vendors to propose unique solutions for different components at a faster pace. In addition, the introduction of a new component called the Radio Intelligent Controller (RIC) in the open RAN architecture allows third parties to build new, vendor-agnostic monitoring and optimization use cases through O-RAN standardized interfaces.

[0038] Despite the appeal of this vision, the opportunity for innovation remains largely untapped due to two major challenges. The first challenge is related to flexible data collection for monitoring and telemetry applications. RAN functions can generate large amounts of telemetry data at high frequencies (e.g., gigabytes per second). Collecting, transmitting, and processing this data can put a strain on computing and network capacity. The conventional approach standardized by the 3rd Generation Partnership Project (3GPP) defines small groups of aggregated cell key performance indicators (KPIs) collected every few seconds or minutes. The O-RAN RIC extends this idea by providing new KPIs with finer time granularity. Each KPI is defined through a service model (in the form of an API), most of which are standardized by O-RAN. However, this approach has evolved slowly and has not scaled well due to the limited number of initial use cases and the need to standardize new proposals. The second challenge stems from the real-time nature of many RAN control and data plane operations. To support new service models, any new functionality added to these operations must be completed within deadlines, which typically range from nanoseconds (μs) to milliseconds (ms). Violating deadlines can result in performance degradation or even the collapse of the vRAN. Any changes to these critical paths can create significant design challenges and make RAN vendors reluctant to add new features.

[0039] In one aspect, the present disclosure describes a system that provides dynamic monitoring and control of vRAN functions through a provably secure execution environment. The system can provide access and security to the execution environment and can be referred to as a gate system. The system extends the RIC concept, allowing vRAN operators to write their own monitoring and control code without the assistance of vendors. These monitoring and control codes, referred to as code segments, can be deployed at different vRAN components at runtime without interrupting vRAN operations. Code segments are typically executed inline on the vRAN critical path, so the code segments have direct access to all important internal vRAN data structures and can collect arbitrary statistics. Existing and new O-RAN service models can be implemented as code segments, and code segments can be used to implement fast control operations such as radio resource allocation. The code segment model can be extended to other computing environments. For example, code segments may also be useful in industrial automation or robotic control, where strict time requirements also exist. In one aspect, code segments can be deployed into applications to execute workloads via a container orchestration system that loads code segments into containers and links code segments to hook points within applications through symbols.

[0040] To provide the above functions, the system design pays special attention to security, efficiency and flexibility. The system utilizes the extended Berkeley Packet Filter (eBPF) technology, which solves similar problems in the Linux kernel. The Linux community has observed that the predefined kernel API limits its observability and controllability. To this end, eBPF was developed as a sandbox execution environment in which system operators can deploy custom code that can access and modify selected kernel structures. Before loading a code segment, the eBPF execution environment statically verifies it and only allows safe code segments to run. eBPF has created a large number of new applications at all levels of the Linux kernel.

[0041] The gate system strives to achieve similar goals in the RAN space and other environments. The gate system is built on the userspace implementation of eBPF, called the Userspace Berkeley Packet Filter (uBPF), while leveraging the existing tools of the eBPF toolchain, such as compilers and verifiers. At a high level, the gate system runs code snippets inside a uBPF virtual environment that is inlined in the control and data paths of a deployed system (e.g., vRAN). For vRAN, there are two main sets of unique challenges.

[0042] The first set of challenges is about flexibility. It is not clear how much and which RAN monitoring or control data is needed to build useful applications. The system focuses on key locations, interfaces, and abstractions within the standard vRAN architecture that provide rich and diverse data from only a few collection points. The system includes a toolchain that allows developers to define arbitrary output data structures that are sent to the RIC. These data structures contrast with the existing Linux output data model that is constrained by a specific format. The gate system can provide a variety of applications. For example, 4 categories of applications have been implemented and tested: flexible statistics collection, interference detection, network slice scheduler, and real-time machine learning (ML) prediction. These categories include 17 applications that add flexibility to vRAN. These applications (in addition to those defined in the RIC data model) cannot be deployed using the standard O-RAN RIC.

[0043] The second set of challenges is about security. The Linux kernel does not typically require strict, microsecond (μs) execution latencies, but this is important for vRAN operations. On the one hand, the system includes an eBPF patching mechanism that preempts code segments that exceed a certain runtime threshold. In addition, the gate system includes multiple features to ensure a lock-free and non-preemptive design in the fast path (where the code segment runs), minimizing the impact of the system on vRAN performance. The system can also include static verification to cover newly introduced flexible output data structures.

[0044] In one aspect, in order to execute the ML model within the application, the ML model can be included in the code segment as code or a call to a supported auxiliary function. The verifier can verify that the extended Berkeley Packet Filter (eBPF) bytecode of the code segment meets the security requirements for execution within the application. For relatively simple ML models, the code segment can include a pre-trained model, and the verifier can verify that the code segment including the ML model meets the security requirements. For more complex ML models, the code segment can include a call to an auxiliary function to infer or predict based on a machine learning model of a type supported by the system. For example, the system can define a variety of supported ML model types based on commonly used model types. The verification of such supported ML models can be performed offline by a trusted system. The code segment can define a specific ML model by including a mapping for a serialized representation of the ML model and a call to an auxiliary function. The system can rebuild a specific ML model according to the supported type based on the mapping. Since the code segment includes a call to a supported auxiliary function, the code segment can be verified. The system can load the verified code segment into the hook point of the application. The system can execute the verified code segment to apply application data to the ML model to infer the result.

[0045] In another aspect, the present disclosure provides a system for injecting code segments into running applications on a cluster of a container orchestration system. The code segments can provide additional capabilities, such as telemetry collection, configuration, or control. The system includes an application programming interface (API) server configured to receive a user configuration for a container image for an application. The user configuration includes a header indicating the dynamic loading of the code segment. The API service is configured to receive a configuration map for the code segment when the application is executed in the main container. The system includes a mutating webhook configured to modify the user configuration in response to the header. For example, the mutating webhook can add a sidecar container to run beside the main container of the container image; install one or more libraries into the main container, wherein the one or more libraries define functions associated with hook points within the application; modify the entry point for the main container to run a script that loads the one or more libraries; or mount a directory for compiled and verified code segments into the main container. The system includes a node agent configured to monitor the configuration map of the API server, compile and verify the code segment, and place the code segment in the directory. The system includes a controller configured to receive annotations to a user configuration via an API server. The sidecar container is configured to symbolically link the code segment to a hook point within the application based on the annotation.

[0046] On the one hand, a code segment including an ML model is loaded into an application, allowing customization of the application at runtime. For example, the ML model can be updated based on recent training or the current scenario. In addition, the code segment with the ML model is executed within the vRAN application, allowing customization of the vRAN application (e.g., by a network operator) without relying on standardized or vendor-specific solutions. In some embodiments, auxiliary functions are used to call ML models of supported types in the application memory, allowing complex ML models that cannot be independently verified to be dynamically loaded into the application. A mapping of output modes that can be written by the code segment is defined, allowing the code segment executed in the sandbox environment of the application to export data without compromising the security of the application. Therefore, the present disclosure provides various improvements to the functionality of a computer system (e.g., a vRAN).

[0047] Now turn to Figures 1 to 6 , examples are depicted with reference to one or more components and one or more methods that can perform the actions or operations described herein, where the components and / or actions / operations in dashed lines may be optional. Figure 7 and 8 The operations described in the description are presented in a particular order and / or performed by example components, but in some examples, the ordering of the actions and components performing the actions may vary depending on the implementation. In addition, in some examples, one or more of the actions, functions, and / or components described may be performed by a specially programmed processor, a processor executing specially programmed software or computer-readable media, or by any other combination of hardware components and software components capable of performing the described actions or functions.

[0048] Figure 1 is a diagram of an example vRAN 100 that connects a user equipment (UE) 110 to a core network 160. The vRAN 100 may include a radio unit 120 that sends and receives wireless signals with the UE 110. The vRAN 100 may include a virtual distributed unit (vDU) 130 that performs processing at layers such as a physical (PHY) layer, a medium access control (MAC) layer, and a radio link control (RLC) layer. The vRAN 100 may include a virtual central unit (vCU) 140 that performs processing at higher layers of a wireless protocol stack. The vRAN 100 may include a RAN intelligent control (RIC) that performs autonomous configuration and optimization of the vRAN 100.

[0049] The functional division between vDU 130 and vCU 140 may depend on the functional division architecture. vCU 140 may be divided into a central unit control plane (CU-CP) and a central unit user plane (CU-UP). CU-UP may include a packet data convergence protocol (PDCP) layer and a service data adaptation (SDAP) layer and a radio resource control (RRC) layer. Different components or layers may have different latency and throughput requirements. For example, the PHY layer may have a latency requirement between 125μs and 1ms and a throughput requirement greater than 1Gbps, the MAC and RLC layers may have a latency requirement between 125μs and 1ms and a throughput requirement greater than 100Mbps, and higher layers at the vCU may have a latency requirement greater than 125μs and a throughput requirement greater than 100Mbps.

[0050] Programmability in the open RAN components may be facilitated by a near real-time RIC 150. Network operators may install applications ((multiple) Apps 152, such as xApps in open RAN) on top of the RIC 150 that may collect detailed telemetry and may leverage the telemetry to optimize network performance or report issues in near real-time (e.g., >10ms to several seconds). Data collection and control of vRAN components may be facilitated by a service model that must be embedded in the vRAN functionality by the vendor. The service model may explicitly define the type and frequency of data reporting for each App 152, as well as a list of control policies that the RIC may use to modify RAN behavior. Each App 152 may specify its own service model, requiring the collection of different telemetry data.

[0051] The initial xApps proposed for standardization in Open RAN focus on optimized handover, self-organizing network (SON) functions, anomaly detection, and coarse-grained radio resource allocation. In these use cases, important network events occur at low rates (100s of milliseconds to seconds). The amount of telemetry data generated is small, and all data is transmitted to the RIC. This allows App 152 to have complete insight into the domain and adjust vRAN functions through a set of predetermined control policies. However, this approach cannot be extended to many other use cases for RAN monitoring and control for two main reasons.

[0052] First, for many lower layer applications (e.g., PHY and MAC), due to the large size of RIC (e.g., Figure 1As shown in the figure, it is inefficient to transmit all data to the RIC. For example, applications like positioning, channel estimation, interference detection, and beamforming may require uplink IQ samples from the physical layer. For 100MHz 4×4 multiple-input multiple-output (MIMO), transmitting all IQ samples to the RIC requires more than 5Gbps per cell. The standard RIC design overcomes this problem by specifying the type and frequency of required data (e.g., in raw or preprocessed format) in the service model of each App. The form of preprocessing (e.g., subsampling, averaging, or data subset) depends greatly on the service model, which imposes severe limitations on interoperability as vRAN vendors must implement and support each proprietary service model.

[0053] Second, many real-time control loops (e.g., packet scheduling and power control) have very tight timing constraints (<10ms). Such timing constraints cannot be met by standard RIC designs with expected latencies on the order of hundreds of milliseconds. As in the case of telemetry, the choice of control strategy by the application is constrained by a set of (standardized) strategies provided by an appropriate service model for the RIC. vRAN vendors are required to implement and integrate such algorithms in their stack while ensuring that they do not impact the runtime performance of vRAN components. This service model framework implanted by vRAN vendors makes it difficult to implement new custom variants of tight control loops in practice.

[0054] Figure 2 2 is a diagram of an example gate system 200 that provides a code execution framework that allows secure dynamic loading of custom code in a sandbox environment at different locations in a vRAN. The gate system may include a gate controller 210 that may be implemented at an RIC 150 and a gate device 230 that may be implemented at a network node such as a vDU 130 or a vCU 140.

[0055] The gate device 230 can be any application 232 that allows the execution of custom code, such as a vRAN component (e.g., a vCU or vDU process). The gate system 200 can execute custom code within a user mode version of eBPF (referred to as uBPF). An application 232, such as a vRAN component, is modified to introduce gate call points or hook points 234 at selected locations in the vRAN function where an eBPF virtual machine (VM) with custom code can be called. The call is inline with the vRAN code and provides the VM with read-only access to selected internal vRAN contexts, which include, for example, various 3GPP-defined data structures. Table 1 below provides exemplary hook points in the vRAN. Table 1

[0056] At runtime, the code segment 272 including custom code can be dynamically loaded and unloaded from the hook point 234 of the gate device 230. In some implementations, the code segment 272 may not affect the performance of the gate device 230 with respect to performing vRAN functions. For example, the code segment 272 may only collect data. In other embodiments, the code segment 272 may control vRAN functions (e.g., make scheduling decisions).

[0057] The gate code snippet 272 is custom code that can be deployed at a single hook point 234 on the gate device 230 at runtime. Developers can write the code snippet 272 in a programming language such as C, and use the eBPF compiler 252 to compile the code snippet into eBPF bytecode. Similar to any eBPF program, the gate code snippet 272 must be written in a way that allows the code snippet 272 to be statically verifiable (for example, the code must introduce memory checks and can only have bounded loops). Any potentially unsafe operations required by the code snippet 272 (for example, accessing memory outside the area that the code snippet is allowed to access) can only be performed through a set of whitelisted auxiliary functions 240 that are deemed safe by the framework. The code snippet 272 does not retain any state between two calls. All states must be stored in an external location called a mapping 236. For example, the code snippet 272 can send its telemetry data to the gate output thread 238 running at the gate device 230 through a special mapping 236, which forwards the telemetry data to the gate controller 210. In some embodiments, the code segment 272 calls the protobuf encoder to write to the special map 236. For each output stream (a map of type JANUS_MAP_TYPE_RINGBUF), a single-producer / single-consumer lockless ring buffer is created to push data from the code segment to the output thread 238. This ensures that the code segment will never be preempted and may only drop excess packets in the worst case.

[0058] The code segment set 270 may refer to a coordinated set of code segments that operate across multiple door hook points of a door device. The different code segments 272 in the code segment set 270 may be coordinated with very low latency via the shared mapping 236. If desired, code segments across devices may be coordinated via the door controller 210.

[0059] The gate controller 210 is responsible for controlling the gate devices 230 and the code segments 270. In the context of O-RAN, the gate controller 210 can be implemented as an App 152 on the RIC 150. Developers can upload code segments 270 to the controller 210 and attach instructions to load / unload them to one or more gate devices 230. For example, these instructions can be as follows about Figure 3Description provided to the container orchestration system. The controller 210 includes a bytecode verifier 214, which verifies the security and termination of each code segment before the controller 210 allows the code segment 270 to be loaded. For this purpose, an eBPF verifier (such as the open source PREVAILeBPF verifier) ​​can be extended to verify the gate auxiliary function and output mode. In some embodiments, the verifier 214 may include a parser 226, which verifies that the serialized representation of the ML model is parsable according to the type of the ML model. The controller 210 includes a bytecode patch 212, which is configured to further modify (or patch) the bytecode of the uploaded code segment with additional control code, and if the running time of the code segment exceeds a certain threshold, the additional control code can preempt the execution of the code segment. The controller 210 includes a just-in-time (JIT) compiler 216 for compiling the patched code segment. The controller 210 includes a network API 218, which is configured to push the compiled code segment to the gate device 230 over the network. The controller 210 may further include a metadata file generator 220 configured to provide a metadata file required for implementing flexible data output using a protobuf output mode. The controller 210 may further provide a data collector 222 that collects and deserializes data 224 sent from the gate code segment.

[0060] The gate system can also provide a gate SDK 250 that allows developers to locally test gate code snippets early in the development cycle. The SDK 250 includes a compiler 252, a validator 254, and a debugger 256, as well as a header file 258 that includes definitions of all helper functions and mapping types supported by the gate device 230.

[0061] The door code snippets 270 are JIT compiled and loaded to the door device 230 through the network API 218 provided by the door controller 210. Developers can upload the developed code snippets 270 to the door controller 210 and load the code snippets 270 to the door device 230 using tools provided by the door SDK 250. The instructions required to upload the code snippet set 270 to the door controller 210 and load the code snippet set 270 to the door device 230 are encoded in a descriptor file written in the yeto-another-markup-language (YAML) format.

[0062] The YAML file specifies at least the names of all code snippets that are part of the code snippet (eBPF byte code object files in ELF format), the name of the hook in the gate device 230 to which the code snippet should be linked, and the calling priority of the code snippet. Multiple code snippets can be linked to the same hook. The YAML file provides other optional configuration parameters for further configuring the code snippet, such as runtime thresholds.

[0063] Code segments 272 of the same code segment set 270 can share state and coordinates. This sharing may be particularly useful when performing monitoring or control operations that require associated events and data across different layers of the vRAN stack (for example, in the case of interference detection). State sharing between code segments of a code segment set is performed using a shared mapping 236. In order for this mechanism to work, the code segments that want to share state must use exactly the same definition for the type, key size (key_size), value size (value_size) and maximum number of entries (max_entries) of the shared mapping 236, while the name of the mapping can be different. Developers can then specify the mapping to be linked in the linked-maps section of the YAML descriptor file they use to load the code segment 270. When the code segment 270 is loaded, the memory for the shared mapping 236 is allocated only once on the gate device 230, and all code segments 272 that share the mapping 236 obtain a pointer to the same memory, which the code segment 272 can then call through the auxiliary function 240 to store and load state.

[0064] Figure 3 An example architecture 300 for loading code segments in a container orchestration system 302 is shown. For example, the container orchestration system 302 can be a Kubernetes system that executes applications within containers grouped into workload pods. In some embodiments, the application can be a vRAN function, and the gate device 230 can be implemented in a container. The architecture 300 includes a container API server 310, a variant network hook 320, a controller 330, a node agent 340, and a workload pod 370.

[0065] The container API server 310 can interact with the user 312 to configure the container for execution. For example, the user 312 can provide a configuration for the container image. In some embodiments, the configuration can be a yeto-another-markup-language (YAML) file or a JavaScript object representation (JSON) file that specifies container properties and resources. The configuration may include a header indicating the dynamic loading of a code segment. The container API server 310 can control the controller 330 and the node agent 340 to instantiate the main container 380 within the workload cabin 370 and provide resources for the container.

[0066] The mutation network hook 320 may include computer executable code for modifying a user configuration of a container image. For example, the mutation network hook 320 may modify the user configuration to add a capability for the main container 380 for dynamically loading code segments. For example, the mutation network hook 320 may add a sidecar container 372 to run alongside the main container 380 for the container image (e.g., within the workload pod 370). The mutation network hook 320 may install one or more libraries 382 into the main container 380. The library 382 may define functionality associated with a hook point 392 within an application 390. The mutation network hook 320 may modify an entry point for the main container to run a script that loads one or more libraries 382. For example, the script and library 382 may be defined by the common script and library 350. The mutation network hook 320 may install a directory 386 for compiled and verified code segments into the main container.

[0067] The node agent 340 may include computer executable code for dynamically loading code segments into the main container 380. The code segments may be dynamically defined by the user 312 via a configuration map for the code segments. The container API server 310 may receive the configuration map when the application 390 is executed in the main container 380. The node agent 340 may monitor the API server 310 for the configuration map. The node agent 340 may compile and verify the code segments to generate compiled and verified code segments 360. The node agent 340 may load the compiled and verified code segments 360 into the code segment directory 386.

[0068] The controller 330 may include computer executable code for controlling the workload pod 370 and the container, which includes the main container 380 and the sidecar container 372. The controller 330 may receive user-configured annotations to the container via the container API server 310. The annotation may associate the code segment with the hook point 392 of the application 390. The controller 330 may provide the annotation to the sidecar container 372. The sidecar container 372 may be configured to symbolically link the hook point 392 within the code segment application 390 indicated by the annotation. For example, the sidecar container 372 may symbolically link the code segment with the function in the library 382 associated with the hook point. Once the compiled and verified code segment 360 stored in the code segment directory 386 is symbolically linked to the hook point, the code segment may be considered as a mapped code segment 384. When the execution of the application 390 reaches the hook point and calls the function in the library 382, ​​the mapped code segment 384 may be executed via the symbolic link. Therefore, the code segment may be dynamically loaded and executed during the execution of the application 390.

[0069] In another embodiment, a user space implementation of the read-copy-update mechanism (RCU) can be used to dynamically load code segments to the hook point 234. RCU allows multiple non-coordinated readers to access shared data structures at the expense of longer write / update times. For example, the reader can be a fast vRAN thread that executes the code segment, and the writer is a (non-real-time) thread that updates the list of hooked code segments.

[0070] Figure 4 An example code listing 400 for a code segment 410 that can be executed in a vRAN using the system 200 is shown. In the example code listing, the system 200 and its components may be referred to as janus. The gate system 200 and / or architecture 300 implement new monitoring and control capabilities. The example code listing 400 refers to a code segment developed for OAI's vDU, which is an open source implementation of the 4G and 5G vRAN stack. At a high level, the example code segment 410 is called by a hook introduced at the functional API (FAPI) interface, which is used for communication between the PHY layer and the MAC layer of the vDU. The FAPI packet is a C structure that contains information for scheduling radio resources to a mobile device. In the example code segment, a counter maintaining the number of captured FAPI events is sent to the data collector 222 after every 1000 events. Although simple, this code segment captures important features that demonstrate the powerful capabilities of the gate system over conventional RIC designs.

[0071] Figure 4The state argument in line 22 of is the context passed to the function by the vRAN via hook point 234 (type janus_ran_fapi_ctx, lines 28 to 29). The state argument contains a pointer to a FAPIDL configuration request message of type nfapi_dl_config_request_pdu_t (lines 31 to 32). This message describes the complete scheduling allocation for a specific downlink timeslot, including more than 20 fields per mobile user, including modulation and coding scheme, transport block size, allocated resource blocks, MIMO layers, etc. The validator 24 ensures read-only access to the context information to achieve secure zero-copy access to the internal vRAN context. Due to the modular vRAN design, a small number of similar interfaces are specified in different standards (3GPP, Small Cell Forum) that carry all relevant states across vRAN components. By adding hook points at these interfaces, the gate controller can provide access to a large amount of vRAN telemetry to the gate code snippet developer. The hooks identified in Table 1 have been implemented. The hooks in Table 1 can be used to enable multiple RIC applications without modifying a single line of code inside the vRAN functionality other than adding the hook point. In some cases, the implementation of the interface may differ across vRAN vendors (e.g., in terms of C-structure memory layout). Due to the flexibility of the gate system, small changes in the code segment can be used to adjust for the observed differences while maintaining the same code segment functionality.

[0072] Gate code segments rely on a shared memory area in eBPF called a map 236 to store state across consecutive calls, and to exchange state with other code segments 272 of the same code segment 270. The gate system provides various map types for storing data, including arrays, hash maps, and Bloom filters. As an example, for Figure 4 The code segment maintains the counter of the observed FAPI packets to export to RIC instead of exporting the entire original captured packet. The counter is implemented by defining an array mapping (lines 6 to 11) containing a single element (max_entry). Whenever one or more FAPI packets are received, the counter can be restored from the memory by an auxiliary function (line 37), the counter is increased with a new number of packets (line 39), and the counter is saved again using an auxiliary function (line 45) for the next call to code segment 410. Various security checks are required to implement static verification (e.g., lines 34 and 38). In addition, mapping 236 can be shared between code segments 272 in code segment 270 to coordinate actions.

[0073] In a similar manner, the gate code segment can use a flexible output scheme to send arbitrary telemetry data to the data collector 222 through a special type of ring buffer mapping (JANUS_MAP_TYPE_RINGBUF). This mapping 236 is linked to a code segment-specific protobuf mode defined by the code segment developer. In the example of Listing 400, the definition of the output mapping of the custom output protobuf mode named output_msg can be seen in lines 13 to 19 (line 26), which has a single counter field (line 41). The data can be exported to the data collector 222 through another auxiliary function 240 (line 42). This flexibility allows the implementation of the data model currently available in the O-RAN RIC specification without having to modify a single line of code in the vCU 140 and vDU 130 after the hook point 234 is in place.

[0074] The validation ensures that the gate code segment 272 cannot modify the state of the vRAN directly. Instead, modification of the vRAN behavior requires control helper functions 240 provided by the vRAN vendor. Helper functions 240 may be associated with specific hook points 234. The verifier 214 may verify that calls to the helper functions are allowed for the associated hook points 234. For example, a vendor may allow a code segment to control scheduling by providing a helper function called allocate_resource_block() that can only be called at the MAC hook for radio resource allocation. Although control helper functions are more dependent on the internal vRAN software architecture, they provide a way for developers to customize vRAN behavior at runtime.

[0075] The gate system 200 can provide several example categories of applications for various vRAN use cases. In the first example, the gate system 200 can provide flexible monitoring of the vRAN. As described above, the O-RAN RIC 150 allows the collection of telemetry data optimized for the network through the specification of service models. Each model undergoes a long standardization process and then needs to be implemented by each RAN vendor that decides to support it. The gate system 200 can be used to implement more flexible monitoring without relying on service models. The gate system 200 can be used to implement code segments that extract key performance indicators (KPIs) specified in the O-RAN key performance measurement (KPM) model as well as raw scheduling data. The implementation and collection of these KPIs can be implemented in the system 200 without having to change a single line of code in the vRAN function that includes the hook point. Therefore, the new data model can be implemented by the developer without the need for further vendor modifications of the vRAN function or standardization between vendors. For example, the system 200 can collect the downlink total physical resource block (PRB) usage KPI by accessing the FAPI hook of Table 1 and capturing the nfapi_dl_config_request_pdu_t structure described in Listing 400 and which contains the number of PRBs allocated to each user at each scheduling decision. The contents of this structure can be stored in the gate map 236, averaged over a period of 0.5 ms and sent to the data collector 222 by the code segment 272.

[0076] Another example use case of system 200 is external interference detection. Detecting external interference sources in cellular networks (e.g., repeaters with improperly adjusted gain, spurious emissions from electronic devices, or jammers) is a difficult problem, and the conventional practice is to dispatch experts and dedicated hardware to the field. The gate code segment 270 can define a spectrum analyzer to detect external interference through a deployed and operational 5G radio unit (e.g., RU 120) without scheduling. The code segment 270 can include two code segments 272 that are coordinated using a mapping. When there is no 5G transmission, the first code segment (installed at the FAPI hook of Table 1) detects idle time slots. The second code segment (installed at the IQ sample hook of Table 1) samples interference during the detected idle time slot. The flexibility of the gate system allows the fidelity and overhead of the spectrum analyzer to be adjusted as needed by specifying some parameters, including at what frequency (e.g., every receive time slot or every 10ms), at what granularity (e.g., the average energy of the original IQ sample relative to each resource block), and from which antenna ports and symbols to collect IQ samples. A similar approach can be used to implement other use cases that require radio channel telemetry data in different formats (e.g., wireless positioning and wireless channel estimation).

[0077] Another example use case for the system 200 is network slicing. Many vertical and enterprise applications may rely on network slicing for stricter service QoS guarantees. For example, a robotic warehouse may require very precise tail communication latency. Existing solutions based on the O-RAN service model allow a set of predefined slice scheduling policies to control scheduling at a granularity of 10 milliseconds. The gate system 200 can provide real-time slicing of arbitrary scheduling policies at a granularity faster than the capabilities of the standard RIC model, which is 0.5 to 10ms. The gate system 200 can introduce a control hook (slice_scheduler()) at the beginning of the MAC downlink scheduling function of the vDU 130, which is responsible for allocating radio resources to the UE 110. The MAC downlink scheduling function can use the structure used by the MAC scheduler as a hook context. The structure contains the scheduling state of the base station (e.g., the number of devices, the slices they belong to, the buffer size, the signal quality, etc.). The auxiliary function 240 (allocate_resource_block()) dedicated to the slice_scheduler() hook can be configured to allow the code segment to modify the allocation of radio resources for each slice. Using this hook, code segment 272 can implement a network slice scheduler that can be dynamically loaded.

[0078] Another example use case for the gate system 200 is real-time machine learning prediction. Because prediction freshness has a direct impact on network performance, real-time parameter prediction has been proposed for the RAN control loop. Due to O-RAN RIC latency, conventional App152 provides predictions of 10s milliseconds. Using the gate system 200, the ML predictor code segment can achieve prediction latency under 10ms. The first example ML predictor is an autoregressive integrated moving average (ARIMA) time series model for predicting user signal quality. The second example ML predictor is a quantized decision tree for predicting the running time of signal processing tasks. More complex models (such as random forests) are more difficult to implement in gate code segments using C code, because such complex models result in a large number of bytecode instructions (>100K) making the verification process slow (>20 minutes), and the code segment may not be verified.

[0079] In one aspect, the gate system 200 can support complex ML models in the form of mappings 236. A pre-trained serialized complex model can be passed to the gate system 200 as a mapping and linked to the defined mapping during code segment loading. The gate system 200 can parse the serialized model and rebuild the model in memory. The model can then be accessed by the code segment using an auxiliary function 240 (e.g., janus_model_predict()). This approach can be extended to other commonly used ML models (e.g., long short-term memory (LSTM) networks).

[0080] Figure 5 500 is a diagram of a gate device 230 configured with code segments for an ML model for inference. A first code segment 272a may include an ML model 510 within the code of the code segment 272a. A second code segment 272n may include a mapping 520 defining the ML model 530.

[0081] ML model 510 can be a relatively simple ML model that can be defined in verifiable code within code segment 272a. For example, the code can define weighting factors applied to decisions based on a pre-trained model. Code segment 272a including ML model 510 can be verified by verifier 214 ( Figure 2 The code segment 272a may be loaded into the hook point 234 and executed within the application 232.

[0082] The ML model 530 may be a relatively complex ML model. For example, the code of the ML model 530 may not be verified by the verifier 214, or the verification may take longer than a threshold time. In order to allow such a complex ML model to be inferred through the code segment, the gate device 230 may support various ML model types 540 as mappings 236. The ML model type 540 may be a well-known type of ML model with a known serialized representation. For example, the ML model type 540 may include two or more of a random forest model, a long short-term memory (LSTM) model, a convolutional neural network (CNN), or a recurrent neural network (RNN) model. Because the ML model type 540 is supported by the gate system 200, the gate system 200 can verify that the code provided by the gate system 200 is safe. The code segment 272n may include a mapping 520 that defines the ML model 530 according to the ML model type 540. The mapping 520 may include a serialized representation of the ML model 530 that can be parsed according to the ML model type 540. The code segment 272n may also include a call 522 to a helper function 524 that accesses the ML model 530. The verifier 214 may verify the code segment 272n by verifying that the mapping 520 is correctly defined and does not violate memory access restrictions. The verifier 214 may also verify that the call 522 to the helper function 524 is allowed. In some embodiments, the verifier 214 may use the parser 226 to check that the mapping 520 is parsable according to one of the supported ML model types 540.

[0083] When the code segment 272n is loaded into the hook point 234, the mapping 520 is passed to the gate mapping 236. The gate device 230 includes a parser 550, which is similar to the parser 226 and is also configured to rebuild the ML model 530 from the serialized representation in the mapping 520 within the memory allocated to the application 232. When the code segment 272n is executed, the call 522 to the auxiliary function 524 passes the model features to the ML model 530, and the ML model 530 returns the results to the code segment 272n. The code segment 272n can use the results for various purposes, such as making decisions to control the application 232 (e.g., based on the predicted value) or storing the results for access outside the application (e.g., analysis). In some embodiments, the ML model 530 can maintain multiple calls from the code segment 272n in the memory allocated to the application 232. The ML model 530 can store state information between calls.

[0084] Figure 6 6 is a schematic diagram of an example of an apparatus (e.g., computing device 600) for implementing gate device 230. Device 600 may be an example of a vRAN component, such as vDU 130 or vCU 140. Device 600 may reside in a data center, which may be an edge data center. Device 600 may be connected to other servers in the data center via switch 640 and wired connections. For example, device 600 may be connected to gate controller 210 or another vRAN component, such as vCU 140 or vDU 130.

[0085] In an example, the device 600 may include at least one processor 602 and / or memory 604 configured to execute or store instructions or other parameters related to providing an operating system 606, which may execute one or more applications or processes, such as, but not limited to, the gate device 230 and the application 232. For example, the processor 602 and the memory 604 may be separate components communicatively coupled via a bus (e.g., on a motherboard or other portion of a computing device, on an integrated circuit such as a system on a chip (SoC), etc.), components integrated with each other (e.g., the processor 602 may include the memory 604 as an onboard component), etc. The memory 604 may store instructions, parameters, data structures, etc. for use / execution by the processor 602 to perform the functions described herein.

[0086] In an example, the gate device 230 may include one or more of an application 232, a gate map 236, and a parser 550. The application 232 may include one or more hook points 234 and one or more code segments 272 loaded into the corresponding hook points 234. The gate map 236 may include a mapping for supported ML model types 540. In some embodiments, the gate map 236 may include an output mode.

[0087] Figure 7 is a flowchart of an example of a method 700 for executing a code segment including a machine learning model in an application. For example, the method 700 can be performed by the device 600 and / or one or more components thereof to use the ML model to perform inference within the application.

[0088] At block 710, method 700 includes verifying that the code segment meets the security requirements for execution within the application based on the compiled eBPF bytecode of the code segment. In an example, bytecode verifier 214 (e.g., in coordination with processor 602, memory 604, and operating system 606) can verify that code segment 272 meets the security requirements for execution within application 232 based on the compiled eBPF bytecode of code segment 272. In some embodiments, at subblock 712, block 710 can optionally include determining that the serialized representation of the machine learning model is parsable based on a type. For example, parser 226 at gate controller 210 can determine that the serialized representation of ML model 530 within mapping 520 is parsable based on ML model type 540.

[0089] At block 720, method 700 includes loading the verified code segment into a hook point of the application. In an example, network API 218 (e.g., in coordination with processor 602, memory 604, and operating system 606) may load third-party code segment 272 into hook point 234 of application 232. In some embodiments, where the application is executed in a container orchestration system, block 720 may include method 800 discussed below. In some embodiments, sub-block 712 may be performed by parser 550 at gate device 230 during block 720. In some embodiments, block 720 may optionally include, at sub-block 722, rebuilding the machine learning model in a memory allocated to the application based on a serialized representation of the machine learning model. For example, parser 550 at gate device 230 may rebuild ML model 530 in memory 604 allocated to application 232 based on a serialized representation of ML model 530 (e.g., mapping 520).

[0090] At block 730, the method 700 includes executing the verified code segment to apply the application data to the machine learning model to infer the result. In an example, the gate device 230 (e.g., in conjunction with the processor 602, the memory 604, and the operating system 606) can execute the verified code segment 272 to apply the application data to the machine learning model 510, 530 to infer the result.

[0091] At block 740, the method 700 can optionally make a decision based on the result. In an example, the gate device 230 executing the application 232 (e.g., in conjunction with the processor 602, the memory 604, and the operating system 606) can make a decision based on the result. For example, in a vRAN use case, the result can be a predicted measurement. The vDU 130 can make a scheduling decision based on the predicted measurement from the ML model 510, 530, for example.

[0092] At block 750, the method 700 may optionally include storing the results for access outside the application. In an example, the gate device 230 executing the code segment 272 (e.g., in conjunction with the processor 602, the memory 604, and the operating system 606) may store the results for access outside the application. For example, the code segment 272 may store the results in an output schema 620, which may be exported to the gate controller 210 via the output thread 238. For example, in a vRAN use case, the ML models 510, 530 may infer network status, which may be useful to the RIC 150 in making optimization decisions.

[0093] Figure 8 800 is a flow chart of an example of a method 800 for loading a code segment into an application executed in a container. For example, method 800 may be performed by device 600 and / or one or more components thereof to load code segment 270 or code segment 272 into application 232. In some embodiments, method 800 may be used to load code into any application executed on a container orchestration system. Method 800 may be performed in conjunction with method 700. For example, method 800 may correspond to block 720.

[0094] At block 810 , method 800 optionally includes modifying the application to include a plurality of hook points. In an example, gate controller 210 or container API server 310 (eg, in conjunction with processor 602 , memory 604 , and operating system 606 ) may modify application 390 to include a plurality of hook points 392 .

[0095] At block 820, method 800 includes receiving a user configuration of a container image for an application, the user configuration including a header indicating dynamic loading of code segments. In an example, container API server 310 (e.g., in cooperation with processor 602, memory 604, and operating system 606) receives a user configuration of a container image (e.g., a YAML file) for application 390, the user configuration including a header indicating dynamic loading of code segments.

[0096] At block 830, method 800 includes receiving a mapping for a code segment when the application is executed in the main container. In an example, container API server 310 (e.g., in coordination with processor 602, memory 604, and operating system 606) can receive a mapping for a code segment when the application is executed in main container 380.

[0097] At block 840, method 800 includes mounting code including functions associated with the hook point of the application to the container. In an example, the variant network hook 320 (e.g., in coordination with the processor 602, the memory 604, and the operating system 606) can load code including functions (e.g., the library 382) associated with the hook point 392 of the application 390 to the container 380.

[0098] At block 850, the method 800 includes mounting code including functionality associated with a hook point of the application to the container. In an example, the mutant web hook 320 (e.g., in coordination with the processor 602, the memory 604, and the operating system 606) may mount code including functionality associated with a hook point 392 of the application 390 (e.g., the library 382) to the container 380. For example, at sub-block 842, the mutant web hook 320 may modify an entry point of the container 380 to execute a script to dynamically load the library 382 capable of executing a code segment at the hook point 392.

[0099] At block 860, method 800 includes making the location containing the compiled and verified code segment available to the container. In an example, mutation web hook 320 (e.g., in coordination with processor 602, memory 604, and operating system 606) can make the location containing the compiled and verified code segment 360 (e.g., code segment directory 386) available to container 380.

[0100] At block 870, method 800 includes detecting annotations for containers identifying third-party code segments during execution of the application. In an example, controller 330 (e.g., processor 602, memory 604, and operating system 606 in coordination) can detect annotations for containers identifying third-party code segments during execution of the application.

[0101] At block 880, the method 800 includes symbolically linking the hook point of the third-party code segment application indicated by the annotation. In the example, the sidecar container 372 (e.g., in conjunction with the processor 602, the memory 604, and the operating system 606) can symbolically link the third-party code indicated by the annotation to the hook point 392 of the application 390.

[0102] Fig. 9 An example of a device 900 is shown including additional optional component details, such as Figure 6As shown. In one aspect, the device 900 may include a processor 902, which may be similar to the processor 602 for performing processing functions associated with one or more of the components and functions described herein. The processor 902 may include a single group or multiple groups of processors or a multi-core processor. In addition, the processor 902 may be implemented as an integrated processing system and / or a distributed processing system.

[0103] The device 900 may also include a memory 904, which may be similar to the memory 604, such as for storing a local version of an operating system (or components thereof) and / or applications executed by the processor 902, such as the door controller 210, the door device 230, etc. The memory 904 may include the type of memory usable by a computer, such as random access memory (RAM), read-only memory (ROM), tapes, magnetic disks, optical disks, volatile memory, non-volatile memory, and any combination thereof.

[0104] Additionally, the device 900 may include a communication component 906 that provides for establishing and maintaining communications with one or more other devices, parties, entities, etc. utilizing hardware, software, and services as described herein. The communication component 906 may transmit communications between components on the device 900 and between the device 900 and external devices, such as devices located across a communication network and / or devices serially or locally connected to the device 900. For example, the communication component 906 may include one or more buses and may also include transmit chain components and receive chain components associated with wireless or wired transmitters and receivers, respectively, operable to interface with external devices.

[0105] In addition, the device 900 may include a data store 908, which may be any suitable combination of hardware and / or software that provides mass storage of information, databases, and programs used in conjunction with the aspects described herein. For example, the data store 908 may be or may include a data repository for an operating system (or components thereof), applications, related parameters, etc., that are not currently executed by the processor 902. Furthermore, the data store 908 may be a data repository for the door controller 210, the door device 230, and / or one or more other components of the device 900.

[0106] The device 900 may optionally include a user interface component 910 that is operable to receive input from a user of the device 900 and further operable to generate output for presentation to the user. The user interface component 910 may include one or more input devices, including but not limited to a keyboard, a numeric keypad, a mouse, a touch-sensitive display, navigation keys, function keys, a microphone, a speech recognition component, a gesture recognition component, a depth sensor, a gaze tracking sensor, a switch / button, any other mechanism capable of receiving input from a user, or any combination thereof. In addition, the user interface component 910 may include one or more output devices, including but not limited to a display, a speaker, a tactile feedback mechanism, a printer, any other mechanism capable of presenting output to a user, or any combination thereof.

[0107] The device 900 may further include a gate controller 210 for providing execution code segments within applications and gate devices 230 as described herein. In some embodiments, the gate controller 210 may be implemented as a container orchestration system 302, and the gate device 230 may be implemented as a workload pod 370.

[0108] As an example, any part of an element or any combination of elements can be implemented with a "processing system" including one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform various functions described throughout the present disclosure. One or more processors in a processing system can execute software. Software should be broadly interpreted as meaning instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, processes, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or other.

[0109] Therefore, in one or more aspects, one or more of the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the function can be stored on a computer-readable medium or encoded as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media. The storage medium can be any available medium that can be accessed by a computer. As an example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer. As used herein, disks and optical disks include optical disks (CDs), laser optical disks, optical disks, digital versatile disks (DVDs), and floppy disks, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination should also be included in the scope of computer-readable media.

[0110] The foregoing description is provided to enable those skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to the full range consistent with the claim language. Unless specifically stated otherwise, references to singular elements are not intended to mean "one and only one", but "one or more". Unless otherwise specifically stated, the term "some" refers to one or more. In addition, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise stated, it is clear from the context that the phrase "X adopts A or B" is intended to mean any natural inclusive replacement. That is, the phrase "X adopts A or B" is satisfied by any of the following examples: X adopts A; X adopts B; or X adopts both A and B. In addition, the articles "a" and "an" as used in the present application and the appended claims should generally be interpreted as meaning "one or more", unless otherwise stated or clearly specified as a singular form from the context. Furthermore, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.A claim element is not to be construed as a means-plus-function unless the element is explicitly recited using the phrase "means for."

Claims

1. A method for executing a machine learning model within an application, comprising: verifying, based on an extended Berkeley Packet Filter (eBPF) bytecode of a code segment, that the code segment satisfies security requirements for execution within the application; Loading the verified code segment into a hook point of the application; as well as The verified code segment is executed to apply the application data to the machine learning model to infer a result.

2. The method of claim 1, wherein the code segment comprises code implementing a pre-trained machine learning model.

3. The method of claim 1 , wherein the code segment includes a call to a machine learning model and a mapping to a serialized representation of the machine learning model, wherein the type of the machine learning model corresponds to one of a plurality of machine learning model types supported by a controller of the application.

4. The method of claim 3, wherein loading the verified code segment comprises determining that the serialized representation of the machine learning model is parsable based on the type.

5. The method of claim 3, wherein the multiple machine learning model types supported by the controller include two or more of the following: a random forest model, a long short-term memory (LSTM) model, a convolutional neural network (CNN), or a recurrent neural network (RNN) model.

6. The method of claim 3, wherein loading the verified code segment comprises rebuilding the machine learning model within a memory allocated to the application based on the serialized representation of the machine learning model.

7. A method according to claim 3, wherein the call to the machine learning model includes the mapping and data structure for the serialized representation, the data structure includes application data as input parameters and returns the result.

8. The method of claim 1, further comprising storing, by the code segment, the result for access outside of the application.

9. The method of claim 1, further comprising making a decision by the application based on the result.

10. The method of claim 1, wherein the application is a virtualized radio access network (vRAN) function.

11. An apparatus for executing a machine learning model within an application, comprising: a memory storing computer executable instructions; as well as At least one processor configured to execute the instructions to: receiving a compiled and verified code segment, wherein an extended Berkeley Packet Filter (eBPF) of the code segment has been verified to meet security requirements for execution within the application; Loading the verified code segment into a hook point of the application; as well as The verified code segment is executed to apply the application data to the machine learning model to infer a result.

12. The apparatus of claim 11, wherein the code segment comprises code implementing a pre-trained machine learning model.

13. An apparatus according to claim 11, wherein the code segment includes a call to a machine learning model and a mapping to a serialized representation of the machine learning model, and the type of the machine learning model corresponds to one of a plurality of machine learning model types supported by the controller of the application.

14. An apparatus according to claim 13, wherein the at least one processor is configured to determine that the serialized representation of the machine learning model is parsable based on the type.

15. The apparatus of claim 11, wherein the application is a virtualized radio access network (vRAN) function.

Images