一種上行半靜態(tài)調(diào)度業(yè)務(wù)資源釋放方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種上行半靜態(tài)調(diào)度業(yè)務(wù)資源釋放方法，屬于移動通信技術(shù)領(lǐng)域。
【背景技術(shù)】
[0002]LTE系統(tǒng)中支持動態(tài)調(diào)度(DS，Dynamic Scheduling)和半靜態(tài)調(diào)度(SPS，Sem1-Persistent Scheduling)兩種調(diào)度模式，其中SPS是在DS基礎(chǔ)上為支持VOIP等分組大小相對固定、到達(dá)具有周期性特點(diǎn)的業(yè)務(wù)引入的。VOIP業(yè)務(wù)的生命周期通常由若干激活期和靜默期交替組成。在進(jìn)行SPS傳輸之前，eNodeB首先通過RRC信令發(fā)送SPS-Config信元，進(jìn)行SPS相應(yīng)配置，如周期、進(jìn)程、隱式釋放、HARQ反饋使用的資源等。然后需要使用SPS資源進(jìn)行傳輸時，eNodeB發(fā)送SPS激活TOCCH為UE實(shí)際分配所使用的SPS資源。通過SPS分配的資源在釋放之前周期性有效。上行SPS資源的釋放有隱式釋放和顯式釋放兩種。隱式釋放由UE發(fā)起，當(dāng)UE發(fā)現(xiàn)在SPS授權(quán)資源上發(fā)送的連續(xù)implicitReleaseAfter個MACPDU中都不包含任何MAC SDU時，立即釋放SPS分配的PUSCH資源。顯式釋放由eNodeB發(fā)起，eNodeB發(fā)送特殊格式的TOCCH，通知UE釋放當(dāng)前的SPS資源。
[0003]由于上行SPS隱式釋放是由UE發(fā)起的，eNodeB只能被動檢測到UE釋放了 SPS資源，且只有在連續(xù)收到implicitReleaseAfter個不包含任何MAC SDU的MAC PDU后才能確認(rèn)UE發(fā)起了隱式釋放。如果上行在傳輸過程中出現(xiàn)由于HARQ重傳導(dǎo)致的MAC PDU丟失，則eNodeB無法及時確認(rèn)UE是否發(fā)起了隱式釋放，導(dǎo)致UE側(cè)和eNodeB側(cè)對SPS資源是否有效理解不一致，造成額外的干擾和不必要的譯碼錯誤。
[0004]現(xiàn)有標(biāo)準(zhǔn)分別定義了隱式釋放和顯式釋放兩種技術(shù)，但對顯式釋放在什么場景下使用，隱式釋放和顯式釋放兩者如何結(jié)合沒有進(jìn)行說明。
[0005]現(xiàn)有技術(shù)中也未發(fā)現(xiàn)針對HARQ重傳失敗造成eNodeB不能及時準(zhǔn)確判斷UE是否發(fā)起了 SPS隱式釋放問題的解決方案。

【發(fā)明內(nèi)容】

