RU information acquisition method and container scheduling method and device based on RU information

Abstract

The invention provides an RU information acquisition method and a container scheduling method and device based on RU information. The RU information acquisition method comprises the steps that first equipment acquires information of RU equipment managed by schedulable nodes in a network cluster; and the first device sends the information of the RU device to a second device, so as to determine a target scheduling node in the schedulable nodes. Therefore, the capability of the existing second equipment is enhanced, the collection of the RU information is supplemented, and the node selection is performed on the to-be-scheduled container based on the collected RU information of the schedulable node, so that the condition that the to-be-scheduled container, especially the to-be-scheduled container of a high-real-time task, is scheduled to the node which does not meet the RU requirement of the to-be-scheduled container is avoided, and the scheduling efficiency of the to-be-scheduled container is improved. Compared with the prior art, the method can be better applied to container scheduling in a high-real-time RU demand scene, not only can proper nodes be more accurately selected for container scheduling, but also the overall reliability of the network, the user experience and the resource utilization efficiency can be improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communication technology, and in particular to a method for obtaining RU information, a container scheduling method and apparatus based on RU information. Background Technology

[0002] In existing technical solutions, container scheduling and management tools are responsible for allocating containers to appropriate nodes in the cluster. The scheduler's operation includes two stages: node filtering and node scoring. In the node filtering stage, the scheduler filters nodes based on the Pod's scheduling requirements and node characteristics, eliminating those that do not meet the criteria to narrow down the candidate node set. Node filtering is typically based on the following criteria: Availability of resources such as CPU (Central Processing Unit) and memory: Checking the resource usage on the node to ensure that the node has sufficient resources to accommodate new Pods. Node labels and tags: Checking the node's labels and tags to ensure that the node meets the Pod's scheduling requirements, such as specific hardware and operating system requirements. Affinity and anti-affinity: Filtering out nodes that do not meet the requirements based on Pod affinity and anti-affinity rules.

[0003] During the node scoring phase, the scheduler calculates a score for each node that meets the filtering criteria and selects the most suitable node to schedule the Pod based on the scores. Node scoring is typically based on the following criteria: Resource utilization: Evaluating the utilization of resources on the node, favoring nodes with lower resource utilization. Node load: Evaluating the load on the node, favoring nodes with lower load. Node health: Evaluating the health status of the node, favoring nodes with good health. Location awareness: Considering the node's location information, such as the region and rack where the node is located, favoring nodes with optimal locations.

[0004] In the existing O-RAN (Open Radio Access Network) system, at the O-Cloud (cloud infrastructure layer of the Open Radio Access Network) layer, the SMO (Service Management and Orchestration) layer can schedule VNF (Virtual Network Function) / CNF (Cloud-native Network Function) that depend on RU (Radio Unit) to the appropriate O-Cloud cluster based on the relevant resource information managed by IMS (Infrastructure Management Services). However, on the one hand, the RU information here needs to be manually queried and reported. On the other hand, the Kubernetes scheduler in the cluster schedules nodes based on their resources (such as CPU and memory) without considering the network topology and the physical location of the RU. When the RU establishes a connection with the corresponding VNF / CNF, it obtains the IP address (Internet Protocol) of the O-RU (Open Radio Unit) controller, i.e., the O-DU (Open Distributed Unit), through DHCP (Dynamic Host Configuration Protocol) and performs NETCONF (Network Configuration Protocol) capability discovery and configuration management. During this process, the O-DU may be scheduled to a node far away from the O-RU, which may lead to increased connection latency or even failure to establish a connection, thereby damaging the reliability and quality of service of the services within the container.

[0005] Existing container scheduling solutions do not include awareness of RU information within the cluster, nor do they have a mechanism for scheduling containers based on RU information. Therefore, there is a possibility that containers may be scheduled to nodes that do not meet the RU requirements of their internal services, thereby impairing the reliability and quality of service of the services within the container. This is especially true in wireless cloud network service scenarios, where many base station services within containers have RU function requirements and specific requirements for RU performance and parameters. Once a container is scheduled to a node that does not meet specific RU requirements, it will immediately affect the availability of base station services. Summary of the Invention

[0006] This invention provides a method for obtaining RU information, a container scheduling method and apparatus based on RU information, to solve the technical problem that the container scheduling in the prior art does not include the perception of RU information within the cluster, nor does it have a mechanism for scheduling containers based on RU information. Therefore, there is a situation where containers are scheduled to nodes that do not meet the RU requirements of their internal business, which affects the availability of services.

[0007] To solve the above-mentioned technical problems, the present invention is implemented as follows:

[0008] In a first aspect, embodiments of this application provide a method for obtaining RU information, including:

[0009] The first device obtains information about the RU devices managed by the schedulable nodes in the network cluster;

[0010] The first device sends the information of the RU device to the second device for determining the target scheduling node among the schedulable nodes.

[0011] Optionally, the first device obtains information about the RU devices managed by the schedulable nodes in the network cluster, including at least one of the following:

[0012] The first device receives information broadcast by the RU devices managed by the schedulable nodes in the network cluster;

[0013] The first device sends a first request to the network cluster and receives information about the RU device from the RU device based on the first request, wherein the first request is used to request information about the RU devices managed by the schedulable nodes in the network cluster.

