本公開涉及一種在移動通信網(wǎng)絡(luò)中處理分組丟失的方法和裝置。更具體地，本公開涉及處理在使用長期演進(LTE)網(wǎng)絡(luò)的語音呼叫過程中出現(xiàn)的分組丟失的方法和裝置。

背景技術(shù)：

移動通信系統(tǒng)已經(jīng)發(fā)展成在保持用戶移動性的同時提供通信。隨著相關(guān)技術(shù)的迅速發(fā)展，移動通信系統(tǒng)能夠提供高速數(shù)據(jù)通信業(yè)務(wù)以及語音通信。近來，在第三代合作伙伴計劃(3GPP)中已將高級長期演進(LTE-A)作為下一代移動通信系統(tǒng)之一進行研究。

LTE(下文的使用中包括LTE-A)是僅針對數(shù)據(jù)通信定義的一種通信標(biāo)準(zhǔn)，其并不包括與語音呼叫相關(guān)聯(lián)的獨立技術(shù)。相反，由于通信速率或帶寬較高，通過LTE傳送語音(VoLTE)使得與呼叫相關(guān)聯(lián)的信息能夠通過因特網(wǎng)發(fā)送。像因特網(wǎng)電話或移動信使應(yīng)用所使用的因特網(wǎng)協(xié)議傳送語音(VoIP)一樣，VoLTE是一種用于通過數(shù)據(jù)網(wǎng)絡(luò)以壓縮形式發(fā)送或接收語音數(shù)據(jù)的技術(shù)。相對于VoIP而言，VoLTE基于網(wǎng)絡(luò)狀況調(diào)整傳輸速率并且優(yōu)先保證呼叫質(zhì)量以便在任意狀況下都能夠保持呼叫連接。

一般來說，對于與語音呼叫相關(guān)聯(lián)的連接來說更為重要的是在呼叫期間保持持續(xù)的連接而不是聲音的總體質(zhì)量。通常，連接狀態(tài)和聲音質(zhì)量處于折衷的關(guān)系。在例如瀏覽網(wǎng)頁的因特網(wǎng)服務(wù)中，斷開一分鐘和/或斷斷續(xù)續(xù)的連接可能并不會對服務(wù)質(zhì)量造成令人不快的影響。但是，在實施語音服務(wù)時連接狀態(tài)差可能直接地且不理想地影響服務(wù)質(zhì)量。因此需要一種防止語音服務(wù)中的質(zhì)量惡化的技術(shù)。

上述信息僅作為背景信息呈現(xiàn)以幫助對本公開的理解。對于以上任何內(nèi)容是否可作為關(guān)于本公開的現(xiàn)有技術(shù)，既不做出判斷也不做出主張。

技術(shù)實現(xiàn)要素：

【技術(shù)問題】

本公開的各方面至少解決了上述提及的問題和/或缺點，并且至少提供了以下所說明的優(yōu)點。據(jù)此，本公開的一方面是提供響應(yīng)于分組丟失用于保持語音呼叫的方法和裝置。

本公開的另一方面是提供在通過長期演進(LTE)網(wǎng)絡(luò)進行語音呼叫處理中，通過防止由于語音分組的大量丟失引起解密失敗而導(dǎo)致的呼叫斷開來保持語音呼叫的方法和裝置。

【問題的解決方案】

根據(jù)本公開的一方面，提供了一種在移動通信網(wǎng)絡(luò)中在分組丟失的情況下處理呼叫的方法。本方法包括從用戶設(shè)備(UE)接收上行鏈路分組，基于第一超幀號(HFN)解密分組，在基于第一HFN解密失敗發(fā)生時將HFN值從第一HFN改變?yōu)榈诙﨟FN，并且基于第二HFN進一步解密分組。

關(guān)于本公開的另一方面，提供了一種被配置成在移動通信網(wǎng)絡(luò)中在分組丟失的情況下建立呼叫的增強節(jié)點B(eNB)的裝置。該裝置包括收發(fā)機單元和分組處理控制器，該收發(fā)機單元被配置成執(zhí)行與至少一個網(wǎng)絡(luò)節(jié)點通信，該分組處理控制器被配置成：通過收發(fā)機單元接收來自UE的上行鏈路分組，基于第一HFN解密該分組，在基于第一HFN解密失敗的情況下將HFN值從第一HFN改變?yōu)榈诙﨟FN，并基于第二HFN進一步解密該分組。

對于那些本領(lǐng)域技術(shù)人員來說，本公開的其它方面、優(yōu)點和突出特征將通過以下詳細的說明變得顯然，該詳細說明結(jié)合附圖揭示了本公開的各種實施例。

【本發(fā)明的有益效果】

