A dynamically reconfigurable CNI system and method based on heterogeneous resource pooling

Abstract

This application provides a dynamically reconfigurable CNI system and method based on heterogeneous resource pooling, comprising: a heterogeneous resource pooling module for abstracting and pooling various heterogeneous hardware resources to generate a global resource view and reporting it to the resource management layer; a resource management layer for parsing user-submitted deployment waveform requests and obtaining corresponding resource requirements, dynamically allocating and elastically scaling resources according to a resource scheduling model by querying the global resource view; a unified service bus for establishing a communication link between the resource management layer and the waveform software application layer; and a waveform software application layer for pulling container images corresponding to waveforms from an image repository and instantiating them on the allocated resources based on the allocation results. This application solves the problems of hardware resource silos, high weight, power consumption, and cost in existing CNI systems, and achieves unified architecture support for the needs of manned aircraft with multiple waveforms and high loads, as well as lightweight and low-cost UAVs.

Description

Technical Field

[0001] This application belongs to the field of electronic system technology, and in particular relates to a dynamically reconfigurable CNI system and method based on heterogeneous resource pooling. Background Technology

[0002] As a core electronic system of an aircraft platform, the CNI (Communication, Navigation, and Identification) system traditionally employs a one-to-one correspondence between dedicated hardware boards and specific waveforms. Each communication, navigation, or identification communication mechanism relies on a dedicated hardware board. This architecture faces significant challenges in practical applications:

[0003] 1) Hardware resource silos: Each dedicated board is a self-contained system, and computing, storage and radio frequency resources cannot be shared between waveforms, resulting in low resource utilization and heavy redundancy within the system.

[0004] 2) System rigidity: The waveform function is strongly coupled with the hardware. Updating or adding waveforms requires replacing or adding hardware, resulting in high system evolution costs and long cycles, making it difficult to adapt to the dynamic changes in waveforms required for future combat missions.

[0005] 3) Weight, power consumption, and cost: The large amount of dedicated hardware results in a heavy system and high power consumption, which is particularly problematic on drone platforms where weight and space are limited. In addition, the research, development, procurement, and maintenance costs of dedicated hardware are extremely high.

[0006] To address these issues, the industry has made some attempts. Software-defined radio (SDR) improves flexibility by software-based implementation of some signal processing functions, but its underlying hardware is usually still statically allocated, failing to achieve deep integration and dynamic sharing of resources. Furthermore, some solutions propose deploying network functions based on container-based cloud-native technologies, but this technology is mainly aimed at cloud computing center network function virtualization (NFV) scenarios, lacking consideration for the stringent real-time performance, reliability, and size and weight constraints of CNI systems. Summary of the Invention

[0007] In view of this, this application aims to propose a dynamically reconfigurable CNI system and method based on heterogeneous resource pooling to solve at least one of the above problems.

[0008] To achieve the above objectives, the technical solution of this application is implemented as follows:

[0009] Firstly, this application provides a dynamically reconfigurable CNI system based on heterogeneous resource pooling, comprising:

[0010] This includes a heterogeneous resource pooling module, a resource management layer, a unified service bus, and a waveform software application layer;

[0011] The heterogeneous resource pooling module is used to abstract and pool various heterogeneous hardware resources to generate a global resource view and report it to the resource management layer. The heterogeneous hardware resources include computing resource pool, storage resource pool and radio frequency resource pool.

[0012] The resource management layer is used to parse the deployment waveform request submitted by the user and obtain the corresponding resource requirements. By querying the global resource view, resources are dynamically allocated and elastically scaled up or down according to the resource scheduling model.

[0013] The unified service bus is used to establish a communication link between the resource management layer and the waveform software application layer.

[0014] The waveform software application layer is used to pull the container image corresponding to the waveform from the image repository according to the allocation result, and instantiate it on the allocated resources.

[0015] Secondly, based on the same inventive concept, this application also provides a dynamically reconfigurable CNI method based on heterogeneous resource pooling, used to execute the dynamically reconfigurable CNI system based on heterogeneous resource pooling described in the first aspect, including:

[0016] The system receives a waveform deployment request, parses the waveform descriptor, and obtains the corresponding resource requirements;

