前文已经提到，如果UE不能通过BSR申请上行资源，则会继续尝试通过SR申请，本篇博文就描述通过SR来申请资源的相关内容。

1.什么是SR

SR，全称Scheduling Request，即调度请求，是UE向网侧申请资源用于新数据传输的一种方式。重传是不需要通过SR申请资源的，因为：如果是自适应重传，网侧会主动下发DCI0配置上行资源；如果是非自适应重传，UE直接使用上一次的RB资源。

SR属于物理层的信息，UE发送SR不需要RB资源，通过PUCCH控制信道传输。网侧成功解码到某个UE的SR信号之后，可能会通过DCI0给该UE分配RB资源，也可能不会分配，UE不应该假设网侧的结果。很多时候，UE为了得到上行RB资源，需要多次发送SR申请。

2.SR的发送时机

当UE触发了一个SR时，该SR就处于“Pending”态，意思就是UE准备但还没有向网侧发送SR。当UE已经组装了一个MAC PDU，并且该PDU包含了最近触发的BSR控制单元，或者上行授权提供的资源可以容纳所有待传的数据，那么处于”Pending“态的SR就会被取消，同时禁止定时器sr-ProhibitTimer也会被停止。换句话说，如果已经准备发送BSR，或者当前的RB资源已经足够，就没有必要再通过SR申请资源了。

sr-ProhibitTimer定时器

sr-ProhibitTimer定时器用于监视在PUCCH中传输的SR信号，当该定时器正在运行时，是不能发送SR的，一旦该定时器超时，UE就需要重新发送SR，直到达到最大发送次数dsr-TransMax。sr-ProhibitTimer定时器的值由RRC配置，在MAC-MainConfig信元中下发到UE，如图1所示。取值范围是0～7，单位是SR周期，值为0表示不配置该定时器，如果值为5，则表示UE发送SR后，如果等待了5个SR周期仍然没有收到DCI0的资源授权，那么将向网侧再次发送SR。

（图1）

那为什么需要这个sr-ProhibitTimer定时器呢？其实在最开始的R9协议里是没有sr-ProhibitTimer定时器的，只是后来发现如果网侧配置的SR周期比较短，或者如果正在执行VOIP业务，那么UE就会发送不必要的SR。为了避免UE发送不必要的SR，2009年11月份，爱立信、诺西等公司联合提出引入sr-ProhibitTimer定时器，规定只有等该定时器超时了才能继续发送SR，这样也大大降低了PUCCH上的负载。

最大发送次数dsr-TransMax

该参数在PhysicalConfigDedicated中的schedulingRequestConfig信元中携带，如图2所示，n4表示SR可以最多发送4次，最大值可以取到n64。如果SR重传到最大次数后仍然没有收到DCI0的资源配置，UE将如何处理呢？会发起竞争随机接入。

（图2）

既然有最大次数dsr-TransMax的概念，那么必然需要有一个变量用来记录当前SR的传输次数，协议把这个变量记为SR_COUNTER。如果一个SR被触发，同时没有其他的SR处于”Pending“态，那么UE会把SR_COUNTER设置为0。

只要有一个SR处于”Pending“态，那么UE在每个TTI内均应该按以下的流程处理：

如果当前TTI没有可用的UL-SCH上行资源，那么：
（1）如果UE没有被网侧配置SR资源，则发起竞争随机接入过程，并取消所有处于”Pending“态的SR。
（2）否则，如果UE在当前TTI有可用的PUCCH资源发送SR，且该TTI不在测量GAP中，同时sr-ProhibitTimer定时器也不在运行，那么：
-------（A）如果当前发送次数SR_COUNTER<dsr-TransMax，即还没有达到最大发送次数，则：
                  （a）将SR_COUNTER加1
                  （b）通知物理层在PUCCH上发送SR
                  （c）启动SR禁止定时器sr-ProhibitTimer
-------（B）否则，
                  （a）通知RRC释放PUCCH/SRS
                  （b）清除所有配置过的上下行授权
                  （c）发起一次竞争随机接入过程，并取消所有处于”Pending“态的SR。

上面的流程可以简单图示如下：

(图3)

一旦sr-ProhibitTimer定时器启动，则将进入循环检测状态，此时流程简单示意如下图4所示。

（图4）

3.SR的发送时刻

UE并不是在任意时刻都可以发送SR的，发送SR请求的时刻点需要满足下面的公式。

其中：nf是当前的系统帧号，范围是0～1023。ns是当前的时隙号，范围是0～19。子帧偏移N_OFFSET_SR和SR传输周期SR_PERIODICITY由参数I_SR决定，如图5所示，I_SR的值等于RRC配置的参数sr-ConfigIndex，被放在RadioResourceConfigDedicated->PhysicalConfigDedicated->SchedulingRequestConfig字段中，见前文的图2所示，范围是0～157。需要注意的是，R8版本的协议不支持SR周期等于1ms和2ms的场景。

（图5）

下面举个例子。假定RRC配置的I_SR=6，则SR周期=10ms，SR子帧偏移量=6-5=1。代入上面的公式，可知SR的周期时刻需要满足：( 10×nf + floor( ns / 2 ) -1 ) mod 10 = 0。此时系统帧号nf=0且时隙号ns=2和3（即子帧1的两个时隙）就可以使上面的公式成立，因此就是一个SR周期点。SR周期时序如图6所示。

（图6）

如果当前是TDD-LTE制式，那么上面这个例子中假定的RRC配置参数是有问题的，为什么呢？因为TDD-LTE制式的所有上下行子帧配置中，1号子帧都是特殊子帧，并不是上行子帧，而UE发送SR只能在上行子帧中发送，因此eNB侧的RRC在配置sr-ConfigIndex参数的时候需要注意到这点。

图7是一个发送SR过程的示意图。从图中可以看到，这个SR的周期是10ms，在第一个SR周期时刻，由于UE没有可传数据，因此并没有向网侧发送SR请求。到了第二个SR周期时刻点，因为有可传数据且触发了SR，因此向网侧发送了SR，并且在n时刻点收到了来自网侧的上行授权，之后UE在（n+4）时刻向网侧发送了数据。由于没有了可传数据，UE在第三个SR周期不再向网侧申请资源。

（图7）