根據(jù)本公開的一方面，提供了一種在通過長期演進(LTE)網(wǎng)絡(luò)進行語音呼叫處理中，防止由于語音分組的大量丟失引起解密失敗而導(dǎo)致的呼叫斷開來保持語音呼叫的方法和裝置。

附圖說明

從結(jié)合附圖的以下說明，本公開的特定實施例的上述和其它方面、特征以及優(yōu)點將變得明顯，其中：

圖1是示出依據(jù)本公開的實施例的長期演進(LTE)系統(tǒng)的結(jié)構(gòu)的圖示；

圖2是示出依據(jù)本公開的實施例的LTE系統(tǒng)中無線協(xié)議棧的圖示；

圖3是示出依據(jù)本公開的實施例的分組數(shù)據(jù)匯聚協(xié)議(PDCP)層的功能結(jié)構(gòu)的圖示；

圖4是示出依據(jù)本公開的實施例的加密方法的圖示；

圖5是示出依據(jù)本公開的實施例由于改變超幀號(HFN)發(fā)生失去同步的圖示；

圖6是示出依據(jù)本公開的實施例處理上行鏈路分組的方法的流程圖；

圖7是示出依據(jù)本公開的實施例處理上行鏈路分組的方法的流程圖；

圖8是示出依據(jù)本公開的實施例的eNB的框圖；以及

圖9是示出依據(jù)本公開的UE的框圖。

整個附圖中，相同的參考編號將被理解為指示相同的部分、組件和結(jié)構(gòu)。

具體實施方式

參考附圖的以下說明被提供以幫助對如通過權(quán)利要求及其等價物限定的本公開的各種實施例進行全面理解。其包括各種特定細節(jié)以幫助理解，但這些應(yīng)被認(rèn)為只是示例性的。據(jù)此，那些本領(lǐng)域普通技術(shù)人員將認(rèn)識到可對本文中說明的各種實施例做出各種變化和修改而不背離本公開的范圍和精神。此外，為了清楚和簡潔的目的可省略對已知功能和構(gòu)造的說明。

在以下說明書和權(quán)利要求書中使用的短語和詞匯并不限于書面意思，而只是發(fā)明人為能夠使本公開具有清楚而一致的理解所使用的。據(jù)此，對于本領(lǐng)域技術(shù)人員明顯的是以下對本公開的各種實施例的說明是為例示目的而提供的并非為了限定由所附權(quán)利要求及其等價物所限定的本公開。

應(yīng)該理解的是單數(shù)形式“一個(a)”、“一個(an)”以及“這個”也包括復(fù)數(shù)形式的參照物，除非上下文清楚指示出相反情況。因此，例如參考“一個組件的表面”也包括參考一個或多個這樣的表面。

本公開適用于任意的移動通信系統(tǒng)，例如，通用移動通信系統(tǒng)(UMTS)、演進的UMTS(E-UMTS)或者任意其它的通信系統(tǒng)和協(xié)議。

本公開的實施例提供了通過在使用LTE網(wǎng)絡(luò)進行語音呼叫處理(例如，通過長期演進傳送語音(VoLTE))的過程中發(fā)生分組丟失時防止呼叫斷開來保持持續(xù)的呼叫的方法。雖然下文中說明的本公開的各種實施例專注于LTE網(wǎng)絡(luò)上的VoLTE，但是這并不應(yīng)解釋為限制了本公開。此外，本公開還可被應(yīng)用于無線鏈路控制非確認(rèn)模式(RLC-UM)的基于因特網(wǎng)協(xié)議(IP)的業(yè)務(wù)服務(wù)(例如，VoIP)。

在本公開的以下實施例中，將說明在RLC-UM下發(fā)送和接收IP業(yè)務(wù)的實例。VoLTE服務(wù)的大部分運營商是基于RLC-UM進行語音呼叫的。也就是說，因為VoLTE需要實時操作并且使重傳最小化，運營商一般使用RLC-UM來管理VoLTE服務(wù)。在VoLTE中，服務(wù)質(zhì)量(QoS)等級標(biāo)識(QCI)可被設(shè)置為1。

RLC層位于媒體接入控制(MAC)層之上并且支持可靠的數(shù)據(jù)傳輸。而且，為了形成具有用于無線接口的適當(dāng)大小的數(shù)據(jù)，RLC層執(zhí)行對從較高層傳遞的RLC服務(wù)數(shù)據(jù)單元(SDU)的分段和級聯(lián)。接收實體的RLC層支持?jǐn)?shù)據(jù)的重組功能以將接收到的RLC協(xié)議數(shù)據(jù)單元(RLC PDU)恢復(fù)成原始RLC SDU。每一個RLC實體可依據(jù)與RLC SDU相關(guān)聯(lián)的處理和發(fā)送方案在透明模式(TM)、非確認(rèn)模式(UM)和確認(rèn)模式(AM)下操作。