[0014] Optionally, the information of the RU device includes one of the following:

[0015] First information;

[0016] First information and second information;

[0017] The first information is the basic configuration information of the RU device, which includes at least one of the following: device address, device capabilities, device port address, device port description, and device port VLAN ID.

[0018] The second information includes at least one of the following: device name, device model, device manufacturer, frequency bands supported by the device, and the device's multiple-input multiple-output (MIMO) configuration.

[0019] Optionally, when the information includes the first information and the second information, the first device obtains information about the RU devices managed by the schedulable nodes in the network cluster, including:

[0020] The first device receives the first information and the second information sent by the RU device;

[0021] or,

[0022] The first device receives the first information sent by the RU device;

[0023] The first device sends a second request to the network management unit in the network cluster, wherein the second request is used to request the second information of the RU device, wherein the network management unit receives and stores the second information of the RU device when the RU device is registered;

[0024] The first device receives the second information from the RU device, which is fed back by the network management unit based on the second request.

[0025] Optionally, the first device sends the information of the RU device to the second device for determining the target scheduling node among the schedulable nodes, including:

[0026] The first device calls the interface of the second device to create resource description information containing information about the RU device, and sends the resource description information to the second device for use in determining the target scheduling node among the schedulable nodes.

[0027] Optionally, when the RU device is a direct connection device of the first device, the resource description information includes at least one of the following: device model, device manufacturer, frequency bands supported by the device, MIMO configuration of the device, and device capabilities;

[0028] When the RU device is a device that is not directly connected to the first device in the network cluster, the resource description information includes at least one of the following: device address, device capabilities, device port address, device port description, VLAN ID of the device port, and custom performance indicators, wherein the custom performance indicators include at least the latency information between the device and the server node.

[0029] Secondly, embodiments of this application provide a container scheduling method based on RU information, including:

[0030] The second device receives a container scheduling request from a user, wherein the container scheduling request carries RU requirement information of the container to be scheduled;

[0031] The second device receives information about the RU devices managed by the schedulable node sent by the first device;

[0032] The second device determines the target scheduling node from among the various schedulable nodes based on the information of the RU device and the RU demand information.

[0033] The second device schedules the container to be scheduled to the target scheduling node.

[0034] Optionally, the second device determines the target scheduling node from the schedulable nodes based on the information of the RU device and the RU demand information, including:

[0035] The second device iterates through all schedulable nodes and performs a candidate node determination step for each schedulable node until a candidate node list is determined.

[0036] The candidate node determination step includes: the second device randomly selects a schedulable node from all the schedulable nodes; determines whether the RU information managed by the randomly selected schedulable node meets each requirement in the RU requirement information; if yes, the randomly selected schedulable node is added to the candidate node list; if no, the randomly selected schedulable node is removed.

[0037] The second device scores each candidate node in the candidate node list to obtain a score for each candidate node; the candidate node with the highest score is determined as the target scheduling node.

[0038] The scoring process involves the second device scoring each indicator in the information of the RU devices managed by the candidate node, obtaining the score corresponding to each indicator; and then performing a weighted summation of the scores corresponding to each indicator to obtain the score corresponding to the candidate node.

[0039] Thirdly, embodiments of this application provide an RU information acquisition device, comprising:

[0040] The acquisition module is used to acquire information about the RU devices managed by the schedulable nodes in the network cluster of the first device;

[0041] The first execution module is used to send the information of the RU device to the second device for determining the target scheduling node among the various schedulable nodes.

[0042] Fourthly, embodiments of this application provide a container scheduling apparatus for RU information, comprising:

[0043] The receiving module is used to receive a user's container scheduling request, wherein the container scheduling request carries RU requirement information of the container to be scheduled;

[0044] Receive information about the RU devices managed by the schedulable node sent by the first device;

[0045] The second execution module is used to determine a target scheduling node from the schedulable nodes based on the information of the RU device and the RU demand information.

[0046] The container to be scheduled is scheduled to the target scheduling node.

[0047] Fifthly, embodiments of the present invention provide a network device, including: a processor, a memory, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the steps of a method for obtaining RU information as described in the first aspect, or, when the program is executed by the processor, it implements the steps of a container scheduling method based on RU information as described in the second aspect.

[0048] In a sixth aspect, embodiments of the present invention provide a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of a method for obtaining RU information as described in the first aspect, or, when the program is executed by the processor, it implements the steps of a container scheduling method based on RU information as described in the second aspect.

[0049] In a seventh aspect, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of a method for obtaining RU information as described in the first aspect, or, when executed by the processor, implement the steps of a container scheduling method based on RU information as described in the second aspect.

[0050] In this embodiment of the invention, the capabilities of the second device are enhanced, supplementing the collection of RU information. Based on the collected RU information of each schedulable node, the node selection for the container to be scheduled is performed, thereby avoiding the situation where the container to be scheduled, especially the container to be scheduled for high real-time tasks, is scheduled to a node that does not meet its RU requirements. Compared with the existing technical solutions, it can be better applied to container scheduling in high real-time RU requirement scenarios. The system can not only select nodes for container scheduling more accurately, but also improve the overall reliability, user experience and resource utilization efficiency. Attached Figure Description

