Air interface resource scheduling method and device, program product, storage medium and base station

By introducing a method that separates background threads and scheduling threads in millimeter-wave communication systems, tasks unrelated to radio resource allocation are handled, solving the problem of scheduling a large number of UEs in a short period of time, and improving system performance and scheduling success rate.

CN119255396BActive Publication Date: 2025-11-18SICHUAN CHUANGZHI LIANHENG TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202411213118.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-08-30
Publication Date
2025-11-18
Estimated Expiration
2044-08-30

AI Technical Summary

Technical Problem

In millimeter-wave communication systems, existing technologies struggle to effectively schedule a large number of user equipment (UEs) in a short period. This is because base stations also need to handle tasks unrelated to resource allocation when allocating radio resources, resulting in excessive computational pressure and low scheduling efficiency.

Method used

By separating the background thread and the scheduling thread, the background thread handles non-scheduling tasks, such as calculating scheduling priorities and ephemeris, while the scheduling thread focuses on wireless resource allocation, reducing the computational burden on the scheduling thread and thus improving scheduling efficiency.

Benefits of technology

Within each transmission time interval, the base station can schedule more UEs, improving the performance and scheduling success rate of the communication system. This is particularly suitable for millimeter wave systems and also improves the scheduling efficiency of non-millimeter wave systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119255396B_ABST
    Figure CN119255396B_ABST
Patent Text Reader

Abstract

The application relates to the technical field of communication, and provides an air interface resource scheduling method, device, program product, storage medium and base station. The air interface resource scheduling method comprises the following steps: a background thread is used to execute a non-scheduling necessary task, and the non-scheduling necessary task does not include allocating wireless resources for a target UE to be scheduled; and a scheduling thread is used to execute a scheduling necessary task, and the scheduling necessary task includes allocating wireless resources for the target UE. In the method, the scheduling thread is only responsible for wireless resource allocation, and the background thread is used to complete tasks other than wireless resource allocation, so that the calculation pressure of the scheduling thread is reduced, the scheduling thread can complete the scheduling of more UEs in each TTI, and the performance of the whole communication system is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to an air interface resource scheduling method, apparatus, program product, storage medium, and base station. Background Technology

[0002] Millimeter-wave communication refers to a technology that uses electromagnetic waves with frequencies between 30 GHz and 300 GHz for communication. Compared to traditional wireless communication technologies, millimeter-wave communication has higher frequencies and shorter wavelengths, enabling higher data transmission rates. Millimeter-wave communication is also an important component of 5G communication technology and has been widely used in areas such as satellite communication.

[0003] The Transmission Time Interval (TTI) is the period during which base stations in 5G communication systems schedule air interface resources. Within each TTI, the base station schedules user equipment (UEs) accessing the system. In millimeter-wave systems, the TTI can be reduced to 0.125ms. Scheduling a larger number of UEs within such a short timeframe presents a significant challenge, and current technologies have not yet provided a satisfactory solution. Summary of the Invention

[0004] The purpose of this application is to provide an air interface resource scheduling method, apparatus, program product, storage medium, and base station to improve at least some of the above-mentioned technical problems.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] In a first aspect, embodiments of this application provide an air interface resource scheduling method, comprising: using a background thread to execute non-mandatory scheduling tasks, wherein the non-mandatory scheduling tasks do not include allocating radio resources to a target UE to be scheduled; and using a scheduling thread to execute mandatory scheduling tasks, wherein the mandatory scheduling tasks include allocating radio resources to the target UE.

[0007] For the base station, the essential task during the scheduling phase (which can be considered within each TTI) is to allocate radio resources to the UEs to be scheduled. Other tasks can be performed during the scheduling phase or not. In the method described above, the scheduling thread is only responsible for radio resource allocation, while a background thread handles tasks other than radio resource allocation. This reduces the computational burden on the scheduling thread, allowing it to schedule more UEs within each TTI, thereby improving the overall performance of the communication system. This method is particularly suitable for millimeter-wave systems, but it can also improve scheduling efficiency in non-millimeter-wave systems.

[0008] In one implementation of the first aspect, the non-schedulable tasks include at least one of the following: calculating the scheduling priority of the UE; sorting the UEs according to the scheduling priority; wherein the target UE is derived from the sorted UEs; calculating the ephemeris; calculating the bit error rate; calculating Quality of Service (QoS) traffic shaping; and processing user plane data at the Medium Access Control (MAC) layer.

[0009] In the above implementation, a series of tasks that are not directly related to radio resource allocation can be handed over to background threads for processing, which can greatly improve the scheduling efficiency of UEs and thus support the scheduling of more UEs within a TTI.

[0010] In one implementation of the first aspect, if the target UE performs downlink scheduling, the scheduling tasks include: allocation processing of Physical Downlink Control Channel (PDCCH) resources and allocation processing of Physical Downlink Shared Channel (PDSCH) resources for downlink scheduling; if the target UE performs uplink scheduling, the scheduling tasks include: allocation processing of PDCCH resources for uplink scheduling, allocation processing of Physical Uplink Shared Channel (PUSCH) resources, allocation processing of Physical Uplink Control Channel (PUCCH) resources, allocation processing of Sounding Reference Signal (SRS) resources, and allocation processing of Physical Random Access Channel (PRACH) resources.

[0011] The above implementations provide the essential scheduling tasks that can be executed during downlink and uplink scheduling. It is clear that these tasks only involve radio resource allocation, thus ensuring high efficiency for the scheduling thread in both downlink and uplink scheduling.

[0012] In one implementation of the first aspect, the scheduling task includes multiple scheduling steps, and the execution of the scheduling task using a scheduling thread includes: using the scheduling thread to execute all scheduling steps for each target UE in sequence; wherein, the completion of all scheduling steps for a target UE indicates that the target UE has completed scheduling.

[0013] In the above implementation, the scheduling thread prioritizes the user experience (UE) during scheduling, meaning it prioritizes scheduling individual target UEs rather than individual scheduling steps. Therefore, even if a target UE times out during scheduling, at least the target UEs that have already completed all scheduling steps before that timeout are still successfully scheduled. This implementation helps improve the UE scheduling success rate.

[0014] In one implementation of the first aspect, the scheduling thread is a single thread, and the step of using the scheduling thread to execute all scheduling steps for each target UE in sequence includes: using the single scheduling thread to execute all scheduling steps for each target UE in sequence, and after scheduling one target UE, starting to schedule the next target UE.

[0015] The above implementation is a single-threaded approach prioritizing UE-level scheduling. In this single-threaded implementation, since target UEs are scheduled sequentially according to the scheduling order (which can be determined by the background thread), even if a target UE times out during scheduling, at least other target UEs scheduled before it will be successfully scheduled. Therefore, this implementation helps improve the UE scheduling success rate.

[0016] In one implementation of the first aspect, the scheduling thread is a plurality of threads, and the step of using the scheduling thread to execute all scheduling steps for each target UE in sequence includes: using multiple scheduling threads to schedule a corresponding number of target UEs in parallel; wherein, each scheduling thread is responsible for executing all scheduling steps for one target UE, and after a scheduling thread has finished scheduling one target UE, the scheduling thread will take a new target UE for scheduling.