在TM模式下操作時，RLC層將RLC SDU傳遞至MAC層而不添加任何頭信息。當(dāng)在UM模式下操作時，RLC層通過對RLC SDU的分段和級聯(lián)形成RLC PDU，同時將頭信息附加至每一個RLC PDU，其中被附加至每一個RLC PDU的頭信息都包括序列號。在UM模式下，不支持?jǐn)?shù)據(jù)重傳和緩沖存儲。在AM模式下操作時，RLC層通過對RLC SDU的分段和級聯(lián)形成RLC PDU，并且可響應(yīng)于分組傳輸中的失敗執(zhí)行重傳。對于AM的這種重傳功能可使用各種參數(shù)和變量，例如傳輸窗口、接收窗口、定時器、計數(shù)器等。特別是，在AM模式下，使用若干規(guī)程和控制PDU來以序列號的順序發(fā)送數(shù)據(jù)。

如上述提及的，在RLC-UM模式的情況下，在RLC層上不存在混合自動重復(fù)請求(HARQ)操作，并且在分組數(shù)據(jù)匯聚協(xié)議(PDCP)層上不存在緩沖操作。因此，在通過VoLTE使用語音呼叫服務(wù)時，VoLTE業(yè)務(wù)也不會被緩沖。因為沒有業(yè)務(wù)緩沖，在RLC-UM模式下的VoLTE具有關(guān)于分組丟失的潛在問題。例如，當(dāng)在RLC-UM模式下通過VoLTE進行通信過程中發(fā)生分組丟失超過窗口大小時，用戶設(shè)備(UE)和增強節(jié)點B(eNB)之間可發(fā)生超幀號(HFN)差異。在這種情況下，用于加密和解密的密鑰值可能改變使得上行鏈路分組可發(fā)生解密失敗。當(dāng)發(fā)生解密失敗時，與呼叫相關(guān)聯(lián)的連接可被斷開。因此，需要一種防止由于分組丟失引起意外的呼叫斷開的方法。

在本公開的各種實施例中，解密失敗包括由于與發(fā)送和接收實體相關(guān)聯(lián)的掩碼變化引起的解密的錯誤，并且還包括HFN失去同步。

安全配置包括加密和解密，并可被應(yīng)用于在UE和eNB之間傳遞的分組。

大量分組丟失是指大小超過關(guān)于PDCP序列號(PDCP SN)大小的窗口范圍的分組丟失。這樣的大量分組丟失可能由無線通信環(huán)境突變引起，例如UE或?qū)嶓w進入無線陰影區(qū)域的切換。

圖1是示出依據(jù)本公開的實施例的LTE系統(tǒng)的結(jié)構(gòu)的圖示。

參考圖1，LTE系統(tǒng)的無線接入網(wǎng)是由基站(也稱為eNB)105、110、115和120、移動性管理實體(MME)125，以及服務(wù)網(wǎng)關(guān)(S-GW)130構(gòu)成的。UE 135(也稱為用戶裝置、終端、移動站等)通過eNB 105-120以及S-GW 130接入外部網(wǎng)絡(luò)。

在圖1中，eNB 105-120中的每一個都對應(yīng)于UMTS系統(tǒng)中的節(jié)點B。eNB 105通過無線信道與UE連接，并執(zhí)行比節(jié)點B更復(fù)雜的功能。在LTE系統(tǒng)中，包括例如VoIP的實時服務(wù)的所有用戶業(yè)務(wù)都通過共享信道進行通信。因此，需要一種通過收集例如UE緩沖狀態(tài)、有效傳輸功率信息以及信道狀態(tài)的狀態(tài)信息來執(zhí)行調(diào)度的裝置。eNB 105-120執(zhí)行這種功能。

一般單個eNB控制多個小區(qū)。為了實現(xiàn)例如100Mbps的傳輸速度，LTE系統(tǒng)在例如20MHz的帶寬上使用了例如正交頻分多址(OFDM)的無線接入技術(shù)。此外，自適應(yīng)調(diào)制和編碼(AMC)方案被應(yīng)用于依據(jù)UE 135的信道狀態(tài)確定調(diào)制方案和信道編碼速率。

S-GW 130是用來提供數(shù)據(jù)承載服務(wù)的裝置，并且還在MME 125的控制下創(chuàng)建或除去數(shù)據(jù)承載服務(wù)。MME 125是在與多個eNB連接時用于執(zhí)行UE 135移動性管理功能以及任意其它控制功能的裝置。

圖2是示出依據(jù)本公開的實施例的LTE系統(tǒng)中無線協(xié)議棧的圖示。

參考圖2，LTE系統(tǒng)中的無線協(xié)議棧包括PDCP層205和240、RLC層210和235，以及MAC層215和230。

