CN116419410B - 一种调度请求周期自适应调整方法 - Google Patents

Abstract

本申请提供了一种调度请求周期自适应调整方法，包括：基站对小区收到的调度请求信息按照统计判决周期P进行统计；基站对小区在线用户数进行统计；基站根据小区调度请求信息和在线用户数的统计信息，判决调度请求周期的调整策略；基站根据调度请求周期的调整策略，执行调度请求周期调整动作。本申请通过基站收到的SR信息和在线用户数对调度请求周期进行自适应调整，使得基站在各种应用场景和忙闲时都能兼顾上行数传时延和空口上行信道资源开销，减少了网络轻载下的上行数传时延，降低了网络重载下SR‑MAX掉话率。

Description

一种调度请求周期自适应调整方法

技术领域

本发明涉及无线通信技术，尤其涉及一种调度请求周期自适应调整方法。

背景技术

5G NR PUCCH信道上传递的UCI(Uplink Control Information,UCI)的负荷包含包括三类信息，分别是调度请求(Scheduling Request,SR)、HARQ-ACK和信道状态信息(Channel State Information,CSI)。调度请求用于向基站gNB请求上行资源以便进行PUSCH的传输，通过用户终端UE的主动申请，能够避免gNB的无效上行数据调度和上行空口资源浪费。

调度请求发送的时机与使用的PUCCH资源只能通过RRC层信令静态配置，由IEScheduling-RequestResourceConfig通知给UE。调度请求周期PERIODICITY(以时隙或符号为单位)和时隙偏移OFFSET由高层参数Periodicity And Offset配置。调度请求周期配置越小，上行数传时延越小，但会占用更多的空口上行信道资源；调度请求周期配置越大，占用空口上行信道资源减少，可容纳更多的UE发调度请求，但上行数传时延会增加。

5G NR定义eMBB、URRLC、mMTC多场景应用，不同场景无线网络中小区用户数负载差异比较大，同一个基站也存在早晚高峰期用户数潮汐现象，所以网络侧很难采用一个统一的调度请求周期配置值同时满足不同场景和不同时段的基站上行数传需求。

发明内容

本发明的目的在于提供一种调度请求周期自适应调整方法，通过对5GNR基站(gNB)小区收到的调度请求信息进行统计，结合用户数，自适应调整调度请求周期配置值，使得基站在各种应用场景和忙闲时兼顾上行数传时延和空口上行信道资源开销，减少网络轻载下的上行数传时延和降低重载下调度请求-MAX掉话率。

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

根据本发明的一方面，提供了一种调度请求周期自适应调整方法，包括：

基站对小区收到的调度请求信息按照统计判决周期P进行统计；

基站对小区在线用户数进行统计；

基站根据小区调度请求信息和在线用户数的统计信息，判决调度请求周期的调整策略；

基站根据调度请求周期的调整策略，执行调度请求周期调整动作。

在一实施例中，所述统计判决周期P的管理粒度为时隙、子帧或帧的整数倍，所述统计判决周期P为预配置或开放给客户界面配置修改。

在一实施例中，所述基站对小区收到的调度请求信息按照统计判决周期P进行统计，具体为：基站分别针对小区收到的调度请求次数、调度请求超过协议配置最大传输次数一半的次数以及调度请求超过协议配置最大传输次数的次数，按照统计判决周期P进行统计。

在一实施例中，所述在线用户数包括RRC连接用户数和激活用户数。

在一实施例中，所述调度请求周期的调整策略包括缩短、拉长或保持调度请求周期。

在一实施例中，每次缩短或拉长调度请求周期只调整1个等级。

在一实施例中，所述基站根据小区调度请求信息和在线用户数的统计信息，判决调度请求周期的调整策略，包括：当调度请求超过协议配置最大传输次数一半的比例高于第一阈值门限时，拉长调度请求周期；当调度请求超过协议配置最大传输次数一半的比例低于第二阈值门限时，缩短调度请求周期。

在一实施例中，所述基站根据小区调度请求信息和在线用户数的统计信息，判决调度请求周期的调整策略，包括：当调度请求超过协议配置最大传输次数的比例超过第三阈值门限，且RRC连接用户数和激活用户数同时超过第四阈值门限时，将SR周期直接调整到协议配置最大值。

在一实施例中，所述执行调度请求周期调整动作仅针对新接入用户生效。