[0017] The dynamic resource management engine queries the global resource view and determines whether the current resources meet the requirements based on the resource scheduling model. If they do, it generates the optimal resource allocation plan.

[0018] The resource allocation scheme is executed based on the generated optimal resource allocation scheme to allocate computing / storage / radio resources from the resource pool;

[0019] Based on the allocation results, pull the waveform container image from the image repository and instantiate it;

[0020] After establishing a communication link by configuring a unified service bus, the waveform began to operate normally.

[0021] Compared with existing technologies, the dynamically reconfigurable CNI system and method based on heterogeneous resource pooling described in this application has the following advantages:

[0022] (1) Improved resource utilization: By breaking down resource silos and realizing resource sharing and dynamic scheduling, the average resource utilization of the system is improved;

[0023] (2) Enhanced system flexibility and scalability: The waveform function is software-based, and adding or upgrading waveforms does not require hardware modifications. Only a new software image needs to be deployed. The modular resource pool can be expanded as needed, smoothly supporting future additions of waveforms.

[0024] (3) Weight, power consumption and cost reduction: The number of hardware boards is greatly reduced through the integration and sharing of hardware resources;

[0025] (4) Wide platform adaptability: The unified architecture can be flexibly adapted to different platforms by adjusting the resource configuration strategy; large manned aircraft can be configured with rich resources to support full-function multi-waveform; small unmanned aircraft can be configured with the minimum resource set as needed to support a few key waveforms, achieving lightweight and low cost. Attached Figure Description

[0026] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 This is a diagram of a dynamically reconfigurable CNI system architecture based on heterogeneous resource pooling, as described in an embodiment of this application.

[0028] Figure 2 This is a schematic diagram of resource scheduling as described in an embodiment of this application;

[0029] Figure 3 This is a schematic diagram of waveform decomposition as described in an embodiment of this application;

[0030] Figure 4 The waveforms described in the embodiments of this application are deployed in the loading flowchart;

[0031] Figure 5 This is a flowchart of a dynamically reconfigurable CNI method based on heterogeneous resource pooling, as described in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0033] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0034] The dynamically reconfigurable CNI system based on heterogeneous resource pooling described in this embodiment aims to solve the traditional architectural bottlenecks of current manned airborne CNI systems, which are characterized by "silos, fixed resources, poor interoperability, and difficult upgrades." It can break down hardware resource silos, realize flexible resource sharing and dynamic reconfiguration, and thus meet the diverse platform requirements from large manned aircraft to light unmanned aerial vehicles.

[0035] The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0036] Example 1

[0037] Please see Figure 1 As shown, this embodiment provides a dynamically reconfigurable CNI system based on heterogeneous resource pooling, including a heterogeneous resource pooling module, a resource management layer, a unified service bus, and a waveform software application layer;

[0038] Among them, the heterogeneous resource pooling module is used to abstract and pool various heterogeneous hardware resources to generate a global resource view and report it to the resource management layer. The heterogeneous hardware resources include computing resource pool, storage resource pool and radio frequency resource pool.

[0039] The resource management layer is used to parse the deployment waveform requests submitted by users and obtain the corresponding resource requirements. By querying the global resource view, resources are dynamically allocated and elastically scaled up or down according to the resource scheduling model.

[0040] The unified service bus is used to establish a communication link between the resource management layer and the waveform software application layer.

[0041] The waveform software application layer is used to pull the container image corresponding to the waveform from the image repository according to the allocation result, and instantiate it on the allocated resources.

[0042] Specifically, in this embodiment, the heterogeneous resource pooling module serves as the foundation of the system, abstracting physically dispersed and heterogeneous hardware resources into unified, on-demand allocable logical resource units, which are used to abstract various computing hardware, storage resources and radio frequency resources into a unified resource pool.

[0043] The resource management layer, based on the loaded resource scheduling strategy and real-time load awareness, enables on-demand allocation and elastic scaling of resources.

[0044] The unified service bus uses the Data Distribution Service (DDS) middleware to provide low-latency, high-reliability, cross-domain data communication services for pooled resources and software-defined waveforms. It can provide service registration, discovery, and invocation mechanisms to achieve decoupled communication between waveform components.