具體地，PDCP層205、240負(fù)責(zé)IP頭壓縮和解壓縮、用戶數(shù)據(jù)的傳送、與無線承載相關(guān)聯(lián)的序列號的維護、加密和解密等。在示例性實施例中，PDCP層執(zhí)行對通過網(wǎng)絡(luò)發(fā)送的分組的加密或解密。在這種情況下，在用于加密或解密的密鑰值之中，對每一個分組的變化的值進行計數(shù)。計數(shù)可由HFN和PDCP SN形成(即，計數(shù)＝HFN+PDCP SN)。其它密鑰值可以是固定的。

RLC層210、235負(fù)責(zé)將PDCP分組數(shù)據(jù)單元(PDU)重組成適當(dāng)?shù)拇笮?。MAC層215、230與一個UE中的若干個RLC層裝置連接，并執(zhí)行將RLC PDU復(fù)用到MAC PDU以及從MAC PDU解復(fù)用出RLC PDU的功能。

物理層(PHY)220、225執(zhí)行信道編碼和調(diào)制較高層數(shù)據(jù)，以及隨后將其OFDM符號發(fā)送至無線信道的功能。PHY層220、225還可執(zhí)行對通過無線信道接收的OFDM符號進行解調(diào)和信道解碼的功能，并且然后將解調(diào)和解碼的符號傳遞至較高層。而且，PHY層220、225使用HARQ進行附加糾錯，其中接收實體向發(fā)送實體發(fā)送1比特以通知是否接收到分組，這被稱為HARQ確認(rèn)/否定確認(rèn)(ACK/NACK)信息。關(guān)于上行鏈路傳輸?shù)南滦墟溌稨ARQ ACK/NACK信息通過PHICH(物理HARQ指示信道)被發(fā)送，并且關(guān)于下行鏈路傳輸?shù)纳闲墟溌稨ARQ ACK/NACK信息通過物理上行鏈路控制信道(PUCCH)或物理上行鏈路共享信道(PUSCH)被發(fā)送。

圖3是示出依據(jù)本公開的實施例的PDCP層的功能結(jié)構(gòu)的圖示。

參考圖3，PDCP層的功能結(jié)構(gòu)包括發(fā)送PDCP實體300和接收PDCP實體302。在示例性實施例中，與發(fā)送PDCP實體300相關(guān)聯(lián)的PDCP層的功能結(jié)構(gòu)指示應(yīng)用于由PDCP層從較高實體接收的PDCP SDU的特定任務(wù)。與接收PDCP實體302相關(guān)聯(lián)的PDCP層的功能結(jié)構(gòu)指示應(yīng)用于由PDCP層從較低實體接收的PDCP PDU的特定任務(wù)。

PDCP層既被用于用戶面(U-plane)信息也被用于控制面(C-plane)信息。PDCP的一些功能是依據(jù)哪個面被使用而被選擇性地應(yīng)用的。例如，如圖3所示，頭壓縮功能(S2)可僅應(yīng)用于用戶面數(shù)據(jù)，而完整性保護功能(S3)可僅用于控制面數(shù)據(jù)。

首先，對發(fā)送PDCP實體處執(zhí)行的數(shù)據(jù)處理過程進行說明：

S1：對于接收到的PDCP SDU，PDCP層給每一個數(shù)據(jù)單元(即，分組)分配序列號。

S2：如果所配置的無線承載(RB)是與用戶面相關(guān)聯(lián)的RB，則PDCP層執(zhí)行對PDCP SDU的頭壓縮任務(wù)。

S3：如果所配置的RB是與控制面相關(guān)聯(lián)的RB，則PDCP層執(zhí)行對PDCP SDU的完整性保護任務(wù)。

S4：對于作為S2或S3操作的結(jié)果創(chuàng)建的數(shù)據(jù)塊，PDCP層執(zhí)行加密任務(wù)。

S5：對于通過S4操作加密的數(shù)據(jù)塊，PDCP層通過對其添加適當(dāng)?shù)念^形成PDCP PDU并將其發(fā)送至RLC層。

然后，對接收PDCP實體處執(zhí)行的數(shù)據(jù)處理過程進行描述。

S6：對于接收到的PDCP PDU，PDCP層移除頭。

S7：對于已移除頭的PDCP PDU，PDCP層執(zhí)行解密任務(wù)。

S8：如果所配置的RB是與控制面相關(guān)聯(lián)的RB，PDCP層對于經(jīng)解密的PDCP PDU執(zhí)行完整性驗證任務(wù)。

S9：如果所配置的RB是與用戶面相關(guān)聯(lián)的RB，PDCP層對于經(jīng)解密的PDCP PDU執(zhí)行頭解壓縮任務(wù)。