在一实施例中，所述执行调度请求周期调整动作针对所有用户，执行调度请求周期调整动作时，按周期对在线用户的调度请求周期进行重配，每个周期内最大重配用户数不超过最大重配门限。

本发明实施例的有益效果是：通过基站收到的SR信息和在线用户数对调度请求周期进行自适应调整，使得基站在各种应用场景和忙闲时都能兼顾上行数传时延和空口上行信道资源开销，减少了网络轻载下的上行数传时延，降低了网络重载下SR-MAX掉话率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1是5G NR空口上行SR调度流程图；

图2是5G NR空口SR-MAX掉话示意图；

图3是本申请实施例提供的SR周期调整流程图；

图4是本申请实施例提供的SR周期自适应调整判决流程；

图5是本申请实施例提供的在线用户重配流程。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

为了更好地理解本申请实施例所提供方法的技术背景原理，先针对5GNR空口上行SR调度流程进行说明。图1是5G NR空口上行SR调度流程，如图1所示，包括以下步骤：

101，UE(用户终端)随机接入。

102，gNB(基站)将SR周期资源和参数配置通过RRC_RECONFIG消息发送给UE，包括SR周期PERIODICITY(以时隙或符号为单位)和时隙偏移OFFSET，以及sr-TransMax(协议配置最大传输次数)。

103，UE判断是否有上行数据要发送给网络。

104，如果有上行数据需要发送给网络，UE判断SR周期是否到了，如果没到继续等待。

105，如果SR周期到了，通过PUCCH信道发送SR给gNB。

106，同时UE维护SR_COUNTER计数器加1。

107，gNB收到UE发送的SR时，进行上行调度给UE分配PUSCH资源，并通过PDCCH信道DCI 0_1将调度UL Grant发送给UE。

108，UE收到PDCCH DCI 0_1时，将UE维护的SR_COUNTER计数器清零。

109，UE同时根据收到DCI 0_1携带的UL Grant信息，通过PUSCH信道发送上行数据。

步骤107中，如果网络重载多用户，该UE可能不能及时得到网络侧上行调度，即UE没有收到UL Grant，就会转到104判断下一个SR周期到了并已达到sr-ProhibitTimer时间间隔，则进行105重新发送SR，同时106SR_COUNTER计数器加1。

如果SR_COUNTER>＝SR-TransMax，UE仍然没有收到UL Grant(得到网络侧调度)，则通知RRC释放所有服务小区的信道资源，并在主小区触发101PRACH随机接入，该流程即SR-MAX掉话。以sr-TransMax配置为8为例，5G NR空口SR-MAX掉话示意图见图2。

在上述背景技术基础上，本申请实施例提供了一种调度请求周期自适应调整方法，包括：

A、基站对小区收到的调度请求信息按照统计判决周期P进行统计；

B、基站对小区在线用户数进行统计；对在线用户数的统计维护是持续、实时的，如用户接入时加1，用户释放时减1。SR周期调整判决处理时，看当前最新的用户数即可。

C、基站根据小区调度请求信息和在线用户数的统计信息，判决调度请求周期的调整策略；

D、基站根据调度请求周期的调整策略，执行调度请求周期调整动作。

改进后的SR调度流程如图3所示。相较于图1 5G NR空口上行SR调度流程，调度流程中主要增加了302用户数统计、308/313网络侧SR_COUNTER计数器维护、309SR信息统计、310SR周期判决以及311SR周期自适应调整判决步骤。

其中：

302，基站针对小区RRC连接用户数、数据用户数均进行维护统计。

308，网络侧收到UE发送的SR时，网络侧维护的SR_COUNTER计数器加1。

309，基站分别针对小区收到的SR次数SR_Receive_Counter，SR_COUNTER>＝sr-TransMax/2的次数,以及

SR_COUNTER>＝sr-TransMax的次数进行统计，每次收到SR均进行统计，并计算出SR_COUNTER达到sr-TransMax一半在小区收到的SR次数SR_Receive_Counter中所占的比例Ratio_SrMaxHalf，以及SR_COUNTER达到sr-TransMax在小区收到的SR次数SR_Receive_Counter中所占的比例Ratio_SrMax。

Ratio_SrMaxHalf＝(SR_COUNTER>＝sr-TransMax/2)/SR_Receive_Counter；

