A method and system for managing resources of a software defined radio communication equipment with heterogeneous resources visibility

Abstract

The application discloses a kind of software radio communication equipment resource management methods and systems of heterogeneous resource visibility, belong to software radio field, including steps: the internal processor of software radio communication equipment is divided into two types of supporting CORBA middleware and not supporting CORBA middleware;For the processor deployment manager of supporting CORBA middleware, platform modeling is carried out according to software radio modeling method;For the processor of not supporting CORBA middleware, test behavior element is formed by splitting to test function, and interface conversion and connector are provided;Then the connector is connected with the manager, and the manager generates platform topology data according to the registration information of the connector, and constructs the unified connection mode of CORBA and MHAL / MOCB by fusion.This application can build the unified management capability of internal resource management mechanism of software radio equipment to processor, and improve the general level of platform.

Description

Technical Field

[0001] This invention relates to the field of software-defined radio, and more specifically, to a method and system for managing software-defined radio communication equipment resources that enables visibility of heterogeneous resources. Background Technology

[0002] Traditional wireless communication radios feature tightly coupled embedded software and underlying hardware, and in most cases, they only support specific communication waveforms. This leads to difficulties in interoperability between radio products from different manufacturers, as well as poor scalability and challenges in technology upgrades. Developing wireless communication radios with open architectures and scalable communication capabilities is one of the most critical challenges facing the industry.

[0003] Software-defined radio (SDR) is a radio communication technology based on programmable devices that achieves software-hardware decoupling through the software-defined communication waveforms. my country's new generation of wireless communication radios, centered on the SRTF (Software Radio Task Force) series of standards, adheres to a consistent standard system. This allows for the configuration of different communication waveform application software according to varying usage scenarios, solving the problems of interconnectivity and continuous technological upgrades between heterogeneous devices.

[0004] Efficient cross-porting of waveforms across different software-defined radio (SDR) general-purpose hardware platforms is one of the core technological advantages of SDR devices. Therefore, platform modeling of the SDR device is necessary, followed by waveform modeling, encapsulation, and embedding based on the platform modeling information. Existing SDR device platforms largely rely on CORBA middleware objects for construction, making it impossible to model a range of processors, including FPGAs and DSPs, that do not support CORBA middleware deployment. For example:

[0005] 1) The deployment of FPGA and DSP components for waveforms needs to be based on a platform-customized method, which affects the platform's versatility and the reusability of waveform components;

[0006] 2) Traditional platform modeling methods can only manage processor sets that have deployed CORBA middleware, and cannot manage dedicated processors such as FPGAs and DSPs that do not support CORBA middleware;

[0007] 3) Traditional software-defined radio devices use a modem hardware abstraction layer or on-chip bus modem hardware abstraction layer (MHAL / MOCB) mechanism to handle data interaction with dedicated processors that do not support CORBA middleware. Waveform software developers need to consider the data conversion design of both middleware simultaneously, increasing the complexity of waveform component design and affecting waveform porting development efficiency. MHAL cannot separate test cases from the device under test (DUT). During test adaptation, test case developers also need to understand the internal data interaction design of the DUT, impacting testing efficiency.

[0008] In summary, software-defined radio communication equipment is a general-purpose hardware platform that meets diverse waveform resource requirements. It is mostly composed of various types of programmable processors. The support capabilities of processors for operating systems and CORBA middleware are inconsistent, which means that general platform modeling and object management cannot cover non-CORBA processors. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and system for managing resources of software radio communication equipment with heterogeneous resource visibility. This method and system can realize unified connection and model abstraction of processors that support CORBA middleware deployment and processors that do not support CORBA middleware deployment within the software radio communication equipment, and support resource management at the system level according to a unified interface.

[0010] The objective of this invention is achieved through the following solution:

[0011] A method for managing resources in software-defined radio communication equipment that allows visibility of heterogeneous resources, comprising the following steps:

[0012] The internal processors of software radio communication equipment are divided into two types based on whether they can deploy an operating system and CORBA middleware: those that support CORBA middleware and those that do not. For processors that support CORBA middleware, the platform is modeled according to the software radio modeling method. For processors that do not support CORBA middleware, test behavior elements are formed by decomposing test functions, and interface conversion and connectors are provided.

[0013] The connector is then connected to the manager, which generates platform topology data based on the connector's registration information, and integrates and builds a unified connection method for CORBA and MHAL / MOCB.

[0014] Furthermore, processors that support CORBA middleware type interact with data based on CORBA middleware, while non-CORBA processors that do not support CORBA middleware type establish a connection between the connector and the connection manager by deploying a connector to ensure that the core framework inside the software radio system can manage non-CORBA type processors.

[0015] Furthermore, the connection between the connector and the manager specifically includes the following sub-steps:

[0016] The manager is deployed on processors that support operating systems and CORBA middleware, enabling logical connections with connectors at the bottom and supporting core framework interface connections at the top, thus enabling the forwarding of control and business logic. The connectors are deployed on processors that do not support operating systems and CORBA middleware, enabling the processor to transfer external connections. Furthermore, the connectors and the connection manager form a many-to-one relationship.

[0017] Furthermore, the manager generates platform topology data based on the connector's registration information, and integrates and constructs a unified connection method for CORBA and MHAL / MOCB, specifically including the following sub-steps:

[0018] S1. Deploy the connector on each processor that does not support CORBA middleware types;

[0019] S2. Each connector registers its local entity and capability descriptor with the manager;

[0020] S3. The manager generates a unified connection topology diagram across processors based on preset policies or user requests.

[0021] S4. The manager sends the topology map to the relevant connectors, and the connectors generate an adapted connection address sequence based on their local connection characteristics.

[0022] S5. Each connector executes a sequence of connection instructions to establish a logical link and periodically reports the link status to the manager.

[0023] S6. When hot-swapping, failure, or security policy changes of any processor cause topology changes, the manager updates the unified connectivity topology map and performs incremental reconfiguration.

[0024] Furthermore, after connecting the connector to the manager, a management mechanism is also included, specifically comprising the following steps:

[0025] SS1: Connection registration. The connector reads the configuration file and sends a registration message to the manager.

[0026] SS2: The manager registers non-CORBA processors with the core framework based on platform topology data, making non-CORBA processors visible to the core framework;

[0027] SS3: The manager maintains the platform topology by periodically querying the connector, and the manager updates the registration status to the core framework based on the platform topology;

[0028] SS4: The core framework issues control commands, which are received by the manager and forwarded through the logical interface with the connector, enabling the core framework to achieve unified control and management of non-CORBA processors.

[0029] Furthermore, in step SS1, the configuration file is a standardized description of the processor, used by the connection manager to maintain information about the entire middleware.

[0030] Furthermore, the standardized description includes a processor description, which is used for a global, static description of the processor type and basic information.

[0031] Furthermore, the standardized description includes a bus description, which provides a global, static description of bus connections between processors.

[0032] Furthermore, the standardized description includes a connectivity description, which is a global and dynamic description of connectivity based on software radio communication equipment middleware visible to heterogeneous resources.

[0033] A software-defined radio communication equipment resource management system with heterogeneous resource visibility includes a computer device, characterized in that the computer device includes a processor and a memory, the memory storing a computer program, which executes the method described in any of the preceding claims when the computer program is loaded by the processor.

[0034] The beneficial effects of this invention include:

[0035] This invention employs a middleware approach to build a unified management mechanism for the processor within a software-defined radio device, thereby improving the platform's versatility. Furthermore, this invention supports fine-grained platform modeling and waveform modeling that closely approximates actual deployment, facilitating the combination, nesting, and reuse of waveform components.