S10：PDCP層將通過S8或S9操作接收到的數(shù)據(jù)塊(即，PDCP SDU)傳遞至較高層。如果所配置的RB是與用戶面相關(guān)聯(lián)的RB，可在將所配置的RB傳遞至較高層之前執(zhí)行重新排序。

下面說明在PDCP層上使用的頭壓縮功能。頭壓縮是一種基于同一分組流的IP分組的IP頭彼此不會有很大不同的事實來減少頭的大小的技術(shù)。在示例性實施例中，未變化的字段以上下文的形式被存儲在發(fā)送實體的壓縮器中以及接收實體的解壓縮器中，變化的字段僅在形成上下文之后被發(fā)送，這使其能夠減少IP頭的開銷。在頭壓縮的初始操作中，因為壓縮器發(fā)送完整的頭分組，以便在解壓縮器處形成與相關(guān)分組流相關(guān)聯(lián)的上下文，因此頭壓縮不存在增益。但是，在解壓縮器處形成上下文之后，壓縮器只發(fā)送壓縮后的頭分組并從而通過頭壓縮增加了潛在增益。

魯棒性頭壓縮(ROHC)是在LTE系統(tǒng)中使用的一種頭壓縮技術(shù)，其被用于減少實時分組(例如實時傳輸協(xié)議(RTP)/用戶數(shù)據(jù)報協(xié)議(UDP)/IP)的頭信息。在此，RTP/UDP/IP分組是指隨著數(shù)據(jù)從較高層下降并通過RTP/UDP/IP層附加相關(guān)的頭的分組。這些頭包括要經(jīng)由網(wǎng)絡(luò)被傳遞至目的地并在接收裝置處被恢復(fù)的數(shù)據(jù)所需的各種頭信息。通常，RTP/UDP/IP分組的頭大小在IP版本4(IPv4)的情況下為40字節(jié)，在IP版本6(IPv6)的情況下為60字節(jié)。使用ROHC壓縮的頭可減少1-3字節(jié)。

圖4示出依據(jù)本公開的實施例的加密方法的圖示。

參考圖4，在PDCP層上執(zhí)行的安全功能包括兩種功能，即，加密和完整性保護。這兩種功能都創(chuàng)建與分組相關(guān)聯(lián)的各種碼，并使用所創(chuàng)建的碼執(zhí)行加密或完整性測試。

分組從屬碼(packet-dependent code)是使用被添加至每一個PDCP PDU的PDCP SN創(chuàng)建的。碼創(chuàng)建參數(shù)中的一個是計數(shù)。該計數(shù)的長度為32比特，其中最低有效位(LSB)是由PDCP SN形成的，而另一個最高有效位(MSB)由HFN形成。由于PDCP SN對于各個RB具有不同長度，例如，5、7或12比特，HFN的長度也是可變的，例如27、25或20比特。例如，在3GPP標(biāo)準(zhǔn)的RLC UM模式下，PDCP SN的大小用作7比特。VoLTE業(yè)務(wù)采用RLC UM模式發(fā)送，并且因此PDCP SN的大小為7比特。當(dāng)PDCP SN為7比特時，窗口范圍為0-127。

發(fā)送實體通過結(jié)合原始數(shù)據(jù)與分組從屬碼(即掩碼)來創(chuàng)建加密的數(shù)據(jù)。這意味著對于每一比特在原始數(shù)據(jù)和掩碼之間執(zhí)行XOR操作。接收實體接收加密數(shù)據(jù)并且使用掩碼解密接收到的數(shù)據(jù)以生成原始數(shù)據(jù)。在示例性實施例中，掩碼可由32比特形成并從若干輸入?yún)?shù)創(chuàng)建。例如，為了對各個分組創(chuàng)建不同的值，使用依據(jù)PDCP PDU而變化的PDCP SN創(chuàng)建計數(shù)。所創(chuàng)建的計數(shù)作為掩碼創(chuàng)建輸入?yún)?shù)中的一個被使用。除計數(shù)以外，掩碼創(chuàng)建輸入?yún)?shù)還包括“承載”、“方向”和“密鑰”(CK)，其中“承載”是RB的指示符，“方向”具有向上或向下值，“密鑰”在RB建立的時候在UE和網(wǎng)絡(luò)之間被交換。

在發(fā)送或接收實體處可能發(fā)生加密錯誤。例如，加密錯誤可能是由于HFN(其是計數(shù)的MSB)被改變時掩碼中的變化引起的。這可能在PDCP SDU丟失時發(fā)生。原因如下：形成計數(shù)的較高塊是SFN且較低塊是PDCP SN。如果PDCP SN達到最大值則其返回為零，而HFN增加1。例如，如果HFN是n且PDCP SN大小為7比特，則PDCP SN的值可以從0至127。即，當(dāng)HFN處于n狀態(tài)時，PDCP SN最大值為127。然后，HFN變?yōu)閚+1，且PDCP SN返回為0并且最多增加至127以執(zhí)行加密。如果發(fā)生任意的大量的分組丟失超過PDCP SN窗口范圍，則可能由于HFN的改變而發(fā)生失去同步。