[0017] In one implementation of the first aspect, the scheduling thread comprises multiple threads, and the step of using the scheduling thread to sequentially execute all scheduling steps for each target UE includes: using multiple scheduling threads to execute a corresponding number of scheduling steps in parallel; wherein each scheduling thread retrieves a scheduling step from a task queue for execution, and after a scheduling thread completes one scheduling step for a target UE, if there is at least one scheduling step that can be parallelized, the scheduling thread puts the at least one scheduling step that can be parallelized into the task queue and retrieves a new scheduling step from the task queue for execution; if there is no at least one scheduling step that can be parallelized, the scheduling thread directly retrieves a new scheduling step from the task queue for execution; the at least one scheduling step that can be parallelized satisfies the following conditions: it is a subsequent scheduling step for the target UE, and there is no dependency between them, and it depends only on the scheduling steps that the target UE has already executed or does not depend on any scheduling steps of the target UE; and / or, it is a new scheduling step for the target UE, and there is no dependency between them.

[0018] Both of the above implementations are multi-threaded implementations that prioritize UE-level scheduling. Compared to single-threaded implementations, multi-threaded implementations offer higher scheduling efficiency, but also require more hardware resources. In fact, since the tasks to be executed by the scheduling thread in this application are greatly simplified, the scheduling efficiency of a single-threaded implementation is also considerable, and it also helps to reduce hardware costs.

[0019] In the two multithreaded implementations mentioned above, the former is parallelism at the granularity of the user experience (UE), while the latter is parallelism at the granularity of the scheduling steps. The latter has a smaller and more flexible granularity, but may require a more complex parallel design because some scheduling steps may have dependencies on each other, and not every two scheduling steps can be parallelized.

[0020] In one implementation of the first aspect, the method further includes: storing the context of each UE in a UE context array, wherein the UE context includes scheduling information that the UE needs to use during scheduling; when the scheduling thread executes the plurality of scheduling steps for the target UE, it only passes the array index of the target UE between and / or within each scheduling step, and within the scheduling step, it obtains the scheduling information corresponding to the target UE from the UE context array through the array index of the target UE, and schedules the target UE based on the scheduling information.

[0021] In the above implementation, all UE scheduling information is stored in the UE context array. The array index of the target UE is only passed between and / or within each scheduling step. When necessary, the scheduling information of the target UE can be obtained from the UE context array through this array index, thereby reducing the overhead of data copying during the scheduling process, which helps to improve scheduling efficiency and save storage resources.

[0022] In one implementation of the first aspect, the scheduling task includes multiple scheduling steps, and the execution of the scheduling task using a scheduling thread includes: using the scheduling thread to execute each scheduling step sequentially for all target UEs.

[0023] In the above implementation, the scheduling thread prioritizes scheduling steps, meaning it prioritizes completing individual scheduling steps rather than individual target UEs. Since multiple target UEs execute the same scheduling step's code within a short period, the CPU cache hit rate is higher, which helps improve scheduling efficiency. However, it should be noted that because the scheduling thread code in this application is already very concise, even with the UE-centric scheduling method, the cache hit rate is not low.

[0024] Secondly, embodiments of this application provide an air interface resource scheduling device, comprising: a first execution module, configured to execute non-mandatory scheduling tasks using a background thread, wherein the non-mandatory scheduling tasks do not include allocating radio resources to a target UE to be scheduled; and a second execution module, configured to execute mandatory scheduling tasks using a scheduling thread, wherein the mandatory scheduling tasks include allocating radio resources to the target UE.

[0025] Thirdly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the method provided in the first aspect or any implementation thereof.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the method provided in the first aspect or any implementation thereof.

[0027] Fifthly, embodiments of this application provide a base station, including: a memory, a processor, a signal transceiver, and a bus. The memory stores computer program instructions, which are read and executed by the processor to perform the method provided in the first aspect or any implementation thereof. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A wireless communication system that can be used in the air interface resource scheduling method provided in the embodiments of this application is shown;

[0030] Figure 2 The flowchart illustrates the possible flow of the air interface resource scheduling method provided in the embodiments of this application;

[0031] Figure 3 This illustrates the first method by which the scheduling thread schedules the UE;

[0032] Figure 4 This illustrates a second method for scheduling the UE using the scheduling thread;

[0033] Figure 5 This application illustrates the functional modules that the air interface resource scheduling device provided in the embodiments of this application may include;

[0034] Figure 6 The possible structure of the base station provided in the embodiments of this application is shown. Detailed Implementation

[0035] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. It should be noted that similar reference numerals and letters in the following drawings indicate similar items; therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0036] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0037] The terms “first,” “second,” etc., are used only to distinguish one entity or operation from another, and should not be construed as indicating or implying relative importance, nor as requiring or implying any such actual relationship or order between these entities or operations.

[0038] The technologies described in this application can be applied to wireless communication systems such as New Radio (NR) and Long Term Evolution (LTE), as well as to communication systems such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), and Single-Carrier Frequency-Division Multiple Access (SC-FDMA), and even communication systems still in the research stage, such as 6G communication systems, etc.

[0039] The technologies described in the embodiments of this application can be used not only in the systems and radio technologies mentioned above, but also in other systems and radio technologies. For simplicity, the following text primarily uses a 5G NR system as an example to illustrate the solution of this application, and the terminology used is also mainly from the 5G NR system. When the solution is applied to other communication systems, the relevant terms can be replaced with similar concepts from other systems.

[0040] Figure 1 A wireless communication system is shown that can be used to execute the air interface resource scheduling method provided in the embodiments of this application. (Refer to...) Figure 1 The wireless communication system 100 includes multiple UEs 110 and base stations 120. It should be understood that the wireless communication system 100 may also include other components, such as core network equipment. Figure 1 The equipment shown is mainly related to air interface resource scheduling.

[0041] UE 110 can be a terminal device such as a mobile phone, tablet, laptop, personal computer, personal digital assistant, wearable device, or in-vehicle device. UE 110 can be a fixed-location device or a mobile device.

[0042] Base station 120 can be a terrestrial base station and / or a satellite base station. That is, the wireless communication system 100 does not necessarily need to include both types of base stations simultaneously. For example, a satellite communication system can include both types of base stations, while a terrestrial millimeter-wave system may only include terrestrial base stations. It should be noted that in the field of communications, a base station may be referred to as a Node B (NB), Evolved Node B (eNB), access point, Base Transceiver Station (BTS), radio base station, radio transceiver, Basic Service Set (BSS), Extended Service Set (ESS), or any other suitable term in the field, as long as the same technical effect is achieved. The term "base station" is not limited to any specific technical term.

[0043] UE 110 can access base station 120 and communicate with base station 120, and then communicate with other UE 110 through base station 120 and possible core network equipment, such as to make voice calls, transfer files, etc. That is, wireless communication system 100 can, but is not limited to, enable communication between different UE 110.

[0044] In the wireless communication system 100, one of the main tasks of the base station 120 is to schedule the access UE 110, that is, to allocate and manage the radio resources used by the UE 110, including time resources, frequency resources, etc. In the 5G NR protocol stack, the scheduling behavior can be performed at the MAC layer. After the scheduling is completed, the UE 110 will use the radio resources allocated to it to conduct uplink or downlink communication with the base station 120 according to the scheduling result.

[0045] For 5G NR systems, scheduling is performed repeatedly in time intervals (TTIs). Within each TTI, base station 120 schedules the UEs 110 accessing that base station 120. Possible TTI values ​​include 1ms, 0.5ms, and 0.25ms. Shorter TTIs provide faster scheduling response times, higher frequency reuse, and finer resource allocation, helping to improve system capacity and throughput; longer TTIs reduce scheduling overhead and the number of control signaling requests, helping to reduce system complexity and power consumption. In 5G NR systems, the TTI length is typically set to 1ms, but flexible configuration of the TTI length is also supported. For example, in millimeter-wave systems, the TTI can be configured to 0.125ms. However, existing technologies do not provide a good solution for scheduling a larger number of UEs 110 within such a short time.