[0036] Specifically, this invention proposes a middleware implementation scheme for software-defined radio communication equipment (SDR) with top-level visibility of heterogeneous resources. It employs a proxy object modeling approach to achieve unified connection and model abstraction for processors within the SDR equipment that support CORBA middleware deployment and those that do not, supporting system-level resource management through a unified interface. This top-level visibility middleware facilitates comprehensive scheduling management at the processor level within the SDR equipment, further supporting the deployment, connection, and offloading of standardized, fine-grained waveform components. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a schematic diagram of the system framework of an embodiment of the present invention;

[0039] Figure 2 This is a schematic diagram of the connector interface according to an embodiment of the present invention;

[0040] Figure 3 This is a schematic diagram of the manager interface according to an embodiment of the present invention;

[0041] Figure 4 This is a schematic diagram of the connection establishment process according to an embodiment of the present invention;

[0042] Figure 5 This is a schematic diagram of the control and management process according to an embodiment of the present invention. Detailed Implementation

[0043] All features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.

[0044] The specific implementation process of this invention is as follows:

[0045] The development of software-defined radio (SDR) devices requires the use of various types of programmable processors. Some dedicated processors do not support operating systems and CORBA middleware deployment, making them difficult to manage directly by the core framework. This results in insufficient platform versatility, affecting fine-grained waveform modeling and waveform component reuse. Therefore, this invention specifically discloses a resource management method and system for SDR communication equipment with heterogeneous resource visibility. It improves the design and implementation method of the internal middleware of SDR communication equipment, aiming to solve the problem that while SDR equipment achieves unified resource management within the system based on the core framework, it requires CORBA middleware and an operating system, leading to the inability to manage a large number of processors within the equipment that do not support CORBA middleware. This invention enables unified connection and model abstraction for processors within the SDR communication equipment that support and do not support CORBA middleware deployment. It supports resource management at the system level according to a unified interface, ultimately achieving fine-grained and universal resource management for the platform, thereby supporting rapid waveform development.

[0046] Specifically, a method for managing software-defined radio communication equipment resources that makes heterogeneous resources visible is provided, comprising the following steps:

[0047] S1: Classify processors by type;

[0048] S2: Deploy connectors on non-CORBA processors and deploy managers on the main processor;

[0049] S3: Connect the connector to the manager. The manager generates platform topology data based on the connector's registration information and integrates and builds a unified connection method for CORBA and MHAL / MOCB.

[0050] Furthermore, step S1 involves classifying processors into different types, specifically including:

[0051] Software-defined radio (SDR) communication equipment processors are categorized into CORBA-type processors that support both an operating system and CORBA middleware, and non-CORBA-type processors that do not. Specifically, CORBA-type processors interact with data based on CORBA middleware, while non-CORBA-type processors require the deployment of connectors. This connection between the connector and the connection manager ensures that the core framework of the SDR system can manage the non-CORBA-type processor.

[0052] Furthermore, the connection between the connector and the manager described in step S3 specifically includes:

[0053] The connection manager is deployed on processors that support operating systems and CORBA middleware. It establishes logical connections with connectors and supports core framework interface connections, enabling control and service forwarding. Connectors are deployed on processors that do not support operating systems and CORBA middleware, providing external communication functionality. The relationship between connectors and the connection manager is many-to-one. CORBA-type processors interact with data based on CORBA middleware, while non-CORBA-type processors establish connections with the connection manager through connector deployment, ensuring that the core framework within the software-defined radio system can manage non-CORBA-type processors.

[0054] Furthermore, the connection between the connector and the manager described in step S3 specifically includes:

[0055] S1. Deploy connectors on each non-CORBA processor;

[0056] S2. Each connector registers its local entity and capability descriptor with the manager;

[0057] S3. The manager generates a unified connection topology diagram across processors based on preset policies or user requests.

[0058] S4. The manager sends the topology map to the relevant connectors, and the connectors generate an adapted connection address sequence based on their local connection characteristics.

[0059] S5. Each connector executes a sequence of connection instructions to establish a logical link and periodically reports the link status to the manager.

[0060] S6. When hot-swapping, failure, or security policy changes of any processor cause topology changes, the manager updates the unified connectivity topology map and performs incremental reconfiguration.