[0051] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0052] Figure 1 A flowchart illustrating a method for obtaining RU information provided in an embodiment of the present invention;

[0053] Figure 2A flowchart illustrating a container scheduling method based on RU information provided in an embodiment of the present invention;

[0054] Figure 3 A flowchart illustrating a container scheduling method based on RU information provided in an embodiment of the present invention;

[0055] Figure 4 A flowchart illustrating a method for determining a target scheduling node according to an embodiment of the present invention;

[0056] Figure 5 A flowchart illustrating a container scheduling method based on RU information provided in an embodiment of the present invention;

[0057] Figure 6 A flowchart illustrating a container scheduling method based on RU information provided in an embodiment of the present invention;

[0058] Figure 7 This is a structural block diagram of a device for acquiring RU information provided in an embodiment of the present invention;

[0059] Figure 8 A structural block diagram of a container scheduling device based on RU information provided in an embodiment of the present invention;

[0060] Figure 9 This is a structural block diagram of a network device provided in an embodiment of the present invention. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Figure 1 This application illustrates a method for obtaining RU information according to an embodiment of the present application, such as... Figure 1 As shown, it includes:

[0063] Step S101: The first device obtains information about the RU devices managed by the schedulable nodes in the network cluster;

[0064] Step S102: The first device sends the information of the RU device to the second device for use in determining the target scheduling node among the schedulable nodes.

[0065] In steps S101 and S102, the first device is a server node, and the RU device is an important component of the network. The RU device is responsible for converting the digital signals sent by the base station into radio waves so that they can be transmitted through the air to user devices (such as mobile phones, tablets, etc.). At the same time, it also converts the received radio waves into digital signals and transmits them back to the core network of the base station. The first device can obtain information about the RU devices managed by each schedulable node in the network cluster through some means (such as querying, monitoring, obtaining broadcast information, etc.). This information may include the status, load, performance indicators, etc. of the RU devices. After obtaining the information about the RU devices, the first device sends this information to the second device, which is a system or node responsible for scheduling decisions. The second device can be a container scheduler (such as Kubernetes). The second device needs this information to evaluate and select the most suitable target scheduling node (described in the following scheme).

[0066] In one possible implementation, step S101, whereby the first device obtains information about the RU devices managed by the schedulable nodes in the network cluster, includes at least one of the following: the first device receives information broadcast by the RU devices managed by the schedulable nodes in the network cluster; the first device sends a first request to the network cluster and receives information about the RU devices fed back by the RU devices based on the first request, wherein the first request is used to request information about the RU devices managed by the schedulable nodes in the network cluster.

[0067] It should be noted that the first device can receive information broadcast by the RU device. The RU device will periodically, continuously, or when a specific event occurs, broadcast its status, performance indicators, load status, and other information to the network for other devices to receive. This method allows the first device to obtain the latest status and performance information of the RU device in a timely manner and to respond quickly to changes in the RU device in the network.

[0068] The first device can also send a first request to the network cluster. The purpose of this request is to obtain information about the RU devices. After receiving the request, the RU devices will respond with relevant information based on the content of the request. In this way, the first device can request specific and detailed RU device information (for example, by adding custom fields to the first request to obtain specific RU device information), ensuring that the obtained data is tailored to its needs. This request-response mechanism can achieve more accurate information acquisition.

[0069] In one possible implementation, the information of the RU device includes one of the following: first information; first information and second information; wherein the first information is the basic configuration information of the RU device, which includes at least one of the following: device address, device capabilities, device port address, device port description, and VLAN ID (Virtual Local Area Network Identifier) ​​of the device port; the second information includes at least one of the following: device name, device model, device manufacturer, frequency bands supported by the device, and MIMO (Multiple Input Multiple Output) configuration of the device.

[0070] In one possible implementation, when the information includes first information and second information, the first device obtains information about the RU devices managed by the schedulable nodes in the network cluster, including:

[0071] The first device receives the first and second information sent by the RU device;

[0072] Alternatively, the first device receives the first information sent by the RU device; the first device sends a second request to the network management unit in the network cluster, wherein the second request is used to request the acquisition of the second information of the RU device, wherein the network management unit receives and stores the second information of the RU device when the RU device is registered; the first device receives the second information of the RU device fed back by the network management unit based on the second request.

[0073] In other words, there are two ways to acquire information. One is that the first device can directly receive the first and second information sent by the RU device. That is, the RU device can actively broadcast this information to the first device, thus enabling quick and direct acquisition of all relevant information from the RU device and reducing information acquisition latency. The other method involves the first device first receiving the first information from the RU device, and then sending a second request to the network management unit (NMU) in the network cluster to obtain the second information from the RU device. The NMU receives and stores the second information of the RU device during RU device registration, and therefore can provide the required information according to the first device's request. Finally, the first device receives the second information of the RU device fed back by the NMU based on the second request. This method allows the first device to obtain real-time status information of the RU device while simultaneously requesting more detailed or static information. Through these two methods, a more comprehensive understanding of the RU device's status can be achieved.

[0074] In one possible implementation, the first device sends information about the RU device to the second device for determining the target scheduling node among the schedulable nodes. This includes the first device calling the interface of the second device to create resource description information containing information about the RU device, and sending the resource description information to the second device for determining the target scheduling node among the schedulable nodes.

