What is the use of SR prohibit timer?

为什么需要引入SR prohibit timer？网上搜索到的答案不多，其中一个解答如下。

“SR prohibit timer is used to prevent UE being transmits SR again and again. Some application doesn't require to send SR frequently , say some application sends few bytes of data (maybe TCP ACK/NACK ) frequently ,in this case UE will send SR frequently to get few bytes of UL data to send .so they have introduced SR prohibit timer to prevent ue to send SR and it buffers few bytes of data till SR prohibit timer expires and it sends SR to ENB. This is applicable only if the application is delay tolerant.”

 

解答的大致理解是为了让UE不必要地频繁地发送SR请求，对于一些时延不敏感的应用，发送的上行数据量不大，例如仅仅发送一些TCP ACK/NACK的确认，那么UE由于在SR prohibit timer处于运行状态时候，不发送SR，在SR prohibit timer超时之后， 将积累的上行数据在一次SR请求之后获得的上行调度中一起发送。

 

在NR -Scheduling Request中，LTE中一般配置的SRprohibit timer的长度是SR周期的整数倍，UE侧实际发送SR的周期相应的扩大了该整数倍。但是对于基站侧来说，为检测每个UE的初始SR请求，还是需要在SR的每个时间点进行检测。

随之而来的一个疑问是，为什么不直接把SR的周期配置得更大呢？

 

网上查了一些关于LTE的提案，发现有两个Timer，一个是sr-ProhibitTimer另外一个是logicalChannelSR-ProhibitTimer。

 

在36.321-g10版本中5.4.5节Buffer Status Reporting，

 

5.4.4节 Scheduling Request

 

先谈一下为什么不直接把SR的周期配置得更大这个问题的个人理解，仅仅从SR的发送间隔来看，两者的效果貌似一样，但是如果把SR的周期变大，可能会造成某些情况下的时延变大，结合示意图，看一下下面两者的差异。

 

然后，在NR中，logicalChannelSR-ProhibitTimer名称已经修改为logicalChannelSR-DelayTimer，从字面上的意思来猜测，要Delay SR的发送。

在R2-145292的CR中，阐述了在LTE中引入logicalChannelSR-ProhibitTimer的原因。

 

在R2-152398的其中一个示例图可知，增加了logicalChannelSR-ProhibitTimer后，可以避免一有上行数据则触发SR请求，在积累到一定数据包，Timer超时之后再触发SR发送。示例使用的是VoIP场景。

 

 

为了避免后续的SR同样能够达到Delay的效果，建议收到上行调度之后重新Start该Timer操作。

 

不必要地频繁发送SR，即可以达到减轻网络负载的效果，又能节省UE自身的功耗，可谓一举两得。

 

SR的一些参考的提案/CR共享如下。

链接: https://pan.baidu.com/s/1pz9v8y0NHBBGoWwIxLtC_Q 提取码: 8pst