LTE上行調(diào)度請求SR

1、LTE上行調(diào)度請求(SchedulingRequest,SR)(2012-12-2721:33:51)轉(zhuǎn)載，標簽：分類：LTEltesrschedulingrequest上行調(diào)度請求上行調(diào)度請求(SchedulingRequest)SR)如果UE沒有上行數(shù)據(jù)要傳輸，eNodeB并不需要為該UE分配上行資源，否則會造成資源的浪費。因此，UE需要告訴eNodeB自己是否有上行數(shù)據(jù)需要傳輸，以便eNodeB決定是否給UE分配上行資源。為此LTE提供了一個上行調(diào)度請求(SchedulingRequest,SR)的機制。UE通過SR告訴eNodeB是否需要上行資源以便用于UL-SCH傳輸，但并不會告訴e

2、NodeB有多少上行數(shù)據(jù)需要發(fā)送(這是通過BSR上報的)。eNodeB收到SR后，給UE分配多少上行資源取決于eNodeB的實現(xiàn)，通常的做法是至少分配足夠UE發(fā)送BSR的資源。eNodeB不知道UE什么時候需要發(fā)送上行數(shù)據(jù)，即不知道UE什么時候會發(fā)送SR0因此，eNodeB需要在已經(jīng)分配的SR資源上檢測是否有SR上報。在載波聚合中，無論配置了多少個上行載波單元(componentcarrier),都只需要1個SR就夠了，畢竟SR的作用只是告訴eNodeB，本UE有上行數(shù)據(jù)要發(fā)送了，你看著給點上行資源吧！由于PUCCH只在PCell上發(fā)送，而SR只在PUCCH上發(fā)送，也就是說，SR只在PCell

3、上發(fā)送本文并不介紹SR如何編碼并在PUCCH上傳輸，這會在以后的PUCCH專題中予以介紹。需要明確的是，只有處于RRC_CONNECTED態(tài)且保持上行同步的UE才會發(fā)送SR;且SR只能用于請求新傳數(shù)據(jù)(而不是重傳數(shù)據(jù))的UL-SCH資源。UE是因為沒有上行PUSCH資源才發(fā)送SR的，所以UE只能在PUCCH上發(fā)送SR0eNodeB可以為每個UE分配一個專用的SR資源用于發(fā)送SR0該SR資源是周期性的，每n個子幀出現(xiàn)一次。SR的周期是通過IE:SchedulingRequestConfig的sr-ConfigIndex字段配置的。由于SR資源是UE專用且由eNodeB分配的，因此SR資源與UE一

4、一對應且eNodeB知道具體的對應關系。也就是說，UE在發(fā)送SR信息時，并不需要指定自己的ID(C-RNTI),eNodeB通過SR資源的位置，就知道是哪個UE請求上行資源。SR資源是通過IE:SchedulingRequestConfig的sr-PUCCH-ResourceIndex字段配置的。SchedulingRequestConfig:=CHOICEreleaseNULL,setupSEQUENCEsr-PUCCH-ResourceIndexINTEGER(0.2047),sr-ConfigIndexINTEGER(0.157),dsr-TransMaxENUMERATEDn4,n8,

5、n16,n32,n64,spare3,spare2,spare1SchedulingRequestConfig-v1020:=SEQUENCEsr-PUCCH-ResourceIndexP1-r10INTEGER(0.2047)OPTIONAL-NeedORUE在某些情況下可能沒有SR資源。場景一：從36.331可以看出，SchedulingRequestConfig是一個UE級的可選的IE（optional），默認為release。如果eNodeB不給某UE配置SR（這取決于不同廠商的實現(xiàn)），則該UE只能通過隨機接入過程來獲取ULgrant（在RAR中分配）。是否配置SR主要影響用戶面的延遲

6、，并不影響上行傳輸?shù)墓δ?！場景二：當UE丟失了上行同步，它也會釋放SR資源，如果此時有上行數(shù)據(jù)要發(fā)送，也需要觸發(fā)隨機接入過程。從上面的描述可以看出，當UE沒有被分配SR資源時，基于競爭的隨機接入過程可以替代SR的功能用于申請上行資源。但這只適用于低密集度的上行資源請求的情況。從36.213的10.1.1節(jié)可以看出，只有PUCCHformat1（包含PUCCHformat1/1a/1b）和PUCCHformat3可用于發(fā)送SR。其中sr-PUCCH-ResourceIndex指定了UE在哪個PUCCHformat1資源上發(fā)送SR。SR資源用PUCCH6即表示，其值與PUCCHformat1的資源

