LTE：上行調度請求（Scheduling Request，SR） LTE：下行資源分配類型

http://blog.sina.com.cn/s/blog_927cff010101a7yh.html

上行調度請求（Scheduling Request，SR）

      如果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字段配置的。

 

SchedulingRequestConfig ::=      CHOICE {

    release                          NULL,

    setup                            SEQUENCE {

       sr-PUCCH-ResourceIndex               INTEGER (0..2047),

       sr-ConfigIndex                   INTEGER (0..157),

       dsr-TransMax                     ENUMERATED {

                                            n4, n8, n16, n32, n64, spare3, spare2, spare1}

    }

}

 

SchedulingRequestConfig-v1020 ::=    SEQUENCE {

    sr-PUCCH-ResourceIndexP1-r10     INTEGER (0..2047)         OPTIONAL       -- Need OR

}

 

      UE在某些情況下可能沒有SR資源。場景一：從36.331可以看出，SchedulingRequestConfig是一個UE級的可選的IE（optional），默認為release。如果 eNodeB不給某UE配置SR（這取決於不同廠商的實現），則該UE只能通過隨機接入過程來獲取UL grant（在RAR中分配）。是否配置SR主要影響用戶面的延遲，並不影響上行傳輸的功能！

      場景二：當UE丟失了上行同步，它也會釋放SR資源，如果此時有上行數據要發送，也需要觸發隨機接入過程。

      從上面的描述可以看出，當UE沒有被分配SR資源時，基於競爭的隨機接入過程可以替代SR的功能用於申請上行資源。但這只適用於低密集度的上行資源請求的情況。

      從36.213的10.1.1節可以看出，只有PUCCH format 1（包含PUCCH format 1/1a/1b）和PUCCH format 3可用於發送SR。

      其中sr-PUCCH-ResourceIndex指定了UE在哪個PUCCH format 1資源上發送SR。SR資源用表示，其值與PUCCH format 1的資源索引相等。

      如果在同一子幀上，需要同時發送SR和PUCCH format 3（HARQ ACK/NACK），則SR會復用到PUCCH format 3發送中（處理方式見36.212的5.2.3.1節），而不是在sr-PUCCH-ResourceIndex指定的PUCCH format 1資源上發送。（關於PUCCH資源，這里就不做詳細說明了，我會在以后的博客中予以介紹）

      sr-ConfigIndex指定了SR的傳輸周期和SR在該周期內的子幀偏移，對應36.213的Table 10.1.5-1。滿足如下條件的上行子幀才能夠用於發送SR：

      其中為系統幀號；為一個系統幀內的slot號，取值范圍為0~19；的值對應子幀號。

      從上面的公式可以看出，保證了每個UE對應的SR資源在每個子幀只出現一次（但UE只在有上行數據要發送卻沒有上行資源時，才用該資源來發送SR）。指定了每個UE對應的SR資源在其周期內的第幾個子幀發送。

      SR資源配置如圖1所示：

 

圖1：SR資源

 

      可以看出，sr-ConfigIndex和sr-PUCCH-ResourceIndex共同決定了一個唯一的SR資源。該資源只能分配給一個UE，但只有當UE有上行數據需要發送但卻沒有上行資源時才會被使用。

      圖2是SR周期配置的一個例子，3個UE的周期都為10ms，但在周期內的子幀偏移各不相同。

 

圖2：SR周期配置的一個例子

 

      當有上行數據到達並觸發SR時，UE會選擇分配給它的下一個可用的SR資源來發送SR。如圖3所示：

 

圖3：SR傳輸

 

      UE發送SR以后，無法確定eNodeB什么時候會下發UL Grant，這取決於上行資源的調度以及優先級等。如果UE等待超時（超時時間由sr-ProhibitTimer決定）就重發SR，重發次數超過了SR的最大重傳次數（由IE：SchedulingRequestConfig的dsr-TransMax決定）就會觸發隨機接入。（見36.321的5.4.4節）

      通常，SR機制是針對整個UE的所有邏輯信道的，但在Rel-9中，LTE還提供了一種基於邏輯信道進行SR請求的機制。對於eNodeB創建的每一個邏輯信道，都有一個logicalChannelSR-Mask-r9字段，用於指定當該邏輯信道有新數據到達時，是否觸發SR。

 

【參考資料】