[0046] The inventors have discovered through long-term research that one of the reasons for the poor scheduling performance of existing technologies is that within each TTI, in addition to allocating radio resources to the UE, the base station also performs some tasks that are not directly related to resource allocation, such as calculating scheduling priorities for the UE and sorting the UEs. Some of these tasks require a lot of computing resources, which results in the actual scheduling time being occupied.

[0047] Based on the above reasons, the air interface resource scheduling method, apparatus, program product, storage medium, and base station provided in this application distinguish between mandatory and non-mandatory scheduling tasks and assign these two types of tasks to different threads for execution. Only the execution of mandatory scheduling tasks will occupy a TTI, while the execution of non-mandatory scheduling tasks will not occupy a TTI. This reduces the number of tasks that the base station needs to execute within each TTI, thereby enabling the scheduling of more UEs and improving the overall performance of the communication system. The specific details of the solution will be described later. In addition, it should be noted that, apart from the solution itself, the above analysis of the reasons for the poor scheduling performance of existing communication systems is also a contribution of the inventors to this application, rather than a conclusion already existing in the prior art.

[0048] Figure 2The illustration shows a possible flow of the air interface resource scheduling method provided in an embodiment of this application. This method can, but is not limited to, be executed by a base station in a wireless communication system, which can be... Figure 1 The wireless communication system 100 in the system, wherein the base station in the wireless communication system can be Figure 1 The base station 120 in the middle, and the base station can have Figure 6 The structure is shown. For the 5G NR protocol stack, this method can be executed at the MAC layer. (Refer to...) Figure 2 Air interface resource scheduling methods include:

[0049] Step S210: Execute non-schedulable tasks using background threads.

[0050] Step S220: Execute the necessary scheduling tasks using the scheduling thread.

[0051] The background thread and the scheduling thread are distinct threads, and there can be one or more of each. Optionally, the background thread and the scheduling thread can be implemented as logical threads in software or as hardware threads; implementation as hardware threads requires corresponding hardware support. After the base station starts operating, the background thread and the scheduling thread can execute simultaneously (but the two types of threads do not necessarily start at the same time), meaning that scheduling tasks and non-scheduling tasks can be executed in parallel.

[0052] The UEs to be scheduled within each TTI are referred to as the target UEs. Mandatory scheduling tasks are those that must be performed during the scheduling phase (or within each TTI). Mandatory scheduling tasks include the task of allocating radio resources to the target UEs. Non-mandatory scheduling tasks are those that are not or not necessarily performed during the scheduling phase. Non-mandatory scheduling tasks do not include the task of allocating radio resources to the target UEs to be scheduled. Radio resources here include, but are not limited to, time-frequency resources. For example, non-mandatory scheduling tasks may include tasks such as calculating scheduling priorities for UEs and sorting UEs (the target UE is determined based on this sorting); mandatory scheduling tasks may include tasks such as allocating time-frequency resources to various physical channels of the target UEs. Further examples of non-mandatory and mandatory scheduling tasks will be provided later.

[0053] For base stations, the primary task during the scheduling phase is allocating radio resources to target UEs. Other tasks can be performed during the scheduling phase or not. In the method described above, the scheduling thread is only responsible for radio resource allocation, while a background thread handles tasks other than radio resource allocation. This reduces the computational burden on the scheduling thread, allowing it to schedule more UEs within each Time Interval (TTI) (tasks performed by the background thread do not occupy a TTI), thereby improving the overall performance of the communication system. This method is particularly suitable for millimeter-wave systems, but it can also improve scheduling efficiency in non-millimeter-wave systems.

[0054] In one implementation, the non-schedulable tasks include, but are not limited to, at least one of the following:

[0055] (1) Calculate the scheduling priority of the UE. The UE here can be all or some of the UEs accessing the base station. The scheduling priority can be a comprehensive index determined based on a variety of data. The scheduling priority can be calculated periodically or irregularly. The algorithms include RR round-robin algorithm, EPF algorithm, MAX-CI algorithm, etc. The main inputs of the algorithm are the configured QoS rules (maximum traffic, minimum traffic, packet loss, jitter, latency, user priority, etc.), the UE's spectrum efficiency, and the data status of the UE that has been scheduled.

[0056] (2) Sort the UEs according to the scheduling priority calculated in (1). The target UE can be determined based on this sorting. For example, if 4 UEs can be scheduled in each TTI according to the system performance, then the first 4 UEs in the sorted queue can be taken as the target UEs in the current TTI.

[0057] (3) Calculate ephemeris. This task is mainly for satellite communication systems. Ephemeris can be understood as a set of data describing the satellite's motion and position in orbit. The results of ephemeris calculation may affect the calculation of scheduling priorities.

[0058] (4) Calculate the bit error rate.

[0059] (5) Calculate QoS traffic shaping. QoS traffic shaping is a network management technique used to control the transmission mode of network traffic to ensure that the quality of service requirements of different types of traffic are met.

[0060] (6) Processing of user plane data at the MAC layer.

[0061] In the above implementation, a series of tasks that are not directly related to radio resource allocation can be handed over to background threads for processing, which can greatly improve the scheduling efficiency of UEs and thus support the base station to schedule more UEs within a TTI.

[0062] For uplink and downlink scheduling, the scheduling tasks can be different. Downlink scheduling refers to the base station scheduling the data sent to the UE, while uplink scheduling refers to the base station scheduling the data sent to itself by the UE.

[0063] If the base station performs downlink scheduling for the target UE, the scheduling tasks may include:

[0064] (A1) Downlink scheduling PDCCH resource allocation processing;

[0065] (A2) PDSCH resource allocation processing.

[0066] If the base station performs uplink scheduling for the target UE, the scheduling tasks must include:

[0067] (B1) Uplink scheduling PDCCH resource allocation processing;

[0068] (B2) PUSCH resource allocation processing;

[0069] (B3) PUCCH resource allocation processing;

[0070] (B4) SRS resource allocation processing;

[0071] (B5) PRACH resource allocation processing.

[0072] It should be noted that tasks A1-A2 and B1-B5 are not necessarily executed in the order listed above. Additionally, resource allocation processing for the Master Information Block (MIB) and the System Information Block (SIB) does not involve specific UEs; it belongs to the system's common resources and does not need to be repeatedly executed for different UEs, therefore it is not listed above.

[0073] The above lists the essential scheduling tasks that can be executed during downlink and uplink scheduling, respectively. It's clear that these tasks only involve radio resource allocation, thus the scheduling thread remains highly efficient in both downlink and uplink scheduling.

[0074] Within a TTI (Time Interval), a base station can perform downlink scheduling only, uplink scheduling only, or both, depending on whether there is downlink or uplink data to be transmitted. If both scheduling are performed simultaneously, the target UEs can be completely different UEs or duplicate UEs.