7、索引與UCCH相等。如果在同一子幀上，需要同時發(fā)送SR和PUCCHformat3（HARQACK/NACK），則SR會復用到PUCCHformat3發(fā)送中（處理方式見36.212的節(jié)），而不是在sr-PUCCH-ResourceIndex指定的PUCCHformat1資源上發(fā)送。（關于PUCCH資源，這里就不做詳細說明了，我會在以后的博客中予以介紹）CDsr-ConfigIndex指定了SR的傳輸周期和SR在該周期內(nèi)的子幀偏移N詆set$R,對應36.213的Table10.1.5-1。滿足如下條件的上行子幀才能夠用于發(fā)送SR:（10*町+1%/2J-SRjmodSJiperio

8、dicm-=0其中叼為系統(tǒng)幀號；為一個系統(tǒng)幀內(nèi)的slot號，取值范圍為019;L，的值對應子幀號。1QH從上面的公式可以看出，m。PERIODICITY保證了每個UE對應的CDSR資源在每ODKTTY個子幀只出現(xiàn)一次（但UE只在有上行數(shù)據(jù)要發(fā)送卻沒有上行資源時，才用該資源來發(fā)送SR）。N。氏1SERSR指定了每個UE對應的SR資源在其周期內(nèi)的第幾個子幀發(fā)送。SR資源配置如圖1所示：S.1xngRequestConfig:=releasesftrfy生ePUCCHfg-nmot1rBSHin：useterSrlseiLup一二二-nt5J二MLELI.INTEGER(0.-2047)

9、f-鄴一=一JHTEGER(0.-1S7,dHE-TEan.HM3tEllUHEiyD(iFspazal):sp仃千yi5.-perxcarcsu&fEmegr不mtSKill：fno#1-msapg4QU.Igi；,一.1第、iff.fJf.Tabl#IOXiS-1;UE卻。Gt*漢陽-山也1PUCCH睢c空鼠,flc5Rpedodicityan(fsubfrdnxcffwtconfiguritrc-nSRGOfifrgurationIndex/、_SRperiodicrty3崗”.RHHIKBITSRsubtrdmeoffset0-4Thi5-1410G-515-34如4T535-7440

10、“sT5-154sa%75155-f562以T551S71圖1:SR資源可以看出，sr-ConfigIndex和sr-PUCCH-ResourceIndex共同決定了一個唯一的SR資源。該資源只能分配給一個UE,但只有當UE有上行數(shù)據(jù)需要發(fā)送但卻沒有上行資源時才會被使用。圖2是SR周期配置的一個例子，3個UE的周期都為10ms,但在周期內(nèi)的子幀偏移各不相同。Sft州pwhjnityCoinfijiiratiorio-f（pprlodfriy口干T|1二&i，；1t，）VE1:sr-Conf-5UE2：8JE3ys*=12圖2:SR周期配置的一個例子當有上行數(shù)據(jù)到達并觸發(fā)SR時，UE會選擇分配給

11、它的下一個可用的SR資源來發(fā)送SR0如圖3所示：DawarTivstoterjninal,SR（ransmitledGrantrecurvedUL-SCHtransmissiotriggersschedulingrequesliSWbHity4-lSRintaivalSRpostibity4SRinervdi圖3:SR傳輸UE發(fā)送SR以后，無法確定eNodeB什么時候會下發(fā)ULGrant,這取決于上行資源的調(diào)度以及優(yōu)先級等。如果UE等待超時（超時時間由sr-ProhibitTimer決定）就重發(fā)SR,重發(fā)次數(shù)超過了SR的最大重傳次數(shù)（由IE：SchedulingRequestConfig的dsr-TransMax決定）就會觸發(fā)隨機接入。（見36.321的5.4.4節(jié)）通常，SR機制是針對整個UE的所有邏輯信道的，但在Rel-9中，LTE還提供了一種基于邏輯信道進行SR請求的機制。對于eNodeB創(chuàng)建的每一個邏輯信道，都有一個logicalChannelSR-Mask-r9字段，用于指定當該邏輯信道有新數(shù)據(jù)到達時，是否觸發(fā)SRo【參考資料】1