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