[0075] It should be noted that mandatory scheduling tasks can also include tasks unrelated to radio resource allocation. For example, if the TTI value is large, the number of UEs to be scheduled is small, or the task itself is very simple (scheduling time is sufficient when these conditions are met), some tasks unrelated to radio resource allocation can be designated as mandatory scheduling tasks and assigned to the scheduling thread. For instance, all UEs to be scheduled are stored sequentially in a scheduling queue (the UEs in the queue can refer to some kind of identification information that represents the UE; similar examples will not be specifically mentioned later). If four UEs need to be scheduled within the current TTI, these four UEs need to be removed from the scheduling queue before allocating radio resources to them. Although this UE removal operation does not directly involve radio resource allocation, it consumes almost no computing resources, so it can be included in the scheduling task. Which tasks are mandatory scheduling tasks and which are not can be pre-set, or certain tasks can be dynamically classified as mandatory or non-mandatory scheduling tasks based on the scheduling situation.

[0076] Based on any of the above embodiments, the scheduling task may include multiple steps, referred to as scheduling steps. For example, each task in A1-A2 and B1-B5 above can be a scheduling step. Of course, several tasks can also be merged into one scheduling step, or one task can be split into multiple scheduling steps, depending on the requirements. The purpose of scheduling is to complete all scheduling steps for each target UE within one TTI, that is, to complete the scheduling of all target UEs. Depending on the way the scheduling steps are executed, step S220 includes at least two implementation methods, which are described in detail below:

[0077] Method 1: Prioritize scheduling based on user experience (UE)

[0078] The scheduling thread executes all scheduling steps sequentially for each target UE. Here, "sequentially" can be understood as the scheduling order of the target UEs, which, as mentioned earlier, can be determined by the background thread. When a target UE has completed all scheduling steps, it indicates that the target UE has completed scheduling, and the scheduling result can serve as the basis for physical layer data transmission.

[0079] Figure 3 This illustrates the first method by which the scheduling thread schedules the UE. (See reference...) Figure 3Currently, there are four target UEs within the TTI that need to be scheduled sequentially, namely UE1 to UE4. The scheduling steps to be executed for each target UE are P1 to P3. The arrows indicate the execution order of the scheduling steps: the scheduling thread first executes scheduling steps P1 to P3 for UE1, then for UE2, then for UE3, and finally for UE4. However, it should be noted that if multi-threaded parallelism is considered, the scheduling thread may not strictly follow the order from UE1 to UE4. Furthermore, for each target UE, such as UE1, the scheduling thread may not execute scheduling steps P1 to P3 consecutively for UE1. However, overall, the execution logic of the scheduling thread still conforms to the general description of Method 1 above. The case of multi-threaded scheduling will be explained in detail later.

[0080] In Method 1, the scheduling thread prioritizes the user experience (UE) during scheduling, meaning it prioritizes scheduling individual target UEs rather than individual scheduling steps. Therefore, even if a target UE times out during scheduling, at least the target UEs that have already completed all scheduling steps before that timeout are still successfully scheduled. This implementation method helps improve the UE scheduling success rate.

[0081] For example, suppose the scheduling thread times out when scheduling UE3 (i.e., the current TTI has ended, but UE3 has not yet completed scheduling), but UE1 and UE2, which have already completed scheduling steps P1 to P3, are successfully scheduled and are not affected by the scheduling failure of UE3.

[0082] The following section will further elaborate on Method 1, specifically for cases where the scheduling thread is single-threaded and multi-threaded:

[0083] 1. The scheduling thread is single-threaded.

[0084] At this point, step S220 can be implemented as follows: using a single scheduling thread to execute all scheduling steps for each target UE in sequence; wherein, after scheduling one target UE, the next target UE is scheduled.

[0085] Reference Figure 3 In a single-threaded implementation, the scheduling thread first executes scheduling steps P1 to P3 for UE1. After execution (i.e., UE1 is scheduled), it then executes scheduling steps P1 to P3 for UE2, and so on, until UE4 is scheduled.

[0086] Since only one thread executes the task that must be scheduled, the next target UE will not be scheduled until the previous target UE has been scheduled. Therefore, even if a target UE times out during the scheduling process, other target UEs scheduled before that target UE can still be scheduled successfully. Thus, this implementation helps improve the UE scheduling success rate.

[0087] 2. The scheduling thread is multi-threaded.

[0088] When the scheduling thread is multi-threaded, step S220 can be implemented using at least the following two parallel schemes:

[0089] a. Parallel processing at the UE level

[0090] Multiple scheduling threads are used to schedule a corresponding number of target UEs in parallel. Each scheduling thread is responsible for executing all scheduling steps for a target UE. After a scheduling thread finishes scheduling a target UE, it will then select a new target UE for scheduling.

[0091] Reference Figure 3 In the multithreaded implementation 'a', assume there are two scheduling threads, Thread 1 and Thread 2 (which can schedule two target UEs in parallel). UE1 through UE4 are stored sequentially in a scheduling queue. Thread 1 retrieves UE1 from the scheduling queue for scheduling. Thread 1 will not schedule other target UEs until scheduling steps P1 through P3 of UE1 are completed. Thread 2 retrieves UE2 from the scheduling queue for scheduling. Thread 2 will not schedule other target UEs until scheduling steps P1 through P3 of UE2 are completed. Threads 1 and Thread 2 can start executing simultaneously or almost simultaneously. If Thread 1 completes scheduling UE1 first, while Thread 2 has not yet completed scheduling UE2, then Thread 1 can retrieve UE3 from the scheduling queue for scheduling, and so on.

[0092] Note that although the target UEs are not necessarily scheduled in the order of scheduling, the order in which each scheduling thread retrieves the target UEs from the scheduling queue is still in the order of scheduling. Therefore, from an overall perspective, it can be considered that the scheduling threads schedule the target UEs sequentially in the order of scheduling.

[0093] b. Parallelism with scheduling steps as the granularity

[0094] Multiple scheduling threads are used to execute a corresponding number of scheduling steps in parallel. Each scheduling thread takes a scheduling step from the task queue for execution. After a scheduling thread completes a scheduling step for a target UE, if there is at least one scheduling step that can be parallelized, the scheduling thread puts the at least one scheduling step that can be parallelized into the task queue and takes a new scheduling step from the task queue for execution. If there is no at least one scheduling step that can be parallelized, the scheduling thread directly takes a new scheduling step from the task queue for execution.

[0095] The above-mentioned parallelizable scheduling step satisfies at least one of the following two conditions:

[0096] Condition 1 (Condition 1 is considered satisfied only if conditions 1.1 through 1.3 are all met):

[0097] 1.1 These scheduling steps are the subsequent scheduling steps for the target UE;

[0098] 1.2 These scheduling steps are independent of each other;

[0099] 1.3 These scheduling steps depend only on the scheduling steps that the target UE has already completed, or do not depend on any scheduling steps of the target UE.

[0100] Condition 2 (2.1 to 2.2 must all be satisfied for condition 2 to be considered satisfied):

[0101] 2.1 These scheduling steps are the scheduling steps for a new target UE;

[0102] 2.2 These scheduling steps are independent of each other.

[0103] For example, there are 4 target UEs that need to be scheduled sequentially in the current TTI, namely UE1 to UE4, and the scheduling steps that need to be performed for each target UE are P1 to P5.

[0104] For the same target UE, the execution order of scheduling steps should be designed reasonably so that the execution of each scheduling step either does not depend on the execution result of any other scheduling step, or depends only on the execution result of the scheduling step that comes before it in the execution order. Here, the execution order can be understood as the order in which the scheduling steps begin execution, not the order in which they finish. For example, the execution of P1 does not depend on the execution result of other scheduling steps; the execution of P2 through P4 all depend on the execution result of P1, but P2 through P4 are independent of each other; the execution of P5 depends on the execution results of P2 through P4. Therefore, P1-P2-P3-P4-P5 is a reasonable execution order. Regardless of how many scheduling threads execute the scheduling steps for each target UE, this execution order is maintained in terms of timing, which can be guaranteed by the order in which the scheduling steps are added to the task queue.

