在《LTE资源调度(4)-上行资源申请方式和BSR缓存状态报告》里已经提到,如果UE不能通过BSR申请上行资源,则会继续尝试通过SR申请,本篇博文就描述通过SR来申请资源的相关内容。
1.什么是SR
SR,全称Scheduling Request,即调度请求,是UE向网侧申请资源用于新数据传输的一种方式。重传是不需要通过SR申请资源的,因为:如果是自适应重传,网侧会主动下发DCI0配置上行资源;如果是非自适应重传,UE直接使用上一次的RB资源。
SR属于物理层的信息,UE发送SR这个动作的本身不需要RB资源,可以通过PUCCH控制信道传输。网侧成功解码到某个UE的SR信号之后,可能会通过DCI0给该UE分配RB资源,但不能保证网侧每次都会分配RB。有些时候虽然UE发送了SR信号,但网侧并没有解码到。UE发出了SR信号后,不要期望网侧一定会在接下来的某个时刻分配RB资源,很多时候,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周期比较短(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中(关于测量GAP请参考《LTE-TDD资源调度(3)-测量GAP》),同时sr-ProhibitTimer定时器也不在运行,那么: -------(A)如果当前发送次数SR_COUNTER (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。帧号和时隙的相关内容,请参考《LTE物理传输资源(1)-帧结构和OFDM符号》。子帧偏移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周期不再向网侧申请资源。关于为什么UE会在(n+4)时刻发送数据,请参考《LTE-TDD HARQ(1)-上行HARQ时序》。
(图7)
参考文献:
(1)3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification
(2)3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)
(3)3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures
(4)《4G LTE/LTE-Advanced for Mobile Broadband》