[0075] It should be noted that, in one possible implementation, when the RU device is a directly connected device of the first device, the resource description information includes at least one of the following: device model, device manufacturer, frequency bands supported by the device, MIMO configuration of the device, and device capabilities; when the RU device is a directly connected device in the network cluster that is not the first device, the resource description information includes at least one of the following: device address, device capabilities, device port address, device port description, VLAN ID of the device port, and custom performance indicators, wherein the custom performance indicators include at least: latency information between the device and the server node.

[0076] This enhances the capabilities of the existing second device (container scheduling and management tool), supplements the collection of RU information, and selects nodes for containers to be scheduled based on the collected RU information of each schedulable node. This avoids the situation where containers to be scheduled, especially those for high real-time tasks, are scheduled to nodes that do not meet their RU requirements. Compared with existing technical solutions, this can be better applied to container scheduling in scenarios with high real-time RU requirements. The system can not only select nodes for container scheduling more accurately, but also improve overall reliability, user experience, and resource utilization efficiency.

[0077] It should be noted that, Figure 1 The method shown describes the process by which the first device obtains RU information. After the first device obtains the RU information, the second device can receive the RU information and perform specific container scheduling based on the RU information. For details, please refer to [reference needed]. Figure 2 .

[0078] Figure 2 This application illustrates a container scheduling method based on RU information according to an embodiment of the present application, such as... Figure 2 As shown, the method includes:

[0079] Step S201: The second device receives the user's container scheduling request;

[0080] The container scheduling request carries the RU requirement information of the container to be scheduled.

[0081] Step S202: The second device receives information about the RU devices managed by the schedulable node sent by the first device;

[0082] Step S203: The second device determines the target scheduling node from among the various schedulable nodes based on the information of the RU device and the RU demand information;

[0083] Step S204: The second device schedules the container to be scheduled to the target scheduling node.

[0084] In one possible implementation, step S203, where the second device determines the target scheduling node from the schedulable nodes based on the RU device information and RU demand information, includes: the second device traversing all schedulable nodes and performing a candidate node determination step for each schedulable node until a candidate node list is determined; wherein the candidate node determination step includes: the second device randomly selecting a schedulable node from all schedulable nodes; determining whether the RU information managed by the randomly selected schedulable node meets each requirement in the RU demand information; if yes, then adding the randomly selected schedulable node to the candidate node list; if no, then removing the randomly selected schedulable node; the second device scoring each candidate node in the candidate node list to obtain a score corresponding to each candidate node; and determining the candidate node with the highest score as the target scheduling node; wherein the scoring is: the second device scoring each indicator in the information of the RU devices managed by the candidate node to obtain a score corresponding to each indicator; and performing a weighted summation of the scores corresponding to each indicator to obtain the score corresponding to the candidate node.

[0085] Therefore, the system can accurately match user RU requirements with the RU device information of each schedulable node, ensuring that containers are scheduled to the most suitable node. Through intelligent scheduling, the system can more effectively utilize existing RU resources, avoiding resource idleness and waste, thereby improving overall resource utilization efficiency. By ensuring that high real-time tasks are scheduled to nodes that meet their RU requirements, the system can reduce task failures or performance degradation caused by resource mismatch, thereby enhancing system reliability. Since containers can run in a suitable environment, users can experience higher service quality and faster response times, thus improving overall user satisfaction.

[0086] The above Figure 1 and Figure 2 Using the first and second devices as the execution entities, this paper introduces schemes for RU information acquisition and container scheduling based on the acquired RU information. An overall embodiment of the container scheduling method based on RU information is then presented. This method enhances existing container scheduling management tools by supplementing the collection of RU information and selecting nodes for the containers to be scheduled based on the collected RU information of each schedulable node. For example, the overall process of the scheme can be found in [reference needed]. Figure 3 .

[0087] Step 1: The server node uses LLDP (Link Layer Discovery Protocol) to obtain information about neighboring devices in the network. Specifically, the RU devices existing in the network topology where the server node is located act as LLDP Neighbors of the server node and broadcast LLDP data packets to the network topology. In this step, you can choose to add custom fields to the data packets to collect information about the RU devices that you want to pay attention to.

[0088] Optionally, step 2: If no custom field was added to the broadcast LLDP data packet in step 1, the server node can request the RU device information corresponding to the custom field from the network management unit.

[0089] Optionally, step 3: If no custom field was added to the broadcast LLDP packet in step 1,

[0090] The network management unit returns the corresponding data packets based on the requested custom fields (as shown in Table 1).

[0091] Step 4: Generate a list of RU resource information in the network topology where the current server node is located based on the basic field information in Table 1, or the basic field information and custom field information, and call the scheduler tool interface to create the corresponding resource description. If the method shown in Steps 2 and 3 is adopted, without adding custom fields, and instead obtaining RU device-related information (the information corresponding to the custom fields) from the network management unit, then in this step, it is necessary to first obtain the device name or device address of the RU device through Step 1, complete the matching, and integrate the two parts of information to form RU resource information.

[0092] Additionally, it should be noted that other RU-related performance metrics not obtained through LLDP can be added at this step, such as the transmission latency between the current node and a specific RU device. These metrics can be obtained using other tools, such as Ping. Server node RU resource information is shown in Table 2.

