A request processing method and apparatus, a storage medium, and a program product
By employing a hybrid architecture of baseband unit and radio frequency remote unit in the physical layer wireless baseband processing unit, and utilizing FPGA and CPU to process functional requests at different levels, the problem of poor flexibility in the prior art is solved, and more efficient and reliable communication processing is achieved.
Patent Information
- Application Number
- CN202411658537.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-19
- Publication Date
- 2025-12-16
- Estimated Expiration
- 2044-11-19
AI Technical Summary
In the prior art, the physical layer wireless baseband processing unit adopts a hybrid architecture of digital signal processing unit and custom integrated circuit, which results in poor flexibility in communication processing requests.
It adopts a hybrid architecture of baseband unit and radio frequency remote unit, uses field-programmable gate array chip and central processing unit to process high-level and low-level physical layer function requests respectively, and optimizes the processing order and resource configuration of bit-level and symbol-level function requests through worker thread and thread pool management technology.
It improves the efficiency and reliability of function request processing, and enhances the flexibility and efficiency of physical layer processing.
Smart Images

Figure CN119544797B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to a request processing method, apparatus, storage medium, and program product. Background Technology
[0002] Currently, physical layer wireless baseband processing units mostly adopt a hybrid architecture of digital signal processing units and custom integrated circuits. After receiving communication processing requests transmitted from the data link layer, they process and schedule the information or data to be processed according to the idle status of the custom integrated circuits.
[0003] However, custom integrated circuits have a limited flexibility in handling communication requests. Summary of the Invention
[0004] This application provides a request processing method, apparatus, storage medium, and program product, which solves the technical problem of poor flexibility in processing communication processing requests in related technologies.
[0005] In a first aspect, this application provides a request processing method, including: receiving a function request; the function request is used to request physical layer function services; processing the function request based on a target unit according to the type of the function request; the target unit includes one of the following: a baseband unit and a radio frequency remote unit; the baseband unit includes one of the following: a field-programmable gate array chip and a central processing unit.
[0006] In one possible implementation, the function request is processed based on the target unit according to the type of the function request, including: if the function request is a higher physical layer function request, the function request is processed by the baseband unit; if the function request is a lower physical layer function request, the function request is processed by the radio frequency remote unit.
[0007] In one possible implementation, the baseband unit includes a field-programmable gate array (FPGA) chip and a central processing unit (CPU). Based on the function request, which is a higher-level physical layer function request, the baseband unit processes the function request, including: bit-level function requests based on the higher-level physical layer function request, processed by the FPGA chip; and symbol-level function requests based on the higher-level physical layer function request, processed by the CPU.
[0008] In one possible implementation, the function request includes bit-level function requests and symbol-level function requests. The function request is a higher-level physical layer function request. The function request is processed based on the baseband unit, including: if the data transmission process corresponding to the function request is an encoding / modulation process, then the bit-level function request and symbol-level function request are processed according to a first processing order, where the priority of processing the bit-level function request is higher than that of processing the symbol-level function request; if the data transmission process corresponding to the function request is a decoding / modulation process, then the bit-level function request and symbol-level function request are processed according to a second processing order, where the priority of processing the bit-level function request is lower than that of processing the symbol-level function request.
[0009] In one possible implementation, the function request is processed based on the target unit according to the type of the function request, including: determining the type of the target unit based on the type of the function request; configuring the worker thread corresponding to the function request based on the type of the target unit; and controlling the target unit to process the function request through the worker thread.
[0010] In one possible implementation, the method further includes: obtaining the processing result corresponding to the worker thread; inputting the processing result into the target parameter prediction model to obtain the processing status corresponding to the processing result, wherein the processing status is used to indicate whether the processing result meets the expected processing status; the processing status includes processing time and / or result accuracy; if the processing status indicates that the processing result does not meet the expected processing status, updating the worker thread corresponding to the function request based on the processing status; and controlling the unit corresponding to the updated worker thread to process the function request through the updated worker thread.
[0011] Secondly, this application provides a request processing apparatus, including: a receiving module and a processing module; the receiving module is used to receive a function request; the function request is used to request physical layer function services; the processing module is used to process the function request based on the type of the function request and based on a target unit; the target unit includes one of the following: a baseband unit and a radio frequency remote unit; the baseband unit includes one of the following: a field-programmable gate array chip and a central processing unit.
[0012] In one possible implementation, the processing module is specifically used to process function requests based on the baseband unit for higher-level physical layer function requests; the processing module is also specifically used to process function requests based on the radio frequency remote unit for lower-level physical layer function requests.
[0013] In one possible implementation, the baseband unit includes a field-programmable gate array (FPGA) chip and a central processing unit (CPU). Specifically, the processing module is further configured to process function requests based on bit-level requests from higher physical layer functional requests using the FPGA chip; or, specifically, to process function requests based on symbol-level requests from higher physical layer functional requests using the CPU.
[0014] In one possible implementation, the function request includes bit-level function requests and symbol-level function requests. The processing module is further specifically configured to process the bit-level and symbol-level function requests according to a first processing order, based on the data transmission process corresponding to the function request being an encoding / modulation process, wherein the priority of processing the bit-level function request in the first processing order is higher than the priority of processing the symbol-level function request; the processing module is also specifically configured to process the bit-level and symbol-level function requests according to a second processing order, based on the data transmission process corresponding to the function request being a decoding / modulation process, wherein the priority of processing the bit-level function request in the second processing order is lower than the priority of processing the symbol-level function request.
[0015] In one possible implementation, the processing module is further specifically used to determine the type of the target unit based on the type of the function request; the processing module is further specifically used to configure the worker thread corresponding to the function request based on the type of the target unit; and control the target unit to process the function request through the worker thread.
[0016] In one possible implementation, the request processing device further includes an acquisition module. The acquisition module is used to acquire the processing result corresponding to the worker thread; input the processing result into the target parameter prediction model to obtain the processing status corresponding to the processing result, the processing status indicating whether the processing result meets the expected processing status; the processing status includes processing time and / or result accuracy; the processing module is further used to update the worker thread corresponding to the function request based on the processing status when the processing status indicates that the processing result does not meet the expected processing status; the processing module is further used to control the unit corresponding to the updated worker thread to process the function request through the updated worker thread.
[0017] Thirdly, this application provides a request processing apparatus, comprising: a processor and a memory configured to store processor-executable instructions; wherein the processor is configured to execute the instructions to implement any of the optional request processing methods in the first aspect described above.
[0018] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed by a request processing device, enable the request processing device to perform any of the optional request processing methods described in the first aspect.
[0019] Fifthly, this application provides a computer program product, which includes computer program instructions that, when executed by a processor, implement any of the optional request processing methods described in the first aspect above.
[0020] The request processing method, apparatus, storage medium, and program product provided in this application target units that are processing units corresponding to the types of function requests. These target units can process function requests more reliably and efficiently. This improves the processing efficiency and reliability of function requests. Attached Figure Description
[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.
[0022] Figure 1 A schematic diagram of a network architecture provided for an embodiment of this application;
[0023] Figure 2 This is a schematic diagram of the structure of a base station provided in an embodiment of this application;
[0024] Figure 3 A schematic diagram of a protocol architecture provided for an embodiment of this application;
[0025] Figure 4 A flowchart illustrating a request processing method provided in an embodiment of this application;
[0026] Figure 5 This application provides a schematic diagram of physical layer partitioning and deployment.
[0027] Figure 6 This is a schematic diagram of another base station structure provided in an embodiment of this application;
[0028] Figure 7 This is a schematic diagram of the overall software architecture of the physical layer provided in an embodiment of this application;
[0029] Figure 8 A schematic diagram of a request processing architecture provided in an embodiment of this application;
[0030] Figure 9 This is a schematic diagram of another request processing architecture provided in an embodiment of this application;
[0031] Figure 10 A flowchart illustrating another request processing method provided in an embodiment of this application;
[0032] Figure 11 This application provides a schematic diagram of a thread pool processing embodiment;
[0033] Figure 12 This is a schematic diagram of the structure of a request processing device provided in an embodiment of this application;
[0034] Figure 13 This is a schematic diagram of another request processing device provided in an embodiment of this application. Detailed Implementation
[0035] The request processing method, apparatus, storage medium, and program product provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.
[0036] The terms "first" and "second," etc., in the specification and drawings of this application are used to distinguish different objects, rather than to describe a specific order of objects. For example, "first processing order" and "second processing order," etc., are used to distinguish different processing orders, rather than to describe a specific order of processing.
[0037] Furthermore, the terms “comprising” and “having”, and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus.
[0038] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0039] The term "and / or" as used in this application includes using either one of two methods or using both methods simultaneously.
[0040] In the description of this application, unless otherwise stated, "a plurality of" means two or more.
[0041] The following explains some concepts involved in the request processing method, apparatus, storage medium, and program product provided in the embodiments of this application.
[0042] The overall network architecture of the 5G wireless cloud base station system is as follows: Figure 1 As shown, gNB, or 5G base station, is responsible for generating downlink wireless signals and receiving uplink wireless signals, enabling wireless access for user terminals.
[0043] Base station architecture as follows Figure 2As shown, the base station is divided into three main parts: Centralized Unit (CU), Distributed Unit (DU), and Radio Unit (RU). The CU is responsible for the higher-level protocol stack and the interface with the core network; the DU is responsible for the lower-level protocol stack and High-PHY functions; and the RU is responsible for Low-PHY and radio functions. The OAM (Operating Management Assistant) module, as an external module, implements the management functions of the entire system and has management interfaces with all modules of the base station.
[0044] Physical Layer Overview: To support the higher throughput and lower latency system requirements proposed by NR, the wireless interface consists of the physical layer (Layer 1, L1), the data link layer (Layer 2, L2), and the application layer (Layer 3, L3).
[0045] Figure 3 The diagram illustrates the NR radio interface protocol architecture surrounding the physical layer (L1). The physical layer connects the Media Access Control (MAC) sublayer of the data link layer (L2) and the Radio Resource Control (RRC) layer of the application layer (L3). The circles between different layers / sublayers represent Serving Access Points (SAPs).
[0046] The physical layer provides transport channels for the MAC layer, and the role of the transport channels is to determine how information is transmitted through the wireless interface. The MAC layer provides different logical channels to the Radio Link Control (RLC) sublayer of the data link layer (L2), and the role of the logical channels is to determine the type of information transmitted.
[0047] The physical layer shall perform at least one of the following functions to provide data transmission services: error detection on the transport channel and indication to higher layers; FEC encoding / decoding of the transport channel; HARQ soft combining; rate matching of the encoded transport channel to the physical channel; mapping the encoded transport channel to the physical channel; power control of the physical channel; modulation and demodulation of the physical channel; frequency and time synchronization; radio signal measurement and indication to higher layers; multiple-input multiple-output (MIMO) antenna processing; radio frequency processing.
[0048] A field-programmable gate array (FPGA) is a special type of chip that can be configured to implement various circuit functions. An FPGA can be configured as a custom circuit to perform specific computational tasks based on specific computational requirements. Unlike instruction-based architectures, FPGAs do not require software programming; instead, they execute computational tasks by directly configuring the hardware circuitry. Because FPGA chips do not rely on general-purpose architectures and software, they can achieve higher performance and efficiency for specific computational tasks.
[0049] A Central Processing Unit (CPU) is a fixed-line circuit with a von Neumann architecture, which excels at instruction scheduling, instruction decoding and execution, and shared memory. Since execution units (such as CPU cores) can execute arbitrary instructions, they require instruction memory, decoders, arithmetic logic units for various instructions, and branch / jump logic. Because the control logic of the instruction flow is complex, there cannot be too many independent instruction flows. Therefore, GPUs use SIMD (Single Instruction Multiple Data) to allow multiple execution units to process different data at the same pace; that is, CPUs also support SIMD instructions. When we need to perform computations, we usually choose to use an instruction-based architecture, such as a CPU or a GPU, and write software programs suitable for these architectures. These architectures are general-purpose and can perform various types of computational tasks.
[0050] As described in the background art, in the relevant technologies, the current physical layer wireless baseband processing unit mostly adopts a hybrid architecture of digital signal processing unit and custom integrated circuit. After receiving the communication processing request transmitted from the data link layer, it processes and schedules the information or data to be processed according to the idle status of the custom integrated circuit.
[0051] However, custom integrated circuits have a limited flexibility in handling communication requests.
[0052] Based on this, embodiments of this application provide a request processing method, apparatus, storage medium, and program product. The target unit is a processing unit corresponding to the type of functional request, and the target unit can process functional requests more reliably and efficiently. This improves the processing efficiency and reliability of functional requests.
[0053] In some embodiments, the request processing device may be a cloud server or control terminal of a 5G wireless cloud base station.
[0054] For example, the request processing apparatus that performs the request processing method provided in the embodiments of this application may further include base stations, evolved node base stations (eNBs), next-generation node base stations (gNBs), new radio eNBs, macro base stations, micro base stations, high-frequency base stations or transmission and reception points (TRPs), non-3rd generation partnership project (3GPP) access networks (such as WiFi) and / or non-3GPP interworking functions (N3IWFs) and other equipment.
[0055] like Figure 4 As shown, the request processing method provided in this application embodiment may include S401-S402.
[0056] S401, Receive function request.
[0057] Among them, the function request is used to request physical layer function services.
[0058] S402. Based on the type of function request, process the function request based on the target unit.
[0059] The target unit includes one of the following: a baseband unit or a radio frequency remote unit; the baseband unit includes one of the following: a field-programmable gate array (FPGA) chip or a central processing unit (CPU).
[0060] It should be understood that the target unit is the processing unit corresponding to the type of function request, and the target unit can process the function request more reliably and efficiently. In this way, the processing efficiency and reliability of the function request can be improved.
[0061] In some embodiments, the above-mentioned processing of function requests based on the type of function request and based on the target unit is implemented in the following ways: if the function request is a higher physical layer function request, the function request is processed by the baseband unit; or if the function request is a lower physical layer function request, the function request is processed by the radio frequency remote unit.
[0062] It should be understood that the baseband unit can process higher physical layer function requests more quickly and reliably than the radio frequency remote unit.
[0063] It should be understood that the radio frequency remote unit can process low-level physical layer function requests more quickly and reliably than the baseband unit.
[0064] In some embodiments, to alleviate the physical layer processing pressure on the baseband processing unit and reduce the throughput pressure on the fronthaul interface, the physical layer functions can be divided into two parts: a higher physical layer (High-PHY) and a lower physical layer (Low-PHY). Specifically, the baseband unit or baseband unit side (i.e., BBU) performs the High-PHY functions, while the remote radio unit or remote radio unit side (i.e., RRU) performs the Low-PHY functions.
[0065] For example, such as Figure 5 The diagram shown is a physical layer partitioning and deployment schematic provided in an embodiment of this application, used to illustrate how physical layer functions are partitioned and deployed into High-PHY and Low-PHY.
[0066] The functions in the High-PHY are implemented by the BBU, while the functions in the Low-PHY are implemented by the RRU. The High-PHY and Low-PHY communicate via a CPRI interface or an eCPRI interface. The CPRI interface is a serial digital bus interface between the RRU and the BBU, including user data, control and management data, and synchronization data. It comprises two layers: a physical layer supporting electrical and optical interfaces, and a data link layer, supporting measurability and adaptability.
[0067] It should be noted that the data transmitted on the communication protocol stack is encoded layer by layer, and the amount of data increases as you go up to the physical layer. Therefore, the CPRI interface can no longer support the signal transmission requirements of 5G. In this case, the eCPRI interface can be used to replace the original CPRI interface.
[0068] In some embodiments, the design idea of eCPRI is as follows: since the data transmitted on the communication protocol stack is encoded layer by layer, the amount of data increases as it goes up to the physical layer. Therefore, the data processed on the BBU can be moved up one layer (processed by the BBU above High Physics) and handed over to the RRU for processing below (processed by the RRU below Low Physics), which can reduce the amount of data between the BBU and the RRU.
[0069] In some embodiments, the eCPRI protocol can be encapsulated on top of UDP or TCP protocols, or it can skip the TCP / IP protocol stack and be carried directly on MAC Ethernet frames.
[0070] In some embodiments, in order to reduce the latency between PHY_High and PHY_Low, the eCPRI protocol can be directly encapsulated on top of the MAC layer Ethernet frame.
[0071] In some embodiments, the eCPRI protocol provides the same three service access points as the CPRI protocol: UserPlane data: here, it is the IQ mobile phone user data between PHY_High and PHY_Low, which is encapsulated through the eCPRI protocol.
[0072] Sync (synchronization plane): This is the synchronization between PHY_High and PHY_Low, and the clock synchronization between RRU and DU. This service is mainly provided by the standard IEEE1588 protocol.
[0073] Control and Management Protocols: The control protocol consists of signaling messages between PHY_High and PHY_Low. The management protocol primarily deals with RRU OAM (Operation, Maintenance, and Management) data and is carried over via standard HTTP or SSH protocols. The control protocol, mainly used for signaling control between PHY_High and PHY_Low, can be carried over via the eCPRI protocol.
[0074] For example, such as Figure 6 The diagram shown illustrates another base station structure provided in this application embodiment. The Out-of-Radio Network (O-RAN) divides the base station system into an O-CU (O-Unit), an O-DU (O-Distribution Unit), and an O-RU (O-Radio Unit). The higher-layer separation interface between the O-CU and O-DU uses the 3GPP F1 interface, while the lower-layer separation interface between the O-DU and O-RU uses Option 7 (i.e., the eCPRI interface). The most significant feature of Option 7 is its ability to divide the physical layer into PHY-High and PHY-Low, which can reduce the required fronthaul bandwidth between the O-DU and O-RU through compression technology. Option 7 can be further subdivided into Option 7-1, Option 7-2, and Option 7-3.
[0075] In some embodiments, the DU side performs the High-PHY portion of the functionality defined in ORAN protocol option 7-2a.
[0076] For example, such as Figure 7 As shown in the diagram, this application provides a schematic of the overall physical layer software architecture. The physical layer software is divided into an FAPI interface adaptation module, a thread processing module, and an RRU interface processing module. The thread processing module is further divided into real-time threads and non-real-time threads. Real-time threads include worker threads and I / O threads, while non-real-time threads include monitoring threads. The 5G FAPI interface is located inside the gNB-DU and is the interface standard between the MAC layer and the physical layer.
[0077] In some embodiments, the baseband unit includes a field-programmable gate array (FPGA) chip and a central processing unit (CPU). The function request is a higher-level physical layer function request, and the baseband unit processes the function request, including: bit-level function requests based on higher-level physical layer function requests, processed by the FPGA chip; and symbol-level function requests based on higher-level physical layer function requests, processed by the CPU.
[0078] It's important to note that the physical channel is the interface between the physical layer and the MAC layer. The physical layer provides services to the MAC layer through the physical channel, similar to how TCP / IP provides different types of application layer ports. The physical channel is the actual carrier of higher-level information in the wireless environment. In LTE, the physical channel is determined by a specific subcarrier, time slot, and antenna port. That is, a specific antenna port corresponds to a series of radio time-frequency resources (REs).
[0079] In some embodiments, the function request includes bit-level function requests and symbol-level function requests. The function request is a higher-level physical layer function request. Processing the function request based on the baseband unit includes: processing the bit-level function request and symbol-level function request according to a first processing order, where the priority of processing the bit-level function request is higher than the priority of processing the symbol-level function request; and processing the bit-level function request and symbol-level function request according to a second processing order, where the priority of processing the bit-level function request is lower than the priority of processing the symbol-level function request, where the data transmission process corresponding to the function request is a decoding-modulation process.
[0080] It's important to note that physical channels generally undergo two main processing steps: bit-level processing and symbol-level processing. From the transmitter's perspective, bit-level processing is the front end of physical channel data processing, primarily involving adding CRC checksums to the binary bit data stream; channel coding; interleaving; rate matching; and scrambling. Following scrambling is symbol-level processing, which includes modulation, layer mapping, precoding, resource block mapping, and antenna transmission. At the receiver, symbol-level processing occurs first, followed by bit-level processing; the processing order differs from that at the transmitter.
[0081] In some embodiments, since the physical layer mainly performs operations such as encoding and modulation on the signal to be transmitted sent by the MAC layer and decoding and demodulating the signal received from the RRU to transmit the decoded signal to the MAC layer, the functions of the High-PHY in the physical layer (PHY) can be identified according to the way the high-level physical layer and the low-level physical layer are divided and the functions of the physical layer.
[0082] For example, such as Figure 8The diagram shown is a schematic of a request processing architecture provided in an embodiment of this application. The functions can be categorized according to the specific content of bit-level processing and symbol-level processing. Based on the functional classification results, High-PHY is further functionally segmented to determine the functions belonging to bit-level processing and symbol-level processing.
[0083] In some embodiments, the bit-level processing function can be associated with an FPGA chip to process bit-level processing requests through the FPGA chip, and the symbol-level processing function can be associated with a CPU processor to process symbol-level processing requests through the CPU processor.
[0084] In some embodiments, different identifiers can be pre-set for bit-level processing requests, symbol-level processing requests, and logic control requests. The identifiers of bit-level processing requests are stored in the FPGA chip's memory, and associated trigger code is written for the FPGA chip so that it automatically triggers processing of the request after recognizing the identifier of a received bit-level processing request. Similarly, the identifiers of symbol-level processing requests and logic control request identifiers are stored in the CPU processor's memory, and associated trigger code is written for the CPU processor so that it automatically triggers processing of the request after recognizing either the identifier of a received symbol-level processing request or the logic control request identifier.
[0085] In some embodiments, before the FPGA chip or CPU processes the data to be processed received by the physical layer, the received data can be identified for processing tasks. Based on the identified processing tasks, the processing function requirements corresponding to each data can be determined, and the data can be classified according to the requirements. Then, each data can be classified and assigned an identifier according to a pre-set identifier, so as to facilitate the identification and processing of the data to be processed by the FPGA chip and the CPU processor.
[0086] It should be understood that associating the bit-level processing function with the FPGA chip and the symbol-level processing function with the CPU processor can accelerate the physical layer channel processing speed and reduce system processing latency. Furthermore, the High-PHY operations in the physical layer are further divided, with bit-level computationally intensive processes handled by the FPGA chip, while logic control and symbol-level processing are handled by the CPU.
[0087] It should be understood that the higher energy efficiency of FPGAs compared to CPUs is essentially a benefit of their instruction-free, shared-memory-free architecture. This is because the function of each logic unit in an FPGA is determined during reprogramming (burning), requiring no instructions. However, this method is more labor-intensive, requiring circuit design and hardware implementation. CPUs are fixed circuits with a von Neumann architecture, which excels at instruction scheduling, thus allowing them to run software—meaning they are software programmable. FPGA logic circuit structures are variable and can be defined at any time; this is the true meaning of hardware programmability. It can implement any circuit through a hardware description language. However, the lack of instructions is also a weakness of FPGAs. Each different task requires a certain amount of FPGA logic resources. If the task is complex and not highly repetitive, it will consume a large amount of logic resources, with most of them idle. In such cases, it is more efficient to use a CPU.
[0088] Understandably, FPGAs are suitable for parallel processing and have high processing speeds based on hardware circuits, while CPUs excel at batch data processing in homogeneous modes and have high processing flexibility using software programming. Therefore, FPGAs and CPUs can work together to handle bit-level processing requests that are localized and repetitive, while complex calculations, symbol-level processing, and logic control can be handled by the CPU.
[0089] In some embodiments, 5G NR physical layer processing is mainly divided into bit-level processing and symbol-level processing. The protocol provides relatively complete specifications for bit-level processing, with a relatively fixed process. For different application scenarios such as multi-user and multi-cell environments, bit-level processing has lower complexity and flexibility. Furthermore, FPGAs are well-suited for bit-level data processing in 5G NR due to their strong programmability, high speed, low power consumption, parallel processing capabilities, high pipelined processing, and gate-based hardware acceleration. Symbol-level data, on the other hand, involves large volumes of data, and the protocol is highly open, allowing different manufacturers to choose their own implementation schemes. In multi-user and multi-antenna scenarios (such as SU-MIMO and MU-MIMO), symbol-level data processing involves different procedures and is more complex. Compared to FPGAs, CPUs have richer computing and storage resources, making them more flexible and easier to configure according to application scenarios. Therefore, considering the characteristics of each stage of physical layer processing and the advantages and disadvantages of FPGA and CPU processing, the physical layer functional processing is divided so that bit-level computationally intensive processes are still handled by FPGA chips, while symbol-level data processing is handled by the CPU.
[0090] For example, such as Figure 9The diagram shown illustrates another request processing architecture provided in this application embodiment. The FPGA acceleration module and the CPU interact via the PCIe bus. Real-time threads running on the CPU initiate processing requests to the acceleration module and receive processing responses from the acceleration module through the underlying driver API. PCIe is a high-speed serial computer expansion bus standard, primarily used to expand the data throughput of the computer system bus and improve device communication speed. PCIe is a high-speed serial point-to-point dual-channel high-bandwidth transmission; connected devices are allocated dedicated channel bandwidth and do not share bus bandwidth. PCIe exists in two forms: M.2 interface channel form and PCIe standard slot.
[0091] In some embodiments, the physical layer CPU processing section utilizes the DPDK software library for functional development. Traditional network devices (switches, routers, etc.) embed network process (NP) processors to quickly process data packets, with built-in hardware circuitry enabling high-speed packet forwarding. With the development of cloud computing, which uses CPUs as its core and Linux as its operating system, network devices are virtualized and lack NP processors. Cloud computing demands high-speed data packet processing. Furthermore, due to the extremely high real-time requirements of physical layer processing, and the fact that the ECPRI interface is based on Ethernet protocol packets, the physical layer CPU processing section utilizes the Data Plane Development Kit (DPDK) software library for functional development to fully leverage the processing performance of domestically produced CPUs for packet data processing.
[0092] It's important to note that DPDK is a data plane development toolset provided by Intel, designed to provide library functions and drivers for efficient packet processing in user space on ARM processor architectures. In simpler terms, DPDK is a software library used to accelerate packet data processing.
[0093] In some embodiments, combined with Figure 4 The illustrated embodiments, such as Figure 10 As shown, the above S402 processes the function request based on the type of the function request and the target unit, including S1001-S1003:
[0094] S1001. Determine the type of the target unit based on the type of the function request.
[0095] S1002. Based on the type of the target unit, configure the corresponding worker thread for the function request.
[0096] S1003. Control the target unit to process function requests through the worker thread.
[0097] It should be understood that by configuring worker threads, it is possible to process function requests.
[0098] In some embodiments, the worker thread corresponding to the request to be processed can be obtained through a pre-built static thread pool. The processing method of the request to be processed can be determined based on the association between the symbol-level processing or bit-level processing and the chip, and the processing thread of the task to be processed can be configured according to the processing method.
[0099] It should be noted that the processing type contained in the worker thread can be the processing tasks contained in the worker thread. The tasks to be processed include bit-level processing, symbol-level processing, and logic control, but the specific type of processing needs to be further identified. Identification method: Compare the characteristics of the data in the task to be processed with the characteristics of the data after bit-level processing and the characteristics of the data after symbol-level processing, and determine the current processing stage of the task to be processed based on the comparison results. Since bit-level processing includes adding CRC checksums, performing channel coding, interleaving, rate matching, and scrambling, and symbol-level processing includes modulation, layer mapping, precoding, resource block mapping, antenna transmission, etc., and bit-level processing and symbol-level processing have a sequential order, the next processing step can be performed once the current stage of the data in the task to be processed is identified.
[0100] In some embodiments, bit-level processing and symbol-level processing are sequential: the physical layer includes two channels, one for encoding and modulating data to ensure data integrity and security during transmission; and the other for decoding and demodulating the encoded and modulated data so that the receiving end can receive and identify the data sent by the sending end. The encoding and modulation process involves first performing bit-level processing on the data and then symbol-level processing, while the decoding and demodulation process involves first performing symbol-level processing on the data and then bit-level processing.
[0101] In some embodiments, the processing threads for physical layer tasks employ a static thread pool design.
[0102] It should be understood that a thread pool is a thread management technique implemented using the pooling concept. Its main purpose is to reuse threads, conveniently manage threads and tasks, and decouple thread creation from task execution. We can reuse already created threads by creating thread pools and reduce the resource consumption caused by frequent thread creation and destruction. A thread pool is essentially a container for managing threads. When a task needs to be processed, it checks whether the core thread count is available, whether the task queue in the thread pool is full, and whether the thread pool size has been exceeded. Then, it calls or creates a thread or queues it. After a thread completes its task, it is not immediately destroyed but continues to wait in the thread pool for the next task. If no new task is added before the thread's lifespan is exceeded, it is destroyed. This reuse of threads reduces overhead.
[0103] For example, such as Figure 11 The diagram shown is a schematic diagram of a thread pool processing method provided in an embodiment of this application.
[0104] The basic architecture of a software thread pool typically includes the following components:
[0105] Thread pool manager: Responsible for managing the state of the thread pool, including thread creation, destruction, and monitoring.
[0106] Task queue: Used to store tasks to be executed, usually implemented using a blocking queue.
[0107] Worker threads: Threads in the thread pool that are responsible for executing tasks in the task queue.
[0108] In some embodiments, configuration parameters that may be involved in thread pool processing include the size of the thread pool, the size of the task queue, etc., which are used to configure the behavior of the thread pool.
[0109] It should be understood that due to the concurrency, asymmetry, and burstiness of physical layer channel and signal processing, in order to fully utilize the computing resources of domestic CPUs, the processing threads for physical layer tasks adopt a static thread pool design. This means that a group of worker threads is created during system startup, and the processing of each worker thread is not pre-defined but rather determined by real-time task requests during system runtime. This brings significant gains to concurrent processing of physical layer channels across multiple cells and users.
[0110] In some embodiments, worker threads in a static thread pool may not have fixed tasks; that is, a single worker thread can handle multiple signal processing tasks. When a worker thread processes a bit-level task, it can call the FPGA chip for processing based on the bit-level task's identifier. When the bit-level task is completed and the thread wants to continue processing symbol-level tasks, it can call the CPU chip for further processing based on the symbol-level task's identifier. Specifically, programmers pre-write two chip-calling code segments for each thread, one for calling the FPGA chip and the other for calling the CPU chip. The dependency between these two code segments is: Finish-to-Start (FS): the subsequent task only begins after the preceding task is completed; the progress of the preceding task directly affects the subsequent task, thus ensuring the execution order of each worker thread. Therefore, the baseband processing unit in the physical layer can consist of either an FPGA chip or a CPU, or, depending on the processing order, a combination of an FPGA chip and a CPU.
[0111] In some embodiments, the baseband processing unit may be composed of an FPGA chip and a CPU. The processing of pending requests may be performed by at least one of the FPGA chip and the CPU. Before task processing, the identification fields of each chip can be read. After identifying the task stage in which the pending task is located, the identifier associated with the task stage can be found, and the remaining computing resources of the chips bound to each identifier can be identified. The chip with remaining computing resources is then called to execute the thread.
[0112] In some embodiments, the pending requests received by the physical layer can be submitted to the task queue of a pre-built static thread pool. The current idle threads in the thread pool are determined by reading the data in the thread pool. Idle threads are allocated to the pending requests according to their priority. The current task stage of the pending task is identified by comparing data characteristics as described above. The chip calling method of each worker thread is determined according to the task stage and the above-mentioned correlation. Then, the computing resources for the thread are configured according to the chip calling method.
[0113] In some embodiments, the priority of pending requests is: interrupt handling task > request reception timestamp. An interrupt handling task monitors the processing data in each worker thread during processing. When it detects that the processed data does not meet the computing power requirements of the pending task, it interrupts the processing progress of that thread and reassigns a thread to the pending task. This pending task is then called the interrupt handling task. The interrupt handling task can be the entire pending task or a part of it. Specifically, if the pending task was not detected as not meeting computing power requirements during bit-level processing in the original worker thread, but is detected during symbol-level processing, the original bit-level processing result is saved, and a new thread is directly assigned to the subsequent symbol-level processing task.
[0114] In some embodiments, the computing power requirements of the task to be processed include: computing power requirements determined based on the data volume and processing content of the task to be processed, and computing power requirements pre-defined by the sending end. For example: performance requirements for chip computing power, such as processing speed, response time, or throughput; chip load characteristics, such as compute-intensive or memory-intensive, and parallel processing capabilities; chip cost and operational stability.
[0115] In some embodiments, the processing data in the worker thread can be monitored; and when the current thread cannot meet expectations, a new thread can be assigned to the task to be processed.
[0116] In some embodiments, the method further includes: obtaining the processing result corresponding to the worker thread; inputting the processing result into the target parameter prediction model to obtain the processing status corresponding to the processing result; updating the worker thread corresponding to the function request based on the processing status if the processing status indicates that the processing result does not meet the expected processing status; and controlling the unit corresponding to the updated worker thread to process the function request through the updated worker thread. The processing status indicates whether the processing result meets the expected processing status. The processing status includes processing time and / or result accuracy.
[0117] It should be understood that the target parameter prediction model can accurately obtain the processing status corresponding to the processing result. If the processing status does not meet the expected processing request, the worker threads are updated. Based on the updated worker threads, the processing requests can be completed more accurately and reliably, thus ensuring the reliability of request processing.
[0118] In some embodiments, the actual processing time of each worker thread for the task to be processed can be monitored.
[0119] In some embodiments, computing resources can be allocated to the worker threads of a task to be processed based on data characteristics to determine the current stage of the task.
[0120] It should be noted that if the judgment result contains a certain degree of error, when the stage of the task to be processed is incorrectly determined, the chip called by the thread and the processing performed will also be incorrect. Furthermore, when allocating computing resources to each thread, the corresponding chip is randomly selected based on the processing type of the task (bit-level processing or symbol-level processing). However, a thread pool can contain multiple chips with different configurations but identical functions. Different tasks have different computing power requirements, and there may be situations where the configuration parameters or performance of the called chip do not meet the computing power requirements of the task to be processed. Therefore, it is necessary to monitor the processing data during or after thread processing and to reallocate threads or chips based on the monitoring results.
[0121] In some embodiments, the actual processing time of a worker thread for a task to be processed is the actual time taken after the worker thread has finished processing its corresponding task.
[0122] In some embodiments, the processing time of each worker thread can be monitored using two CountDownLatch countdown locks. These two CountDownLatch countdown locks include a start timer lock and a task end timer lock. The start timer lock blocks all child threads using `await()` when the child thread task begins, and then, in the main thread, uses CountDownLatch to control all child threads to simultaneously acquire the start time. The task end timer lock counts down once after each child thread finishes execution, until all child threads have finished, at which point the main thread begins recording the end time of all tasks. Alternatively, the processing time of each worker thread can be determined by obtaining the timestamps from each worker thread.
[0123] Optionally, before obtaining the processing time of each worker thread, each worker thread can be classified according to the complexity of its processing type and the amount of data to be processed in the thread. The processing time of one worker thread in each category can be sampled. Based on the sampling results and the number of threads in each category, the actual processing time of each worker thread for the request to be processed can be estimated, thereby reducing the need to count the processing time of threads in the thread pool and improving the efficiency of the statistics.
[0124] For example, the processing type complexity of each worker thread is determined based on the number of processing tasks and processing requirements of each worker thread in the static thread pool, and the processing type complexity is sorted. The data volume of each worker thread is sorted based on the data volume of the tasks to be processed. The sum of the processing type complexity sort and the data volume sort is calculated. Workers with the same type are classified as the same type of worker thread. The processing time of one thread in the same type of worker thread is obtained and used as the processing time of all worker threads included in its type.
[0125] In some embodiments, the worker thread can be input into a pre-trained processing time prediction model, the preset processing time of the request to be processed can be predicted according to the processing time prediction model, and the actual processing time can be compared with the preset processing time.
[0126] It should be noted that the processing time prediction model can be a neural network model pre-trained by the physical layer developers based on the historical worker threads in the static thread pool and the processing times corresponding to those historical worker threads. The processing times corresponding to the historical worker threads can be the processing times of each worker thread in the thread pool by the physical layer before physical layer segmentation using this scheme. The preset processing time can be the processing time of each worker thread in the thread pool for the task to be processed, predicted by the processing time prediction model, without physical layer segmentation.
[0127] Understandably, the purpose of functionally decomposing the physical layer and using FPGA chips and CPU processors to classify and process pending requests is to make full use of the CPU's processing power and improve processing efficiency. Therefore, it can be determined whether the processing method of pending requests has improved processing efficiency by comparing whether the actual processing time is less than the preset processing time.
[0128] Specifically, if the processing method of the pending request is correct, the processing time of the pending request in the physical layer should be less than the processing time before the physical layer is split (i.e., the preset processing time).
[0129] In some embodiments, only the processing time of the task to be processed in each stage can be monitored. If it is detected that the time taken for a worker thread to complete a certain stage of the task to be processed exceeds the preset processing time of that stage, the thread can be directly interrupted and a new worker thread can be assigned to it. The stage task can be the entire process of bit-level processing or the entire process of symbol-level processing.
[0130] In some embodiments, the actual processing results of each worker thread in the pending request can be obtained, the worker threads can be input into a pre-trained processing result prediction model to predict the predicted processing results of each worker thread, and it can be identified whether the accuracy of the actual processing results meets the standard of the predicted processing results.
[0131] In some embodiments, the actual processing result of each worker thread can be the data obtained after processing the data in the task to be processed by each worker thread. The processing result prediction model can be a neural network model pre-trained by the physical layer developers based on the historical worker threads in the static thread pool and the processing results corresponding to the historical worker threads. The processing results corresponding to the historical worker threads are the processing results of each worker thread in the thread pool by the physical layer before the physical layer is split using this scheme. The predicted processing result is the processing result of the physical layer on the worker threads in the thread pool, predicted by the processing result prediction model, without physical layer splitting. The standard for predicting the processing result can be the maximum and minimum values of the processing results of each worker thread on the task to be processed, under the condition that the physical layer functions are not split and the FPGA chip and CPU in the physical layer are running normally.
[0132] Furthermore, if the actual processing data of a certain stage of the pending task does not meet the predicted processing result standard, the thread can be directly interrupted. An assessment of the compatibility between the computing resources allocated by the thread for subsequent stages and the computing power requirements of those subsequent stages can be performed. Based on the assessment results, it can be determined whether computing resources need to be reallocated to the subsequent stages. The specific assessment method follows Formula 1:
[0133]
[0134] Where i represents the computing resource requirement item for the subsequent stage task, n represents the number of computing resource requirement items, f(t) represents the computing resources called by the worker thread for the subsequent stage task, and the value of β is set according to the specific computing resource requirement of the task to be processed.
[0135] Understandably, the purpose of functionally decomposing the physical layer and using FPGA chips and CPU processors to process requests is to fully unleash the computing power of domestically produced CPUs and improve the performance of domestically produced 5G cloud base station equipment. In other words, request processing using the physical layer functional decomposition method in this solution should guarantee the accuracy of the processing results. Therefore, the accuracy of the processing method for the pending request can be judged by comparing whether the accuracy of the actual processing results meets the standard for predicting the processing results. Specifically, if the processing method for the pending request is correct, the accuracy of the physical layer's processing results should not be lower than the accuracy of the processing results before the physical layer decomposition (i.e., the standard for predicting the processing results).
[0136] In some embodiments, if at least one of the worker threads fails to meet the prediction criteria, it is determined that there is a problem with how the pending request is being processed.
[0137] In some embodiments, if at least one of the worker threads does not meet the prediction criteria, it indicates that there is an error in the judgment of the stage of the task to be processed or an error in the allocation of computing resources. Therefore, the worker threads to be processed can be reallocated and the computing resources of each worker thread can be reconfigured.
[0138] Specifically, if a thread does not meet the preset processing time standard, it means that the current task stage of the task to be processed is incorrectly judged. At this time, the task stage initially judged is filtered out, and the task stage is re-judged according to the data characteristics of the task to be processed. The new idle threads in the thread pool are polled, and the task to be processed is assigned to the new idle threads. Then, the processing time of the threads is traversed to meet the preset processing time standard.
[0139] In some embodiments, the task stage is determined based on the data characteristics of the task to be processed: the similarity between the data type, format, and size characteristics of the data in the task to be processed and the data characteristics corresponding to each task stage is compared, and the task stage with the highest similarity is taken as the current or completed task stage of the task to be processed. The next step of processing for the task to be processed is determined based on the current or completed task stage and the order of the task stages in bit-level processing and symbol-level processing. Then, the chip calling order of the thread is determined based on the next processing requirement. If the thread does not meet the criteria for predicting the processing result, computing resources can be reallocated.
[0140] This application embodiment can divide the request processing device and the like into functional modules according to the above method examples. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.
[0141] When dividing each function into modules according to its corresponding function. Figure 12 A possible structural schematic diagram of the request processing apparatus involved in the above embodiments is shown, such as... Figure 12 As shown, the request processing device may include a receiving module 1201 and a processing module 1202.
[0142] The receiving module 1201 is used to receive function requests; the function requests are used to request physical layer function services.
[0143] The processing module 1202 is used to process the function request based on the type of the function request and the target unit; the target unit includes one of the following: a baseband unit and a radio frequency remote unit; the baseband unit includes one of the following: a field-programmable gate array chip and a central processing unit.
[0144] In one possible implementation, the processing module 1202 is specifically used to process the function request based on the baseband unit, which is a higher-level physical layer function request.
[0145] The processing module 1202 is also specifically used to process function requests based on the radio frequency remote unit, which is a low-level physical layer function request.
[0146] In one possible implementation, the baseband unit includes a field-programmable gate array (FPGA) chip and a central processing unit (CPU).
[0147] The processing module 1202 is also specifically used to process function requests based on the field-programmable gate array chip, which is based on the higher physical layer function request as a bit-level function request.
[0148] The processing module 1202 is also specifically used to process function requests based on the central processing unit, which is based on symbol-level function requests from the higher physical layer.
[0149] In one possible implementation, the function request includes bit-level function requests and symbol-level function requests.
[0150] The processing module 1202 is also specifically used to process bit-level function requests and symbol-level function requests according to a first processing order, based on the data transmission process corresponding to the function request being an encoding and modulation process, wherein the priority of processing bit-level function requests is higher than the priority of processing symbol-level function requests in the first processing order.
[0151] The processing module 1202 is also specifically used to process bit-level function requests and symbol-level function requests according to the second processing order, based on the data transmission process corresponding to the function request being a decoding and modulation process. In the second processing order, the priority of processing bit-level function requests is lower than the priority of processing symbol-level function requests.
[0152] In one possible implementation, the processing module 1202 is also specifically used to determine the type of the target unit based on the type of the function request.
[0153] The processing module 1202 is also specifically used to configure the corresponding worker thread for the function request based on the type of the target unit; and to control the target unit to process the function request through the worker thread.
[0154] In one possible implementation, the request processing device further includes an acquisition module 1203.
[0155] The acquisition module 1203 is used to acquire the processing result corresponding to the worker thread; input the processing result into the target parameter prediction model to obtain the processing status corresponding to the processing result, and the processing status is used to indicate whether the processing result meets the expected processing status; the processing status includes processing time and / or result accuracy.
[0156] The processing module 1202 is also used to update the worker thread corresponding to the function request based on the processing status when the processing status indicates that the processing result does not meet the expected processing status.
[0157] The processing module 1202 is also used to control the unit corresponding to the updated worker thread to process the function request through the updated worker thread.
[0158] When using integrated units, Figure 13 A possible structural diagram of the request processing apparatus involved in the above embodiments is shown. For example... Figure 13 As shown, the request processing device may include a processing module 1301 and a communication module 1302. The processing module 1301 can be used to control and manage the actions of the request processing device. The communication module 1302 can be used to support communication between the request processing device and other entities. Optionally, as... Figure 7 As shown, the request processing device may further include a storage module 1303 for storing the program code and data of the request processing device 130.
[0159] The processing module 1301 can be a processor or a controller. The communication module 1302 can be a transceiver, transceiver circuit, or communication interface, etc. The storage module 1303 can be a memory.
[0160] In this configuration, when the processing module 1301 is a processor, the communication module 1302 is a transceiver, and the storage module 1303 is a memory, the processor, transceiver, and memory can be connected via a bus. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc.
[0161] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0162] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0163] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0164] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0165] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.
[0166] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A request processing method, characterized in that, The method includes: Receive a function request; the function request is used to request physical layer function services. Based on the type of the function request, the function request is processed based on the target unit; the target unit includes one of the following: a baseband unit, a radio frequency remote unit; the baseband unit includes one of the following: a field-programmable gate array chip, a central processing unit; The process of processing the function request based on the type of the function request and based on the target unit includes: Since the function request is a high-level physical layer function request, the function request is processed by the baseband unit. Since the function request is a low-level physical layer function request, the function request is processed by the radio frequency remote unit. The baseband unit includes a field-programmable gate array (FPGA) chip and a central processing unit (CPU). The function request is a higher-level physical layer function request. Processing the function request by the baseband unit includes: Since the higher physical layer function request is a bit-level function request, the function request is processed by the field-programmable gate array chip. The higher-level physical layer function request is a symbol-level function request, and the function request is processed by the central processing unit.
2. The method according to claim 1, characterized in that, The function request includes bit-level function requests and symbol-level function requests. The function request is a higher-level physical layer function request. Processing the function request based on the baseband unit includes: Based on the fact that the data transmission process corresponding to the function request is an encoding and modulation process, the bit-level function request and the symbol-level function request are processed in a first processing order, wherein the priority of processing the bit-level function request is higher than the priority of processing the symbol-level function request in the first processing order. Based on the data transmission process corresponding to the function request being a decoding and modulation process, the bit-level function request and the symbol-level function request are processed according to the second processing order, wherein the priority of processing the bit-level function request is lower than the priority of processing the symbol-level function request in the second processing order.
3. The method according to claim 1, characterized in that, The process of processing the function request based on the type of the function request and based on the target unit includes: The type of the target unit is determined based on the type of the function request; Configure the worker thread corresponding to the function request based on the type of the target unit; The target unit is controlled to process the function request through the worker thread.
4. The method according to claim 3, characterized in that, The method further includes: Obtain the processing result corresponding to the worker thread; The processing result is input into the target parameter prediction model to obtain the processing status corresponding to the processing result. The processing status is used to indicate whether the processing result meets the expected processing status. The processing status includes processing time and / or result accuracy. If the processing status indicates that the processing result does not meet the expected processing status, the worker thread corresponding to the function request is updated based on the processing status. The updated worker thread controls the corresponding unit to process the function request.
5. A request processing apparatus, characterized in that, include: Receive module and processing module; The receiving module is used to receive function requests; The function request is used to request physical layer function services; The processing module is used to process the function request based on the type of the function request and based on the target unit; the target unit includes one of the following: a baseband unit, a radio frequency remote unit, a field-programmable gate array chip, and a central processing unit; The processing module is specifically used to process the function request based on the baseband unit, based on the fact that the function request is a high-level physical layer function request. The processing module is also specifically used to process the function request based on the radio frequency remote unit, based on the fact that the function request is a low-level physical layer function request. The processing module is also specifically used to process the function request based on the field-programmable gate array chip, since the higher physical layer function request is a bit-level function request. The processing module is further specifically used to process the function request based on the central processing unit, since the higher physical layer function request is a symbol-level function request.
6. A request processing apparatus, characterized in that, The request processing device includes: processor; A memory configured to store processor-executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1-4.
7. A computer-readable storage medium storing instructions thereon, characterized in that, When the instructions in the computer-readable storage medium are executed by the request processing device, the request processing device is able to perform the method as described in any one of claims 1-4.
8. A computer program product, characterized in that, The computer program product includes computing technology program instructions, which, when executed by a processor, implement the method as described in any one of claims 1-4.
Citation Information
Patent Citations
Reconfigurable wireless MAC layer structure based on microprocessor on FPGA
CN108664444A
Scheduling request SR sending method and device
CN111818656A