[0045] The waveform software application layer decomposes traditional waveform functionality into a series of containerized microservice components. Waveforms are no longer bound to hardware but are stored in a repository as software images. When a waveform needs to be deployed, the application layer framework allocates resources that meet the requirements from the resource pool based on the waveform descriptor (which declares the required resource type, quantity, and real-time requirements) through a dynamic resource management engine, and instantiates the corresponding waveform container. The framework supports hot migration and elastic scaling of waveforms.

[0046] The dynamic reconfigurable CNI system based on heterogeneous resource pooling described in this application changes the rigid, bulky, and high-power consumption architecture of traditional CNI systems through resource pooling, software waveforms, and intelligent dynamic scheduling. This system significantly improves resource utilization, flexibility, and scalability, while effectively reducing system weight, power consumption, and cost. It provides a unified and sustainably evolving CNI system solution for various aircraft platforms, from complex manned aircraft to low-cost unmanned aerial vehicles, and has extremely high economic benefits.

[0047] In some implementations, the heterogeneous resource pooling module abstracts and pools various hardware resources through hardware pooling technology, specifically including:

[0048] (1) Computing Resource Pool: Integrates heterogeneous computing units such as general-purpose processors (CPU), graphics processing units (GPU), field-programmable gate arrays (FPGA), and digital signal processors (DSP), and abstracts physical resources into virtual computing units through hardware virtualization technology. The processing methods for different types of processors are shown in Table 1.

[0049] Table 1. Pooling Processing of Computational Resource Pools

[0050] Resource types Pooling core technology Pooled virtual resource form Management Interface CPU Lightweight container virtualization CPU time slice: Limits and allocates the number of CPU cores and their usage share. CPU set: Groups CPU cores, binds them to critical tasks, and avoids scheduling jitter. Standard system calls or container runtime interfaces GPU vGPU, SR-IOV GPU instance: Dividing a physical GPU into multiple virtual GPUs with independent memory and computing units. GPU computing power time-sharing: Proportionally allocating computing power to multiple containers through drivers or runtime. GPU driver API or container runtime hook FPGA Partial reconfiguration or hardware abstraction FPGA Image: Compiles different waveform processing functions into independent bitstream files. Virtual FPGA Unit: Virtualizes different areas of an FPGA into multiple "accelerator instances". FPGA management tools or dedicated device drivers DSP RTOS and Hardware Partitioning DSP Task: On a real-time operating system, each waveform processing task runs as an independent, protected real-time task. DSP Core: For multi-core DSPs, each core is treated as an independent, allocable resource. Dedicated SDK or Task Management API

[0051] The pooling management software will discover these virtual resources, report them to the resource management engine, and mount them into the container when the container starts, as instructed.

[0052] (2) Storage resource pool: Unified management of memory and non-volatile storage media, providing virtual shared memory and a unified address space through distributed storage technology to meet the needs of high-speed sharing and persistence of waveform data. The processing methods for different types of processors are shown in Table 2.

[0053] Table 2 Storage Resource Pool Pooling Processing Table

[0054] Storage type Pooling core technology Pooled virtual resource form Access methods Memory Distributed memory pool Shared memory volumes: Provide a distributed shared memory space across containers with unified addressing for extremely low-latency waveform data exchange. Memory key-value pairs Local flash memory Distributed file system Block storage volume: Provides each waveform container with an independent, persistent virtual hard disk for storing waveform programs, configuration parameters, and logs. Standard file system operations Non-volatile memory PMEM-aware file system Persistent memory volumes: Provide a storage solution with performance and latency between memory and SSDs, for disaster recovery and critical state preservation. Memory mapping

[0055] The unified management plane mounts these virtual storage resources to the specified path in the waveform container through the container storage interface.

[0056] (3) RF Resource Pool: Integrates RF front-end processing resources such as ADC (Analog-to-Digital Converter), DAC (Digital-to-Analog Converter), DDC (Digital Down-Converter), and DUC (Digital Up-Converter). Through highly integrated RF components such as PA, it provides dynamically configurable RF channels for different waveforms. The RF resource pool supports dynamic reconfiguration of RF parameters through the software-defined RF concept. The processing methods for different types of processors are shown in Table 3.