[0093] Ping is a network tool and command used to test the reachability and latency of network connections.

[0094] Step 5: The first network element / user sends a container scheduling request to the container scheduler through the operation interface, and adds the container's demand information for RU in the request. The demand information can include all or part of the fields shown in Table 2, and the demand information can be described in terms of precise values ​​or threshold ranges.

[0095] Step 6: The container scheduler, based on the demand information of the containers to be scheduled and the obtained RU resource information, filters schedulable nodes within the cluster and scores and sorts the filtered nodes. It can also make judgments based on the demand information and each field in Table 2. The process can be referenced below. Figure 4 If the node's RU information does not meet the container's requirements, the node will be removed from the scheduling list.

[0096] The container scheduler scores schedulable nodes based on a score of ∑ k∈metrics ωk, where k is the RU information indicator, including but not limited to the number of MIMO antennas, latency / distance with the current node, etc. in Table 2, and ω is the preset weight coefficient of each indicator. Finally, the container scheduler sorts the deployable nodes of the current container to be scheduled according to the scoring results and selects the node with the highest score as the final scheduling target.

[0097] Step 7: The container scheduler dispatches the network functions to be scheduled to the target node by issuing scheduling instructions.

[0098] Table 1 LLDP Data Packets

[0099]

[0100]

[0101]

[0102] Table 2 Node RU Resource Information

[0103]

[0104]

[0105]

[0106]

[0107] In specific application scenarios, a method for implementing Kubernetes Pod scheduling based on RU information by adding a custom LLDP field is provided, and the process is as follows: Figure 5 As shown.

[0108] The main steps include:

[0109] Step 1: RU devices in the network broadcast LLDP packets, as shown in Table 1. These packets include basic LLDP information and RU device-related information in custom fields. The server node starts the LLDP daemon to obtain network topology information, as shown in Table 1.

[0110] Step 2: The server node, based on the information collected by LLDP, calls the Kubernetes API Server (one of the core components of the Kubernetes cluster, responsible for handling all interactions and requests with the Kubernetes cluster) to create the corresponding custom resource description, as shown in Table 2. RU resources are generated based on the relevant information list from Step 1. An example resource description is as follows:

[0111] 1.apiVersion:custom.k8s.io / v1

[0112] 2. kind:NodeRUStatus

[0113] 3. metadata:

[0114] 4. name:node-rus-status-example

[0115] 5.spec:

[0116] 6. nodeName: "node-example"

[0117] 7.rus:

[0118] 8. -deviceName:"RU-001"

[0119] 9. model:"Model-X"

[0120] 10. Manufacturer: "Vendor-A"

[0121] 11. frequencyBand: "2.6GHz"

[0122] 12. mimoConfiguration:"4x4"

[0123] 13.systemCapabilities:"Bridge,Router"

[0124] 14. portVlanId:"100"

[0125] 15.neighborDeviceId:"00:11:22:33:44:55"

[0126] 16.neighborPortId:"1"

[0127] 17. distance: 5

[0128] 18.connectionStatus: "Connected"

[0129] 19. -deviceName:"RU-002"

[0130] 20.model:"Model-Y"

[0131] 21. Manufacturer: "Vendor-B"

[0132] 22. frequencyBand: "3.5GHz"

[0133] 23. mimoConfiguration:"8x8"

[0134] 24.systemCapabilities:"Bridge"

[0135] 25.portVlanId:"200"

[0136] 26.neighborDeviceId:"66:77:88:99:AA:BB"

[0137] 27.neighborPortId:"2"

[0138] 28. distance: 10

[0139] 29.connectionStatus: "Disconnected"

[0140] Step 3: Store the node RU resource description in the etcd database.

[0141] Step 4: The first network element sends a Pod creation request to the kube-api-server. It adds a description of the Pod's requirements for RUs to the YAML file describing the Pod. The requirements are shown in Table 2. The requirements can be described in terms of exact values ​​or threshold ranges.

[0142] Step 5: The kube-api-server sends a Pod scheduling request to the kube-scheduler. The request contains a description of the Pod's RU requirements, as shown in Table 2.

[0143] Step 6: kube-scheduler queries the etcd database for resource information of each node in the cluster, including RU-related information, as shown in Table 2. kube-scheduler then filters schedulable nodes within the cluster based on the Pod to be scheduled. This is done by judging each field in the demand information table and the collected node RU information table, as follows: Figure 4 As shown. kube-scheduler scores schedulable nodes based on score = ∑ k∈metrics ωk, where k is the RU information indicator, including but not limited to the number of MIMO antennas and the latency / distance to the current node in Table 1, and ω is the preset weight coefficient for each indicator. kube-scheduler sorts the deployable nodes of the currently scheduled Pod according to the scoring results and selects the node with the highest score as the final scheduling target.

[0144] Step 7: kube-scheduler issues scheduling instructions to the kubelet of the selected target node.

[0145] In specific application scenarios, a method for Kubernetes Pod scheduling based on RU information is also provided in the O-RAN architecture by enhancing the O1 interface. The process is as follows: Figure 6 As shown.

[0146] The main steps include:

[0147] Step 1: After the RU is powered on, it registers its device information with the NETCONF Server (Network Configuration Protocol Server), as shown in the custom fields in Table 1. The NETCONF Server reports the relevant information to the NETCONF Client (Network Configuration Protocol Client) located at the SMO through the NETCONF Call Home mechanism.

[0148] Step 2: RU devices in the network broadcast LLDP packets, as shown in Table 1. These packets include basic LLDP information and RU device-related information in custom fields. The server node starts the LLDP daemon to obtain network topology information, as shown in Table 1.

[0149] Step 3: The server node information processing unit requests the RU device information stored in the SMO through the O1 interface, as shown in the custom fields in Table 1. When making the request, it needs to specify the device identifier to the SMO based on the device address in the current network topology collected in Step 3.

[0150] Step 4: The SMO returns the stored RU-related device information through the O1 interface, as shown in the custom fields in Table 1.

[0151] Step 5: The server node calls kube_api_server to create corresponding custom resource descriptions based on the information collected by LLDP and the RU device information fed back by SMO, as shown in Table 2. RU resources are generated based on the relevant information list from Step 1. An example of a resource description is as follows:

[0152] 1.apiVersion:custom.k8s.io / v1

[0153] 2. kind:NodeRUStatus

[0154] 3. metadata:

[0155] 4. name:node-rus-status-example

[0156] 5.spec:

[0157] 6. nodeName: "node-example"

[0158] 7.rus:

[0159] 8. -deviceName:"RU-001"

[0160] 9. model:"Model-X"

[0161] 10. Manufacturer: "Vendor-A"

[0162] 11. frequencyBand: "2.6GHz"

[0163] 12. mimoConfiguration:"4x4"

[0164] 13.systemCapabilities:"Bridge,Router"

[0165] 14. portVlanId:"100"

[0166] 15.neighborDeviceId:"00:11:22:33:44:55"

[0167] 16.neighborPortId:"1"

[0168] 17. distance: 5

[0169] 18.connectionStatus: "Connected"

[0170] 19. -deviceName:"RU-002"

[0171] 20.model:"Model-Y"

[0172] 21. Manufacturer: "Vendor-B"

[0173] 22. frequencyBand: "3.5GHz"

[0174] 23. mimoConfiguration:"8x8"

[0175] 24.systemCapabilities:"Bridge"

[0176] 25.portVlanId:"200"

[0177] 26.neighborDeviceId:"66:77:88:99:AA:BB"

[0178] 27.neighborPortId:"2"

[0179] 28. distance: 10

[0180] 29.connectionStatus: "Disconnected"

[0181] Step 6: Store the node RU resource description in the etcd database.

[0182] Step 7: The first network element sends a Pod creation request to the kube-api-server. It adds a description of the Pod's requirements for RUs to the YAML file describing the Pod. The requirements are shown in Table 2. The requirements can be described in terms of exact values ​​or threshold ranges.

[0183] Step 8: The kube-api-server sends a Pod scheduling request to the kube-scheduler. The request contains a description of the Pod's RU requirements, as shown in Table 2.

[0184] Step 9: kube-scheduler queries the etcd database for resource information of each node in the cluster, including RU-related information, as shown in Table 2. kube-scheduler then filters schedulable nodes within the cluster based on the Pod to be scheduled. This is done by judging each field in the demand information table and the collected node RU information table, as follows: Figure 4 As shown. kube-scheduler scores schedulable nodes based on score = ∑ k∈metrics ωk, where k is the RU information indicator, including but not limited to the number of MIMO antennas and the latency / distance to the current node in Table 1, and ω is the preset weight coefficient for each indicator. kube-scheduler sorts the deployable nodes of the currently scheduled Pod according to the scoring results and selects the node with the highest score as the final scheduling target.

[0185] Step 10: kube-scheduler issues scheduling instructions to the selected target node kubelet.

[0186] It should also be noted that the first agreement includes at least one of the following:

[0187] SNMP (Simple Network Management Protocol) and NETCONF.

[0188] Container schedulers include at least one of the following: Kubernetes, Docker Swarm, etc. Container scheduling can be triggered by the presence of new containers to be scheduled, i.e., a new container scheduling request from a user, or by changes in the current node RU information, which no longer meets the RU requirements of containers already running on the node.

[0189] In summary, this application provides a container scheduling method based on RU information. This method enhances the capabilities of existing container scheduling and management tools, supplements the collection of RU information, and selects nodes for containers to be scheduled based on the collected RU information of each schedulable node. This avoids the situation where containers to be scheduled, especially those for high real-time tasks, are scheduled to nodes that do not meet their RU requirements. Compared with existing technical solutions, this method can be better applied to container scheduling in scenarios with high real-time RU requirements. The system can not only select nodes for container scheduling more accurately, but also improve overall reliability, user experience, and resource utilization efficiency.