[0105] For different target UEs, the scheduling steps to be executed are independent of each other. For example, UE1.P2 (scheduling step P2 for UE1, similar notation will not be explained separately in the following text) depends on UE1.P1, but UE2.P2 does not depend on UE1.P1.

[0106] Suppose there are two scheduling threads, namely thread 1 and thread 2 (which can schedule two scheduling steps in parallel), and the two scheduling threads share a task queue.

[0107] Initially, thread 1 executes UE1.P1, while thread 2 executes UE2.P1.

[0108] Assuming thread 1 has finished executing UE1.P1, but thread 2 has not yet finished executing UE2.P1, since there are still 4 scheduling steps for UE1 that have not been executed, the scheduling steps that can be parallelized are selected from the remaining scheduling steps of UE1. Furthermore, since UE1.P2 through UE1.P4 are all subsequent steps of UE1.P1, and UE1.P2 through UE1.P4 are independent of each other, and their execution depends only on the execution result of UE1.P1, thread 1 can add UE1.P2 through UE1.P4 to the task queue in sequence, and then retrieve a new scheduling step, UE1.P2, from the task queue for execution.

[0109] Assuming that thread 1 has not yet finished executing UE1.P2, while thread 2 has finished executing UE2.P1, then thread 2 can refer to the above operation of thread 1 to add UE2.P2 to UE2.P4 to the task queue in sequence, and take a new scheduling step, UE1.P3, from the task queue to execute. That is, at this time, the two scheduling steps UE1.P2 and UE1.P3, which belong to UE1, are executed in parallel by different threads.

[0110] Assuming thread 1 has finished executing UE1.P2, but thread 2 has not yet finished executing UE1.P3, and although UE1.P5 is a follow-up step to UE1.P4 which has been added to the task queue, since UE1.P3, on which UE1.P5 depends, has not finished executing, and UE1.P4 has not yet been executed, there is no scheduled step that can be put into the task queue at this time. Thread 1 directly takes a new scheduled step, namely UE1.P4, from the task queue and executes it.

[0111] Assume thread 2 executes UE1.P3 first, and thread 1 executes UE1.P4 afterward. For simplicity, we will focus on thread 1. Since there is still one scheduling step for UE1 that has not been executed, the scheduling step that can be executed in parallel is selected from the remaining scheduling steps of UE1. Furthermore, since UE1.P5 is a follow-up step to UE1.P4 that has been added to the task queue, and since UE1.P5 has only one step and there is no mutual dependency problem, and the execution of UE1.P5 only depends on the execution results of UE1.P2 to UE1.P4, thread 1 can add UE1.P5 to the task queue and take a new scheduling step from the task queue for execution.

[0112] Suppose that at some point later, thread 1 finishes executing UE1.P5, but the scheduling steps for UE2 have not yet been fully executed. Since the scheduling steps for UE1 have already been completed, the scheduling steps that can be parallelized should be selected from the scheduling steps of a new target UE, namely UE3. Furthermore, since UE3.P1 has only one step and no mutual dependencies, thread 1 can add UE3.P1 to the task queue and retrieve a new scheduling step from the task queue for execution.

[0113] The subsequent execution process is similar and will not be analyzed in detail. Optionally, after thread 1 finishes executing UE1.P4, it can also add UE1.P5 (satisfying condition 1) and UE3.P1 (satisfying condition 2) to the task queue together, which simplifies the operation.

[0114] In the example above, if we change the dependencies between scheduling steps to such that the execution of P1, P3, and P4 does not depend on the results of other scheduling steps, the execution of P2 depends on the result of P1, and the execution of P5 depends on the result of P2, and assuming the execution order remains P1-P2-P3-P4-P5, the possible execution process of the scheduling thread can be analyzed as follows:

[0115] Initially, thread 1 executes UE1.P1, while thread 2 executes UE2.P1.

[0116] Assuming thread 1 has finished executing UE1.P1, while thread 2 has not yet finished executing UE2.P1, since UE1.P2 through UE1.P4 are all subsequent steps of UE1.P1, and UE1.P2 through UE1.P4 are independent of each other, and only the execution of UE1.P2 depends on the execution result of UE1.P1, while UE1.P3 and UE1.P4 do not depend on the execution result of any scheduling step, thread 1 can add UE1.P2 through UE1.P4 to the task queue in sequence, and then take a new scheduling step, UE1.P2, from the task queue to execute.

[0117] For simplicity, we will focus on thread 1. Assume that thread 1 has finished executing UE1.P2. Since UE1.P5 is a follow-up step to UE1.P4 which has been added to the task queue, and since UE1.P5 has only one step and there is no mutual dependency problem, and the execution of UE1.P5 depends only on the execution result of UE1.P2, thread 1 can add UE1.P5 to the task queue and take a new scheduled step from the task queue for execution.

[0118] The subsequent execution process is similar and will not be analyzed in detail. Note that in the multi-threaded implementation b, although the target UEs are not necessarily scheduled in the order of scheduling, the order in which each scheduling thread retrieves the first scheduling step of the target UE from the task queue is still in the order of scheduling. Therefore, from an overall perspective, it can be considered that the scheduling threads schedule the target UEs sequentially in the order of scheduling.

[0119] Both implementations a and b described above are multi-threaded implementations prioritizing UE-level scheduling. Compared to single-threaded implementations, multi-threaded implementations offer higher scheduling efficiency and can schedule more UEs per TTI, but they also require more hardware resources. In fact, since the tasks to be performed by the scheduling thread in this application are greatly simplified, the scheduling efficiency of a single-threaded implementation is also considerable, and it also helps to reduce hardware costs.

[0120] Comparing multithreaded implementations a and b, method a is parallelism at the granularity of user experience (UE), while method b is parallelism at the granularity of scheduling steps. Method b has a smaller and more flexible granularity, but it may require a more complex parallel design because some scheduling steps may have dependencies on each other, and not every two scheduling steps can be parallelized.

[0121] It should also be noted that, for the sake of simplicity, the above description of multithreaded implementation assumes that the scheduling steps of different target UEs are independent of each other. However, in reality, this condition may not be met. For example, the same scheduling step of different target UEs may access common resources, which leads to resource mutual exclusion issues in multithreaded scenarios. This is an issue that needs to be considered when designing parallel systems, and can be resolved, for example, by using locking mechanisms.

[0122] Method 2: Scheduling based on the dimension of scheduling steps

[0123] The scheduling thread executes each scheduling step sequentially for all target UEs. "Sequentially" here can be understood as the execution order of the scheduling steps. Of course, when executing each scheduling step, it can still follow the scheduling order of the target UEs, executing the step for each target UE sequentially. When a target UE has completed all scheduling steps, it indicates that the target UE has completed scheduling, and its scheduling result can serve as the basis for physical layer data transmission.

[0124] Figure 4 This illustrates a second method for the scheduling thread to schedule the UE. (See reference...) Figure 4 Currently, there are four target UEs (UEs) within the TTI (Time to Time) that need to be scheduled sequentially, namely UE1 to UE4. The scheduling steps for each target UE are P1 to P3. The arrows indicate the execution order of the scheduling steps: the scheduling thread first executes scheduling step P1 for UE1 to UE4, then executes scheduling step P2, and finally executes scheduling step P3. However, it should be noted that if multi-threaded parallelism is considered, the scheduling thread may not strictly follow the order from P1 to P3. Furthermore, for each scheduling step, such as P1, the scheduling thread may not strictly follow the order from UE1 to UE4. However, overall, the execution logic of the scheduling thread still conforms to the general description of Method Two above.