[1]      TS 36.213的10.1.5節      介紹SR資源

[2]      TS 36.321的5.4.4節      介紹SR流程

[3]      TS 36.331的6.3.2節      IE: SchedulingRequestConfig

[4]      《4G LTE/LTE-Advanced for Mobile Broadband》的13.2.2.2節

[5]      《LTE - The UMTS Long Term Evolution, 2nd Edition》的16.3.7節

http://blog.sina.com.cn/s/blog_927cff010101a042.html

http://blog.sina.com.cn/s/blog_927cff010101a05x.html

 

下行資源分配類型

      本文主要介紹下行物理信道PDSCH的3種資源分配類型：Type 0、Type 1和Type 2。

      具體使用哪種資源分配類型取決於所選的DCI format以及DCI內相關bit的配置。

      每種DCI format支持哪種資源分配類型，以及有哪些與資源分配相關的bit，詳見36.212的5.3.3節。由於這篇文章主要是介紹幾種下行資源分配類型，而不是介紹DCI format的，所以文章中只是略微提及，並不做深入分析。

      圖1是幾種下行DCI format與下行資源分配類型的對應關系：

圖1：DCI format與下行資源分配類型的對應關系

      注意：（1）下行資源是基於VRB而是PRB分配的。當然，VRB與PRB有一定的對應關系，詳見36.211的6.3.2節；（2）DCI format 1/2/2A/2B/2C同時支持Type 0和Type 1，具體使用哪種類型是通過1比特的域（見圖3）來指定的。

 

一、RBG介紹

      介紹資源分配類型Type 0和Type 1之前，需要先介紹一下RBG的概念。

      RBG（Resource Block Group，資源塊組）是一組連續的集中式VRB（localized VRB）。RBG的大小（P，即每個RBG中包含的VRB數。最后一個RBG包含的VRB數可能小於P）與系統帶寬相關，對應關系見圖2：

 

圖2：RBG size與下行系統帶寬的關系（36.213的Table 7.1.6.1-1）

      對應下行系統帶寬，RBG的總數為：

      其中，前個RBG的大小為P；如果 % P > 0，則最后一個RBG的大小為。

      以下行系統帶寬 = 50 RB為例，其P值為3，RBG的總數為17，前16個RBG各包含3個VRB，最后一個RBG只包含2個VRB。

 

二、資源分配類型0（Resource allocation type 0）

      在資源分配類型0中，DCI format 1/2/2A/2B/2C通過一個bitmap來指示分配給UE的RBG。bitmap共包含比特，每1比特對應1個RBG，最高位表示RBG 0，最低位表示RBG   - 1，依此類推。如果某個RBG分配給了某個UE，則bitmap中對應比特置為1；否則置為0。

圖3：DCI format 1/2/2A/2B/2C中與Type 0相關的字段

 

      以小區系統帶寬25 RB為例。

      1）通過查36.213的Table 7.1.6.1-1可以知道，RBG大小P = 2；

      2）RBG的總數。其中前12個RBG的每個RBG大小為2，最后一個RBG的大小為1（如圖4所示）；

圖4：資源分配類型0的RBG資源（25 RB）

      3）即bitmap共包含13比特。

      4）假如分配給某UE的資源的bitmap為：1001110100010，則該UE被分配了RBG 0、RBG 3、RBG 4、RBG 5、RBG 7、RBG 11（如圖5所示）。

圖5：資源分配類型0的例子（25 RB）

      從上面的例子可以看出：1）資源分配類型0支持頻域上的非連續RB分配；2）調度的粒度比較粗：調度的最小單位是RBG，對於較大的帶寬而言，無法按照單個RB來分配資源。當payload較小時，可能會造成資源的浪費。

 

三、資源分配類型1（Resource allocation type 1）

      在資源分配類型1中，所有的RBG被分為P個子集，P為RBG的大小（見圖2）。每個RBG子集p（）包含從RBG p開始，間隔為P的所有RBG。分配給某個UE的VRB資源必須來自於同一個子集。

      在資源分配類型1中，DCI format 1/2/2A/2B/2C通過3個域來指示分配給UE的VRB（注意：與資源分配類型0不同，這里是VRB，而不是RBG）。

