MAC--SR

UE是没有权利主动在PUSCH上发送数据的，只能通过PUCCH向eNB发送Scheduling Request(SR)，eNB给UE分配上行资源后UE才可在PUSCH上发送数据。但在SR中并没有包含所要传输数据的大小，因此eNB要么分配一个足够大的资源（这显然不可能），要么分配一个大于Buffer Status Report(BSR)的资源，这样在分配资源比所要发送的数据包小时，只发送一个BSR，以请求一个更大的上行资源。 
UE只有在RRC_CONNECTED状态下切上行同步的情况下才会发起SR，重传数据没有SR。如果此时状态不是RRC_CONNECTED或者上行失步，UE将发起RA，以RAR3的形式完成调度请求。在SR请求极度不平常时，甚至可以不实现SR，单纯以RA代替。 
另一个问题在于，UE发起SR时机的是随机的，eNB并不知道在什么位置能收到SR。因此eNB必须在可能的SR位置一直作检测。这样，SR就形成一个周期。SR在PUCCH（PUCCH format 1）上发送（UE可以在PUCCH上主动发请求）。某个UE的SR周期是由eNB通过SchedulingRequestConfig.sr-ConfigIndex指定的，因此eNB可以根据收到SR的位置推断出到底是哪一个UE发的SR而无需C-RNTI。 
SchedulingRequestConfig的各个字段如下图所示。其中sr-PUCCH-ResourceIndex指明了SR使用的是哪一个PUCCH1资源（port 0）；Sr-ConfigIndex配置了SR的周期以及在周期内的偏移；dsr-TransMax指明了SR的最大传输次数。注意到SchedulingRequestConfig 
只有 PUCCH format 1/1a/1b 和 PUCCH format 3 可用于发送 SR。如果在同一子帧上，需要同时发送 SR 和 PUCCH format 3（HARQ ACK/NACK），则 SR 会复用到 PUCCH format 3 发送中，而不是在 sr-PUCCH-ResourceIndex 指定的PUCCH format 1 资源上发送。 

通过Sr-ConfigIndex查下表可得SR的周期和在后期内的偏移。 

eNB回发UL Grant的时机是不确定的，一种最极端的情况是eNB根本没有收到SR，因此当然也不会回发UL Grant。因此UE必须维护一个sr-ProhibitTimer定时器，当UE在此窗口期间没有收到UL-Grant(或其他回应），UE将重发SR，直到最大次数dsr-TransMax。当超过dsr-TransMax则认为UE与eNB失去连接或失步，发起RA过程。 
从上面的配置文件可以看出，小区内不同UE的SR周期可以不一样，但通常都会配置相同的SR周期。从之前的表格可以看出，此周期越大可容纳的UE越多，每个子帧上预留给SR PUCCH1的资源越少，但是SR延迟越高。 
配置SR所使用的PUCCH1资源是UE specific的，配置的参数前面已经描述过了为sr-PUCCH-ResourceIndex。此参数较为简单，不予详述。