LTE-TDD的時序不同於LTE-FDD，並不是固定的n+4的關係，而是與上下行子幀配置UL/DL config引數相關，該引數由SIB1中的tdd-Config欄位下發到UE。

（圖1）

1.上行HARQ時序需要考慮的地方

本文主要從時序方面分析上行HARQ過程，主要包括以下幾個時序：

（1）eNB收到RA/SR/BSR後分配UL_GRANT，UE使用該UL_GRANT在PUSCH中傳送資料的時序；

（2）eNB在PHICH中傳送NACK，UE接收PHICH的時序；

（3）UE執行上行重傳的同步時序。

下面從時序角度具體分析各個過程。

2.eNB排程ULSCH資源，UE使用分配的UL_GRANT傳送UL_DATA的時序

這裡需要分兩種情況討論：

（1）UE通過隨機接入過程，向eNB傳送MSG1（隨機接入過程內容較多，以後專門另開博文介紹）。eNB在RAR中配置MSG3將要使用的UL_GRANT，後續UE在UL_GRANT指定的資源中傳送MSG3。具體流程如下。

（圖2）

因為MSG1發出後的第3個子幀，UE才開始接收RAR，因此上圖中標註的下行時間是（>=t+3），具體時間需要依賴於eNB實際排程。RAR的格式如下圖所示。

（圖3）

其中UL_GRANT佔用20個bits，具體內容是：

- Hopping flag – 1 bit

- Fixed size resource block assignment – 10 bits

- Truncated modulation and coding scheme – 4 bits

- TPC command for scheduled PUSCH – 3 bits

- UL delay – 1 bit

- CQI request – 1 bit

UL_delay欄位表示MSG3使用哪個時刻的PUSCH資源。如果UL_delay=0，那麼MSG3將在（m+p）的第一個上行子幀傳送，p>=6，如果UL_delay=1，那麼MSG3將在（m+p）的第一個上行子幀的下一個上行子幀傳送。比如當前上下行子幀配置是1（2、3、7、8號子幀是上行子幀），RAR在1號子幀下發，那麼如果UL_delay=0，則MSG3將在（m+p）=(1+6)=7號子幀中傳送；如果UL_delay=1，則MSG3將在（m+p）=(1+6)=7號子幀的下一個上行子幀，即8號子幀中傳送。

（圖4）

（2）eNB收到SR/BSR後分配UL_GRANT。協議36213中Table8-2規定了其中一種時序關係（下圖。注：上行重傳也要用到這個表），這種關係可以簡單稱之為（n+k）的關係。

（圖5）

即：n表示下行攜帶UL_GRANT（DCI0）的子幀號，k表示子幀時延，也就是上圖中二維表格中的焦點值，（n+k）%10的值表示UE需要在哪個子幀的PUSCH上傳送資料。比如上下行子幀配置1模式，eNB在1#子幀給UE下發了DCI0，UE將在（1+6）=7#子幀中上傳資料，而eNB也會在這個時刻點去解碼來自該UE的資料。 

特殊的，如果是上下行子幀配置0，除了支援（n+k）的關係外，還支援（n+7）的關係。因為上下行子幀配置0中有6個上行子幀，而下行子幀只有4個，那麼如果按照（n+k）的規則，勢必會浪費2個上行子幀。因此這裡引入了一個新的規則，就是（n+7）的規則。

在上下行子幀配置0的情況下，一個DCI0的資源既可以在（n+k）中使用，也可以在（n+7）中使用。比如UE在0號子幀收到了DCI0，那麼UE和eNB怎麼協商這種對應關係？UE怎麼知道它當前是需要使用（n+k）的資源還是需要使用（n+7）的資源？既然這種關係是不確定的，因此就沒有辦法在協議中事先規定好，只能通過唯一的途徑即DCI0來解決。因此，協議在DCI0中引入了一個叫UL_INDEX的欄位。UL_INDEX欄位只有2個bits，具體含義是：

高位元（MSB）=1、低位元（LSB）=0，表示互動雙方需要使用（n+k）的規則；

高位元（MSB）=0、低位元（LSB）=1，表示互動雙方需要使用（n+7）的規則；

高位元（MSB）=1、低位元（LSB）=1，表示互動雙方同時需要使用（n+k）以及（n+7）的規則，此時就是1個DCI0同時排程2個PUSCH的資源。另外，正如下圖描繪的，SR/BSR到UL_GRANT（DCI0）之間的時延，協議並沒有明確說明，因此由eNB側的實現決定。

（圖6）

3.eNB在PHICH中傳送NACK，UE接收PHICH的時序

eNB解碼資料之後，需要向UE回覆ACK或NACK。這個ACK/NACK資訊被封裝在PHICH的特定位置（以後會有博文詳細介紹PHICH中怎麼回覆ACK/NACK）。既然eNB要傳送PHICH，UE要接收PHICH，那麼雙方就需要事先知道PHICH傳送的時刻。這裡協議也給我們規定了這種時序關係，即（n+k）的關係。n是UE傳送PUSCH資料的上行子幀號，k是二維表格中的焦點值，如下圖所示。需要說明的是，這裡不再有（n+7）的關係了。

（圖7）