圖5是示出依據(jù)本公開的實施例由于改變超幀號(HFN)發(fā)生失去同步的圖示。

參考圖5，UE 510可向eNB 530發(fā)送上行鏈路數(shù)據(jù)。該上行鏈路數(shù)據(jù)可包括VoLTE語音分組。在上行鏈路上發(fā)送的VoLTE語音分組可在UE 510處使用特定的HFN加密并且在eNB 530處使用相同的HFN解密。正如以上討論的，HFN與PDCP SN一起形成了計數(shù)。

在對分組的加密和解密中使用了多種密鑰。在這些密鑰中，計數(shù)值依據(jù)各個分組而變化。該計數(shù)可由HFN和PDCP SN形成(即，計數(shù)＝HFN+PDCP SN)。其它密鑰值可以是固定的。

如果應(yīng)用于每一個分組的計數(shù)值不相同，則在解密處理中會發(fā)生失去同步并因此接收到的分組不能被解密。如圖5所示，當(dāng)在UE 510和eNB 530之間發(fā)生大量分組丟失時，在UE 510處用于加密分組的計數(shù)可與在eNB 530處用于解密分組的計數(shù)不同。

如果在PDCP SN窗口范圍內(nèi)發(fā)生任意的分組丟失，eNB 530可基于與該分組相關(guān)聯(lián)的SN來應(yīng)用HFN。例如，如果PDCP SN的大小為7比特，則SN值可從0至127。跟著具有PDCP SN值為127的前一分組的一特定分組，其HFN值增加1而PDCP SN值為零。

如果正常接收分組之后在窗口范圍內(nèi)發(fā)生分組丟失，eNB 530可通過將分組丟失后接收到的PDCP SN與之前正常接收的分組的PDCP SN進行比較來應(yīng)用HFN。但是，如果分組丟失發(fā)生在窗口范圍以外，則即使對PDCP SN進行比較，eNB也不能確定兩個分組是否具有相同的HFN。因此，在解密處理過程中會發(fā)生解密失敗并且在UE 510和eNB 530之間會發(fā)生HFN失去同步。

如以上討論的，HFN失去同步的發(fā)生會導(dǎo)致解密處理失敗。在這種情況下，接收實體不能將接收到的數(shù)據(jù)恢復(fù)成原始數(shù)據(jù)并因此丟棄該接收到的數(shù)據(jù)。因此，由于解密失敗而不能保持呼叫，并且與該呼叫相關(guān)聯(lián)的連接被斷開。由此，語音呼叫被釋放。因為這是一種由于分組丟失引起的不期望的呼叫斷開，所以需要一種防止這樣的呼叫斷開的方法。

圖6是示出依據(jù)本公開的實施例處理上行鏈路分組的方法的流程圖。

參考圖6，在操作610中，eNB可從UE接收上行鏈路分組。依據(jù)3GPP標(biāo)準(zhǔn)，VoLTE語音分組使用RLC UM模式發(fā)送且每一個分組使用特定計數(shù)加密。該特定計數(shù)可由HFN和PDCP SN形成。

在操作620中，eNB對從UE接收到的上行鏈路分組執(zhí)行解密。eNB可使用依據(jù)與該UE的同步來配置的HFN解密接收到的分組。在3GPP標(biāo)準(zhǔn)中，上行鏈路分組在UE處被加密和在eNB處被解密是通過使用相同的密鑰值進行的。如果用于加密和解密的密鑰彼此相同，則解密中不會出現(xiàn)問題。但是，如果由于分組丟失等(包括密鑰具有不同的HFN的情況)原因?qū)е旅荑€不同，則可發(fā)生解密失敗。

因此，在操作630中，eNB可確定經(jīng)加密的分組是否是正常的IP分組。例如，可基于IP分組的形式來執(zhí)行該確定。解密失敗的結(jié)果是除正常IP分組形式以外的垃圾值。進行解密后，eNB執(zhí)行頭解壓縮。如果使用了錯的掩碼來解密，頭解壓縮處理中將繼續(xù)發(fā)生錯誤。當(dāng)錯誤發(fā)生時，IP分組可被確定為不正常。

如果接收的上行鏈路分組是正常的IP分組(即，如果分組具有正常IP分組形式)，則eNB可在操作640處處理該接收到的分組并且然后向更高的節(jié)點發(fā)送該接收到的分組。

