一種半靜態調度下行傳輸的實現方法
2023-09-10 16:54:20 3
專利名稱：：一種半靜態調度下行傳輸的實現方法
技術領域：
：本發明涉及LTE技術，特別涉及一種半靜態調度下行傳輸的實現方法。
背景技術：
：為了應對寬帶接入技術的挑戰，同時為了滿足新型業務的需求，國際標準化組織3GPP在2004年底啟動了其長期演進(LTE)技術的標準化工作。LTE系統採用下行正交頻分多址接入(OFDMA)、上行單載波頻分復用(SC-FDMA)的接入方式，同時引入了多輸入輸出(MIMO)技術，很大程度地提高了系統的傳輸能力，有效地抵抗了多徑幹擾，並且，可以靈活地配置不同的帶寬。在20M帶寬的情況下，LTE的目標是達到上行50Mbps、下行100Mbps的峰值傳輸速率。另外，LTE的演進目標為全IP的通信網絡，支持豐富的多媒體、IP語音(VoIP,VoiceoverIP)、數據下載等業務。其中，VoIP也是LTE系統一個主推的特色業務。LTE的特點在於高速，而VoIP業務是低速業務，但是VoIP業務的數據到達時間比較均勻固定，從而對於這類特殊業務，LTE系統採用了一種在以往的通信系統中所沒有的調度方式——半靜態調度(SPS，semi-persistentscheduling)方式，來控制這類業務的傳輸。LTE系統中，半靜態調度是指基站給特定業務的數據包分配固定的時頻資源，而該特定業務的數據包周期性的在該固定的時頻資源位置傳輸，即在預分配的資源上傳輸，不需額外的物理下行控制信道(PDCCH，PhysicalDownlinkControlChannel)調度信息。通過一個半靜態配置好的傳輸周期，一次調度以後，用戶終端(UE)即按照配置的周期和初始調度的資源進行5數據的發送和接收。如，對於VoIP業務而言，目前下行傳輸的默認配置周期為20ms,使用半靜態調度方式傳輸VoIP業務，假設業務初始調度是在資源編號為n的資源上，則UE會每20ms在同樣的資源n上進行發送/接收動作。對於半靜態調度方案而言，除了調度算法以外，最重要的步驟有三步，分別為半靜態調度傳輸的啟動、半靜態調度傳輸的重傳過程以及半靜態調度傳輸的釋放。由於半靜態調度是一次配置、多次按照配置進行傳輸的方式，所以對於配置信息傳輸的準確性有很高的要求，以避免錯誤地接收配置信息而之後的每次傳輸都對其他用戶造成嚴重幹擾的情況。目前的LTE標準中明確指出半靜態調度的啟動是通過半靜態調度傳輸-小區無線網絡臨時標識(SPS-C-RNTI)掩碼的分組數據控制信道(PDCCH)來指示的。為了提高可靠性，還規定了PDCCH中用於啟動半靜態調度的一些固定的比特位。其中包括下行半靜態調度傳輸的PDCCH中，混合自動重傳請求(HARQ)進程ID必須設置為全O。為了提高半靜態調度的可靠性而採取的上述固定PDCCH比特位的方法，同樣也帶來一些問題。對於下行傳輸而言，HARQ進程號是通過PDCCH來指示的。即使演進基站(eNB)自己維護了HARQ進程，但是，由於半靜態調度的啟動過程中eNB並未向UE給出相應的HARQ進程號，使得UE無法同步地獲知當前半靜態調度所使用的HARQ進程，如此，導致在存在重傳的情況下，UE無法對重傳下來的數據進行軟合併。為了解決對重傳的數據進行軟合併的問題，3GPP提出了為半靜態調度預留一些HARQ進程的方法。即只要是半靜態調度，eNB發送的用於啟動半靜態調度傳輸的PDCCH中就不需要攜帶HARQ進程的相關信息，UE自動地將預留的HARQ進程作為半靜態傳輸的HARQ進程，並據此進行相關的軟合併。然而，對於下行半靜態調度而言，預留HARQ進程會導致UE下行峰值6速率的降低。這是因為半靜態調度算法主要是為一些低速率、數據包到達間隔比較固定的業務設計的，目前主要面向的是VoIP業務，但是，LTE的峰值速率主要是靠突發性的動態業務來實現，因此，為半靜態調度預留HARQ進程會使UE的下行峰值速率降低n/m。這裡，n表示預留的HARQ進程數，m表示最大的HARQ進程數。原則上來講，為半靜態調度預留的HARQ進程數應該剛剛滿足其需求，這樣既能夠保證半靜態傳輸的HARQ，又不會過多地影響UE的下行峰值速率。目前，LTE標準中規定，採用無線資源控制(RRC)消息為UE配置下行半靜態調度所預留的HARQ進程數。以頻分復用(FDD)為例，採用現有技術，如果僅為半靜態調度預留一個HARQ進程，則會因為時間不足而導致每個UE的下行數據最多只能進行兩次重傳。這主要是因為第一次傳輸和下一次重傳之間至少需要間隔基站往返時延(RTT)ms,即對FDD而言是8ms的時間，而VoIP的半靜態調度周期為20ms，在20ms內，只能進行2次重傳。如圖1所示數據包l、數據包2和數據包3分別是對應於第一個、第二個和第三個半靜態調度傳輸周期的數據包；重傳包1是當數據包1沒有傳輸正確時，eNB重傳的數據包1;UE預留了一個HARQ進程用於重傳，進程ID為x。假設數據包1的第一次傳輸沒有傳輸正確，其經過兩次重傳之後，第二個半靜態調度的數據包2已經發送，則對於在數據包2和數據包3之間重傳的重傳包l,UE將無法將其與數據包1合併。這是因為當UE接收到數據包2後，將清空半靜態調度預留的HARQ進程中的緩存數據，並將新接收到的數據包2存入緩存。這樣不僅導致數據包1的重傳次數受到限制從而影響傳輸準確性，並且，eNB在數據包2和數據包3之間進行數據包1的重傳還有可能帶來HARQ合併失敗。同樣的問題，在時分復用(TDD)LTE系統中會更為明顯和嚴重。目前，3GPP傾向於預留2個或2個以上的HARQ進程，如圖2所示數據包l、數據包2和數據包3分別是對應於第一個、第二個和第三個半靜態調度傳輸周期的數據包；重傳包1是當數據包1沒有傳輸正確時，eNB重傳的數據包l，重傳包2是當數據包2沒有傳輸正確時，eNB重傳的數據包2;UE預留了兩個HARQ進程用於重傳，進程ID分別為x和y。假設數據包1的第一次傳輸沒有傳輸正確，其第二次重傳的數據包在重傳時，第二個半靜態調度的數據包2已經發送；並且，假設lt據包2的第一次傳輸也沒有傳輸正確，那麼，在數據包2和數據包3之間重傳的將有兩個數據包重傳包1和重傳包2。對於這兩個重傳的數據包，UE可以根據進程ID將其區分開來，並順利進行合併。如此，通過預留2個或者更多的HARQ進程，並按照一定的規則進行循環使用，則重傳通過PDCCH指示相應的HARQ進程號，可以避免圖1所示現有技術的問題。考慮到大部分情況下，半靜態調度的數據包不需要傳輸到最大次數就可以正確傳輸，同時，出於節省進程資源的考慮，LTE標準目前支持動態業務和半靜態業務的調度共享資源的方式。即如果系統為半靜態業務預留了多個HARQ進程，並且對應於某一個進程的半靜態業務已經傳輸正確，在下次使用該進程傳輸新的半靜態數據之前，可以在該進程上調度動態業務的數據，但是，一旦到達半靜態調度周期，該進程就被收回用作半靜態調度傳輸，而不管當前的動態業務是否已經傳輸正確。上述現有的預留多個HARQ進程用於半靜態調度的下行傳輸方法，存在:io下缺點1、LTE作為3G系統的長期演進，主推的一個功能即為高速的傳輸性能。對於VoIP而言，其典型速率在1020Kbps範圍內，而LTE在20M帶寬的下行峰值速率為100Mbps，因此，半靜態調度這種業務的傳輸速率相對於峰值速率幾乎可以忽略，而預留n個(n>2)HARQ進程會使LTE用戶的下行峰值速率降低n/m。尤其是對於TDD模式而言，上下行子幀配置為0的情況，可能造成峰值速率損失一半或者更多。2、對於預留多少個HARQ進程，目前協議規定由RRC配置，即需要額外的3bitRRC信令開銷來配置預留多少個HARQ進程。3、上述現有半靜態調度和動態調度共享HARQ進程的方案，增加了調度的複雜度和不可控因素。
發明內容有鑑於此，本發明的主要目的在於提供一種半靜態調度下行傳輸的實現方法，以避免HARQ合併失敗，降低半靜態調度下行傳輸的HARQ機制對LTE下行峰值速率的影響，節省RRC的信令開銷，以及在保證下行動態數據傳輸速率的同時降低下行調度的複雜度。為達到上述目的，本發明的技術方案具體是這樣實現的一種半靜態調度下行傳輸的實現方法，該方法包括A、演進基站為用戶終端預留一個混合自動重傳請求HARQ進程用於半靜態調度下行傳輸；B、演進基站將半靜態調度的數據包進行綁定傳輸，使每個數據包在其對應的傳輸周期中的最大可傳輸次數大於等於四次。較佳地，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包連續發送兩次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送兩次。對應於上述較佳方案，該方法可以進一步包括用戶終端在所述第一次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第二次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。9較佳地，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包發送一次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送三次。對應於上述較佳方案，該方法可以進一步包括用戶終端在所述第一次傳輸中接收一次數據包，並對所述數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第二次傳輸中連續接收三次數據包，並對所述三次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。較佳地，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包發送三次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包發送一次。對應於上述較佳方案，該方法可以進一步包括用戶終端在所述第一次傳輸中連續接收三次數據包，並對所述三次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第二次傳輸中接收一次數據包，並對所述數據包進行解碼，如果解碼正確，則向演進基站返回確i人信息，否則，向演進基站返回非確認信息。較佳地，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包發送一次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送兩次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第三次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送兩次。對應於上述較佳方案，該方法可以進一步包括用戶終端在所述第一次傳輸中接收一次數據包，並對所述數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確iU言息；用戶終端在所述第二次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果至少解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第三次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼。由上述技術方案可見，本發明中，演進基站通過將半靜態調度的數據包進行綁定傳輸，並保證每個數據包在其對應的傳輸周期中的最大可傳輸次數大於等於四次，使得演進基站只需為用戶終端預留一個HARQ進程用於半靜態調度下行傳輸即可。這是因為傳輸次數大於等於四次可以認為已經能夠將數據包正確傳輸，而本發明對同一數據包的多次傳輸均在該數據包所對應的傳輸周期中進行，對應於某一傳輸周期的數據包不會出現在該傳輸周期的下一傳輸周期中，因此>即使只預留一個HARQ進程也能夠使用戶終端分辨出當前接收到的數據包屬於哪一個傳輸周期，不會使對應於不同傳輸周期的數據包之間混淆，從而避免了HARQ合併失敗。由於採用本發明實現半靜態調度下行傳輸只需預留一個HARQ進程，使得半靜態調度下行傳輸中的HARQ機制對LTE下行峰值速率的影響降至最低。並且，採用本發明實現半靜態調度下行傳輸只需預留一個HARQ進程，無需通過RRC信令配置預留多少個HARQ進程，從而節約了RRC的信令開銷。此外，由於採用本發明實現半靜態調度下行傳輸只需預留一個HARQ進程，無需將該預留的HARQ進程與動態業務共享使用，因此，無需涉及複雜的調度算法進行相應的資源調度，在保證下行動態數據傳輸速率的同時降低了下行調度的複雜度。1圖1為現有為下行半靜態調度預留1個HARQ進程的數據重傳示意圖；圖2為現有為下行半靜態調度預留2個HARQ進程的數據重傳示意圖。圖3為本發明實施例一中對半持續調度的下行數據包進行綁定傳輸的示意圖4為本發明實施例二中對半持續調度的下行數據包進行綁定傳輸的示意圖5為本發明實施例三中對半持續調度的下行數據包進行綁定傳輸的示意圖6為本發明實施例四中對半持續調度的下行數據包進行綁定傳輸的示意圖7為在TDD模式、上下行子幀配置為0的情況下採用本發明實施例圖8為在TDD模式、上下行子幀配置為1的情況下採用本發明實施例二中的方法對半持續調度的下行數據包進行綁定傳輸的示意圖9為在TDD模式、上下行子幀配置為6的情況下採用本發明實施例二中的方法對半持續調度的下行數據包進行綁定傳輸的示意圖10為將本發明實施例二應用於下行半靜態調度傳輸過程的傳輸流程示意圖。具體實施例方式為使本發明的目的、技術方案及優點更加清楚明白，以下參照附圖並舉實施例，對本發明作進一步詳細說明。本發明的主要思想是演進基站將半靜態調度的數據包進行綁定傳輸，並保證每個數據包在其對應的傳輸周期中的最大可傳輸次數大於等於四次，使得演進基站只需為每一個用戶終端預留一個HARQ進程用於半靜態調度下行傳輸即可。基於本發明上述主要思想，本發明提供了四種將半靜態調度的下行數據包進行綁定傳輸的方式，下面通過實施例一至實施例四分別予以詳細說明。由於本發明涉及下行傳輸，如無特殊說明，本發明所述的數據包均為下行數據包。實施例一本實施例中，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將該數據包連續發送兩次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將該數據包也連續發送兩次。也就是說本實施例中，演進基站的兩次傳輸都採用綁定傳輸的方式。在UE側，UE在第一次傳輸中連續接收兩次數據包，並對這兩次接收的數據包進行合併，然後對合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息(ACK)，否則，向演進基站返回非確認信息(NACK);如果存在第二次傳輸，那麼UE在第二次傳輸中也是連續接收兩次數據包，並對這兩次接收的數據包進行合併，然後對合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。也就是說，UE並非每接收到一個數據包就對其進行解碼，並產生相應的ACK/NACK信息，而是在接收到每一次綁定傳輸的兩個數據包之後才進行合併、解碼，並根據解碼結果產生ACK/NACK信息。圖3為本發明實施例一中對半持續調度的下行數據包進行綁定傳輸的示意圖。參見圖3:數據包l、數據包2和數據包3分別是對應於第一個、第二個和第三個半靜態調度傳輸周期的數據包；重傳包1和重傳包2分別是數據包1和數據包2的重傳數據包；UE預留了一個HARQ進程用於重傳，進程ID為x。通過圖3可以看到，每一個半靜態調度的數據包的最大可傳輸次數為四次，這與現有技術中預留兩個和以上的HARQ進程的傳輸效果相同。才艮據現有相關參考文獻，VoIP發生重傳的概率為10%-15%，在此，簡單地假設每次傳輸都以上述概率發生重傳，可以按照(1)式計算傳輸次數的期望值ax(l-(error一rate)a)+bx(error—rate)a(1)(1)式中，error—rate表示重傳的概率；a表示第一次傳輸中，需要傳輸的數據包的次數，其發生的概率為1-(error—rate)a;b表示在第一次傳輸失敗，發生第二次傳輸時，需要傳輸的數據包的次數，由於必須是在第一次傳輸失敗的情況下，才會進行b次數據包的傳輸，因此，其發生的概率為(error一rate)a。對應到本實施例，a的取值為2,b的取值為4,error—rate的取值範圍為10%~15%，因此，本實施例中，傳輸次數的期望值為2.02-2.045次。實施例二本實施例中，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站僅將該數據包發送一次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將該數據包連續發送三次。也就是說本實施例中，演進基站僅在第二次傳輸時採用綁定傳輸的方式。在UE側，UE在第一次傳輸中接收一次數據包，並即刻對該數據包進行解碼，如果解碼正確，則向演進基站返回ACK，否則，向演進基站返回NACK;如果存在第二次傳輸，那麼UE在第二次傳輸中連續接收三次數據包，並對這三次接收的數據包進行合併，然後對合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。也就是說，本實施例中，UE在接收到演進基站第一次傳輸的數據包時，即刻對其進行解碼，並產生相應的ACK/NACK信息，而在第二次傳輸時，是在接收到綁定傳輸的三個數據包之後才進行合併、解碼，並根據解碼結果產生ACK/NACK信息。圖4為本發明實施例二中對半持續調度的下行數據包進行綁定傳輸的示意圖。參見圖4:數據包l、數據包2和數據包3分別是對應於第一個、第二個和第三個半靜態調度傳輸周期的數據包；重傳包1和重傳包2分別是數據包1和數據包2的重傳數據包；UE預留了一個HARQ進程用於重傳，進程ID為x。通過圖4可以看到，每一個半靜態調度的數據包的最大可傳輸次數為四次，這與現有技術中預留兩個和以上的HARQ進程的傳輸效果相同。按照(1)式計算本實施例中傳輸次數的期望值，a的取值為1，b的取值為4，error_rate的取值範圍為10%~15%,因此，本實施例中，傳輸次數的期望值為1.3~1.5次。實施例三本實施例中，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將該數據包連續發送三次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將該數據包僅發送一次。也就是說本實施例中，演進基站僅在第一次傳輸時採用綁定傳輸的方式。在UE側，UE在第一次傳輸中連續接收三次數據包，並對這三次接收的數據包進行合併，然後對合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回ACK，否則，向演進基站返回NACK;如果存在第二次傳輸，那麼UE在第二次傳輸中僅接收一次數據包，並即刻對該數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。也就是說，本實施例中，UE在接收到演進基站第一次綁定傳輸的三個數據包時，才對這三個數據包進行合併、解碼，並產生相應的ACK/NACK信息，而在第二次傳輸時，由於只有一個數據包，接到該數據包就可以進行解碼，並根據解碼結果產生ACK/NACK信息。圖5為本發明實施例三中對半持續調度的下行數據包進行綁定傳輸的示意圖。參見圖5:數據包l、數據包2和數據包3分別是對應於第一個、第二個和第三個半靜態調度傳輸周期的數據包；重傳包l和重傳包2分別是數據包l和數據包2的重傳數據包；UE預留了一個HARQ進程用於重傳，進程ID為x。通過圖5可以看到，每一個半靜態調度的數據包的最大可傳輸次數為四次，這與現有技術中預留兩個和以上的HARQ進程的傳輸效果相同。按照(1)式計算本實施例中傳輸次數的期望值，a的取值為3，b的取值為4，error_rate的取值範圍為10%~15%,因此，本實施例中，傳輸次數的期望值為3.0010~3.0034次。實施例四本實施例中，對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站僅將該數據包發送一次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將該數據包連續發送兩次，如果演進基站仍然沒有接收到用戶終端返回的確認信息，則進行第三次傳輸，在第三次傳輸時，演進基站將該數據包連續發送兩次。也就是說本實施例中，演進基站在第二次傳輸和第三次傳輸時採用綁定傳輸的方式。在UE側，UE在第一次傳輸中接收一次數據包，並即刻對該數據包進行解碼，如果解碼正確，則向演進基站返回ACK，否則，向演進基站返回NACK;如果存在第二次傳輸，那麼UE在第二次傳輸中連續接收兩次數據包，並對這兩次接收的數據包進行合併，然後對合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；如果存在第三次傳輸，那麼UE在第三次傳輸中連續接收兩次數據包，並對這兩次接收的數據包進行合併，然後對合併得到的數據包進行解碼，這一次，UE不產生相應的ACK/NACK信息，演進基站也認為該數據包已經達到最大傳輸次數。圖6為本發明實施例四中對半持續調度的下行數據包進行綁定傳輸的16示意圖。參見圖6:數據包l、數據包2和數據包3分別是對應於第一個、第二個和第三個半靜態調度傳輸周期的數據包；重傳包1和重傳包2分別是數據包1和數據包2的重傳數據包；UE預留了一個HARQ進程用於重傳，進程ID為x。通過圖6可以看到，每一個半靜態調度的數據包的最大可傳輸次數為五次，比現有技術中預留兩個和以上的HARQ進程的最大可傳輸次數還要多一次。對應於本實施例，可以按照(2)式計算傳輸次數的期望1x(l—error—rate)+3x(error—rate-Orror—rate)3)+5x(error—rate)3(2)根據error—rate的取值範圍10%~15%,可以得出本實施例中，傳輸次數的期望值為1.202-1.3067次。根據上面的分析，我們可以看出首先，實施例二和實施例四在平均傳輸次數上具有比較明顯的優勢。其次，在實施例二和實施例四之間，二者具有相近的平均傳輸次數，但是，一方面，由於LTE下行傳輸為異步HARQ,而實施例四對於重傳的時間限制比較嚴格，將會導致調度靈活性的損失；另一方面，實施例四在第三次傳輸中UE不反饋ACK/NACK信息，這對UE和eNB的行為改變較大。鑑於以上原因，在本發明所提供的諸實施例中，實施例二應當是下行半靜態調度傳輸的最佳實現方案。對比目前LTE協議版本中的方案，其平均傳輸次數的數學期望為1.11111.1764次，本發明實施例二為1.3-1.5次，可見，實施例二在節省HARQ進程的同時並不會帶來嚴重的系統資源浪費。以上實施例--實施例四中的圖3~圖6以FDD才莫式為例，示意性it明了本發明對半持續調度的下行數據包如何進行綁定傳輸。本發明同樣也適用於TDD模式，下面以實施例二所提供的方案為例，結合附圖，舉例進行說明。tableseeoriginaldocumentpage18設演進基站調度了子幀10、子幀ll和子幀15給該UE,那麼，在第二次傳輸中，重傳包1將在子幀10、子幀11和子幀15中連續傳輸三次，UE將在對應的時間連續接收三次數據包。假設將本發明實施例二所提供的技術方案應用於上下行子幀配置為1的LTETDD系統中，將可以得到如圖8所示的綁定傳輸示意圖。參見圖8:數據包1和數據包2分別是對應於第一個和第二個半靜態調度傳輸周期的數據包；重傳包1是數據包1的重傳數據包。假設演進基站分配給本例中UE使用的下行半持續調度資源對應為子幀0、子幀20、子幀40……。在第一個半靜態調度傳輸周期的第一次傳輸中，數據包1將在子幀0中傳輸。根據實施例二所提供的方法，UE接收到數據包1之後將進行解碼，假設解碼不正確，UE可以在子幀4中向eNB返回NACK信息。eNB收到該NACK信息後，確定需要進行第二次傳輸，因此，需要將子幀5~子幀19之間的連續三個下行子幀調度給該UE使用。假設演進基站調度了子幀911給該UE,那麼，在第二次傳輸中，重傳包1將在子幀9~11中連續傳輸三次，UE將在對應的時間連續接收三次數據包。假設將本發明實施例二所提供的技術方案應用於上下行子幀配置為6的LTETDD系統中，將可以得到如圖9所示的綁定傳輸示意圖。參見圖9:數據包1和數據包2分別是對應於第一個和第二個半靜態調度傳輸周期的數據包；重傳包1是數據包1的重傳數據包。假設演進基站分配給本例中UE使用的下行半持續調度資源對應為子幀0、子幀20、子幀40......。在第一個半靜態調度傳輸周期的第一次傳輸中，數據包1將在子幀0中傳輸。根據實施例二所提供的方法，UE接收到數據包1之後將進行解碼，假設解碼不正確，UE可以在子幀4中向eNB返回NACK信息。eNB收到該NACK信息後，確定需要進行第二次傳輸，因此，需要將子幀5~子幀19之間的連續三個下行子幀調度給該UE使用。假設演進基站調度了子幀199~11給該UE，那麼，在第二次傳輸中，重傳包1將在子幀9~11中連續傳輸三次，UE將在對應的時間連續接收三次數據包。將本發明實施例二提供的方法應用於下行半靜態調度傳輸過程中，可以得到如圖IO所示的傳輸流程。參見圖10，該傳輸流程從演進基站的角度進行描述，包括以下步驟步驟1001:進行RRC配置。如前所述，採用本發明只需預留一個HARQ進程即可，無需通過RRC配置來告知UE預留多少個HARQ進程，因此，本步驟中的RRC配置只需按照現有技術執行除配置預留多少個HARQ進程之外的操作即可。通過PDCCH指示UE將要進行下行半持續調度傳輸。初始化變量n，置n-0。進行第n個數據包的第一次傳輸。判斷是否收到ACK,如果收到，執行步驟1008，否則，執進行第n個數據包的三次綁定傳輸。判斷是否收到ACK，如果收到，執行步驟1008,否則，執步驟1002步驟1003步驟1004步驟1005行步驟1006。步驟1006步驟畫7行步驟1009。步驟1008:得出第n個數據包傳輸正確的結論，執行步驟1010。步驟1009:得出第n個數據包傳輸失敗的結論，執行步驟1010。步驟1010:n自力口1。步驟1011:判斷全部數據包是否傳輸完畢，如果尚未傳輸完畢，返回步驟1004，如果傳輸完畢，結束本傳輸流程。由於本發明各實施例均基於同一主要思想，且前面已對各實施例已進行詳細介紹，因此，以上舉例僅以實施例二為例進行說明，本發明其它實施例參照實施即可。由上述實施例可見，本發明中，演進基站通過將半靜態調度的數據包進行綁定傳輸，並保證每個數據包在其對應的傳輸周期中的最大可傳輸次數大於等於四次，使得演進基站只需為用戶終端預留一個HARQ進程用於半靜態調度下行傳輸即可。這是因為傳輸次數大於等於四次可以認為已經能夠將數據包正確傳輸，而本發明對同一數據包的多次傳輸均在該數據包所對應的傳輸周期中進行，對應於某一傳輸周期的數據包不會出現在該傳輸周期的下一傳輸周期中，因此，即使只預留一個HARQ進程也能夠使用戶終端分辨出當前接收到的數據包屬於哪一個傳輸周期，不會使對應於不同傳輸周期的數據包之間混淆，從而避免了HARQ合併失敗。由於採用本發明實現半靜態調度下行傳輸只需預留一個HARQ進程，使得半靜態調度下行傳輸中的HARQ機制對LTE下行峰值速率的影響降至最低。並且，採用本發明實現半靜態調度下行傳輸只需預留一個HARQ進程，無需通過RRC信令配置預留多少個HARQ進程，從而節約了RRC的信令開銷。此外，由於採用本發明實現半靜態調度下行傳輸只需預留一個HARQ進程，無需將該預留的HARQ進程與動態業務共享使用，因此，無需涉及複雜的調度算法進行相應的資源調度，在保證下行動態數據傳輸速率的同時降低了下行調度的複雜度。以上所述僅為本發明的較佳實施例而已，並非用於限定本發明的保護範圍。凡在本發明的精神和原則之內所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。2權利要求1、一種半靜態調度下行傳輸的實現方法，其特徵在於，該方法包括A、演進基站為用戶終端預留一個混合自動重傳請求HARQ進程用於半靜態調度下行傳輸；B、演進基站將半靜態調度的數據包進行綁定傳輸，使每個數據包在其對應的傳輸周期中的最大可傳輸次數大於等於四次。2、根據權利要求1所述的方法，其特徵在於，所述B包括對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包連續發送兩次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述lt據包連續發送兩次。3、根據權利要求2所述的方法，其特徵在於，該方法進一步包括用戶終端在所述第一次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第二次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。4、根據權利要求1所述的方法，其特徵在於，所述B包括對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包發送一次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送三次。5、根據權利要求4所述的方法，其特徵在於，該方法進一步包括用戶終端在所述第一次傳輸中接收一次數據包，並對所述數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信白.用戶終端在所述第二次傳輸中連續接收三次數據包，並對所述三次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息。6、根據權利要求1所述的方法，其特徵在於，所述B包括對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包發送三次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包發送一次。7、根據權利要求6所述的方法，其特徵在於，該方法進一步包括用戶終端在所述第一次傳輸中連續接收三次數據包，並對所述三次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第二次傳輸中接收一次數據包，並對所述數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信ir8、根據權利要求1所述的方法，其特徵在於，所述B包括對於每一個半靜態調度的數據包，在第一次傳輸時，演進基站將所述數據包發送一次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第二次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送兩次，如果演進基站沒有接收到用戶終端返回的確認信息，則進行第三次傳輸，在第二次傳輸時，演進基站將所述數據包連續發送兩次。9、根據權利要求8所述的方法，其特徵在於，該方法進一步包括用戶終端在所述第一次傳輸中接收一次數據包，並對所述數據包進行解碼，如果解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第二次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼，如果至少解碼正確，則向演進基站返回確認信息，否則，向演進基站返回非確認信息；用戶終端在所述第三次傳輸中連續接收兩次數據包，並對所述兩次接收的數據包進行合併，對所述合併得到的數據包進行解碼。全文摘要本發明公開了一種半靜態調度下行傳輸的實現方法，該方法中，eNB僅為每一個用戶終端預留一個HARQ進程用於半靜態調度下行傳輸，並將半靜態調度的數據包進行綁定傳輸，使每個數據包在其對應的傳輸周期中的最大可傳輸次數大於等於四次。應用本發明可以在保證HARQ的正常合併的同時，將半靜態調度下行傳輸的HARQ機制對LTE下行峰值速率的影響降至最低，並節省RRC的信令開銷，以及在保證下行動態數據傳輸速率的同時降低下行調度的複雜度。文檔編號H04W28/04GK101646202SQ20091009176公開日2010年2月10日申請日期2009年8月25日優先權日2009年8月25日發明者煒白申請人:普天信息技術研究院有限公司