本文主要是介绍LTE资源调度 -- 上行调度请求(2)SR,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
前文已经提到,如果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)
参考文献:
(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》
这篇关于LTE资源调度 -- 上行调度请求(2)SR的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!