【泡泡学通信】SR：SCheduling request

泡泡学SR 二、流程 三、SR传输和配置（原文连接%E5%9F%BA%E7%A1%80-SR/）四、SR配置五、SR发送六、SR调度流程注意事项

一、定义 基础背景了解

（1）在认识SR之前我们先简单了解一下，协议栈、各种信道，我们知道无线协议栈的架构是一层一层的，每一层都有自己的职责，如下：

那么在RLC（无线链路控制层）和MAC（媒介访问控制层）之间有5条道，称为逻辑信道，分别是PCCH、BCCH、CCCH、DCCH、DTCH；在MAC层到物理层有5条道，称为传输信道，分别是PCH、BCH、DL-SCH、UL-SCH、RACH；在物理层除了一些参考信号外存在6条道，称为物理信道，分别是PBCH、PDSCH、PDCCH、PUSCH、PUCCH、PRACH；问题：是不是CSI-RS、PSS等信号不在这些信道中传输？

（2）其中有两种信号DCI：下行控制信号在PSCCH中传输，UCI：上行控制信号，在PUCCH和PUSCH中传输。

UCI信号包括：与当前UE状态相关的信息，比如当前UE是否需要请求上行资源、当前UE检测到的下行链路质量、UE告诉eNB应该使用的预编码矩阵、UE能够区分出来的传输层个数，以及UE是否成功解码到了PDSCH块等信息，这些信息eNB侧是无法获知的，只能由UE上报。

（3）定义：文章主角SR是UCI信息的一种：用于请求上行资源，在PDCCH的数据格式1中携带（图文章连接）

上面是4G中的PUCCH，在5GNR中定义了5中PUCC格式:如下图，SR在用格式0或格式1标识，

PUCCH格式0特点为段PUCCH，当PUCCH格式0用于传输SR时，UE只有在存在肯定（）SR时才进行PUCCH传输，具体来说，使用高层信令预先配置给SR的一个循环移位产生传输序列，在对应的时频域资源上传输即可。当UE不存在SR （ 即 SR ） 时 ，不 需要传输PUCCH ， 即非连续发送（ ，DTX）。

PUCCH格式1特点为长PUCCH，在时域上可以占用4～14个OFDM符号，用于承载1～-ACK和SR。为了保证较低的PAPR，进一步提升多用户复用传输容量，PUCCH格式1沿用了LTE PUCCH格式1a/1b的传输结构。具体结构参考书《5G移动通信系统设计与标准详解》6.3.2.

不是每次都能申请到PUCCH资源，只有UE处于RRC 状态且保持上行同步的UE才会发送SR；

二、流程 4G中的流程（原文连接）

在LTE上行调度请求中，当UE打算在上行中传输数据时，UE先通过PUCCH发送SR消息，在成功检测到SR之后，eNB经由包含上行许可的PDCCH发送DCI以分配上行资源。随后，UE在所分配的资源中的PUSCH上发送BSR，用于通知eNB UE的缓冲器中要发送的数据量。基于BSR信息，eNB在上行许可中为UE分配适当的资源和MCS以在PUSCH上传输上行数据。如果UE不请求上行资源，则在所配置的PUCCH资源上不发送任何内容。

5G流程

5G中上行资源请求的流程类似，不同的是引入低时延上行传输：

1）支持灵活的帧结构：与4GLTE只支持15kHz的子载波间隔，每个子帧固定长度1ms相比，5G NR支持多种子载波间隔。越高的子载波间隔每个时隙的传输时间越短，带来越低的延迟性能。并且对于TDD，NR支持更加灵活的上下行配置，可动态指示符号的上下行方向，大幅降低了上下行切换的时延。

2）引入更小的时间资源单位，支持符号级别的调度。数据信道映射类型B支持起始符号位置灵活配置，分配符号数量少，时延短。短格式的PUCCH仅占1~2个符号。

3）支持灵活的PDCCH配置：通过配置合理的PDCCH的监听周期和偏移值，可以实现较为密集的PDCCH 监听机会，可以应对URLLC需求突发的业务场景，满足低时延要求。

4）上行采用免调度授权的机制，终端可不需要通过基站上行授权直接发送数据。

5）定义终端对下行数据接收和上行数据发送的快速处理能力。

6）支持URLLC业务对eMBB业务的抢占：基站可以在已经分配的，用于eMBB业务数据的时频资源选择部分或全部资源传输URLLC业务数据，在选择的用于传输URLLC业务数据的时频资源上停止发送eMBB业务。

实行用NR PUCCH上的缓冲区状态报告（BSR： ）以无竞争或基于竞争的方式替换SR。

*对于低时延应用，例如URLLC，请求上行传输资源的L1控制信令可能更适合于满足严格的时延要求。在UE支持多个并且时延敏感服务与一个特定*（是什么 ）**相关联（例如，使用更大的子载波间隔和更短的符号持续时间）的情况下，UE可以使用SR请求资源用于具有相关的低时延上行传输。

*专用SR资源可被配置为请求用于低时延服务的上行传输的资源。如图3所示，在专用资源上成功检测到SR之后，gNB可以使用适当的方法（例如，使用较大的子载波间隔）为BSR和上行数据传输分配资源。