[0057] Table 3. RF Resource Pool Pooling Processing Table

[0058] Storage type Pooling core technology Pooled virtual resource form Management Interface RF front-end processing module (ADC / DAC / DDC / DUC) Software-defined radio frequency (SDR) + dynamic parameter reconfiguration + hardware abstraction layer (HAL) Virtual RF Channels: Physical RF channels are divided into multiple virtual channels with independent frequency, bandwidth, and gain parameters, supporting on-demand waveform binding. Flexible Processing Instances: Processing units such as DDC / DUC are abstracted into schedulable computing power slices, allocating downconversion / upconversion capabilities according to waveform requirements. Parameterized RF Interface: Each virtual channel provides dynamically configurable RF parameters (center frequency, sampling rate) for rapid waveform adaptation. Hook the RF resource management SDK or dynamic configuration interface in the standard RF control API or container runtime. Power amplifier module (PA) Dynamic load scheduling + power slicing technology Virtual PA Slicing: Proportionally distributes the output power of a single PA to multiple virtual channels, supporting dynamic power adjustment. Load Balancing Instance: Assigns dedicated PA slices to high-power waveform tasks, avoiding power interference between multiple waveforms. PA-specific management tools or power scheduling API

[0059] The pooling management software automatically identifies physical RF resources (such as the number of ADCs / DACs and the power capacity of PAs) and abstracts them into virtual resource instances, which are then reported to the dynamic resource management engine. The resource management engine dynamically mounts virtual RF channels, processing instances, and other resources into the corresponding containers based on the RF requirements of the waveform task (such as bandwidth, power, and frequency).

[0060] In some implementations, the resource management layer is configured with a dynamic resource management engine, a resource scheduling and orchestration module, and a resource awareness and monitoring module;

[0061] The dynamic resource management engine is used to parse waveform descriptors and query the global resource view, generate the optimal resource allocation scheme based on resource requirements and optimization goals, and issue allocation instructions to the resource scheduling and orchestration module through device plug-ins and CSI drivers;

[0062] The resource scheduling and orchestration module is used to allocate computing / storage / radio resources from the resource pool according to the issued allocation instructions;

[0063] The resource awareness and monitoring module is used to continuously monitor resource status and waveform performance in order to trigger dynamic adjustments to resource allocation or waveform migration.

[0064] Specifically, in this embodiment, the dynamic resource management engine is the "brain" of resource scheduling, and its core is a multi-objective resource scheduling model based on an improved particle swarm optimization (PSO) algorithm. The constraints include resource capacity constraints, real-time constraints, and power consumption constraints. The decision-making mechanism involves the engine periodically collecting resource status and waveform requirements, and solving for the optimal resource allocation scheme through the aforementioned model to achieve a balance between resource utilization and task response time. It should be noted that the multi-objective resource scheduling model involved in this embodiment is a technical application of an existing model. This application does not involve technical improvements to this model, nor is it considered a technical protection point of this application; therefore, it will not be elaborated further.

[0065] Among them, such as Figure 2 The resource scheduling and orchestration graph includes task sets, task scheduling, resource matching, resource pooling, and heterogeneous resources, as detailed below:

[0066] (1) Task set: Analyze the tasks, identify parallelizable subtasks and hardware constraints. Based on the task's requirements for computing resources and the computing performance of the computing nodes, analyze the real-time available computing power of hardware resources, the minimum requirements of the task for computing resources, the end-to-end latency of hardware execution of the task, and the probability that the hardware resources are currently available for scheduling, and give the optimal matching parameters.

[0067] (2) Task scheduling: Generate hybrid execution plans, aggregate the resources required for tasks, such as video processing tasks, construct virtual resources of CPU+GPU+FPGA, support CPU flow control, GPU processing encoding and decoding, and FPGA accelerating feature extraction task execution.

[0068] (3) Resource matching: Match candidate pooled resources according to resource tags, calculate cross-device communication overhead (such as PCIe / NVLink bandwidth), and achieve optimal resource matching.