[0125] In Method 2, the scheduling thread prioritizes scheduling steps, meaning it prioritizes completing individual scheduling steps rather than individual target UEs. Since multiple target UEs execute the same scheduling step within a short period, the cache hit rate for the base station CPU is higher, thus improving scheduling efficiency. However, it should be noted that because the scheduling thread code in this application is already very streamlined, even with the UE-centric scheduling method, the cache hit rate is not low.

[0126] Method two can also be divided into cases where the scheduling thread is single-threaded or multi-threaded; only a brief introduction is given here. (See reference...) Figure 4 In a single-threaded scenario, the scheduling thread first executes scheduling step P1 for UE1 to UE4. After all target UEs have completed P1, it then executes scheduling step P2 for UE1 to UE4, and so on, until all target UEs have completed P3. If UE2 times out while executing P2, then UE1 to UE4 will not have executed P3, meaning none of them have been successfully scheduled.

[0127] In multi-threaded scenarios, parallelism can be categorized into UE-level parallelism and scheduling step-level parallelism. UE-level parallelism means that when executing the same scheduling step, it can be performed in parallel for different target UEs. (See reference...) Figure 4Assuming there are two scheduling threads, thread 1 and thread 2, when executing P1, thread 1 can execute UE1.P1, and thread 2 can execute UE2.P1. After thread 1 finishes executing UE1.P1, if thread 2 has not yet finished executing UE2.P1, then thread 1 will continue to execute UE3.P1, and so on. Optionally, the scheduling steps can still be executed serially. For example, if P1 has not been executed for all target UEs, then P2 will not be executed.

[0128] Parallelism at the scheduling step level means that different scheduling steps can be executed in parallel. (See reference...) Figure 4 Assuming there are two scheduling threads, thread 1 and thread 2, and there is no dependency between steps P2 and P3, then while thread 1 is executing P2 for UE1 to UE4, thread 2 is allowed to execute P3 for UE1 to UE4. However, when thread 1 is executing P2, it can still execute sequentially from UE1 to UE4.

[0129] Similar to Method 1, in Method 2, compared to single-threaded implementation, multi-threaded implementation has higher scheduling efficiency and can schedule more UEs per TTI, but it also has higher hardware resource requirements.

[0130] Furthermore, based on method one, scheduling efficiency can be further improved through the following schemes:

[0131] First, the base station stores the context of each accessing UE in an array called the UE context array. This array can be created during system initialization and maintained in the base station's memory. The number of elements in the array can be a preset value, such as the maximum number of users the base station can handle (this number is unrelated to the maximum number of users the base station can schedule within a TTI). The UE context can be understood as the information and state related to the UE, including the scheduling information that the UE needs to use during scheduling.

[0132] Each UE has an array index that describes the storage location of the UE's context in the UE context array. This array index can be implemented as a pointer, an array element number, or something similar. In short, the array index itself occupies a very small amount of data.

[0133] Then, when the scheduling thread executes all scheduling steps for each target UE in sequence, it can pass the array index of the target UE only between and / or within each scheduling step, and obtain the scheduling information corresponding to the target UE from the UE context array through the array index of the target UE within the scheduling step, and schedule the target UE based on the scheduling information.

[0134] Taking a single-threaded scenario as an example, each scheduling step can be implemented as a function. Scheduling steps P1 to P3 correspond to functions F1 to F3, respectively. When scheduling UE1, the scheduling thread passes the array index of UE1 to F1 and then executes F1. If F1 contains some sub-functions, these sub-functions also pass the array index of UE1. When allocating radio resources for UE1 within F1, the context of UE1 can be obtained from the UE context array based on the array index of UE1, thereby obtaining the scheduling information of UE1. Then, radio resources can be allocated to UE1 based on this scheduling information. After F1 is executed, the scheduling thread continues to pass the array index of UE1 to F2 and then executes F2. The analysis can be referenced to the execution of F1, and will not be repeated here.

[0135] In the above implementation, all UE scheduling information is stored in the UE context array. Only the array index of the target UE is passed between and / or within scheduling steps. When necessary, the target UE's scheduling information can be retrieved from the UE context array using this array index, thus reducing the overhead of data copying during scheduling (without transmitting the UE's scheduling information itself), which helps improve scheduling efficiency and save storage resources. Furthermore, since Method 1 prioritizes scheduling by UE dimension, the array index of the target UE is sufficient to complete the scheduling, eliminating the need for more complex data structures, which also contributes to improved scheduling efficiency. In contrast, Method 2 might require maintaining a linked list of target UEs for each scheduling step; UEs completing the current scheduling step are added to the linked list for the next scheduling step.

[0136] In addition to the solutions mentioned above, there are other solutions that can improve scheduling efficiency. The combined effect of these solutions will help millimeter-wave communication systems to schedule more UEs within the TTI.

[0137] Option 1:

[0138] When the scheduling thread allocates time-frequency resources to the UE, it does so according to time-frequency resource blocks. If the time-frequency space is regarded as a plane with the number of symbols (representing time) on the horizontal axis and the number of Resource Blocks (RBs) (representing frequency) on the vertical axis, then the time-frequency resource block is a rectangular area in this plane.

[0139] One possible allocation process is as follows:

[0140] First, obtain the first resource block parameters corresponding to the resource block to be allocated. These first resource block parameters describe the location and / or size information of the resource block to be allocated in the time-frequency space. For example, the first resource block parameters may include the number of symbols, the starting symbol, the number of redundancies (RBs), and the starting redundancy (RB) of the resource block to be allocated (the latter two parameters are optional).

[0141] Then, by comparing the parameters of the first resource block with the parameters of the second resource block in the idle resource record, an initial resource block that meets the resource allocation requirements is determined from the idle resource blocks in the time-frequency space. The idle resource record includes the parameters of the second resource block corresponding to the idle resource block. These parameters describe the location and / or size information of the idle resource block in the time-frequency space. For example, the second resource block parameters may include the number of symbols, the starting symbol, the number of redundancies (RBs), and the starting RB (the latter two parameters are optional). The idle resource record can be implemented as a specific data structure, such as an array, linked list, hash table, tree, or a combination thereof. Since resource scheduling is performed on a time-frequency interval (TTI), the time-frequency space in this step can be understood as the time-frequency space within one TTI.

[0142] For example, the free resource record can be implemented as an array, where each array element corresponds to a symbol count (the last array element corresponds to the maximum symbol count within the TTI). Each array element points to a linked list (which can be empty). Each linked list node corresponds to a free resource block. The starting symbol, RB count, starting RB, and other parameters of the free resource block can be stored in the linked list node. All linked list nodes in the same linked list correspond to the same number of symbols in their free resource blocks, which is the symbol count corresponding to the position of the data element in that linked list.

[0143] When searching for the initial resource block from the free resource record, we can first find the array element whose number of symbols is the same as the number of symbols of the resource block to be allocated. Then, we can sequentially access the linked list nodes pointed to by the array element and determine whether the starting symbol, number of RBs, and starting RB of the free resource block stored in the linked list node match the starting symbol, number of RBs, and starting RB of the resource block to be allocated (matching does not necessarily mean being completely equal). If the parameters stored in a linked list node match the parameters of the resource block to be allocated, then the free resource block corresponding to that linked list node is determined as the initial resource block. Otherwise, we repeat the above process for other array elements in the array that are in order after the current array element to continue searching for the initial resource block.