以配置1為例，eNB在2#子幀收到了PUSCH資料後，需要在（2+4）=6#子幀下發PHICH（含ACK或NACK）。那麼，除了這個規則，UE和eNB之間的互動就沒有其它需要考慮的問題了嗎？不妨再看看配置0的情況。

對於配置0來說，就稍微複雜些。比如eNB在3#和4#上行子幀都收到了PUSCH資料，按照上面表格中的（n+k）規則，都需要在0#下發PHICH。也就是說，eNB需要在同個子幀傳送兩個不同的PHICH序列，那麼UE怎麼來區分到底哪個是我3#子幀傳送的應答，哪個是4#子幀傳送的應答呢？畢竟eNB可能在3#子幀解碼資料失敗，而在4#子幀解碼資料成功，那麼兩個PHICH序列，其中1個攜帶的可能是NACK資訊，而另一個則是ACK資訊。

（圖8）

進一步分析子幀配置0會發現，這種2個不同PUSCH子幀對應同1個PHICH子幀的場景，只出現在子幀3、4之間，以及子幀8、9之間，如上圖所示。基於此，在計算PHICH位置的時候，協議巧妙的引入一個引數I_PHICH。當PHICH是反饋子幀4或子幀9的時候，I_PHICH等於1，否則等於0。由於這個I_PHICH引數是計算PHICH位置的（後面會有博文詳細介紹這個I_PHICH引數），不同的子幀和資源位置，能得到不同的PHICH序列，也就能區分指定的ACK/NACK資訊了。

總結如下：

（1）上下行子幀配置0

（圖9）

（2）上下行子幀配置1（其他配置的時序關係類似，不再給出）

（圖10）

4.UE執行上行重傳的同步時序

若eNB解碼PUSCH失敗，可能向UE反饋NACK。如果UE解碼到了NACK且沒有達到HARQ最大次數，就需要重傳PUSCH資料。無論是自適應重傳還是非自適應重傳，上行都是執行同步時序，即重傳的時機與新傳的時機存在著固定的時序關係。那麼協議怎麼來規定PUSCH資料重傳的時機問題呢？

對於上下行子幀配置不等於0的場景，上行新傳與重傳的子幀號始終是相同的，比如UE在3#子幀新傳了某個資料，那麼重傳將會在下個系統幀的3#子幀進行，如下圖所示。

（圖11）

對於子幀配置0來說，UE可能會在0子幀（或5子幀）收到2個不同的PHICH序列，分別對應上一次3#、4#子幀（或8#、9#子幀）的PUSCH資料應答，如果兩個子幀的PUSCH資料都需要重傳，那麼就需要在不同子幀的PUSCH上分別重傳3#、4#子幀（或8#、9#子幀）的PUSCH資料。

協議36213規定了：

如果0、5子幀收到的PHICH，對應的I_PHICH引數=0（即分別對應3、8子幀的PUSCH資料應答），那麼就按照Table 8-2表，按（n+k）的時序重傳，n是下行PHICH子幀號，k是表格中的焦點值。

如果0、5子幀收到的PHICH，對應的I_PHICH引數=1（即分別對應4、9子幀的PUSCH資料應答），那麼就按照（n+7）的時序重傳，n是下行PHICH子幀號。

另外，如果是1、6子幀收到的PHICH，採用的也是（n+7）的時序重傳。下圖給出了0、6子幀PHICH與HARQ重傳的時序示意圖。從圖中可以得到，在上下行子幀配置0的情況下，上行重傳的子幀號是前次傳輸的子幀的下一個上行子幀。如圖中所示的，前次傳輸的子幀是4號子幀，那麼重傳的子幀號是4號子幀的下一個上行子幀，即7號子幀。

（圖12）

本段開頭提到，eNB解碼PUSCH失敗，可能返回的是NACK，這裡意味著eNB也可能返回ACK。這種場景比較特殊，如資源碰撞導致。比如上下行子幀配置1，eNB在7#子幀有來自UE1的PUSCH資料，該PUSCH的PHICH需要在下個系統幀的1#下發。此時eNB可能有另一個UE2的MSG3資源需要排程。基於MSG3的（n+6）的規則，排程的是下個系統幀7#子幀的PUSCH資源，而這塊ULRB資源可能佔用了UE1的非自適應重傳資源位置，如果此時UE1的PUSCH解碼失敗，且沒有其他的ULRB分配給UE1，那麼eNB必須向UE1傳送ACK，以便阻止UE1的非自適應重傳，從而避免影響UE2的MSG3傳輸。

（圖13）

為了繼續讓該UE1重傳PUSCH，後續需要執行上行HARQ的自適應重傳過程。比如在1#給UE1下發DCI0（NDI不翻轉），重新在7#子幀分配PUSCH資源。

不用擔心eNB向UE反饋ACK導致PUSCH資料丟失的問題。因為協議36300中已經明確了（下表），如果UE只是收到了ACK，是不會丟棄資料的。

（圖14）

5.後文

在我們實際測試中發現，Aeroflex公司生產的TM500儀器，並沒有很好的測試子幀配置0的流程。如果有該公司的同事，希望可以私下交流下。

6.參考資料

（1）3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures

（2）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification

（3）3GPP TS 36.300 V9.10.0 (2012-12) Overall description

（4）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)

（5）http://www.sharetechnote.com