[0069] (4) Resource pooling: Resource pooling realizes the integration and fine-grained segmentation of resources. Through the resource perception and monitoring module, the utilization rate of each resource, the performance index of the waveform container and the health status of the system are continuously collected. When the resource utilization rate is detected to be too high or too low, the waveform performance is not up to standard or a hardware failure occurs, the dynamic resource management engine will trigger dynamic adjustment.

[0070] (5) Heterogeneous resources: Resources in different functional domains (computing (CPU, FPGA, GPU, NPU, etc.), storage (RAM, Flash, etc.)).

[0071] It should be noted that resource matching specifically includes the following process:

[0072] First, setting and configuring resource tags:

[0073] Resource tags are identification information that characterizes the attributes of heterogeneous pooled resources, including hardware computing power tags, network interface tags, load status tags, functional capability tags, and communication domain tags. During the resource registration and pooling stage, the resource management module generates static basic tags based on the inherent attributes of the hardware, and during the system operation stage, it dynamically updates dynamic status tags based on the real-time status of the resources.

[0074] Secondly, candidate pooled resources are matched based on resource tags:

[0075] During resource matching, the resource requirements of the current task are parsed into a set of requirement tags. The requirement tag set is then matched with the resource tags of each pooled resource in terms of dimension and similarity score. Pooled resources that meet the constraints and have a matching degree higher than a preset threshold are selected to form a set of candidate pooled resources.

[0076] Finally, the calculation of cross-device communication overhead.

[0077] Cross-device communication overhead is quantified and calculated based on the link bandwidth, data transmission volume, network hop count, communication protocol type, and real-time load of the node between the candidate resource and the task execution node to obtain the total communication overhead. The target reconstructed resource is then selected by combining the matching result with the total communication overhead.

[0078] The specific details are as follows:

[0079] 1) Rules and setup phase for setting resource tags

[0080] ①Resource tag definition and dimensions

[0081] The resource tags described in this invention are table-transformed metadata for heterogeneous resource pooling management, and are structured using multi-dimensional key-value pairs, including:

[0082] Hardware attribute tags: Device type, computing power specifications, storage capacity, interface type, bandwidth capability;

[0083] Network attribute tags: Node, Network Domain, Communication Protocol, Link Bandwidth, Latency Level;

[0084] Status attribute tags: load, availability, priority, and business domain;

[0085] Functional attribute tags: Supported CNI plugin types, refactoring capabilities, and scheduling constraints.

[0086] ② Resource Tag Setting Stage

[0087] Resource tags are written and updated in two stages:

[0088] Resource registration and pooling phase: When heterogeneous devices are connected to the CNI system and complete virtualization pooling, the resource management module automatically collects the inherent attributes of the hardware and network and generates static basic tags.

[0089] During the runtime dynamic update phase: The system collects device load, link status, and refactoring events at fixed intervals, and refreshes dynamic tags in real time to ensure that the tags are consistent with the actual resource capabilities.

[0090] 2) Candidate pooling resource matching process based on resource tags

[0091] Resource matching is based on a multi-dimensional weighted matching of task requirement tags and pooled resource tags, and the steps are as follows:

[0092] Requirements analysis: Parse the resource requirements of business / restructuring tasks into a standardized set of requirement tags (computing power, network, interface, latency, etc.);

[0093] Initial screening and filtering: Based on hard constraints such as device type, network domain, and availability, resources that do not meet the basic conditions are extracted from the resource pool to obtain a candidate resource set;

[0094] Precise matching: The similarity of candidate resources is calculated using tags, and a weighted scoring method is applied.

[0095] ;

[0096] In the formula, Weights for each tag dimension, The tag matching score is 1 for a perfect match, 0-1 for a partial match, and 0 for no match. The tag attributes of candidate resources are the inherent characteristic values ​​of candidate resources (such as the number of cores, supported radio frequency bands, processor architecture, communication protocol type, etc.). The tag attributes for the required resources are the resource requirements proposed by the task planning (such as requiring an eight-core CPU, supporting S-band communication, low power consumption, etc.).

[0097] Sorting preference: By Sort the resources from high to low and select the Top-N (first N) candidate pooled resources to proceed to the communication overhead calculation stage.