[0190] Specifically, by collecting and analyzing the RU (Resource Requirement) information of each schedulable node, the system can intelligently select the most suitable node to schedule containers to be processed. This precise node selection ensures that high real-time tasks are scheduled to nodes that meet their RU requirements, thereby avoiding performance degradation caused by resource mismatch. By understanding the RU capabilities and status of each node, the system can effectively avoid scheduling multiple high real-time tasks on the same node, thus reducing resource conflicts and competition, ensuring that each task can obtain the necessary resources, and improving the overall system stability. For high real-time tasks, ensuring that they are scheduled to suitable RU nodes can greatly improve the task completion rate and response speed. This ability to guarantee service quality is crucial for many critical business scenarios (such as real-time communication, online games, and IoT applications). Through the effective collection and utilization of RU information, the decision time in the scheduling process is shortened, and the system can allocate tasks faster, reducing the overall scheduling latency. In summary, by enhancing the capabilities of container scheduling management tools, especially in the collection and application of RU information, the system can not only select nodes for container scheduling more accurately, but also improve overall reliability, user experience, and resource utilization efficiency. This technical solution performs particularly well in scheduling scenarios for high real-time tasks, providing strong support for various applications and promoting the intelligent management of network and computing resources.

[0191] Figure 7 An RU information acquisition device according to an embodiment of this application is shown, such as... Figure 7 As shown, it includes:

[0192] The acquisition module 701 is used to acquire information about the RU devices managed by the schedulable nodes in the network cluster of the first device;

[0193] The first execution module 702 is used to send information from the RU device to the second device in order to determine the target scheduling node among the various schedulable nodes.

[0194] In one possible implementation, the acquisition module 701 is used to receive information broadcast by RU devices managed by schedulable nodes in the network cluster; send a first request to the network cluster and receive information of RU devices fed back by RU devices based on the first request, wherein the first request is used to request information of RU devices managed by schedulable nodes in the network cluster.

[0195] In one possible implementation, the information of the RU device includes one of the following:

[0196] First information;

[0197] First information and second information;

[0198] The first piece of information is the basic configuration information of the RU device, which includes at least one of the following: device address, device capabilities, device port address, device port description, and device port virtual LAN identifier (VLAN ID).

[0199] The second information includes at least one of the following: device name, device model, device manufacturer, frequency bands supported by the device, and the device's multiple-input multiple-output (MIMO) configuration.

[0200] In one possible implementation, when the information includes first information and second information, the acquisition module 701 is used to receive the first information and second information sent by the RU device; or, to receive the first information sent by the RU device; to send a second request to the network management unit in the network cluster, wherein the second request is used to request the acquisition of the second information of the RU device, wherein the network management unit receives and stores the second information of the RU device when the RU device is registered; and to receive the second information of the RU device fed back by the network management unit based on the second request.

[0201] In one possible implementation, the first execution module 702 is used to call the interface of the second device to create resource description information containing information about the RU device, and send the resource description information to the second device for determining the target scheduling node among the schedulable nodes.

[0202] In one possible implementation, when the RU device is a directly connected device of the first device, the resource description information includes at least one of the following: device model, device manufacturer, frequency bands supported by the device, MIMO configuration of the device, and device capabilities; when the RU device is a directly connected device in the network cluster that is not the first device, the resource description information includes at least one of the following: device address, device capabilities, device port address, device port description, VLAN ID of the device port, and custom performance indicators, wherein the custom performance indicators include at least: latency information between the device and the server node.

[0203] Figure 8 This application illustrates a container scheduling device 80 based on RU information according to an embodiment of the present application, such as... Figure 8 As shown, it includes:

[0204] The receiving module 801 is used to receive a user's container scheduling request, wherein the container scheduling request carries RU requirement information of the container to be scheduled; and to receive information on the RU devices managed by the schedulable node sent by the first device.

[0205] The second execution module 802 is used to determine the target scheduling node from the schedulable nodes based on the information of the RU device and the RU demand information; and to schedule the container to be scheduled to the target scheduling node.

[0206] In one possible implementation, the second execution module 802 is used to traverse all schedulable nodes and perform a candidate node determination step for each schedulable node until a candidate node list is determined; each candidate node in the candidate node list is scored to obtain a score corresponding to each candidate node; the candidate node with the highest score is determined as the target schedulable node; wherein, the scoring is: the second device scores each indicator in the information of the RU devices managed by the candidate node to obtain a score corresponding to each indicator; the scores corresponding to each indicator are weighted and summed to obtain the score corresponding to the candidate node. The candidate node determination step includes: the second device randomly selects a schedulable node from all schedulable nodes; determining whether the RU information managed by the randomly selected schedulable node meets each requirement in the RU requirement information; if yes, the randomly selected schedulable node is added to the candidate node list; if no, the randomly selected schedulable node is removed.

[0207] In summary, this approach enhances the capabilities of existing container scheduling and management tools, supplements the collection of RU (Resource Requirement) information, and selects nodes for containers to be scheduled based on the collected RU information of each schedulable node. This avoids situations where containers to be scheduled, especially those for high real-time tasks, are scheduled to nodes that do not meet their RU requirements. Compared with existing technical solutions, this approach can be better applied to container scheduling in scenarios with high real-time RU requirements. The system can not only select nodes for container scheduling more accurately, but also improve overall reliability, user experience, and resource utilization efficiency.

[0208] This invention provides a network device 90, such as... Figure 9 As shown, the network device 90 includes a processor 901, a memory 902, and a program stored in the memory 902 and executable on the processor 901. When the program is executed by the processor 901, it implements the steps of the RU information acquisition method and the container scheduling method based on RU information as shown in the above embodiments.

