CN107689929B

CN107689929B - Scheduling method for evolution towards 5G low delay

Info

Publication number: CN107689929B
Application number: CN201610630337.XA
Authority: CN
Inventors: 董敏; 安思麒
Original assignee: Potevio Information Technology Co Ltd
Current assignee: Potevio Information Technology Co Ltd
Priority date: 2016-08-03
Filing date: 2016-08-03
Publication date: 2020-10-09
Anticipated expiration: 2036-08-03
Also published as: CN107689929A

Abstract

The invention provides a scheduling method for evolution towards 5G low delay, which comprises the following steps: receiving newly transmitted data at a current subframe, generating a pre-scheduling user queue, and synchronously receiving retransmission service and/or emergency service data; adjusting pre-scheduling users in the scheduling queue, and inserting emergency service users and retransmission service users into the pre-scheduling user queue; multiplexing and packaging the sending user, and sending the multiplexing and packaging to a baseband; and returning the user queue of the unsuccessfully transmitted retransmission failure user/new data, wherein the user of unsuccessfully transmitted emergency service generates a preemption queue return. The scheduling method can process retransmission and newly transmitted services in parallel, greatly reduces the processing time of an MAC layer, enables the system to smoothly evolve towards low delay, and better meets the requirement of the future 5G low delay.

Description

Scheduling method for evolution towards 5G low delay

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a scheduling method for evolving towards 5G low latency.

Background

The third generation partnership project Long Term Evolution (LTE) system and the enhanced LTE-advanced thereof can work based on two systems, one is a frequency division duplex system, downlink transmission and uplink transmission are carried on paired frequency spectrums, and the two systems are subjected to frequency division duplex to avoid mutual frequency band interference; the other is a time division duplex system, downlink transmission and uplink transmission are carried at the same frequency point, and the downlink transmission and the uplink transmission have the same frequency and time division duplex, so that mutual time slot interference is avoided.

With the abundance of service types, some services sensitive to delay, called low-delay services, appear at present, and the end-to-end delay is required to reach millisecond level. In the existing LTE system, after a current subframe is scheduled, a round-trip delay is minimum to 8 milliseconds, and if data needs to be retransmitted, the data needs to wait for 8 milliseconds, which is relatively long in waiting time.

In the current wireless communication system, PDCP data needs to be sent to a physical layer after being combed by protocol layers below the PDCP layer, that is, an MAC layer and an RLC layer, and is sent out through the physical layer.

And the main flow process of the scheduling of the MAC layer is serial, the bottom layer data is received firstly, the retransmission user fed back as NACK is processed preferentially according to the bottom layer feedback result (ACK or NACK) during scheduling, and then the user to be sent with new data is processed. That is, the MAC layer of the corresponding subframe can be processed only after receiving the feedback result of the baseband, and the retransmission data and the newly transmitted data are independently transmitted, and this serial processing mode limits the processing time of the MAC layer, so that a bottleneck occurs when the system evolves toward low latency.

Disclosure of Invention

The present invention provides a scheduling method evolving towards 5G low latency that overcomes or at least partially solves the above mentioned problems.

According to an aspect of the present invention, there is provided a scheduling method for low latency evolution to 5G, including:

step 1, receiving newly transmitted data at a current subframe, generating a pre-scheduling user queue, and synchronously receiving retransmission service and/or emergency service data;

step 2, adjusting the pre-scheduling users in the scheduling queue, and inserting the emergency service users and the retransmission service users into the pre-scheduling user queue;

step 3, multiplexing and packaging the sending user, and sending the multiplexing and packaging to a baseband for processing according to the appointed user number;

and 4, returning the user queue of the unsuccessfully transmitted retransmission failure user/new data, wherein the user unsuccessfully transmitted emergency service generates a preemption queue return.

Wherein the step 2 further comprises:

based on the queue length and the number of users required by the baseband, the users corresponding to newly transmitted data in the pre-scheduling queue are replaced by the emergency service users and the retransmission service users.

Wherein the step 4 further comprises:

returning the user queue of which the retransmission fails and the new data is unsuccessfully sent to the pre-scheduling module for rearrangement; and the user who does not successfully send the emergency service generates a preemption queue, and continues to take the preemption flow in the next real-time processing subframe to preferentially send the emergency service.

Wherein, step 4 further comprises:

the baseband correctly receives the multiplexing packet data, matches the multiplexing packet data with the information stored in the Hp process, demultiplexes the data, and sends the data to a high layer; or

The baseband incorrectly receives the multiplexing package data or is not matched with the information stored in the Hp process, determines that the transmission times do not reach the maximum transmission times configured for the user, generates a retransmission queue and initiates retransmission processing; or

The excess number of users is returned to their respective queues by the MAC itself.

Wherein, step 2 further comprises:

step 21, receiving a pre-scheduling queue result of a corresponding subframe;

step 22, determining that a retransmission queue or a preemption queue is not empty, or determining that a burst emergency service exists;

and step 23, adding retransmission into the retransmission failure user queue, preferentially sending the emergency service, and placing the unsuccessfully sent emergency service into the preemption user queue.

Wherein step 22 further comprises:

if the current sub-frame pre-scheduling queue has the to-be-transmitted users with the same id, replacing the user and writing the originally pre-transmitted user into a new data unsent queue;

and if the current sub-frame pre-scheduling queue does not have the users to be transmitted with the same id, determining that idle resources exist and the number of the users in the pre-scheduling queue does not exceed the maximum number of users supported by TTI, allocating resources for the users, and adding the users into a sending queue.

Wherein step 22 further comprises:

if a retransmission user queue exists and users with the same id to be transmitted exist in the current sub-frame pre-scheduling queue, putting the retransmission users into a sending queue, putting the users to be transmitted in the original pre-scheduling queue into a new data non-sending queue, and firstly making the retransmission users;

an uplink preemptive user queue exists, users to be transmitted with the same id exist in a current subframe pre-scheduling queue, the preemptive users are placed in a transmission queue, the users to be transmitted in the original pre-scheduling queue are placed in a new data non-transmission queue, the preemptive users are firstly made, but the priority is lower than that of a retransmission user;

if there is an emergency service user and there is a user waiting for transmission with the same id in the current sub-frame pre-scheduling queue, the emergency service user is put into the transmission queue, the user waiting for transmission in the original pre-scheduling queue is put into the new data non-transmission queue, and the emergency service user is firstly made.

And replacing other users with the same CCE position in the pre-scheduling queue by the user in the preemption queue, putting the replaced user into a new data unsent queue, and preferentially sending the user in the preemption queue.

If the retransmission user can not be processed, the retransmission user is put into a retransmission failure user queue, the subframe number of the retransmission frame is recorded and returned to the pre-scheduling module, and then the pre-scheduling module initiates the self-adaptive retransmission.

If the emergency service is not successfully sent, the emergency service is put into a queue of preempting users, and the users in the queue preempt other resources meeting the conditions in the subsequent processing sub-frames;

and for users with short SR periods, preempting part or all of new data resources of other users in the pre-scheduling queue, and putting the replaced users into a new data unsent queue.

The scheduling method can process retransmission and newly transmitted services in parallel, greatly reduces the processing time of an MAC layer, enables the system to smoothly evolve towards low delay, and better meets the requirement of the future 5G low delay.

The invention processes the scheduled new transmission and retransmission services in parallel, separates the user priority ordering function occupying most of the processing capacity of the MAC from the real-time processing flow, and greatly shortens the processing time of the MAC.

The method eliminates the time sequence restriction between the baseband processing and the protocol processing, only the processing of the HARQ retransmission user with strong real-time relation with the air interface is limited by the feedback time point of the baseband, the MAC module can be more flexibly deployed, a foundation is provided for the subsequent realization of an optimized resource allocation method, and the product can smoothly evolve towards the short TTI subframe.

The method of the invention can meet the QoS requirements of different types of services, open up a real-time channel for the emergent emergency service, better realize the global utilization of resources, greatly reduce the link overhead of the emergency service with high time delay requirement, and better meet the requirement of the future 5G low time delay service.

Drawings

Fig. 1 is a flowchart of a scheduling method for evolution to 5G low latency according to an embodiment of the present invention;