[0098] 3) Method for calculating cross-device communication overhead

[0099] After candidate resources are determined and before refactoring, the system quantifies the cross-device communication overhead between candidate resources and task execution nodes / related resources, as shown in the following model:

[0100] First, establish a communication overhead composition model, with the specific formula as follows:

[0101] ;

[0102] In the formula, This represents the link transmission overhead, which is determined by the physical distance, link bandwidth, and data volume. Indicates protocol encapsulation overhead; This represents the forwarding and scheduling overhead, including cross-node routing, CNI plugin processing, and queue latency.

[0103] Secondly, perform quantification calculations:

[0104] a) Link delay overhead

[0105] ;

[0106] In the formula, Indicates the estimated amount of data to be transmitted; Indicates link bandwidth; Indicates the number of hops between devices; This represents the single-hop delay coefficient.

[0107] b) Protocol overhead

[0108] Take a fixed cost value based on the actual CNI network model used.

[0109] c) System forwarding overhead

[0110] The calculation is based on real-time node load and port queue length, and is positively correlated with the current CPU utilization.

[0111] d) Output and Decision

[0112] Total communication overhead As a constraint for reconfiguration scheduling, it is combined with resource matching score for joint decision-making; the wired selection of resources with high matching degree and low communication overhead completes dynamic reconfiguration.

[0113] In some real-time methods, the waveform software application layer is decomposed according to the functional modules of the signal processing link to obtain multiple microservice components, and each microservice component is encapsulated as an independent container image.

[0114] Specifically, in this embodiment, traditional waveform software is a monolithic entity running on dedicated hardware. This solution breaks it down into highly cohesive, loosely coupled microservice components. Taking a typical communication waveform as an example, it is decomposed according to the functional modules of the signal processing link.

[0115] Waveform decomposition diagram as follows Figure 3As shown, waveform decomposition has the following characteristics: clear functional boundaries, with each service responsible for a specific and complete sub-function; heterogeneous resource requirements, with different services having different preferences for computing resources (e.g., using DSP / FPGA for encoding and decoding, and CPU for link control); and different real-time requirements, with RF services and modulation / demodulation services being extremely sensitive to latency, while link control services allow for a certain amount of latency.

[0116] Each microservice component is encapsulated as an independent container image, including a base image, runtime environment, service code, startup script, environment variables, etc. Ultimately, a complete waveform is no longer a single executable file, but a "chart" composed of multiple container images, which interact with each other through the unified service bus DDS.

[0117] This embodiment decomposes the monolithic waveform software into a series of highly cohesive, loosely coupled microservice components according to the signal processing chain, and encapsulates each component and its operating environment into an independent, portable container image.

[0118] The deployment and loading process of software waveforms is as follows: Figure 4 As shown, the deployment process is dynamic and declarative, and is completed automatically by the system, especially the resource binding stage, which specifically includes the following steps:

[0119] 1) Submit a deployment request; The user submits a waveform descriptor YAML file to the system, which includes which microservices are needed, the resource requirements of each service, the dependencies between services, and the service quality requirements.

[0120] 2) Scheduling and resource allocation: The dynamic resource management engine parses waveform descriptors and queries the global resource pool. Based on resource requirements and optimization goals, it generates resource allocation schemes and locks resources.

[0121] 3) Container startup and resource injection: When starting a container, the system injects specific hardware resources into the container according to the allocation scheme, and pulls the relevant container images from the image repository.

[0122] 4) Service registration and communication establishment: After each waveform container starts, it automatically registers itself with the unified service bus and subscribes to the data topics it needs (including allocating vGPU and dedicated CPU cores to the RF service container, starting the RF server and injecting hardware resources; allocating FPGA bitstream memory to the codec service container, starting the codec service container and injecting hardware resources; allocating general-purpose CPU and memory to the link control container, starting the link control container and injecting hardware resources); it automatically discovers all services through the unified service bus DDS and establishes direct data channels between them to achieve low-latency, high-throughput communication.

[0123] 5) Operation and lifecycle management: Once a waveform enters the running state, the system continuously monitors its performance and resource usage. If a service exits abnormally, the orchestration system will automatically restart it. If the load changes, the engine will trigger elastic scaling.