圖6：DCI format 1/2/2A/2B/2C中與Type 1相關的字段

      第一個域包含比特，用於指定所選的RBG子集，即p的值。

      第二個域包含1比特（shift bit），用於指定子集內的資源是否偏移，1表示偏移，0表示不偏移。

      第三個域包含一個bitmap，bitmap的每一比特對應所選RBG子集中的一個VRB（注意：不是RBG）。最高位表示子集中的第一個VRB，最低位表示子集中的最后一個VRB，依此類推。如果某個VRB分配給了某個UE，則bitmap中對應比特置為1；否則置為0。bitmap的大小，即bitmap包含的比特數為

      一個選定的RBG子集中的VRB起始於該子集中的最小VRB號 + 偏移量，並對應bitmap中的最高位。該偏移量以VRB的數量表示，並且是發生在選定的RBG子集內的偏移。如果DCI的資源塊分配信息中的第二個域為0，則RBG子集p的偏移；如果DCI的資源塊分配信息中的第二個域為1，則RBG子集p的偏移，且bitmap中的最低比特位調整為對應RBG子集中的最后一個VRB。

      為RBG子集p包含的VRB數，計算公式如下：

      對於RBG子集p而言，其bitmap中的每一比特i（）對應的VRB可通過如下公式計算：

      關於偏移可能較難理解，莫急，對照后面的例子來學習，會比較清晰的。

      還是以小區帶寬25 RB為例。

      1）通過查36.213的Table 7.1.6.1-1可以知道，P = 2，即有2個子集：子集0（從RBG0開始）和子集1（從RBG1開始）；

圖7：資源分配類型1中的子集（25 RB）

      2） = 1，即第一個域使用1比特指定所選的RBG子集；

      3）第二個域使用1比特指定RBG子集中的資源是否偏移；

      4）bitmap包含的比特數 = 13 -1 -1 = 11；即bitmap只能對應11個VRB。

      5）每個RBG子集p包含的VRB數為

	13
	12

      可以看出，bitmap不足以表示每個子集中包含的所有VRB。

      6）接下來，我們詳細介紹第二個域，即shift bit對bitmap所表示的VRB的影響。

      如果shift bit為0，RBG子集p的偏移；

      如果shift bit為1，RBG子集p的偏移為

	2  （13 – 11）
	1  （12 - 11）

     從之前的分析可以看出，每個子集包含哪些RBG是確定的，也就是說，包含哪些VRB也是確定的。對應圖7，每個子集可用的VRB集合如圖8所示：

圖8：資源分配類型1中每個子集可用的VRB集合（25 RB）

      當shift bit = 0時，根據下面的公式，可知道bitmap（對於25RB帶寬，共11比特）的每一個比特對應哪個VRB。

      結果如下：

圖9：每個子集的bitmap中的每個比特對應的VRB（25 RB, shift bit = 0）

      從圖9可以看出，如果shift bit = 0（不發生偏移），每個子集的bitmap對應的VRB，是從圖8給定的VRB集合中的第一個VRB開始（對應子集0，起始VRB為VRB0；對應子集1，起始VRB為VRB2），順序選取11個VRB。

 

      當shift bit = 1時，根據下面的公式，可知道bitmap（對於25RB帶寬，共11比特）的每一個比特對應哪個VRB。

      結果如下：

圖10：每個子集的bitmap的每個比特表示的VRB（25 RB, shift bit = 1）

      從圖10可以看出，如果shift bit = 1（發生偏移），每個子集的bitmap對應的VRB，是從圖8給定的VRB集合中的第一個VRB，加上偏移量開始（對應子集0，偏移量 = 2，即在圖8給定的p = 0的VRB集合中，往前移2個，得到起始VRB為VRB4；對應子集1，偏移量 = 1，即在圖8給定的p = 1的VRB集合中，往前移1個，得到起始VRB為VRB3），順序選取11個VRB。

      圖11介紹了使用資源分配類型1的例子（25 RB）：

      上半部分對應：資源分配類型1；子集0；shift bit 為0；bitmap 為10011101000。即分配該UE的資源為：VRB0、VRB5、VRB8、VRB9、VRB13。

      下半部分對應：資源分配類型1；子集0；shift bit 為1；bitmap 為10011101000。即分配該UE的資源為：VRB4、VRB9、VRB12、VRB13、VRB17。

