如果UE沒有上行數據要傳輸，eNodeB並不需要爲該UE分配上行資源，否則會造成資源的浪費。因此， UE需要告訴eNodeB自己是否有上行數據需要傳輸，以便eNodeB決定是否給UE分配上行資源。爲此LTE提供了一個上行調度請求（Scheduling Request，SR）的機制。
UE通過SR告訴eNodeB是否需要上行資源以便用於UL-SCH傳輸，但並不會告訴eNodeB有多少上行數據需要發送（這是通過BSR上報的）。eNodeB收到SR後，給UE分配多少上行資源取決於eNodeB的實現，通常的做法是至少分配足夠UE發送BSR的資源。
eNodeB不知道UE什麼時候需要發送上行數據，即不知道UE什麼時候會發送SR。因此，eNodeB需要在已經分配的SR資源上檢測是否有SR上報。
在載波聚合中，無論配置了多少個上行載波單元（component carrier），都只需要1個SR就夠了，畢竟SR的作用只是告訴eNodeB，本UE有上行數據要發送了，你看着給點上行資源吧！由於PUCCH只在PCell上發送，而SR只在PUCCH上發送，也就是說，SR只在PCell上發送。
本文並不介紹SR如何編碼並在PUCCH上傳輸，這會在以後的PUCCH專題中予以介紹。
需要明確的是，只有處於RRC_CONNECTED態且保持上行同步的UE纔會發送SR；且SR只能用於請求新傳數據（而不是重傳數據）的UL-SCH資源。
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字段配置的。
UE通過SR向eNodeB請求上行資源時，只指明瞭其是否有上行數據需要發送，而沒有指明自己需要發送多少上行數據。UE需要通過BSR（Buffer Status Report）告訴eNodeB，其上行buffer裏有多少數據需要發送，以便eNodeB決定給該UE分配多少上行資源。
根據業務的不同，UE可能建立大量的無線承載（radio bearer，每個bearer對應一個邏輯信道），如果爲每一個邏輯信道上報一個BSR，會帶來大量的信令開銷。爲了避免這種開銷，LTE引入了LCG（Logical Channel Group）的概念，並將每個邏輯信道放入一個LCG（共4個）中。UE基於LCG來上報BSR，而不是爲每個邏輯信道上報一個BSR。
某個邏輯信道所屬的LCG是在邏輯信道建立時通過IE: LogicalChannelConfig 的logicalChannelGroup字段來設置的