[0124] The system described in this embodiment is based on a unified system architecture with dynamic resource pooling. It breaks away from the rigid architecture of traditional CNI systems that uses "one waveform, one board" and innovatively proposes a system architecture that unifies and pools heterogeneous computing resources (CPU / GPU / FPGA / DSP), storage resources, and radio frequency resources.

[0125] Example 2

[0126] Based on the same inventive concept, corresponding to any of the above-described embodiments, this application also provides a dynamically reconfigurable CNI method based on heterogeneous resource pooling, specifically including the following steps:

[0127] Step S101, System Initialization:

[0128] After the platform is powered on, the heterogeneous resource pooling module automatically discovers and identifies all available computing, storage, and radio frequency resources, generating a global resource view; the dynamic resource management engine loads resource scheduling policies; and the unified service bus starts, waiting for service registration and requests.

[0129] Step S102, waveform deployment, as follows Figure 5 As shown, the specific process is as follows:

[0130] 1) The system receives a request to deploy a waveform and the corresponding waveform descriptor;

[0131] 2) The dynamic resource management engine parses waveform descriptors and obtains their resource requirements;

[0132] 3) The dynamic resource management engine queries the global resource view and determines whether the current resources meet the requirements based on the resource scheduling model; if they do, it generates a resource allocation plan; if they do not, it returns an error.

[0133] 4) The engine generates the optimal resource allocation scheme and allocates computing / storage / RF channels from the resource pool;

[0134] 5) The waveform software application layer pulls the container image corresponding to the waveform from the image repository according to the allocation result and instantiates it on the allocated resources;

[0135] 6) The unified service bus establishes communication links between this waveform instance and other related waveforms or system components;

[0136] 7) Once the waveform starts running normally, continuously monitor the resource status and waveform performance, and determine whether adjustments are needed. If adjustments are needed, trigger dynamic adjustment of resource allocation or waveform migration until the waveform runs normally.

[0137] In addition, this embodiment also has resource awareness and monitoring functions. The resource awareness and monitoring module continuously collects the utilization rate of each resource, the performance indicators of the waveform container and the health status of the system. When it is detected that the resource utilization rate is continuously too high or too low, the waveform performance is not up to standard or a hardware failure occurs, the dynamic resource management engine will trigger dynamic adjustment.

[0138] Adjustments may include: dynamically allocating more resources to waveforms that are underperforming; merging waveform instances with low load to free up idle resources; or migrating waveform instances from faulty hardware to healthy hardware.

[0139] The methods described above are used to implement the corresponding systems in any of the foregoing embodiments and have the beneficial effects of the corresponding system embodiments, which will not be repeated here.

[0140] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0141] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A dynamically reconfigurable CNI system based on heterogeneous resource pooling, characterized in that: This includes a heterogeneous resource pooling module, a resource management layer, a unified service bus, and a waveform software application layer; The heterogeneous resource pooling module is used to abstract and pool various heterogeneous hardware resources to generate a global resource view and report it to the resource management layer. The heterogeneous hardware resources include computing resource pool, storage resource pool and radio frequency resource pool. The resource management layer is used to parse the deployment waveform request submitted by the user and obtain the corresponding resource requirements. By querying the global resource view, resources are dynamically allocated and elastically scaled up or down according to the resource scheduling model. The unified service bus is used to establish a communication link between the resource management layer and the waveform software application layer. The waveform software application layer is used to pull the container image corresponding to the waveform from the image repository according to the allocation result, and instantiate it on the allocated resources; Radio frequency resource pool pooling includes: The pooling management software identifies the RF front-end processing module and the power amplification module. Through software-defined RF, dynamic parameter reconstruction, and hardware abstraction layer, it performs virtual resource pooling on the RF front-end processing module to obtain the pooled virtual resource form, including virtual RF channels, flexible processing instances, and parameterized RF interfaces. The virtual RF channel is a physical RF channel divided into multiple virtual channels with independent frequency, bandwidth, and gain parameters. The flexible processing instance is a processing unit abstracted into a computing power slice with scheduling, and downconversion or upconversion capabilities are allocated according to waveform requirements. The parameterized RF interface provides dynamically configurable RF parameters for each virtual channel. The power amplifier module is virtualized into a pooled resource using dynamic load scheduling and power slicing techniques to obtain a pooled virtual resource form, including virtual power amplifier module slices and load balancing instances. The virtual power amplifier module slices are used to proportionally divide the output power of a single power amplifier module into multiple virtual channels. The load balancing instances are used to allocate dedicated power amplifier module slices for high-power waveform tasks.

