本文主要是介绍NR - Scheduling Request，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
SR（Scheduling Request），在UE有上行数据需要发送，但是无上行资源时，通过发送SR请求，向网络申请上行调度（DCI format 0-0/0-1）。SR在物理层信道PUCCH上发送。
在MAC配置中，逻辑信道可以分别关联一个SR配置。
不同SR配置，通过schedulingRequestId来区分，MAC层面，schedulingRequestId还关联了sr-ProhibitTimer和SR的发送最大次数sr-TransMax。
具体的SR对应到物理层资源配置，在PUCCH-Config中，该配置为各个上行BWP分别配置，使用schedulingRequestResourceId来区分不同资源配置，其中会关联schedulingRequestID。当然还包括SR发送时间点配置，对应的PUCCH Resource配置。
总结起来，其关联关系如下图所示，一个逻辑信道最多对应一个SchedulingRequestID，多个逻辑信道可以共用一个SchedulingRequestID，对于图示中的Logical Channel 4，由于未配置SR，如果该逻辑信道上有数据发送，则只能通过随机接入过程来获得上行调度。
SchedulingRequestResourceConfig中的periodicityAndOffset确定了SR的发送时间位置，注意到，其最小周期为2 Symbol。
协议描述中有Positive SR和Negative SR的概念，UE并不是一直有发送SR请求的需求，对于Positive SR即UE有SR请求发送，需要物理层发送SR/PUCCH，而对于无SR发送请求的UE，在SR资源的时间点，则该SR为Negative SR。
对应到物理层，SR使用PUCCH format 0或者PUCCH format 1发送。
-
当使用PUCCH format 0发送时，mcs=0，m0为initialCyclicShift
-
当使用PUCCH format 1发送时，b(0)=0
sr-ProhibitTimer在Running的时候，在UE需要发送SR，且在SR时间点位置时，不能发送SR。
当SR请求发送达到最大次数仍然不能获得上行调度后，通过发送PRACH触发随机接入过程来获得上行调度了，在NR 随机接入过程（三）可知，RACH Response中包含了上行调度。
当SR的到达最大发送次数后无上行调度，除了发送PRACH外，MAC执行的操作还包括：
-
通知RRC Release所有服务小区PUCCH配置
-
通知RRC Release所有服务小区SRS配置
-
清除Configured DL assignments和 Configured UL Grants
-
清除用于发送semi-persistent CSI的PUSCH Resource
这篇关于NR - Scheduling Request的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