Ratio_SrMax＝(SR_COUNTER>＝sr-TransMax)/SR_Receive_Counter。

根据基站系统网络设计经验，SR_COUNTER达到sr-TransMax一半时，需要考虑提高SR调度请求调度优先级，降低SR-MAX掉话风险。考虑本SR周期自适应调整方法和SR调度优先级调整方法配合，所以本方法统计SR_COUNTER达到sr-TransMax一半的比例。

310，判断SR统计判决周期是否到了，如果周期结束则进行311SR周期自适应调整判决；否则继续等待判决周期结束，跳到312执行步骤。

311，SR周期调整分为三种策略，分别是SR周期缩短/拉长/保持，具体判决流程见图4及方法示例四。

313，网络侧调度发送UL Grant后，即将网络侧维护的SR_COUNTER计数器清零。

为了避免SR周期调整乒乓波动，可设计高低迟滞门限用于保持状态，即当调度请求超过协议配置最大传输次数一半的比例高于第一阈值门限时，拉长调度请求周期；当调度请求超过协议配置最大传输次数一半的比例低于第二阈值门限时，缩短调度请求周期，从而使得调度请求超过协议配置最大传输次数一半的比例保持在第一阈值门限与第二阈值门限之间。

进一步地，每次缩短或拉长调度请求周期只调整1个等级，使SR周期逐渐向当前网络合理值自适应调整收敛。

以FR1 SCS＝30kHz协议定义为例：

SR可配置周期包括：1sl,2sl,4sl,8sl,10sl,16sl,20sl,40sl,80sl,160sl，其中"sl"代表时隙slot。该协议定义配置周期已从小到大排列好，本方法假定相邻周期配置为1个等级。例如当前SR周期配置值为10sl，如果本次统计判决周期判决为406需要拉长一个等级，则下一个统计周期的SR周期配置调整为10sl的下一个等级即16sl；如果本次统计判决周期判决为408需要缩短一个等级则下一个统计周期的SR周期调整为10sl前一个等级即8sl。

在可能的实施例中，考虑到SR-MAX掉话属于重载网络比较严重的掉话问题，所以当判断满足SR-MAX掉话条件时，需要将SR周期直接调整为协议定义配置的最大值，以尽快消除掉话故障。

具体而言，当调度请求超过协议配置最大传输次数的比例超过第三阈值门限，且RRC连接用户数和激活用户数同时超过第四阈值门限时(增加该判断是为了排除个别空口质量差UE导致SR-MAX异常场景，而非重载多用户数传SR调度不及时场景)，将SR周期直接调整到协议配置最大值。

在本实施例中，具体判断过程如图4所示。

401，判断SR统计时长是否到统计判决周期，如果统计周期到了，则进行402统计周期判决处理，否则继续统计。

402，判决SR_COUNTER达到sr-TransMax的比例Ratio_SrMax是否超过第三阈值门限Threshold_SrMax，满足条件继续进行403继续判断用户数条件，否则跳转到405判断SR_COUNTER达到sr-TransMax一半的比例Ratio_SrMaxHalf。

403，判决RRC连接用户数和激活用户数是否同时超过第四阈值门限(分别为Threshold_Rrc_UE和Threshold_Active_UE)，必须同时满足。增加该判断是为了排除个别空口质量差UE导致SR-MAX异常场景，而非重载多用户数传SR调度不及时场景。满足条件进行404SR周期直接调整到协议配置最大值，否则跳转到409SR周期保持不变。SR-MAX掉话属于重载网络比较严重的掉话问题，所以设计该判断分支满足条件时，需要将SR周期直接调整为协议定义配置最大值，尽快消除掉话故障。

404，SR周期直接调整到协议可配置最大值，协议定义和小区子载波间隔相关，例如以FR1 SCS＝30kHz为例，SR可配置周期：1sl,2sl,4sl,8sl,10sl,16sl,20sl,40sl,80sl,160sl,那么协议定义配置最大值为160sl。

405，判决SR_COUNTER达到sr-TransMax一半的比例Ratio_SrMaxHalf是否高于第一阈值门限ThresholdHigh_SrMaxHalf(例如可预设为60％，可界面配置)。满足条件进行406调整处理，否则跳转到407继续判决。

406，如果满足条件则SR周期基于当前周期配置值根据协议SR周期配置列表拉长一个等级。