圖11：資源分配類型1的例子（25 RB）

  

      關於資源分配類型1的更多例子，還可以參考[6]。

      從上面的例子可以看出：1）資源分配類型1支持頻域上的非連續RB分配；2）和資源分配類型0相比，資源分配類型1支持粒度為1 RB的分配；3）資源分配類型0和資源分配類型1使用相同的bit數來表示資源的分配；4）bitmap的比特數實際上比RBG子集中的VRB數要少，通過shift bit，bitmap才能覆蓋所有的VRB。

 

三、資源分配類型2（Resource allocation type 2）

      在資源分配類型2中，分配給UE的資源為一段連續的VRB，其VRB可以是集中式（localized），也可以是分布式的（distributed）。

      對於DCI format 1A/1B/1D而言，有一個bit（對應Localized/Distributed  VRB assignment flag）用於指示是集中式VRB（該bit為0）還是分布式VRB（該bit為0）。

圖12：DCI format 1A中與Type 2相關的字段 

      對於集中式VRB分配而言，分配給一個UE的資源可以從1個VRB到整個系統帶寬的所有VRB。

      如果DCI format 1A使用分布式VRB分配方式，且其DCI的CRC由P-RNTI、RA-RNTI或SI-RNTI加擾，則分配給對應UE的VRB數可以從1個到個。（的計算見36.211的6.2.3.2節，這里就不做介紹了）

      如果DCI format 1A/1B/1D使用分布式VRB分配方式，且其DCI的CRC由C-RNTI加擾，則當下行帶寬為6~49 RB時，分配給對應UE的VRB數可以從1個到最多個；則當下行帶寬為50~110 RB時，分配給對應UE的VRB數可以從1個到最多16個。

      對於DCI format 1A/1B/1D而言，資源分配由一個資源指示值RIV來表示。通過這個值，可以推導出分配給UE的起始RB（）以及連續分配的RB的長度（）。計算公式如下：

      如果 ，則；否則。其中且不超過。

     當UE收到一個RIV后，如何計算和？

     通過可以知道是還是，並最終計算出和。

      由於且不超過，且必定有，故，也就有

      1）當時，；

      2）當時，。

      UE收到RIV后，計算的值x，

      1）如果，則得知，也就得到了最終結果；

      2）如果，則得知，也就得到了最終結果。

 

      圖13介紹了DCI format 1A/1B/1D使用資源分配類型2的例子（25 RB）：

      起始RB（）為3，連續分配的VRB數（）為8，，所以。

 

圖13：資源分配類型2的例子（25 RB）

 

      DCI format 1C只支持分布式VRB分配方式。對於DCI format 1C而言，分配給某個UE的資源可以從個到最多個VRB。其中為增長的步進值，並與下行系統帶寬相關（如圖14）。

 

圖14：值與下行系統帶寬的對應關系

      對於DCI format 1C而言，資源分配也是通過一個資源指示值RIV來表示。通過這個值，可以推導出分配給UE的起始RB（）以及連續分配的RB的長度（）。計算公式如下：

      如果，則；否則。其中，並且。而且不超過 。

      對於DCI format 1C而言，UE收到一個RIV后計算和的方式與DCI format 1A/1B/1D類似，這里就不做介紹了。

       假設是在DCI format 1C中的資源分配且系統帶寬為25 RB，，，則有

      因為，所以 = 12 * (4 - 1) + 1 = 37。

 

      從上面的例子可以看出：1）資源分配類型2只支持連續VRB的分配；2）對於資源分配類型2，DCI format 1A/1B/1D與DCI format 1C的格式是不同的，DCI format 1C多了步進的概念；3）與資源分配類型0/1只支持集中式VRB分配不同，資源分配類型2既支持集中式VRB也支持分布式VRB。

 

注：本來想修改一下博文，但新浪博客有問題，保存時只有部分內容保存了下來，所以從其他轉載的文章拷貝過來，如果對你的閱讀產生了干擾，請見諒！

 

【參考資料】

[1]      TS 36.213的7.1.6節     Resource allocation

[2]     TS 36.212的5.3.3節     Downlink control information

[3]     TS 36.211的6.2.3.1節   Virtual resource blocks of localized type

[4]     《4G LTE/LTE-Advanced for Mobile Broadband》的10.4.4節

[5]     《LTE - The UMTS Long Term Evolution, 2nd Edition》的9.3.5.4節

[6]     《Type 1 Resource Allocation in LTE》by Prakash 

 

[7]      《Resource Allocation Type》