2. The dynamically reconfigurable CNI system based on heterogeneous resource pooling according to claim 1, characterized in that: For the computing resource pool, physical resources are abstracted into virtual computing units through hardware virtualization; For the aforementioned storage resource pool, memory and non-volatile storage media are managed uniformly, and virtual shared memory and a unified address space are provided through distributed storage. For the radio frequency resource pool, radio frequency components provide dynamically configured radio frequency channels for different waveforms.

3. The dynamically reconfigurable CNI system based on heterogeneous resource pooling according to claim 1, characterized in that: The resource management layer is equipped with a dynamic resource management engine and a resource scheduling and orchestration module; The dynamic resource management engine is used to parse waveform descriptors and query the global resource view, generate the optimal resource allocation scheme according to resource requirements and optimization goals, and issue allocation instructions to the resource scheduling and orchestration module through device plug-ins and CSI drivers. The resource scheduling and orchestration module is used to allocate computing / storage / radio resources from the resource pool according to the issued allocation instructions.

4. A dynamically reconfigurable CNI system based on heterogeneous resource pooling according to claim 3, characterized in that: The resource scheduling and orchestration module includes a task decomposition stage, a dynamic orchestration stage, and a resource matching stage. The task decomposition stage is used to parse tasks, identify parallelizable subtasks and hardware constraints. The dynamic orchestration phase is used to generate hybrid execution plans and aggregate the resources required for tasks. The resource matching stage is used to match candidate pooled resources based on resource tags to achieve optimal resource matching.

5. A dynamically reconfigurable CNI system based on heterogeneous resource pooling according to claim 3, characterized in that: It also includes a resource awareness and monitoring module, which is used to continuously monitor resource status and waveform performance in order to trigger dynamic adjustments to resource allocation or waveform migration.

6. A dynamically reconfigurable CNI system based on heterogeneous resource pooling according to claim 1, characterized in that: The waveform software application layer is decomposed according to the functional modules of the signal processing link to obtain multiple microservice components, and each microservice component is encapsulated as an independent container image.

7. A dynamically reconfigurable CNI system based on heterogeneous resource pooling according to claim 6, characterized in that: According to the allocation results, the waveform software application layer pulls the container image corresponding to the waveform from the image repository, starts the service container and injects hardware resources, establishes a communication link between microservices through the unified service bus, and the waveform enters the running state.

8. A dynamically reconfigurable CNI method based on heterogeneous resource pooling, characterized in that, For executing any one of claims 1 to 7, a dynamically reconfigurable CNI system based on heterogeneous resource pooling, comprising: The system receives a waveform deployment request, parses the waveform descriptor, and obtains the corresponding resource requirements; The dynamic resource management engine queries the global resource view and determines whether the current resources meet the requirements based on the resource scheduling model. If they do, it generates the optimal resource allocation plan. The resource allocation scheme is executed based on the generated optimal resource allocation scheme to allocate computing / storage / radio resources from the resource pool; Based on the allocation results, pull the waveform container image from the image repository and instantiate it; After establishing a communication link by configuring a unified service bus, the waveform began to operate normally.

9. The dynamically reconfigurable CNI method based on heterogeneous resource pooling according to claim 8, characterized in that, include: Continuously monitor resource status and waveform performance, and determine whether adjustments are needed. If adjustments are needed, trigger dynamic adjustments to resource allocation or waveform migration.

10. The dynamically reconfigurable CNI method based on heterogeneous resource pooling according to claim 8, characterized in that, include: By dynamically allocating more resources to waveforms that are not performing well; Merge waveform instances with lower load to free up idle resources; Alternatively, the waveform instance can be migrated from faulty hardware to healthy hardware.

Images