[0061] Furthermore, it also includes a management mechanism, specifically comprising the following steps:

[0062] SS1: Connection registration. The connector reads the configuration file and sends a registration message to the manager.

[0063] SS2: The manager registers non-CORBA processors with the core framework based on platform topology data, making non-CORBA processors visible to the core framework;

[0064] SS3: The manager maintains the platform topology by periodically querying the connector, and the manager updates the registration status to the core framework based on the platform topology;

[0065] SS4: The core framework issues control commands such as query, load, and unload, which are received by the manager and forwarded through the logical interface with the connector, enabling the core framework to achieve unified control and management of non-CORBA processors.

[0066] Furthermore, the configuration file provides a standardized description of the processor: This standardized middleware resource description is a resource description method based on XML, used by the connection manager to maintain information about the entire middleware. Its content includes: processor description, basic bus description, CORBA deployment description, and proxy connection description. Some details are explained below:

[0067] Processor Description: A global, static description of the processor type and basic information. Includes: processor type, physical location (the module in which the processor resides), logical location (the logical channel in which the processor resides), and external interfaces.

[0068] Bus description: A global, static description of the bus connections between processors. Includes: Ethernet bus topology, Ethernet address allocation, non-Ethernet bus topology, and corresponding bus address allocation;

[0069] Connection Description: A global and dynamic description of connections made using software-defined radio communication equipment middleware that is visible to heterogeneous resources. Includes: processor type, processor physical location, processor logical location, and connection flags.

[0070] More specifically, in other embodiments, such as Figures 1-5 As shown, it includes the following steps:

[0071] Step 1: To achieve unified management of all processors, the processors inside the software radio device are first classified according to the processor's operating system and CORBA middleware deployment, into CORBA-type processors that support both the operating system and CORBA middleware, and non-CORBA-type processors that do not support both the operating system and CORBA middleware.

[0072] Step 2: Adapt and deploy the connector on non-CORBA type processors, and adapt and deploy the manager on the main processor where the core framework is deployed.

[0073] Step 3: Edit the configuration file for non-CORBA type processors to enable the linker to read information about each non-CORBA type processor, mainly processor type, identifier, address, interface, etc.

[0074] Step 4: After the system is running, the connector reads the configuration file and sends registration information to the manager to register the processor resources based on the general modem hardware abstraction layer MHAL or the on-chip bus modem hardware abstraction layer MOCB interface.

[0075] Step 5: After the manager registers, the corresponding interface object is generated, and then the interface object is registered with the CORBA naming service. The registration information of the interface object is consistent with the information reported by the connector.

[0076] Step 6: The system core framework monitors the status of non-CORBA type processors through the interface object. The core framework issues control commands for adding and unloading waveform components through the interface object, which are then forwarded by the interface object to the connector on the non-CORBA type processor via the manager to execute the corresponding operations. This enables the non-CORBA type processor to be visible to upper-layer applications and achieves unified resource management within the platform.

[0077] Step 7: The manager periodically maintains the system processor connection topology. When it is determined that a connector is offline, it promptly requests the cancellation of the corresponding interface object from the core framework so that the core framework can obtain the online and offline status of the processor.

[0078] On the other hand, a software-defined radio communication equipment resource management system with heterogeneous resource visibility is provided, including a computer device. The computer device includes a processor and a memory, and the memory stores a computer program. When the computer program is loaded by the processor, it executes the method described in any of the preceding claims. The computer device, including the middleware configuration, data access interface, test resource proxy, and test adaptation process, applies the embodiments of the present invention.

[0079] It should be noted that, within the scope of protection defined in the claims of this invention, the following embodiments can be combined and / or extended or replaced in any logical manner from the above specific embodiments, such as the disclosed technical principles, disclosed technical features or implicitly disclosed technical features.

[0080] Example 1

[0081] A method for managing resources in software-defined radio communication equipment that allows visibility of heterogeneous resources, comprising the following steps:

[0082] The internal processors of software radio communication equipment are divided into two types based on whether they can deploy an operating system and CORBA middleware: those that support CORBA middleware and those that do not. For processors that support CORBA middleware, the platform is modeled according to the software radio modeling method. For processors that do not support CORBA middleware, test behavior elements are formed by decomposing test functions, and interface conversion and connectors are provided.

[0083] The connector is then connected to the manager, which generates platform topology data based on the connector's registration information, and integrates and builds a unified connection method for CORBA and MHAL / MOCB.

[0084] Example 2

[0085] Based on Example 1, processors that support CORBA middleware type interact with data based on CORBA middleware. Processors that do not support CORBA middleware type (non-CORBA) establish a connection between the connector and the connection manager by deploying a connector to ensure that the core framework inside the software radio system can manage non-CORBA type processors.

[0086] Example 3

[0087] Based on Example 1, the connection between the connector and the manager specifically includes the following sub-steps:

[0088] The manager is deployed on processors that support operating systems and CORBA middleware, enabling logical connections with connectors at the bottom and supporting core framework interface connections at the top, thus enabling the forwarding of control and business logic. The connectors are deployed on processors that do not support operating systems and CORBA middleware, enabling the processor to transfer external connections. Furthermore, the connectors and the connection manager form a many-to-one relationship.

[0089] Example 4

[0090] Based on Example 1, the manager generates platform topology data according to the connector's registration information, and integrates and constructs a unified connection method for CORBA and MHAL / MOCB, specifically including the following sub-steps:

[0091] S1. Deploy the connector on each processor that does not support CORBA middleware types;

[0092] S2. Each connector registers its local entity and capability descriptor with the manager;

[0093] S3. The manager generates a unified connection topology diagram across processors based on preset policies or user requests.

[0094] S4. The manager sends the topology map to the relevant connectors, and the connectors generate an adapted connection address sequence based on their local connection characteristics.

[0095] S5. Each connector executes a sequence of connection instructions to establish a logical link and periodically reports the link status to the manager.

[0096] S6. When hot-swapping, failure, or security policy changes of any processor cause topology changes, the manager updates the unified connectivity topology map and performs incremental reconfiguration.

[0097] Example 5

[0098] Based on Example 1, after connecting the connector to the manager, a management mechanism is also included, specifically comprising the following steps:

[0099] SS1: Connection registration. The connector reads the configuration file and sends a registration message to the manager.

[0100] SS2: The manager registers non-CORBA processors with the core framework based on platform topology data, making non-CORBA processors visible to the core framework;

[0101] SS3: The manager maintains the platform topology by periodically querying the connector, and the manager updates the registration status to the core framework based on the platform topology;

[0102] SS4: The core framework issues control commands, which are received by the manager and forwarded through the logical interface with the connector, enabling the core framework to achieve unified control and management of non-CORBA processors.

[0103] Example 6

[0104] Based on Example 5, in step SS1, the configuration file is a standardized description of the processor, used by the connection manager to maintain information about the entire middleware.

[0105] Example 7

[0106] Based on Example 6, the standardized description includes a processor description, which is used for a global, static description of the processor type and basic information.

[0107] Example 8

[0108] Based on Example 6, the standardized description includes a bus description, which is used for a global, static description of bus connections between processors.

[0109] Example 9

[0110] Based on Example 6, the standardized description includes a connection description, which is used for a global and dynamic description of connections based on software radio communication equipment middleware that is visible to heterogeneous resources.

[0111] Example 10

[0112] A software-defined radio communication equipment resource management system with heterogeneous resource visibility includes a computer device, characterized in that the computer device includes a processor and a memory, the memory storing a computer program, which, when loaded by the processor, executes the method described in any one of Embodiments 1 to 9.

[0113] According to one aspect of the present invention, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described above.

[0114] In another aspect, embodiments of the present invention also provide a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

Claims