407，判决SR_COUNTER达到sr-TransMax一半的比例Ratio_SrMaxHalf是否低于第二阈值门限ThresholdLow_SrMaxHalf(例如可预设为40％，可界面配置)。满足条件进行408调整处理，否则跳转到409处理。

408，如果满足条件则SR周期基于当前周期配置值根据协议SR周期配置列表缩短一个等级。

409，SR周期保持，即不调整。

410，SR统计周期判决完成后，SR相关统计值清零。

411，处理结束。

步骤D中，执行调度请求周期调整动作可以有两种方案，方案选择策略可由客户界面配置。

方案一：仅针对新接入用户生效。方案一处理比较简单，在303新接入用户下发SR配置时执行即可；

方案二：针对所有用户(包括已接入在线用户)均调整。方案二考虑在线用户多时，同时RRC重配调整所有在线用户SR周期会短时间大量增加空口RRC重配消息，极大可能导致空口消息拥塞，还可能导致SR周期自适应拉长和缩短状态乒乓。因此方案二调整设计为按周期(该周期与统计判决周期P相同)进行在线用户SR周期重配，周期内限制最大重配用户数门限，比如10个(可根据实际测试情况调试优化)。

可在313后增加在线用户调整执行处理，具体处理流程见图5，包括：

501，根据311SR周期统计判决针对在线用户处理。

502，判决策略为保持则跳转到509无需调整处理，否则进行503处理。

503，小区SR周期重配用户数初始化零。

504，轮询小区在线用户。

505，判决小区是否还存在未重配SR周期的在线用户，存在则进行506判决处理，否则跳转到509。

506，判决已完成SR周期重配用户数是否小于最大重配用户数门限。满足条件进行507重配用户SR周期处理，否则跳转到509结束处理，等待下一个周期继续重配调整。

507，gNB下发RRC重配消息给UE，重配用户SR周期。

508，SR周期重配用户数加1。

509，处理结束。

综上所述，本申请实施例提供了一种调度请求周期自适应调整方法，通过基站收到的SR信息和在线用户数状况对SR配置周期进行自适应调整，使得基站在各种应用场景和忙闲时兼顾上行数传时延和空口上行信道资源开销，能够减少网络轻载下的上行数传时延和降低网络重载下SR-MAX掉话率。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

以上所述仅为本申请的较佳实例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (6)

1.一种调度请求周期自适应调整方法，其特征在于，包括：

基站对小区收到的调度请求信息按照统计判决周期P进行统计，具体为：基站分别针对小区收到的调度请求次数、调度请求超过协议配置最大传输次数一半的次数以及调度请求超过协议配置最大传输次数的次数，按照统计判决周期P进行统计；

基站对小区在线用户数进行统计，所述在线用户数包括RRC连接用户数和激活用户数；

基站根据小区调度请求信息和在线用户数的统计信息，判决调度请求周期的调整策略，包括：当调度请求超过协议配置最大传输次数一半的比例高于第一阈值门限时，拉长调度请求周期；当调度请求超过协议配置最大传输次数一半的比例低于第二阈值门限时，缩短调度请求周期；当调度请求超过协议配置最大传输次数的比例超过第三阈值门限，且RRC连接用户数和激活用户数同时超过第四阈值门限时，将SR周期直接调整到协议配置最大值；

基站根据调度请求周期的调整策略，执行调度请求周期调整动作。

2.根据权利要求1所述的调度请求周期自适应调整方法，其特征在于：所述统计判决周期P的管理粒度为时隙、子帧或帧的整数倍，所述统计判决周期P为预配置或开放给客户界面配置修改。

3.根据权利要求1所述的调度请求周期自适应调整方法，其特征在于，所述调度请求周期的调整策略包括缩短、拉长或保持调度请求周期。

4.根据权利要求3所述的调度请求周期自适应调整方法，其特征在于，每次缩短或拉长调度请求周期只调整1个等级。

5.根据权利要求1所述的调度请求周期自适应调整方法，其特征在于，所述执行调度请求周期调整动作仅针对新接入用户生效。

6.根据权利要求1所述的调度请求周期自适应调整方法，其特征在于，所述执行调度请求周期调整动作针对所有用户，执行调度请求周期调整动作时，按周期对在线用户的调度请求周期进行重配，每个周期内最大重配用户数不超过最大重配门限。