LTE SR资源配置

如果UE没有上行数据要传输，eNodeB并不需要为该UE分配上行资源，否则会造成资源的浪费。因此， UE需要告诉eNodeB自己是否有上行数据需要传输，以便eNodeB决定是否给UE分配上行资源。为此LTE提供了一个上行调度请求（Scheduling Request，SR）的机制。

UE是因为没有上行PUSCH资源才发送SR的，所以UE只能在PUCCH上发送SR。eNodeB可以为每个UE分配一个专用的SR资源用于发送SR。该SR资源是周期性的，每n个子帧出现一次。SR的周期是通过IE：SchedulingRequestConfig的sr-ConfigIndex字段配置的。

 

由于SR资源是UE专用且由eNodeB分配的，因此SR资源与UE一一对应且eNodeB知道具体的对应关系。也就是说，UE在发送SR信息时，并不需要指定自己的ID（C-RNTI），eNodeB通过SR资源的位置，就知道是哪个UE请求上行资源。SR资源是通过IE：SchedulingRequestConfig的sr-PUCCH-ResourceIndex字段配置的。sr-PUCCH-ResourceIndex指定了UE在哪个PUCCH format 1资源上发送SR。SR资源用表示，其值与PUCCH format 1的资源索引相等。

可以看出，sr-ConfigIndex和sr-PUCCH-ResourceIndex共同决定了一个唯一的SR资源。该资源只能分配给一个UE，但只有当UE有上行数据需要发送但却没有上行资源时才会被使用。

通常，SR机制是针对整个UE的所有逻辑信道的，但在Rel-9中，LTE还提供了一种基于逻辑信道进行SR请求的机制。对于eNodeB创建的每一个逻辑信道，都有一个logicalChannelSR-Mask-r9字段，用于指定当该逻辑信道有新数据到达时，是否触发SR。

 

 

UE在某些情况下可能没有SR资源。

场景一：从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE（optional），默认为release。如果eNodeB不给某UE配置SR（这取决于不同厂商的实现），则该UE只能通过随机接入过程来获取UL grant（在RAR中分配）。是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！

场景二：当UE丢失了上行同步，它也会释放SR资源，如果此时有上行数据要发送，也需要触发随机接入过程。

 

转载于:https://www.cnblogs.com/charlieqian/p/6963937.html