上行調度請求(Scheduling Request,SR) 與uffer Status Report(BSR)

如果UE沒有上行數據要傳輸,eNodeB並不需要爲該UE分配上行資源,否則會造成資源的浪費。因此, UE需要告訴eNodeB自己是否有上行數據需要傳輸,以便eNodeB決定是否給UE分配上行資源。爲此LTE提供了一個上行調度請求(Scheduling RequestSR)的機制。

      UE通過SR告訴eNodeB是否需要上行資源以便用於UL-SCH傳輸,但並不會告訴eNodeB有多少上行數據需要發送(這是通過BSR上報的)。eNodeB收到SR後,給UE分配多少上行資源取決於eNodeB的實現,通常的做法是至少分配足夠UE發送BSR的資源。

      eNodeB不知道UE什麼時候需要發送上行數據,即不知道UE什麼時候會發送SR。因此,eNodeB需要在已經分配的SR資源上檢測是否有SR上報。

      在載波聚合中,無論配置了多少個上行載波單元(component carrier),都只需要1SR就夠了,畢竟SR的作用只是告訴eNodeB,本UE有上行數據要發送了,你看着給點上行資源吧!由於PUCCH只在PCell上發送,而SR只在PUCCH上發送,也就是說,SR只在PCell上發送。

      本文並不介紹SR如何編碼並在PUCCH上傳輸,這會在以後的PUCCH專題中予以介紹。

      需要明確的是,只有處於RRC_CONNECTED態且保持上行同步的UE纔會發送SR;且SR只能用於請求新傳數據(而不是重傳數據)的UL-SCH資源。

      UE是因爲沒有上行PUSCH資源才發送SR的,所以UE只能在PUCCH上發送SReNodeB可以爲每個UE分配一個專用的SR資源用於發送SR。該SR資源是週期性的,每n個子幀出現一次。SR的週期是通過IESchedulingRequestConfigsr-ConfigIndex字段配置的。

      由於SR資源是UE專用且由eNodeB分配的,因此SR資源與UE一一對應且eNodeB知道具體的對應關係。也就是說,UE在發送SR信息時,並不需要指定自己的IDC-RNTI),eNodeB通過SR資源的位置,就知道是哪個UE請求上行資源。SR資源是通過IESchedulingRequestConfigsr-PUCCH-ResourceIndex字段配置的。

 

 

UE通過SReNodeB請求上行資源時,只指明瞭其是否有上行數據需要發送,而沒有指明自己需要發送多少上行數據。UE需要通過BSRBuffer Status Report)告訴eNodeB,其上行buffer裏有多少數據需要發送,以便eNodeB決定給該UE分配多少上行資源。

      根據業務的不同,UE可能建立大量的無線承載(radio bearer,每個bearer對應一個邏輯信道),如果爲每一個邏輯信道上報一個BSR,會帶來大量的信令開銷。爲了避免這種開銷,LTE引入了LCGLogical Channel Group)的概念,並將每個邏輯信道放入一個LCG(共4個)中。UE基於LCG來上報BSR,而不是爲每個邏輯信道上報一個BSR

      某個邏輯信道所屬的LCG是在邏輯信道建立時通過IE: LogicalChannelConfig logicalChannelGroup字段來設置的 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章