[0144] Then, the resource blocks to be allocated are determined from the initial resource blocks based on the parameters of the first resource block.

[0145] Then, the second resource block parameter corresponding to the initial resource block is removed from the idle resource record.

[0146] Finally, if there are remaining time-frequency resources in the initial resource block besides the resource blocks to be allocated, the parameters of the second resource block corresponding to the remaining resource block formed by the remaining time-frequency resources are added to the idle resource record. For example, linked list nodes corresponding to the remaining resource blocks can be created, and these linked list nodes can be inserted into appropriate positions in the appropriate linked lists of the above data structure. Optionally, when determining the resource blocks to be allocated from the initial resource block, the positions of the resource blocks to be allocated can be reasonably selected. For example, (under other conditions) they can be selected according to the priority order of the number of intersection edges between the resource blocks to be allocated and the initial resource block from most to least, so that the number of remaining resource blocks is as small as possible.

[0147] In the above scheme, the remaining free resource blocks are maintained by using free resource records. The number of free resource blocks is usually not large, so the allocation of time-frequency resource blocks can be completed quickly by matching resource block parameters. Compared with some complex time-frequency resource allocation algorithms in the existing technology, its efficiency is significantly improved.

[0148] Option 2:

[0149] After determining the time-frequency resource block occupied by the PDCCH using Scheme 1, this time-frequency resource block can be further allocated to multiple UEs. However, in existing technologies, the allocation algorithm is very complex. In millimeter-wave systems, due to the small value of the Time-In-Time (TTI), the scheduling of a limited number of UEs is usually limited by equipment performance. In this special scenario, the time-frequency resource allocation method in the PDCCH can be simplified as follows:

[0150] First, n resource blocks are allocated from the time-frequency resources occupied by the PDCCH for uplink and downlink scheduling respectively. n is a positive integer and is determined by the maximum number of UEs that can be scheduled within a TTI. For example, if 4 UEs (uplink or downlink) can be scheduled within each TTI, then n can be 4. Typically, n between 2 and 4 is suitable. Furthermore, some implementations allow for different numbers of resource blocks for uplink and downlink scheduling.

[0151] The methods for uplink and downlink scheduling are similar. Taking downlink scheduling as an example, n resource blocks available for downlink scheduling are allocated to the target UE to be scheduled according to the set rules. Note that here, resource blocks can be allocated directly according to the rules, without having to start from the search starting position corresponding to each target UE and search for suitable time-frequency resource blocks for each target UE in the time-frequency resources occupied by the PDCCH using a specific algorithm, as in existing technologies. Therefore, its resource allocation efficiency is significantly improved.

[0152] The rules set here include at least the following two; choose one to implement:

[0153] The first method involves numbering the n resource blocks to obtain the resource block number i for each resource block, where i ranges from 1 to n; and allocating the resource block with resource block number i to the i-th scheduled target UE according to the scheduling order of the target UE.

[0154] The second method involves allocating n resource blocks to the target UE according to its search resource start position. The target UE's search resource start position can be determined based on its ID (e.g., C-RNTI), subframe number, and PDCCH type. The resource block where the target UE's search resource start position is located is the resource block allocated to that target UE. If the resource block where the target UE's search resource start position is located is already occupied, a resource block is selected from the remaining resource blocks and allocated to the target UE.

[0155] Figure 5 This illustration shows the functional modules that may be included in the air interface resource scheduling device 300 provided in an embodiment of this application. The air interface resource scheduling device 300 can be installed in the base station of a wireless communication system. (Refer to...) Figure 5 The air interface resource scheduling device 300 includes:

[0156] The first execution module 310 is used to execute non-schedulable tasks using a background thread, wherein the non-schedulable tasks do not include allocating radio resources for the target UE to be scheduled.

[0157] The second execution module 320 is used to execute scheduling-required tasks using a scheduling thread, the scheduling-required tasks including allocating radio resources to the target UE.

[0158] In one implementation of the air interface resource scheduling device 300, the non-mandatory scheduling tasks include at least one of the following: calculating the scheduling priority of the UE; sorting the UEs according to the scheduling priority; wherein the target UE is derived from the sorted UEs; calculating the ephemeris; calculating the bit error rate; calculating QoS traffic shaping; and processing user plane data at the MAC layer.

[0159] In one implementation of the air interface resource scheduling device 300, if the target UE performs downlink scheduling, the scheduling tasks include: downlink scheduling PDCCH resource allocation processing and PDSCH resource allocation processing; if the target UE performs uplink scheduling, the scheduling tasks include: uplink scheduling PDCCH resource allocation processing, PUSCH resource allocation processing, PUCCH resource allocation processing, SRS resource allocation processing, and PRACH resource allocation processing.

[0160] In one implementation of the air interface resource scheduling device 300, the scheduling task includes multiple scheduling steps. The second execution module 320 executes the scheduling task using a scheduling thread, including: using the scheduling thread to execute all scheduling steps for each target UE in sequence; wherein, the completion of all scheduling steps for a target UE indicates that the target UE has completed scheduling.

[0161] In one implementation of the air interface resource scheduling device 300, the scheduling thread is a single thread, and the second execution module 320 uses the scheduling thread to execute all scheduling steps for each target UE in sequence, including: using a single scheduling thread to execute all scheduling steps for each target UE in sequence, and after scheduling one target UE, starting to schedule the next target UE.

[0162] In one implementation of the air interface resource scheduling device 300, the scheduling thread is a plurality of threads, and the second execution module 320 uses the scheduling thread to execute all scheduling steps for each target UE in sequence, including: using multiple scheduling threads to schedule a corresponding number of target UEs in parallel; wherein, each scheduling thread is responsible for executing all scheduling steps for one target UE, and after a scheduling thread has finished scheduling one target UE, the scheduling thread will take a new target UE for scheduling.

[0163] In one implementation of the air interface resource scheduling device 300, the scheduling thread comprises multiple threads. The second execution module 320 utilizes the scheduling threads to sequentially execute all scheduling steps for each target UE, including: utilizing multiple scheduling threads to execute a corresponding number of scheduling steps in parallel; wherein each scheduling thread retrieves scheduling steps from a task queue for execution. After a scheduling thread completes one scheduling step for a target UE, if there are at least one scheduling step that can be parallelized, the scheduling thread places the at least one scheduling step that can be parallelized into the task queue and retrieves a new scheduling step from the task queue for execution; if there are no at least one scheduling step that can be parallelized, the scheduling thread directly retrieves a new scheduling step from the task queue for execution; the at least one scheduling step that can be parallelized satisfies the following conditions: it is a subsequent scheduling step for the target UE, and there is no dependency between them; it depends only on the scheduling steps that the target UE has already executed or does not depend on any scheduling steps of the target UE; and / or, it is a scheduling step for a new target UE, and there is no dependency between them.

[0164] In one implementation of the air interface resource scheduling device 300, the device further includes: an information storage module, used to store the context of each UE in a UE context array, wherein the UE context includes scheduling information that the UE needs to use during scheduling; when the scheduling thread executes the multiple scheduling steps for the target UE, it only passes the array index of the target UE between and / or within each scheduling step, and within the scheduling step, it obtains the scheduling information corresponding to the target UE from the UE context array through the array index of the target UE, and schedules the target UE based on the scheduling information.