fig. 2 is a flowchart of a baseband uplink reception process according to an embodiment of the present invention;

FIG. 3 is a flowchart of a process for adjusting a pre-scheduled queue according to an embodiment of the present invention.

Detailed Description

The following detailed description of embodiments of the present invention is provided in connection with the accompanying drawings and examples. The following examples are intended to illustrate the invention but are not intended to limit the scope of the invention.

In general, the method and the device eliminate the time sequence restriction relationship between the baseband processing and the protocol processing as much as possible, only the design idea of the HARQ retransmission function with the strong real-time relationship with the air interface is reserved in the real-time part, the newly transmitted service and the retransmission service are processed separately and in parallel, and the processing time of an MAC layer is reduced. Aiming at the future 5G service with low time delay requirement, an emergency service channel is opened in the real-time processing task, and the preemption processing flow of preferentially sending the emergency service by preempting the resource of the low-priority user is provided.

Specifically, fig. 1 shows a flowchart of a scheduling method capable of evolving to 5G low latency according to an embodiment of the present application, and as shown in fig. 1, the method includes the following steps.

S1, the real-time process begins;

s3, performing pre-scheduling processing, receiving the current sub-frame needing to be newly transmitted, and generating a pre-scheduling user queue;

s2, simultaneously, performing baseband uplink receiving processing, including receiving PUSCH and PUCCH channels, and generating a retransmission user queue;

s4, at the same time, receiving whether an emergency service user arrives at the high level, and acquiring a low-delay warning service;

s5, adjusting the pre-dispatching users in the dispatching queue which has finished sending preparation, inserting the emergency service users and the retransmission service users into the pre-dispatching user queue, and possibly replacing the users corresponding to the newly transmitted data in the pre-dispatching queue;

s6, multiplexing and packaging the users which need to be sent finally, and sending the control channel and the data channel which are generated finally to the baseband;

s7, returning the user queue of the unsuccessfully transmitted retransmission failure user/new data to the pre-scheduling module for rearrangement; and the user who does not successfully send the emergency service generates a preemption queue, and continues to take the preemption flow in the next real-time processing subframe to preferentially send the emergency service.

S8, the flow ends.

After receiving the information of the control channel and the data channel, the baseband performs a receiving process, where uplink and downlink scheduling of the baseband are basically the same, and fig. 2 shows a flowchart of the baseband uplink receiving process according to the embodiment of the present application, and as shown in fig. 2, specific operation steps are as follows.

S1, start;

s2, reaching the time point of receiving the uplink data;

s3, whether the user data is correctly received and matched with the information stored in the Hp process, if yes, executing step S4, otherwise executing step S6;

s4, demultiplexing the data and sending to the high layer;

s5, releasing the corresponding resources and processes, and directly turning to the step S8;

s6, accumulating the transmission times in the process, and judging whether the transmission times reaches the maximum transmission times configured for the user, if so, executing the step S5, otherwise, executing the step S7;

s7, generating a retransmission queue, and initiating retransmission processing (if retransmission fails, adding a user into the retransmission failure queue);

s8, judging whether all users finish the processing, if yes, executing the step S9, otherwise returning to the step S3;

and S9, ending.

After entering the pre-scheduled user queue, the newly transmitted data, the retransmitted data and the emergency service data need to be correspondingly adjusted, so that the transmission is more efficient. Fig. 3 is a flowchart illustrating a process of adjusting a pre-scheduling queue according to an embodiment of the present application, and specific operation steps are as follows, as shown in fig. 3.

S1, starting processing;

s2, receiving a pre-scheduling queue result of a corresponding subframe;

s3, determining whether the retransmission queue or the preemption queue is not empty;

s4, determining that there is a burst emergency service;

s5, judging whether the same user exists in the pre-dispatching queue, if so, turning to S6, and if not, turning to S7;

s6, replacing the user with the same id to-be-transmitted user in the current sub-frame pre-scheduling queue, writing the user which is originally pre-transmitted into a new data non-transmission queue (if the user is an SR user, the original user is not preempted), and turning to S10;

