Converged communication server resource scheduling method and system
By using RESTful API-based protocol conversion and dynamic resource allocation, combined with NUMA topology awareness and containerized management, the resource conflict and dynamic environment adaptability issues of converged communication servers are resolved, achieving efficient resource utilization and rapid fault recovery, and improving system performance and reliability.
Patent Information
- Application Number
- CN202511366952.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-24
- Publication Date
- 2026-02-10
AI Technical Summary
Existing converged communication server resource scheduling solutions suffer from low resource utilization, insufficient adaptability to dynamic environments, high latency in cross-die access, and low fault recovery efficiency. They are particularly difficult to meet heterogeneous requirements in multi-dimensional resource conflict scenarios.
It employs protocol conversion based on RESTful API format, dynamic resource allocation strategy, NUMA topology-aware scheduling and containerized management, combined with Kubernetes scheduler and CCIX high-speed interconnect technology, to achieve precise allocation of CPU, memory and network bandwidth and second-level fault recovery.
It improved CPU utilization, reduced cross-die access latency, met telecom-grade SLA requirements, enhanced system reliability and the performance of the domestic platform, and enabled rapid fault recovery.
Smart Images
Figure CN121509533A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network communication, and in particular to a method and system for scheduling resources of a converged communication server. Background Technology
[0002] As the core platform of modern enterprise communication systems, converged communication servers integrate multiple communication capabilities such as voice, video, and instant messaging, enabling seamless collaboration across terminals and networks. With the development of 5G and cloud-native technologies, traditional single-function servers are evolving into multi-functional converged architectures, integrating independent modules such as local regeneration servers, edge servers, multipoint control unit (MCU) servers, and address book servers onto a unified hardware platform. Microservice architecture, due to its loose coupling and scalability, has become a key technology for achieving this convergence, decoupling each communication service module into independent instances through containerized deployment. However, when multiple services share hardware resources, dynamic resource scheduling becomes a core challenge in ensuring service quality—requiring real-time coordination of CPU core, memory, and network bandwidth allocation to meet the differentiated real-time and reliability requirements of different services.
[0003] Currently, resource scheduling for converged communication servers mainly adopts two types of schemes: 1. Static Resource Partitioning: This involves pre-allocating fixed resource quotas to each service module (e.g., reserving 16 CPU cores for the MCU service). While simple to implement, this approach suffers from low resource utilization (averaging only 40%-50%) and poor adaptability to sudden traffic surges (e.g., inability to quickly scale up when voice concurrency in border services spikes). Experiments show that in a scenario with 60,000 concurrent users, static allocation leads to a core communication service response latency exceeding 800ms, violating telecom-grade SLA requirements.
[0004] 2. Load balancing-based dynamic scheduling: This method triggers resource reallocation by monitoring CPU / memory utilization. While this approach offers some flexibility, it suffers from three major bottlenecks: Ignoring physical constraints: The impact of heat dissipation bottlenecks (such as fan speed limits) on performance was not considered, and forced frequency reduction under high temperature conditions led to service interruption; Lack of NUMA topology awareness: Memory access latency across CPU Die surges by 80%, severely impacting real-time speech processing performance; Coarse scheduling granularity: Resources are allocated on a process-by-process basis, making it impossible to precisely control container-level network bandwidth, causing video services to preempt voice transmission bandwidth.
[0005] In summary, the existing solutions do not consider the following issues: 1. Multi-dimensional resource conflict challenge: How to simultaneously meet the heterogeneous requirements of high-concurrency proxy for edge services (>1000 voice channels), low-latency decoding for MCU services (24 channels of 720P video), and big data query for address book services (60,000 records) in scenarios where CPU, memory, and network resources are contended; 2. Insufficient adaptability to dynamic environments: How to establish a linkage mechanism between heat dissipation status (such as fan speed and junction temperature) and resource allocation to prevent service degradation caused by overheating triggering hardware protection; 3. Lack of optimization for domestic platforms: How to reduce cross-die access latency and improve the real-time performance of independently controllable systems through NUMA-aware scheduling under domestic multi-die architectures such as Kunpeng 920; 4. Low fault recovery efficiency: How to achieve second-level fault migration of service instances to ensure that a single point of failure does not affect the global service continuity (RTO<30 seconds). Summary of the Invention
[0006] The purpose of this invention is to propose a resource scheduling method and system for converged communication servers, which solves the technical problems of existing converged communication servers, such as easy conflict of multi-dimensional resources, insufficient adaptability to dynamic environments, lack of domestic platform availability, and low fault recovery efficiency.
[0007] Specifically, the present invention provides a method for fast message push based on converged communication, comprising the following steps: S1. Receive user communication requests and convert heterogeneous protocols into standard RESTful API format through the protocol conversion layer; S2. Identify the target service module based on the request type, wherein the service module includes at least two of the following: local regeneration service, border service, multipoint control unit service, and address book service; S3. Query real-time resource monitoring data and dynamically allocate CPU cores, memory, and network bandwidth resources according to the preset priority strategy; S4. Start the target service instance in the containerized environment and communicate between instances through the service mesh; S5 executes the service logic and returns the results, recording resource consumption data to the performance database.
[0008] A converged communication server resource scheduling system includes: Protocol adaptation module: Receives user communication requests and converts heterogeneous protocols into standard RESTful API format through a protocol conversion layer; Service routing module: Identifies target service modules based on request type, wherein the service modules include at least two of the following: local regeneration service, border service, multipoint control unit service, and address book service; Resource scheduling module: Query real-time resource monitoring data and dynamically allocate CPU cores, memory and network bandwidth resources according to preset priority policies; Container cluster module: Starts target service instances in a containerized environment and enables inter-instance communication through the service mesh; Distributed tracing module: Executes service logic and returns results, and records resource consumption data to the performance database.
[0009] The beneficial effects provided by this invention are: 1. The dynamic weight allocation model integrates multi-dimensional parameters such as heat dissipation margin, SLA level, and memory margin, which improves CPU utilization and makes memory allocation more reasonable. 2. Ensure the quality of service for multiple services and meet carrier-grade SLA requirements. NUMA topology-aware scheduling reduces cross-die access latency; voice services offer concurrent multi-path access with reduced latency; video services also experience reduced multi-path decoding latency compared to traditional solutions. 3. Achieve intelligent adaptation to the physical environment and improve system reliability. Through thermodynamic heat dissipation margin calculation, overheating risks can be predicted in advance. 4. Enhance the performance of domestically produced platforms to achieve independent control. This involves enhancing the performance of domestically produced platforms to achieve full-stack independent control, while also promoting the collaboration of domestically produced software and hardware, such as using Tongxin UOS and TiDB databases. Attached Figure Description
[0010] Figure 1 This is a simplified flowchart of the method of the present invention. Detailed Implementation
[0011] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described below with reference to the accompanying drawings.
[0012] Before formally describing this invention, a general overview of its solution is provided for ease of understanding. The relevant technical terms of this invention are explained below: 1. Containerized environment: Isolates the runtime environment through lightweight virtualization technology (such as Docker), allowing multiple services to share the operating system kernel. Compared to virtual machines: startup speed is in seconds (virtual machines take minutes), and resource consumption is 10 times lower.
[0013] 2. Kubernetes Scheduler: A core component of the container cluster management system, responsible for automatically deploying containerized services to physical nodes; analogous to an airport control tower, which allocates parking spaces (server resources) based on the type of aircraft (container).
[0014] 3. NUMA Node: Non-Uniform Memory Access, a memory partitioning management unit for multi-CPU servers. Key features: Each CPU has its own dedicated memory area (fast local access), while access to other memory areas across CPUs is slow (slow remote access). Example: Kunpeng 920 dual-CPU → 2 NUMA nodes, each managing 256GB of memory.
[0015] 4. CCIX High-Speed Interconnect: A chip-to-chip interconnect technology based on the PCIe protocol, allowing multiple CPUs to directly share cache data (without going through memory). Function: Reduces communication latency across NUMA nodes (Kunpeng 920's CCIX latency is <100ns).
[0016] Please refer to Figure 1 The present invention provides a method for fast message push based on converged communication, comprising: S1. Receive user communication requests and convert heterogeneous protocols into standard RESTful API format through the protocol conversion layer; It should be noted that the implementation steps of the protocol conversion layer in step S1 include: S11. Parse the SIP / H.323 / IMS protocol header fields; S12. Extract session control parameters and encapsulate them into a JSON object; S13. Add timestamps and service identifiers to generate standardized RESTful API format requests.
[0017] Specifically, it can use regular expressions to extract key fields from the protocol, such as Call-ID in the SIP protocol and ConferenceID in H.323. On the other hand, it can encapsulate them into a unified JSON structure, for example: json { "protocol": "SIP", "call_id": "x1872", "src_ip": "192.168.1.101", "timestamp": 1689321600 }
[0018] The standard RESTful API format in this invention adopts a three-layer structured data format, namely the metadata layer, the operation instruction layer, and the protocol parameter payload layer.
[0019] The specifications for the metadata layer are shown in Table 1 below: Table 1 Metadata Layer Specification
[0020] The specifications for the operation instruction layer are shown in Table 2 below: Table 2 Operation Instruction Layer Specifications
[0021] It should be noted that the protocol parameter payload layer is used to convert different protocols into standard API formats, such as: The original SIP protocol data is as follows: INVITE sip:bob@domain SIP / 2.0 Via: SIP / 2.0 / UDP 192.168.1.101:5060 From: "Alice"<sip:alice@domain> ;tag=12345 To: "Bob"<sip:bob@domain> Call-ID: x1872@192.168.1.101 CSeq: 314159 INVITE Contact:<sip:alice@192.168.1.101> Content-Type: application / sdp Content-Length: 142 v=0 o=alice 2890844526 2890844526 IN IP4 192.168.1.101 s=Session SDP c=IN IP4 192.168.1.101 t=0 0 m=audio 5060 RTP / AVP 0 a=rtpmap:0 PCMU / 8000 m=video 5062 RTP / AVP 96 a=rtpmap:96 H.264 / 90000.
[0022] The converted RESTful API is as follows: { "metadata": { "request_id": "req_9b7d8f2a-4c6e-41d8", "timestamp": 1689321600123, "protocol_type": "SIP", "service_flag": "BOUNDARY_a3f5c7", "security_level": 2 }, "operation": "POST / sessions", "payload": { "sip_headers": { "Call-ID": "x1872@192.168.1.101", "From": "\"Alice\"<sip:alice@domain>", "To": "\"Bob\"<sip:bob@domain>", "CSeq": "314159 INVITE", "Contact": "<sip:alice@192.168.1.101>" }, "sdp": { "media": [ { "type": "audio", "port": 5060, "protocol": "RTP / AVP", "codec": "PCMU", "clock_rate": 8000 }, { "type": "video", "port": 5062, "protocol": "RTP / AVP", "codec": "H.264", "clock_rate": 90000, "resolution": "1280x720" } ] } }} S2. Identify the target service module based on the request type, wherein the service module includes at least two of the following: local regeneration service, border service, multipoint control unit service, and address book service; It should be noted that step S2 can be implemented using a routing rule table. For example, if the request type or request characteristic `media_type=video`, the corresponding service module is the MCU service; if the request characteristic `method=REGISTER`, the corresponding service module is the border service; and if the request characteristic `cmd=contace_query`, the corresponding service module is the address book service. This invention is for illustrative purposes only and is not intended to be particularly limiting.
[0023] S3. Query real-time resource monitoring data and dynamically allocate CPU cores, memory, and network bandwidth resources according to the preset priority strategy; It should be noted that the priority strategy generation steps in step S3 are as follows: S31. Compile historical load data and establish a mapping table between service types and resource consumption; As an example, the mapping table can be as follows: Table 3 Mapping Relationship between Service Type and Resource Consumption
[0024] S32. Calculate the heat dissipation margin based on the current server temperature and fan speed; It should be noted that the formula for calculating the heat dissipation margin in step S32 is as follows: (1) (2) in Indicates thermal resistance coefficient, The CPU junction temperature is obtained through a chip, such as the temperature sensor built into the Kunpeng 920. This indicates the air inlet temperature of the chassis, obtained through a temperature probe. The real-time power consumption of a single server is obtained through the PMBUS of the power module (such as Huawei power module); For heat dissipation margin, the first term on the right side of equation (2) is the temperature safety factor, the second term on the right side is the thermal resistance degradation factor, and the third term on the right side is the airflow efficiency factor. ; The safe temperature difference threshold; The nominal thermal resistance coefficient of the heat sink; Dust accumulation coefficient; For fan efficiency, This is the actual measured air volume; To achieve the maximum design airflow, this invention couples multiple physical parameters to optimize heat conduction (thermal resistance). ), convection heat transfer (air volume) Q ) and material aging (dust accumulation) It can calculate the heat dissipation margin more accurately.
[0025] This invention uses a thermal resistance degradation factor to quantify the performance degradation of a heatsink, in the case of a new machine. =1, as time goes by The value can be gradually reduced and preset. It can also be dynamically updated, for example, through adaptive updates using a neural network. This invention is only provided as a limited extension.
[0026] S33. Generate dynamic resource allocation weights based on thermal margin and Service Quality Level Agreement (SLA). The dynamic resource allocation weight formula in step S33 is as follows: (3) in, This refers to the i-th service in the service module. , , , To constrain the weighting coefficients, S i For the first i SLA level of each service D i For the first i The service is for response delay, M free Indicates the free memory of the NUMA node; M total This represents the total memory of the NUMA node; For SLA level mapping, please refer to Table 4 below: Table 4 SLA Level Mapping Table
[0027] S34. Based on dynamic resource allocation weights, CPU cores, memory, and network bandwidth resources are dynamically allocated through cgroups.
[0028] The dynamic resource allocation in step S34 is as follows: (4) (5) (6) in N total Indicates the total number of available CPU cores on the server. Uavg Indicates CPU utilization, B total Indicates the total bandwidth of the network interface. B max Indicates the maximum bandwidth of the network interface. Q depth This indicates the network interface card (NIC) queue depth, i.e., the number of packets to be processed. This is a CPU utilization compensation function. k 1, k 2 is an adjustable parameter; This is a network congestion suppression function.
[0029] In this invention, resource allocation can be performed using cgroups, such as: CPU core binding instructions: cgset -r cpuset.cpus=0-15 boundary_service; Memory limit directives: cgset -r memory.limit_in_bytes=8G mcu_service; Bandwidth control commands: tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst10.0.0.2 flowid 1:1; S4. Start the target service instance in the containerized environment and communicate between instances through the service mesh; It should be noted that the specific steps for building the containerized environment in step S4 are as follows: S41. Create an independent Docker image for each service module, with each image containing a simplified version of the Kylin operating system; S42. Bind CPU cores and memory between NUMA nodes using the Kubernetes scheduler; It should be noted that in step S42, the binding between NUMA nodes specifically includes: S421, Detect the physical core topology of the Kunpeng 920 processor; S422, bind high real-time services to cores on the same CPU die; S423. Allocate core groups across dies for compute-intensive services and enable CCIX high-speed interconnect.
[0030] S43. Configure network policies to limit the bandwidth for communication between containers.
[0031] S5 executes the service logic and returns the results, recording resource consumption data to the performance database.
[0032] Specifically, the method of the present invention also includes a fault recovery step, as follows: S61. Monitor the heartbeat packets of service instances and mark the instance as abnormal after a timeout. S62. Read the last valid status from the TiDB database; S63. Restart the instance on the standby NUMA node and restore its state.
[0033] A converged communication server resource scheduling system includes: Protocol adaptation module: Receives user communication requests and converts heterogeneous protocols into standard RESTful API format through a protocol conversion layer; Service routing module: Identifies target service modules based on request type, wherein the service modules include at least two of the following: local regeneration service, border service, multipoint control unit service, and address book service; Resource scheduling module: Query real-time resource monitoring data and dynamically allocate CPU cores, memory and network bandwidth resources according to preset priority policies; Container cluster module: Starts target service instances in a containerized environment and enables inter-instance communication through the service mesh; Distributed tracing module: Executes service logic and returns results, and records resource consumption data to the performance database.
[0034] This invention provides an embodiment for conducting a stress test with 60,000 users, wherein the hardware environment is configured as follows: Server: Huawei 2288H V5, 2×Kunpeng 920 (64 cores@2.6GHz); Memory: 512GB Changxin DDR4-3200; Storage: 4 × Huawei ES3521A SSDs (1.92TB, RAID10); Network: 4×25G SFP28 optical ports; The test scenarios are shown in Table 5 below: Table 5 Test Scenarios for the Invention
[0035] The actual measurement results of this invention are shown in Table 6 below: Table 6 Test Results of the Invention
[0036] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A resource scheduling method for a converged communication server, characterized in that: Includes the following steps: S1. Receive user communication requests and convert heterogeneous protocols into standard RESTful API format through the protocol conversion layer; S2. Identify the target service module based on the request type, wherein the service module includes at least two of the following: local regeneration service, border service, multipoint control unit service, and address book service; S3. Query real-time resource monitoring data and dynamically allocate CPU cores, memory, and network bandwidth resources according to the preset priority strategy; S4. Start the target service instance in the containerized environment and communicate between instances through the service mesh; S5 executes the service logic and returns the results, recording resource consumption data to the performance database.
2. The converged communication server resource scheduling method as described in claim 1, characterized in that: In step S1, the implementation steps of the protocol conversion layer include: S11. Parse the SIP / H.323 / IMS protocol header fields; S12. Extract session control parameters and encapsulate them into a JSON object; S13. Add timestamps and service identifiers to generate standardized RESTful API format requests.
3. The converged communication server resource scheduling method as described in claim 1, characterized in that: In step S3, the priority strategy is generated as follows: S31. Compile historical load data and establish a mapping table between service types and resource consumption; S32. Calculate the heat dissipation margin based on the current server temperature and fan speed; S33. Generate dynamic resource allocation weights based on thermal margin and Service Quality Level Agreement (SLA). S34. Based on dynamic resource allocation weights, CPU cores, memory, and network bandwidth resources are dynamically allocated through cgroups.
4. The resource scheduling method for a converged communication server as described in claim 1, characterized in that: The specific steps for building the containerized environment in step S4 are as follows: S41. Create an independent Docker image for each service module, with each image containing a simplified version of the Kylin operating system; S42. Bind CPU cores and memory between NUMA nodes using the Kubernetes scheduler; S43. Configure network policies to limit the bandwidth for communication between containers.
5. The converged communication server resource scheduling method as described in claim 4, characterized in that: In step S42, the binding between NUMA nodes specifically includes: S421, Detect the physical core topology of the Kunpeng 920 processor; S422, bind high real-time services to cores on the same CPU die; S423. Allocate core groups across dies for compute-intensive services and enable CCIX high-speed interconnect.
6. The converged communication server resource scheduling method as described in claim 1, characterized in that: It also includes fault recovery steps, as follows: S61. Monitor the heartbeat packets of service instances and mark the instance as abnormal after a timeout. S62. Read the last valid status from the TiDB database; S63. Restart the instance on the standby NUMA node and restore its state.
7. The resource scheduling method for a converged communication server as described in claim 1, characterized in that: In step S32, the formula for calculating the heat dissipation margin is as follows: （1） （2） in Indicates thermal resistance coefficient, This is the CPU junction temperature, obtained through a temperature sensor built into the chip. This indicates the air inlet temperature of the chassis, obtained through a temperature probe. The real-time power consumption of a single server is obtained via the power module PMBUS. For heat dissipation margin, the first term on the right side of equation (2) is the temperature safety factor, the second term on the right side is the thermal resistance degradation factor, and the third term on the right side is the airflow efficiency factor. ; The safe temperature difference threshold; The nominal thermal resistance coefficient of the heat sink; Dust accumulation coefficient; For fan efficiency, This is the actual measured air volume; Maximum design air volume; The dynamic resource allocation weight formula in step S33 is as follows: （3） in, This refers to the i-th service in the service module. , , , To constrain the weighting coefficients, S i For the first i SLA level of each service D i For the first i The service is for response delay, M free Indicates the free memory of the NUMA node; M total This represents the total memory of the NUMA node; The dynamic resource allocation in step S34 is as follows: （4） （5） （6） in N total Indicates the total number of available CPU cores on the server. U avg Indicates CPU utilization, B total Indicates the total bandwidth of the network interface. B max Indicates the maximum bandwidth of the network interface. Q depth This indicates the network interface card (NIC) queue depth, i.e., the number of packets to be processed. This is a CPU utilization compensation function. k 1, k 2 is an adjustable parameter; This is a network congestion suppression function.
8. A converged communication server resource scheduling system, characterized in that: include: Protocol adaptation module: Receives user communication requests and converts heterogeneous protocols into standard RESTful API format through a protocol conversion layer; Service routing module: Identifies target service modules based on request type, wherein the service modules include at least two of the following: local regeneration service, border service, multipoint control unit service, and address book service; Resource scheduling module: Query real-time resource monitoring data and dynamically allocate CPU cores, memory and network bandwidth resources according to preset priority policies; Container cluster module: Starts target service instances in a containerized environment and enables inter-instance communication through the service mesh; Distributed tracing module: Executes service logic and returns results, and records resource consumption data to the performance database.