[0006]為了克服現(xiàn)有技術(shù)的不足，本發(fā)明提供一種上行半靜態(tài)調(diào)度業(yè)務(wù)資源釋放方法。
[0007]—種上行半靜態(tài)調(diào)度業(yè)務(wù)資源釋放方法，含有以下步驟；當(dāng)由于HARQ重傳失敗等原因，eNodeB無法判斷在某個上行SPS資源上傳輸?shù)腗AC PDU中是否包含非零個MAC SDU’進(jìn)而無法判斷UE是否在上行SPS資源上傳輸了 implicitReleaseAfter個不含任何MACSDU的MAC PDU時，eNodeB主動發(fā)起顯式釋放命令，使UE和eNodeB都認(rèn)為分配的SPS上行資源已經(jīng)失效；若后續(xù)還有VOIP激活期數(shù)據(jù)包需要傳輸，UE可以再向eNodeB申請上行SPS資源。
[0008]兩個計數(shù)器NO和NI ;N0用于記錄最近連續(xù)收到的不包含任何MAC SDU的MAC PDU個數(shù)，NI用于記錄最近由于HARQ重傳失敗導(dǎo)致的數(shù)據(jù)包丟失的個數(shù)；根據(jù)UE只在發(fā)送連續(xù)發(fā)送implicitReleaseAfter個不含任何MAC SDU的MAC PDU后才發(fā)起上行SPS隱式釋放的特點(diǎn)，eNodeB每次收到包含非零個MAC SDU的MAC PDU后就將NO和NI清零，當(dāng)NO或NO與NI之和大于等于implicitReleaseAfter時,就判斷UE是否發(fā)起了隱式釋放以及是否需要發(fā)起顯示釋放信令；
[0009]還包括以下步驟:
[0010]步驟1、開始；
[0011]步驟2、判斷當(dāng)前時刻是否為UL SPS新數(shù)據(jù)或重傳數(shù)據(jù)解復(fù)用完畢時刻，若是，轉(zhuǎn)入步驟3，否則轉(zhuǎn)入步驟I;
[0012]步驟3、判斷是否收到CRC校驗(yàn)正確的MAC H)U，若是轉(zhuǎn)入步驟6，否則轉(zhuǎn)入步驟4 ;
[0013]步驟4、判斷相應(yīng)的傳輸塊是否已經(jīng)達(dá)到最大傳輸次數(shù)，若是，轉(zhuǎn)入步驟5，否則轉(zhuǎn)入步驟9 ；
[0014]步驟5、計數(shù)器NI++，轉(zhuǎn)入步驟9 ；
[0015]步驟6、判斷收到的MAC PDU中是否包含非零個MAC SDU，若是轉(zhuǎn)入步驟7，否則轉(zhuǎn)入步驟8 ；
[0016]步驟7、將計數(shù)器NO和NI置O，轉(zhuǎn)入步驟9 ；
[0017]步驟8、將計數(shù)器NO++，轉(zhuǎn)入步驟9 ；
[0018]步驟9、判斷計數(shù)器NO是否大于等于配置的隱式釋放門限implicitReleaseAfter,若是,轉(zhuǎn)入步驟10,否則轉(zhuǎn)入步驟11 ；
[0019]步驟10、可以確定UE側(cè)已經(jīng)發(fā)起了 UL SPS隱式釋放，eNodeB對維護(hù)的響應(yīng)ULSPS資源置為已釋放狀態(tài)，轉(zhuǎn)入步驟13 ；
[0020]步驟11、判斷計數(shù)器NO和NI之后是否大于等于配置的隱式釋放門限implicitReleaseAfter,若是轉(zhuǎn)入步驟12,否則轉(zhuǎn)入步驟13 ；
[0021]步驟12、由于HARQ重傳失敗造成丟包,eNodeB不能判斷UE是否發(fā)生隱式釋放,觸發(fā)eNB發(fā)起顯式UL SPS資源釋放流程，轉(zhuǎn)入步驟13 ；
[0022]步驟13;結(jié)束.
[0023]本發(fā)明的優(yōu)點(diǎn)是:當(dāng)由于HARQ重傳失敗等原因，eNodeB無法判斷在某個上行SPS資源上傳輸?shù)腗AC PDU中是否包含非零個MAC SDU’進(jìn)而無法判斷UE是否在上行SPS資源上傳輸了 implicitReleaseAfter個不含任何MAC SDU的MAC PDU時，eNodeB主動發(fā)起顯式釋放命令，使UE和eNodeB都認(rèn)為分配的SPS上行資源已經(jīng)失效。若后續(xù)還有VOIP激活期數(shù)據(jù)包需要傳輸，UE可以再向eNodeB申請上行SPS資源。
【附圖說明】
[0024]當(dāng)結(jié)合附圖考慮時，通過參照下面的詳細(xì)描述，能夠更完整更好地理解本發(fā)明以及容易得知其中許多伴隨的優(yōu)點(diǎn)，但此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本發(fā)明的一部分，本發(fā)明的示意性實(shí)施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定，如圖其中:
[0025]圖1為本發(fā)明的流程圖。
[0026]圖2為本發(fā)明的說明基站如何采用本發(fā)明方案進(jìn)行上行SPS資源釋放示意圖。
[0027]下面結(jié)合附圖和實(shí)施例對本發(fā)明進(jìn)一步說明。
【具體實(shí)施方式】
[0028]顯然，本領(lǐng)域技術(shù)人員基于本發(fā)明的宗旨所做的許多修改和變化屬于本發(fā)明的保護(hù)范圍。
[0029]實(shí)施例1:如圖1、圖2所示，
[0030]本發(fā)明是一種聯(lián)合使用隱式釋放和顯式釋放兩種方式進(jìn)行上行半靜態(tài)調(diào)度資源釋放的方法和裝置。所述方法和裝置，在需要進(jìn)行上行SPS資源釋放處理時刻，如果eNodeB無法確定UE是否發(fā)起了隱式釋放，則主動發(fā)起顯式釋放；如果可以確定UE發(fā)起了隱式釋放，則將上行SPS資源置為已釋放；設(shè)置兩個計數(shù)器NO和NI維護(hù)上行SPS資源釋放處理時亥IJ，該時刻為當(dāng)NO或NO與NI之和大于等于配置的隱式釋放門限時刻；N0用于記錄收到的不包含任何MAC SDU的MAC PDU個數(shù)，NI用于記錄HARQ重傳失敗的SPS授權(quán)的PUSCH傳輸次數(shù)，每次收到包含MAC SDU的MAC PDU之后，將NO和NI置O。
[0031]本發(fā)明提出了一種聯(lián)合使用隱式釋放和顯式釋放兩種方式進(jìn)行上行半靜態(tài)調(diào)度業(yè)務(wù)資源釋放的方法，其特征是在需要進(jìn)行上行SPS業(yè)務(wù)資源釋放處理時刻；
[0032]-如果由于HARQ重傳失敗等原因，eNodeB無法確定UE是否發(fā)起了隱式釋放的情況下，eNode