s7, if there is no waiting user with the same id in the prescheduling queue of the current sub-frame, judging whether there is free resource and the number of prescheduling queue users does not exceed the maximum number of users supported by TTI; if so, go to S8, if not to S9;

s8, allocating resources for the user, adding the user into a sending queue, and turning to S10;

s9, retransmitting and adding into the retransmission failure user queue, wherein the emergency service is sent preferentially, and the emergency service which is not sent successfully is put into the preemption user queue;

s10, when the user processing in the sub-frame pre-scheduling queue/preemption queue is finished or the PDCCH and PDSCH resources are exhausted, turning to S11;

s11, the flow ends.

In step S3, if there is a retransmission user that needs to be processed and there is a user to be transmitted with the same id in the current sub-frame pre-scheduling queue, the user to be transmitted is placed in the new data unsent queue and the retransmission user is made first;

further, if the retransmission user can not be processed, the retransmission user is put into a retransmission failure user queue, the subframe number of the retransmission frame is recorded and returned to the pre-scheduling module, and then the pre-scheduling module initiates the self-adaptive retransmission.

In step S3, the uplink preemption user queue is processed (if there are users with the same id in the pre-scheduling queue, then processing is the same as a in the first step), the user in the preemption queue can replace other users with the same CCE position in the pre-scheduling queue, the replaced user is placed in the new data unsent queue, and the user in the preemption queue is preferentially sent (note that the transmission of MSG3, TTIbundling user, retransmission user, SPS service user cannot be preempted).

In step S4, if an emergency service arrives (if there are users with the same id in the pre-scheduling queue, process a in the same first step), and the number of pre-scheduling queue users reaches the maximum number of scheduling users supported by TTI, place the user with the same CCE position in the sub-frame pre-scheduling queue into a new data unsent queue, and preferentially send the emergency service (note that transmission of MSG3, TTIbundling user, retransmission user, SPS service user cannot be preempted).

In step S9, if the emergency service is not successfully sent, the emergency service is placed in a queue for preempting users, and the users in the queue can preempt the resources of other users meeting the conditions in the subsequent processing subframes; in step S9, a user with an SR period of 10ms, that is, a user with a short SR period, may move through a preemption process (which is equivalent to processing of emergency services, and preemption priority is lower than formal emergency services), preempt part or all of new data resources of other users in the pre-scheduling queue, and place a replaced user in a new data unsent queue; and if the SR queue fails to be allocated, putting the SR users into the preemptive user queue.

Finally, the method of the present application is only a preferred embodiment and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A scheduling method for evolution to 5G low latency, comprising:

step 4, the retransmission failure user/new data unsuccessfully sent user queue is returned, and the user unsuccessfully sent emergency service generates a preemption queue return;

wherein, step 2 further comprises:

step 21, receiving a pre-scheduling queue result of a corresponding subframe;

step 23, adding retransmission into a retransmission failure user queue, wherein the emergency service is sent preferentially, and the emergency service which is not sent successfully is put into a preemption user queue;

wherein step 22 further comprises:

if the current sub-frame pre-scheduling queue does not have the users to be transmitted with the same id, determining that idle resources exist and the number of the users in the pre-scheduling queue does not exceed the maximum number of users supported by TTI, allocating resources for the users, and adding the users into a sending queue;

wherein step 22 further comprises:

2. The method of claim 1, wherein the step 2 further comprises:

3. The method of claim 1, wherein the step 4 further comprises:

4. The method of claim 1, wherein step 4 further comprises:

5. The method according to claim 1, wherein the user in the preemption queue replaces other users with the same CCE position in the pre-scheduling queue, the replaced user is put into a new data unsent queue, and the user in the preemption queue is preferentially sent.

6. The method according to claim 1, wherein if the retransmission user cannot be processed, the retransmission user is put into the retransmission failure user queue, and the subframe number of the retransmission frame is recorded and returned to the pre-scheduling module, and then the pre-scheduling module initiates the adaptive retransmission.

7. The method of claim 1, wherein if the emergency service is not successfully transmitted, the emergency service is placed in a queue for preempting users, and the users in the queue preempt the resources of other users meeting the conditions in the subsequent processing sub-frames;