三、SR传输和配置（原文连接%E5%9F%BA%E7%A1%80-SR/）

在NR中，除了以时隙的整数倍为单位的SR周期外，还定义了小于一个时隙的传输周期，例如2个OFDM符号和7个OFDM符号的传输周期，这是为了支持在一个时隙中的任何一个OFDM符号上传输低时延业务。当传输周期不小于一个时隙时，根据高层配置的SR周期以及时隙偏移值确定SR的传输机会；当传输周期小于一个时隙时，根据高层配置的SR周期以及一个时隙内的起始符号偏移值确定SR的传输机会。

在NR中，为了支持针对不同业务类型的上行数据的调度请求，可以同时为一个用户配置最多8个SR配置。每个SR配置对应一系列与SR传输相关的参数，如SR周期、偏移、PUCCH资源等。不同的SR配置对应不同的逻辑信道，对应关系在MAC层维护。当MAC层触发多个SR配置在同一个时隙中传输时，存在多个PUCCH传输 SR。如果多个 SR的PUCCH资源与HARQ-ACK/CSI的PUCCH资源存在重叠，则在执行6.3.4.4节的重叠信道的复用传输规则之前，UE需要自主选择一个 SR与HARQ-ACK/CSI进行复用传输，丢弃其他 SR；如果在一个时隙中存在多个时域资源不重叠的 SR，则UE需要自主选择至多2个时域上不重叠的 SR，丢弃其他，在选择2个PUCCH时，其中的一个PUCCH必须为短PUCCH。上述UE选择SR的行为由UE实现，不做具体标准化。

（协议描述中有 SR和 SR的概念，UE并不是一直有发送SR请求的需求，对于 SR即UE有SR请求发送，需要物理层发送SR/PUCCH，而对于无SR发送请求的UE，在SR资源的时间点，则该SR为 SR。）

四、SR配置

log实例：

fig {

{

0,

sr- n64

(1)对应的就是0-7 ；

(2)MAC的配置中， 逻辑信道可以分别关联SR配置，一个MAC实体可以配置0个、1个或者多个SR配置，不同的逻辑信道可以关联相同的，如果没有给相应的逻辑信道配置SR，当该逻辑信道有数据发送时只能通过随机接入获得上行调度。

(3)一个mac实体通过MAC-->fig->配置一个SR列表。其中每个SR配置对应一个fig；

（4）在pucch-中为各个上行bwp配置了sr资源，使用来区分不同的资源配置（格式0 1），会关联，还包括SR发送时间点配置，以及对应的pucch 配置。

五、SR发送

针对每个SR资源，基站通过->告诉UE使用PUCCH 还是 来发送SR。

在中的字段指定传送SR的PUCCH资源的周期,以符号或者slot为单位，确定了SR的发送时间位置[TS38.331 9.2.4]。可以看到SR的最小周期是2符号。

基于SR周期的差异，把SR对应三种场景来，如下图case所示：(触发条件)

从协议指示的配置范围可以看出，根据不同的子载波间隔，可选择的周期偏移有所不同；当UE发现一个SR传输机会对应PUCCH资源所在的slot，用于改pucch传输的符号数小于对应pucch资源所需的符号数，UE不会在该slot上发送pucch资源；

SR资源是UE专用，UE发送SR时不需要指定自己的CRNTI，基站通过SR资源的时域、频域和码分复用信息就知道哪个UE请求上行资源。

协议描述中有 SR和 SR的概念，UE并不是一直有发送SR请求的需求，对于 SR即UE有SR请求发送，需要物理层发送SR/PUCCH，而对于无SR发送请求的UE，在SR资源的时间点，则该SR为 SR。基站不知道UE什么时候发送SR，需要在已经分配的SR资源上检测是否有SR上报，会在每个SR上来的时刻监测是否有SR资源，具体的SR调度流程如下图所示：

六、SR调度流程注意事项

1 只有在pucch资源上配置了SR才能发送SR请求上行调度，不然只能通过随机接入申请上行资源；

2 SR发送实际在PUCCH的特定位置，以便基站能检测到SR；

3 SR发送实际不能和测量GAP重合；

4 如果sr-未超时，则不能发送SR，此时定时器放置SR发送过多，降低PUCCH负载；

5 当的传输实际和测量gap重叠或者sr-未超时等原因不能发送SR时，需要循环检测，指导条件满足；

6 SR-为计数器，只有当SR- 7 UE触发SR后，这个SR级处于态，意思是为UE准备单是还没有发送SR，如果已经准备发送BSR，或者PUSCH资源足够，那么的SR会被取消。

UE发送SR之后，无法确定基站什么时候会下发UL Grant，如果UE等待超时（由果sr-定时器配置）就会尝试重发SR，每个SR都有自己的果sr-。

当SR请求发送达到最大次数仍然不能获得上行调度后，通过发送PRACH触发随机接入过程来获得上行调；当SR的到达最大发送次数后无上行调度，除了发送PRACH外，MAC执行的操作还包括：

1.通知RRC 所有服务小区PUCCH配置;

2.通知RRC 所有服务小区SRS配置;

3.清除 DL 和 UL .

4.清除用于发送semi- CSI的PUSCH .