如果接收到的上向鏈路分組不是正常的IP分組(即，如果分組不具有正常IP分組形式)，則eNB可執(zhí)行操作650。任意的經(jīng)解密的分組不是正常IP分組的原因在于由于解密處理中分組丟失導(dǎo)致HFN值不匹配而發(fā)生失去同步。因此，eNB可改變HFN值。即，eNB確定由于大量分組丟失導(dǎo)致HFN被改變并然后改變計數(shù)值中的HFN值。eNB可增加當(dāng)前的HFN值。例如，如果當(dāng)前的HFN值為n，則eNB可將該值增加至n+1。

然后，eNB可在操作620處使用已改變的HFN值對接收到的分組再次執(zhí)行解密。如果由于大量分組丟失超過窗口范圍而導(dǎo)致解密失敗，則使用已改變的HFN值進行解密可使得接收的分組被正常地解密。然后eNB處理該正常加密的分組并且然后向更高節(jié)點發(fā)送該正常加密的分組。

同時，當(dāng)針對特定分組使用已改變的HFN解密導(dǎo)致正常解密，則eNB可通過繼續(xù)使用該已改變的HFN對后續(xù)分組執(zhí)行解密。

一般來說，當(dāng)由于分組丟失導(dǎo)致HFN失去同步發(fā)生時，UE和eNB之間的呼叫可被斷開。但是，依據(jù)圖6中的上述實施例則能夠忽略分組丟失而保持呼叫(即使分組丟失超出窗口范圍)。

圖7是示出依據(jù)本公開的實施例處理上行鏈路分組的方法的流程圖。

參考圖7，與圖6中所示的前述實施例相比，本實施例中加入了操作745和760。依據(jù)圖6的前述實施例，當(dāng)任意IP分組由于解密失敗而被確定為不正常時，則通過改變HFN值再次執(zhí)行解密。但是，當(dāng)已經(jīng)應(yīng)用了已改變的HFN之后發(fā)生解密失敗時，則需要另一種方法來處理該接收到的分組。

在以下關(guān)于圖7的說明中，將省略那些與圖6中相同的元素和操作。

在操作730處，eNB可確定經(jīng)加密的分組是否是正常IP分組。如果不是正常的IP分組，eNB可在操作745處進一步確定該分組是否是使用已改變的HFN值的分組以便再次解密該分組，即，eNB可通過HFN檢查解密歷史以便確定是否在以前執(zhí)行過對該分組的解密。

當(dāng)具有已改變的HFN值的分組要再次被解密時，eNB可在操作760處丟棄分組。即，通過HFN以及已改變的HFN都不能解密的分組被認(rèn)為是不能應(yīng)用適當(dāng)?shù)腍FN值的分組或者是損壞的分組，因此，eNB跳過解密處理并丟棄該分組。而且，eNB可釋放與該UE的呼叫連接。

同時，eNB和UE可在滿足預(yù)定義的條件時設(shè)置要被釋放的呼叫連接。例如，eNB可對于一段給定的時間或關(guān)于同一HFN對丟棄的分組進行計數(shù)。如果被丟棄的分組的數(shù)量超過預(yù)定值，則eNB可釋放與該UE的呼叫連接。

當(dāng)在操作745處確定該分組并不是具有已改變的HFN值要再次解密的分組時，eNB可執(zhí)行操作750。即，如在操作650處討論的，eNB可改變HFN值，并且然后再次解密該分組。

同時，在操作745處，可定義對分組可執(zhí)行解密的次數(shù)的標(biāo)準(zhǔn)。例如，操作760可被設(shè)置成當(dāng)解密被執(zhí)行兩次或更多次時被執(zhí)行。在這種情況下，如果eNB使用HFN值為n進行解密失敗，則該eNB可使用已改變的HFN值n+1執(zhí)行第一次解密，并且然后到達操作745處。此時，由于解密該分組的次數(shù)為2次以下，eNB可在操作750處將HFN值再次改變?yōu)閚+2，并且使用該已改變的HFN值再次執(zhí)行解密。如果即使應(yīng)用該HFN值為n+2還發(fā)生解密失敗，則eNB可在操作760處丟棄該分組。

同時，在圖6和圖7的實施例中，可進一步定義改變HFN的附加條件。該附加條件可以是HFN改變的觸發(fā)條件。例如，當(dāng)對單個分組發(fā)生解密失敗時，HFN的改變可被設(shè)置成并不立即執(zhí)行，而是僅在滿足這樣的附加條件時執(zhí)行。例如，可累積解密中分組失敗的數(shù)目。例如，基于操作630或730中的判定結(jié)果，可累積被解密成具有異常IP分組形式的分組數(shù)目。如果累積值滿足預(yù)定義的附加條件，則改變HFN。