[0209] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of the RU information acquisition method and the RU information-based container scheduling method shown in the above embodiments, achieving the same technical effect. To avoid repetition, these steps will not be repeated here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0210] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the steps of the RU information acquisition method and the container scheduling method based on RU information shown in the above method embodiments, and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0211] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0212] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0213] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A method for acquiring radio frequency unit (RU) information, characterized in that, include: The first device obtains information about the RU devices managed by the schedulable nodes in the network cluster; The first device sends the information of the RU device to the second device for determining the target scheduling node among the schedulable nodes.

2. The method according to claim 1, characterized in that, The first device obtains information about the RU devices managed by the schedulable nodes in the network cluster, including at least one of the following: The first device receives information broadcast by the RU devices managed by the schedulable nodes in the network cluster; The first device sends a first request to the network cluster and receives information about the RU device from the RU device based on the first request, wherein the first request is used to request information about the RU devices managed by the schedulable nodes in the network cluster.

3. The method according to claim 1, characterized in that, The information of the RU device includes one of the following: First information; First information and second information; The first information is the basic configuration information of the RU device, which includes at least one of the following: device address, device capabilities, device port address, device port description, and device port VLAN ID. The second information includes at least one of the following: device name, device model, device manufacturer, frequency bands supported by the device, and the device's multiple-input multiple-output (MIMO) configuration.

4. The method according to claim 3, characterized in that, When the information includes the first information and the second information, the first device obtains information about the RU devices managed by the schedulable nodes in the network cluster, including: The first device receives the first information and the second information sent by the RU device; or, The first device receives the first information sent by the RU device; The first device sends a second request to the network management unit in the network cluster, wherein the second request is used to request the second information of the RU device, wherein the network management unit receives and stores the second information of the RU device when the RU device is registered; The first device receives the second information from the RU device, which is fed back by the network management unit based on the second request.

5. The method according to claim 1, characterized in that, The first device sends the information of the RU device to the second device for determining the target scheduling node among the schedulable nodes, including: The first device calls the interface of the second device to create resource description information containing information about the RU device, and sends the resource description information to the second device for use in determining the target scheduling node among the schedulable nodes.

6. The method according to claim 5, characterized in that, When the RU device is a direct connection device of the first device, the resource description information includes at least one of the following: device model, device manufacturer, frequency bands supported by the device, MIMO configuration of the device, and device capabilities; When the RU device is a device that is not directly connected to the first device in the network cluster, the resource description information includes at least one of the following: device address, device capabilities, device port address, device port description, VLAN ID of the device port, and custom performance indicators, wherein the custom performance indicators include at least the latency information between the device and the server node.

7. A container scheduling method based on RU information, characterized in that, include: The second device receives a container scheduling request from a user, wherein the container scheduling request carries RU requirement information of the container to be scheduled; The second device receives information about the RU devices managed by the schedulable node sent by the first device; The second device determines the target scheduling node from among the various schedulable nodes based on the information of the RU device and the RU demand information. The second device schedules the container to be scheduled to the target scheduling node.

8. The method according to claim 7, characterized in that, The second device, based on the information of the RU device and the RU demand information, determines the target scheduling node from the schedulable nodes, including: The second device iterates through all schedulable nodes and performs a candidate node determination step for each schedulable node until a candidate node list is determined. The candidate node determination step includes: the second device randomly selects a schedulable node from all the schedulable nodes; determines whether the RU information managed by the randomly selected schedulable node meets each requirement in the RU requirement information; if yes, the randomly selected schedulable node is added to the candidate node list; if no, the randomly selected schedulable node is removed. The second device scores each candidate node in the candidate node list to obtain a score for each candidate node; the candidate node with the highest score is determined as the target scheduling node. The scoring process involves the second device scoring each indicator in the information of the RU devices managed by the candidate node, obtaining the score corresponding to each indicator; and then performing a weighted summation of the scores corresponding to each indicator to obtain the score corresponding to the candidate node.

9. A device for acquiring RU information, characterized in that, include: The acquisition module is used to acquire information about the RU devices managed by the schedulable nodes in the network cluster of the first device; The first execution module is used to send the information of the RU device to the second device for determining the target scheduling node among the various schedulable nodes.

10. A container scheduling device based on RU information, characterized in that, include: The receiving module is used to receive a user's container scheduling request, wherein the container scheduling request carries RU requirement information of the container to be scheduled; Receive information about the RU devices managed by the schedulable node sent by the first device; The second execution module is used to determine a target scheduling node from the schedulable nodes based on the information of the RU device and the RU demand information. The container to be scheduled is scheduled to the target scheduling node.

11. A network device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the RU information acquisition method as described in any one of claims 1-6, or, when the program is executed by the processor, it implements the steps of the container scheduling method based on RU information as described in any one of claims 7-8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the RU information acquisition method as described in any one of claims 1-6, or, when executed by the processor, implements the steps of the container scheduling method based on RU information as described in any one of claims 7-8.

13. A computer program product, characterized in that, The program includes computer instructions that, when executed by a processor, implement the steps of the RU information acquisition method as described in any one of claims 1-6, or, when executed by the processor, implement the steps of the container scheduling method based on RU information as described in any one of claims 7-8.

Images