1. A method for managing software-defined radio communication equipment resources with heterogeneous resource visibility, characterized in that, Includes the following steps: The internal processors of software radio communication equipment are divided into two types based on whether they can deploy an operating system and CORBA middleware: those that support CORBA middleware and those that do not. For processor deployment managers that support CORBA middleware, platform modeling is performed according to the software radio modeling method. For processors that do not support CORBA middleware, test behavior elements are formed by splitting the test functions, and interface conversion and connectors are provided. The connector is then connected to the manager, which generates platform topology data based on the connector's registration information, and integrates and builds a unified connection method for CORBA and MHAL / MOCB. The manager generates platform topology data based on the connector's registration information and integrates and constructs a unified connection method for CORBA and MHAL / MOCB, specifically including the following sub-steps: S1. Deploy connectors on each processor that does not support CORBA middleware; S2. Each connector registers its local entity and capability descriptor with the manager; S3. The manager generates a unified connection topology diagram across processors based on preset policies or user requests. S4. The manager sends the topology map to the relevant connectors, and the connectors generate an adapted connection address sequence based on their local connection characteristics. S5. Each connector executes a sequence of connection instructions to establish a logical link and periodically reports the link status to the manager. S6. When hot-swapping, failure, or security policy changes of any processor cause topology changes, the manager updates the unified connectivity topology map and performs incremental reconfiguration.

2. The software-defined radio communication equipment resource management method for heterogeneous resource visibility according to claim 1, characterized in that, Processors that support CORBA middleware interact with data based on CORBA middleware; processors that do not support CORBA middleware (non-CORBA) establish a connection between the connector and the connection manager by deploying connectors, ensuring that the core framework within the software radio system can manage non-CORBA type processors.

3. The software-defined radio communication equipment resource management method for heterogeneous resource visibility according to claim 1, characterized in that, The step of connecting the connector to the manager specifically includes the following sub-steps: The manager is deployed on a processor that supports the operating system and CORBA middleware, enabling logical connections with connectors at the bottom and supporting core framework interface connections at the top, thus enabling the forwarding of control and business logic. Furthermore, the connector is deployed on processors that do not support operating systems and CORBA middleware to enable the processor to transfer external connections; and the connector and the connection manager form a many-to-one relationship.

4. The method for managing software-defined radio communication equipment resources with heterogeneous resource visibility according to claim 2, characterized in that, After connecting the connector to the manager, a management mechanism step is also included: SS1: Connection registration. The connector reads the configuration file and sends a registration message to the manager. SS2: The manager registers non-CORBA processors with the core framework based on platform topology data, making processors that do not support CORBA middleware visible to the core framework. SS3: The manager maintains the platform topology by periodically querying the connector, and the manager updates the registration status to the core framework based on the platform topology; SS4: The core framework issues control commands, which are received by the manager and forwarded through the logical interface with the connector, enabling the core framework to achieve unified control and management of non-CORBA processors.

5. The software-defined radio communication equipment resource management method for heterogeneous resource visibility according to claim 4, characterized in that, In step SS1, the configuration file is a standardized description of the processor, used by the connection manager to maintain information about the entire middleware.

6. The software-defined radio communication equipment resource management method for heterogeneous resource visibility according to claim 5, characterized in that, The standardized description includes a processor description, which is used for a global, static description of the processor type and basic information.

7. The software-defined radio communication equipment resource management method for heterogeneous resource visibility according to claim 5, characterized in that, The standardized description includes a bus description, which is used for a global, static description of bus connections between processors.

8. The software-defined radio communication equipment resource management method for heterogeneous resource visibility according to claim 5, characterized in that, The standardized description includes a connectivity description, which is a global and dynamic description of connectivity based on software radio communication equipment middleware that is visible to heterogeneous resources.

9. A software-defined radio communication equipment resource management system with heterogeneous resource visibility, including computer equipment, characterized in that: The computer device includes a processor and a memory, the memory storing a computer program that, when loaded by the processor, executes the method as described in any one of claims 1 to 8.

Images