例如，eNB可從UE接收IP分組。然后eNB從IP分組中移除PDU頭并使用包括特定HFN的計數(shù)執(zhí)行解密。而且，在解密之后，eNB可解壓縮分組的頭。當(dāng)發(fā)生分組解密失敗時，由于在頭解壓縮處理中的異常IP分組形式會導(dǎo)致任意的錯誤發(fā)生。eNB可計算解密錯誤出現(xiàn)的數(shù)目。如果該數(shù)目滿足預(yù)定義的閾值，則eNB可改變HFN。

此外，當(dāng)檢測到分組丟失超出對應(yīng)于從UE接收到的分組的PDCP SN的窗口范圍時，eNB可改變HFN。

圖8是示出依據(jù)本公開的實施例的eNB的框圖。

參考圖8，eNB 800可包括收發(fā)機單元810和控制單元830。收發(fā)機單元810被配置成執(zhí)行與至少一個網(wǎng)絡(luò)節(jié)點的通信。控制單元830被配置成控制對eNB 800的全部操作。控制單元830可包括分組處理控制器831。

依據(jù)本公開的實施例，分組處理控制器831可從UE接收上行鏈路分組，并然后基于第一HFN解密接收到的分組。當(dāng)基于該第一HFN發(fā)生解密失敗時，分組處理控制器831可將HFN值從第一HFN改變?yōu)榈诙﨟FN，并且然后基于該第二HFN解密該分組。在此，如果第一HFN為n，則第二HFN可為n+1。

此外，分組處理控制器831可檢查經(jīng)解密的分組的頭。例如，如果經(jīng)解密的分組不具有IP分組形式，分組處理控制器831可將此狀態(tài)確定為發(fā)生解密失敗。

此外，當(dāng)發(fā)生解密失敗時，分組處理控制器831可確定是否具有使用已改變的HFN解密該分組的歷史。如果具有使用已改變的HFN進行解密的歷史(例如，以前已經(jīng)使用過已改變的HFN解密該分組)，則該分組處理控制器831可丟棄該分組。如果沒有使用已改變的HFN進行解密的歷史，分組處理控制器831可將HFN的值從第一HFN改變成第二HFN。

此外，分組處理控制器831可定義HFN改變的觸發(fā)條件。如果與同一HFN相關(guān)聯(lián)的解密失敗的數(shù)目滿足HFN改變觸發(fā)條件時，分組處理控制器831可將HFN值從第一HFN改變成第二HFN。

分組可以是與RLC UM模式下的基于IP的語音業(yè)務(wù)相關(guān)聯(lián)的分組。

此外，當(dāng)檢測到分組丟失超出對應(yīng)于該分組的PDCP SN的窗口范圍時，分組處理控制器831可將HFN值從第一HFN改變成第二HFN。

雖然參考圖8進行說明，但是eNB 800的操作和功能還可包括前面在圖1至圖7中說明的那些。

而且，在圖8中，為了清楚和簡潔的目的使用了標(biāo)記eNB 800的元素的方框。如在本領(lǐng)域中已知的，在eNB 800中也可固有地或選擇性地包括任意其它的元素。此外，分組處理控制器831的操作可由控制單元830執(zhí)行。

圖9是示出依據(jù)本公開的UE的框圖。

參考圖9，UE 900可包括收發(fā)機單元910以及控制單元930。收發(fā)機單元910被配置成執(zhí)行與至少一個網(wǎng)絡(luò)節(jié)點通信?？刂茊卧?30被配置成控制UE 900的全部操作。

在本公開的實施例中，控制單元930可控制收發(fā)機單元910向eNB發(fā)送上行鏈路分組。此時，可能發(fā)生分組丟失。取決于對分組的解密成功或失敗，UE和eNB之間的呼叫連接可被保持或者被釋放。

在本公開的各種實施例中，控制單元930可如前面參考圖1至圖7所述的那樣控制對UE的操作。而且，取決于在eNB處分組解密的結(jié)果，控制單元930可控制UE和eNB之間的連接狀態(tài)。

依據(jù)本公開的各種實施例，可提供一種在移動通信網(wǎng)絡(luò)中用于處理分組丟失的改進的通信方法。

此外，本公開的各種實施例可提供一種用于在大量分組丟失的情況下防止呼叫斷開并從而保持無縫呼叫的方法和裝置。

而且，依據(jù)本公開的各種實施例可提供一種檢測大量分組丟失的方法，一種檢測解密后IP分組形式的方法，以及一種檢測損壞的分組而沒有任何丟失的方法。

雖然本公開已經(jīng)參考其各種實施例進行展示和說明，但是那些本領(lǐng)域技術(shù)人員應(yīng)該理解的是在形式和細節(jié)上可在其中做出各種改變而不背離如通過隨附的權(quán)利要求及其等價物限定的本公開的精神和范圍。