[0165] In one implementation of the air interface resource scheduling device 300, the scheduling task includes multiple scheduling steps. The second execution module 320 executes the scheduling task using a scheduling thread, including: using the scheduling thread to execute each scheduling step sequentially for all target UEs.

[0166] The air interface resource scheduling device 300 provided in this application embodiment can be used to execute the air interface resource scheduling method provided in this application embodiment. Its implementation principle and the resulting technical effects have been described in the foregoing method embodiments. For the sake of brevity, any part not mentioned in the device embodiment can be referred to the corresponding content in any of the foregoing method embodiments.

[0167] Figure 6 The diagram illustrates a possible structure of the base station 400 provided in an embodiment of this application. (Refer to...) Figure 6 The base station 400 includes a processor 410, a memory 420, a signal transceiver 430, and a bus 440. The processor 410, the memory 420, and the signal transceiver are interconnected and communicate with each other through the bus 440 and / or other forms of connection mechanisms (not shown).

[0168] The processor 410 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor 410 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a special-purpose processor, including a Graphics Processing Unit (GPU), a Neural-network Processing Unit (NPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors 410, some can be general-purpose processors and others can be special-purpose processors.

[0169] The memory 420 includes one or more (only one is shown in the figure), which may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0170] Processor 410 and other possible components can access memory 420, read and / or write data therein. In particular, memory 420 can store one or more computer program instructions, which processor 410 can read and execute to implement the air interface resource scheduling method provided in the embodiments of this application.

[0171] The transceiver 430 includes one or more (only one is shown in the figure) that can be used to transmit or receive electrical signals to enable direct or indirect communication with other devices. The transceiver 430 can be a wired and / or wireless communication module. For example, a wireless communication module can be used to communicate with the UE, and a wired communication module can be used to communicate with core network equipment.

[0172] Understandable. Figure 6 The structure shown is for illustrative purposes only; the base station 400 may also include more than [other components]. Figure 6 The more or fewer components shown, or having the same Figure 6 Different configurations are shown. For example, base station 400 may also include components such as antennas and brackets. Furthermore, Figure 6 The components shown can be implemented using hardware, software, or a combination thereof.

[0173] Base station 400 can be deployed in wireless communication systems, such as 5G and 4G systems. In addition, base station 400 can be a ground station or a satellite station.

[0174] This application also provides a computer-readable storage medium storing computer program instructions. These computer program instructions are read and executed by a processor to perform the air interface resource scheduling method provided in this application. For example, the computer-readable storage medium can be implemented as follows: Figure 6 The memory 420, optical disc, USB flash drive, etc. in the base station 400.

[0175] This application also provides a computer program product, which includes computer program instructions. These computer program instructions are read and executed by a processor to perform the air interface resource scheduling method provided in this application. For example, these computer program instructions can be stored in... Figure 6 The memory 420 in the base station 400 may be stored inside a USB flash drive, a portable hard drive, or burned onto a CD, etc.

[0176] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An air interface resource scheduling method, characterized in that, include: Utilize a background thread to perform non-schedulable tasks, which do not include allocating radio resources for the target UE to be scheduled. as well as, The scheduling thread is used to execute scheduling-required tasks, which include allocating radio resources to the target UE. The scheduled task includes multiple scheduling steps, and the execution of the scheduled task using a scheduling thread includes: The scheduling thread executes all scheduling steps for each target UE sequentially; the completion of all scheduling steps for a target UE indicates that the target UE has completed scheduling.

2. The air interface resource scheduling method according to claim 1, characterized in that, The non-schedulable mandatory tasks include at least one of the following: Calculate the scheduling priority of the UE; The UEs are sorted according to the scheduling priority; wherein, the target UE is derived from the sorted UEs; Calculate ephemeris; Calculate the bit error rate; Calculate QoS traffic shaping; User plane data processing at the MAC layer.

3. The air interface resource scheduling method according to claim 1, characterized in that, If the target UE performs downlink scheduling, the scheduling tasks must include: downlink scheduling PDCCH resource allocation processing and PDSCH resource allocation processing; If the target UE performs uplink scheduling, the scheduling tasks must include: uplink scheduling PDCCH resource allocation processing, PUSCH resource allocation processing, PUCCH resource allocation processing, SRS resource allocation processing, and PRACH resource allocation processing.

4. The air interface resource scheduling method according to claim 1, characterized in that, The scheduling thread is a single thread, and the scheduling thread is used to execute all scheduling steps for each target UE in sequence, including: A single scheduling thread is used to execute all scheduling steps for each target UE in sequence. After scheduling one target UE, the scheduling of the next target UE begins.

5. The air interface resource scheduling method according to claim 1, characterized in that, The scheduling thread comprises multiple threads, and the scheduling steps are executed sequentially for each target UE using these threads, including: Multiple scheduling threads are used to schedule a corresponding number of target UEs in parallel. Each scheduling thread is responsible for executing all scheduling steps for a target UE. After a scheduling thread finishes scheduling a target UE, it will then select a new target UE for scheduling.

6. The air interface resource scheduling method according to claim 1, characterized in that, The scheduling thread comprises multiple threads, and the scheduling steps are executed sequentially for each target UE using these threads, including: Multiple scheduling threads are used to execute a corresponding number of scheduling steps in parallel. Each scheduling thread retrieves a scheduling step from a task queue for execution. After a scheduling thread completes one scheduling step for a target UE, if at least one parallelizable scheduling step exists, the scheduling thread adds the at least one parallelizable scheduling step to the task queue and retrieves a new scheduling step from the task queue for execution. If no parallelizable scheduling step exists, the scheduling thread directly retrieves a new scheduling step from the task queue for execution. The at least one parallelizable scheduling step satisfies the following conditions: These are subsequent scheduling steps for the target UE, and there are no dependencies between them. Each step depends only on the completed scheduling steps of the target UE or does not depend on any scheduling steps of the target UE; and / or, This is a scheduling step for a new target UE, and there are no dependencies between them.

7. The air interface resource scheduling method according to claim 1, characterized in that, The method further includes: The context of each UE is stored in a UE context array, and the UE context includes the scheduling information that the UE needs to use during scheduling; When the scheduling thread executes the multiple scheduling steps for the target UE, it only passes the array index of the target UE between and / or within each scheduling step, and within the scheduling step, it obtains the scheduling information corresponding to the target UE from the UE context array through the array index of the target UE, and schedules the target UE based on the scheduling information.

8. An air interface resource scheduling device, characterized in that, include: The first execution module is used to execute non-schedulable tasks using a background thread, wherein the non-schedulable tasks do not include allocating radio resources to the target UE to be scheduled. The second execution module is used to execute scheduling-required tasks using a scheduling thread, the scheduling-required tasks including allocating radio resources to the target UE; The scheduling task includes multiple scheduling steps. The second execution module uses a scheduling thread to execute the scheduling task, including: using the scheduling thread to execute all scheduling steps for each target UE in sequence; wherein, the completion of all scheduling steps for a target UE indicates that the target UE has completed scheduling.

9. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-7.

11. A base station, characterized in that, include: The system includes a memory, a processor, a transceiver, and a bus, wherein the memory stores computer program instructions that are read and executed by the processor to perform the method of any one of claims 1-7.

Citation Information

Patent Citations

  • Task processing method and device, electronic equipment and medium

    CN116069485A