到，則將WLAN鏈路和LTE鏈路進行關聯(lián)，以便后續(xù)啟動調(diào)度策略協(xié)商和數(shù)據(jù)流的分流過程；
[0115]4)、上述過程的是根據(jù)WLAN鏈路的MAC Address來進行WLAN鏈路和LTE鏈路關聯(lián)的，也可以使用其他任意定義的參數(shù)來關聯(lián)WLAN鏈路和LTE鏈路，本實施例不作限定。
[0116]實施例四、UE在WLAN中的認證方法四:
[0117]本實施例四的方法是，UE在WLAN、LTE中的認證仍然按照現(xiàn)有的方法進行，認證成功并建立鏈路后，通知eNB進行LTE鏈路和WLAN鏈路的關聯(lián)。具體方法如下:
[0118]1)、UE在LTE、WLAN中的接入和認證分別進行，相互透明；
[0119]2)、對于UE而言，UE是知道其接入的LTE和WLAN的情況的，所以UE在建立LTE鏈路、WLAN鏈路并關聯(lián)后，可以通過WLAN向網(wǎng)絡側(cè)(如eNB)發(fā)送關聯(lián)LTE鏈路、WLAN鏈路的流程消息;通過該流程消息網(wǎng)絡側(cè)(如eNB)可以將WLAN鏈路和LTE鏈路進行關聯(lián)，并后續(xù)啟動調(diào)度策略協(xié)商和數(shù)據(jù)流的分流過程。
[0120]本實施例四中，為了幫助UE識別哪些WLAN鏈路可以和LTE鏈路關聯(lián)，在WLAN的ESSID中可以加上網(wǎng)絡側(cè)(如eNB)的信息。本實施例四不需要3GPP標準作任何改動。
[0121 ]上述給出了多種對UE在WLAN中的認證方法，各有優(yōu)缺點，具體使用哪一種取決于多種因素，比如標準化的可能性、比如對UE實現(xiàn)的影響等等。
[0122]本發(fā)明實施例中，UE和網(wǎng)絡側(cè)(如eNB)在進行WLAN鏈路和LTE鏈路關聯(lián)之后，可以對同一數(shù)據(jù)流進行分流。以下分別進行說明。
[0123]實施例五、數(shù)據(jù)流在WLAN鏈路和LTE鏈路中的分流方法一:
[0124]本實施例五中，可以在UE和網(wǎng)絡側(cè)(如eNB)中分別設置“數(shù)據(jù)分發(fā)/匯聚”模塊，該模塊布局的位置不同，造成的影響和實際的處理過程也不同。本實施例五中，UE和網(wǎng)絡側(cè)(如eNB)中設置的“數(shù)據(jù)分發(fā)/匯聚”模塊可以位于MAC層，如圖4所示。
[0125]在上行方向上，UE中設置的“數(shù)據(jù)分發(fā)/匯聚”主要起到數(shù)據(jù)流分流作用，而網(wǎng)絡側(cè)(如eNB)中設置的“數(shù)據(jù)分發(fā)/匯聚”主要起到數(shù)據(jù)流匯聚作用。在下行方向上，UE中設置的“數(shù)據(jù)分發(fā)/匯聚”主要起到數(shù)據(jù)流匯聚作用，而網(wǎng)絡側(cè)(如eNB)中設置的“數(shù)據(jù)分發(fā)/匯聚”主要起到數(shù)據(jù)流分流作用。
[0126]由圖4可以看出，在無線鏈路控制(Rad1Link Control，RLC)層以上統(tǒng)一使用LTE協(xié)議棧;而在RLC層以下才分為LTE和WLAN兩種RAT。因此，“數(shù)據(jù)分發(fā)/匯聚”模塊可以在MAC層上將RLC數(shù)據(jù)包分流到LTE鏈路和WLAN鏈路進行傳輸。LTE和WLAN這兩種RAT并行存在，可負荷分擔、可主備分擔，共同提高系統(tǒng)的空口吞吐率。
[0127]本實施例五中，由于分流到WLAN鏈路的數(shù)據(jù)包已經(jīng)經(jīng)過了分組數(shù)據(jù)集中協(xié)議(Packet Data Convergence Protocol，PDCP)層處理，這意味著已經(jīng)獲得了安全保護，所以在WLAN鏈路上就不再需要額外的安全保護了。由于分流到WLAN鏈路和LTE鏈路的數(shù)據(jù)包已經(jīng)經(jīng)過了 I3DCP層處理，這意味著已經(jīng)經(jīng)過了頭壓縮，這意味著在WLAN鏈路和LTE鏈路的傳輸效率也提高了。由于分流到WLAN鏈路和LTE鏈路的數(shù)據(jù)包已經(jīng)經(jīng)過了I3DCP層處理，這意味著已經(jīng)經(jīng)過了PDCP層的排序了，所以不會造成亂序，所以對傳輸控制協(xié)議(Transmiss1nControl Protocol，TCP)層的傳輸影響較小。因此，本實施例五可以解決如圖1所示的現(xiàn)有技術(shù)中WLAN鏈路的安全依靠UE和TOG之間的IPSec保證所帶來的處理量大，且會增加額外的頭開銷的問題。
[0128]實施例六、數(shù)據(jù)流在WLAN鏈路和LTE鏈路中的分流方法二:
[0129]本實施例六中，UE和網(wǎng)絡側(cè)(如eNB)中設置的“數(shù)據(jù)分發(fā)/匯聚”模塊可以位于IP層，如圖5所示。
[0130]本實施例六中，同一數(shù)據(jù)流的分流是在IP層完成的，即“數(shù)據(jù)分發(fā)/匯聚”模塊分流到WLAN鏈路和LTE鏈路的對象是IP數(shù)據(jù)包。
[0131]本實施例六中，在UE端不需要修改下層協(xié)議棧，數(shù)據(jù)流分發(fā)/匯聚可以在應用層完成，所以對終端的修改很容易；相比較而言，實施例五的數(shù)據(jù)流分發(fā)/匯聚是位于MAC層和RLC層之間，一般終端的MAC層和RLC層都是ASIC芯片實現(xiàn)，一旦批量生產(chǎn)后難以修改。
[0132]在實施例五中，被分流的數(shù)據(jù)包是經(jīng)過PDCP層處理的，意味著已經(jīng)獲得了安全保護的，所以在WLAN鏈路和LTE鏈路上就不再需要額外的安全保護了。但是，在本實施例六中，分流到WLAN鏈路和LTE鏈路的對象是IP數(shù)據(jù)包，IP數(shù)據(jù)包是沒有經(jīng)過I3DCP層處理的，因此需要在WLAN鏈路和LTE鏈路上增加額外的安全保護措施；當然如果安全要求不高的話，也可以不進行安全保護。
[0133]在實施例五中，被分流的數(shù)據(jù)包是經(jīng)過PDCP層處理的，這意味著已經(jīng)經(jīng)過了頭壓縮，這意味著在WLAN鏈路和LTE鏈路的傳輸效率也提高了。但是，在本實施例六中，分流到WLAN鏈路和LTE鏈路的對象是IP數(shù)據(jù)包，IP數(shù)據(jù)包是沒有經(jīng)過I3DCP層處理的，意味著IP數(shù)據(jù)包是沒有經(jīng)過頭壓縮的，也意味著在WLAN鏈路和LTE鏈路的傳輸效率不如實施例五高。
[0134]在實施例五中，被分流到WLAN鏈路和LTE鏈路的數(shù)據(jù)包已經(jīng)經(jīng)過了rocp層處理，這意味著已經(jīng)經(jīng)過了PDCP層的排序了，所以不會造成亂序，所以對TCP層的傳輸影響較小。但是，在本實施例六中，LTE鏈路和WLAN鏈路的時延不同可能會造成亂序，該亂序?qū)CP層的處理會產(chǎn)生影響。
[0135]實施例七、數(shù)據(jù)流在WLAN中的傳輸:
[0136]本發(fā)明實施例中，被分流到WLAN鏈路上的數(shù)據(jù)包，不管是RLC包還是IP數(shù)據(jù)包，都需要封裝到一個邏輯鏈路控制(Logical Link Control，LLC)層上，如下圖6所示。對于本發(fā)明實施例而言，為了能更好地將數(shù)據(jù)流分流在WLAN鏈路和LTE鏈路中，可以在WLAN中也建立類似于承載的概念。
[0137]舉例來說，可以采用如下方法定義WLAN中的承載:
[0138]方法1、在802.2SNAP的Class中定義幾個值，將其和LTE中的承載標識(Bearer ID)——對應起來。
[0139]方法2、在802.2LLC中的DSAP和SSAP中定義幾個值，將其和LTE中的承載標識(Bearer ID)--對應起來。
[0140]實施例八、數(shù)據(jù)流整形方法一:
[0141]本實施例八對數(shù)據(jù)流整形的目的是為了解決上述的實施例六中的IP數(shù)據(jù)包在LTE鏈路和WLAN鏈路分別傳輸所造成的亂序問題。
[0142]其中，IP數(shù)據(jù)包經(jīng)過“數(shù)據(jù)分發(fā)/匯聚”模塊分流后將在LTE鏈路和WLAN鏈路中分別傳輸，由于WLAN和LTE的技術(shù)特性不同，IP數(shù)據(jù)包在WLAN鏈路和LTE鏈路中傳輸?shù)臅r延可能不同，其結(jié)果是對某一確定的IP數(shù)據(jù)流，經(jīng)過兩種RAT傳輸后，在接收端將造成亂序。其中，亂序?qū)CP傳輸造成影響，例如導致TCP包的重傳、導致TCP源端的擁塞控制等。
[0143]本實施例八給出的數(shù)據(jù)流整形方法說明如下:
[0144]“數(shù)據(jù)分發(fā)/匯聚”模塊根據(jù)數(shù)據(jù)流來進行分流:
[0145]I)、如果IP數(shù)據(jù)包頭中的Protocol ID是UDP，則可以將數(shù)據(jù)流可以在WLAN鏈路和LTE鏈路上任意分流；
[0146]2)、如果IP包頭中的Protocol ID是TCP，則需要將每一個數(shù)據(jù)流分在某一確定的RAT中，一個數(shù)據(jù)流使用5元組來表示。
[0147]本實施例六中，如果同一個數(shù)據(jù)流在同一個RAT中傳輸，其順序得到保證;但是如果這樣做，分流的好處將會損失掉。
[0148]“數(shù)據(jù)分發(fā)/匯聚”模塊也可以根據(jù)承載來進行分流:
[0149]目前在LTE中一個數(shù)據(jù)流一定是承載在某一個確定的承載上的，這樣如果是對承載進行調(diào)度，則也會將確定的數(shù)據(jù)流分在確定的RAT中。
[0150]本實施例八提供的數(shù)據(jù)流整形方法雖然可以避免TCP的重傳和流控問題，但是把一個數(shù)據(jù)流束縛在同一個承載中，會喪失本發(fā)明的很多優(yōu)點。
[0151]實施例九、數(shù)據(jù)流整形方法二:
[0152]本實施例九對數(shù)據(jù)流整形的目的仍然是為了解決上述的實施例六中的IP數(shù)據(jù)包在LTE鏈路和WLAN鏈路分別傳輸所造成的亂序問題。
[0153]前面已經(jīng)說明，IP數(shù)據(jù)包在LTE鏈路和WLAN鏈路分別傳輸所造成的亂序?qū)е耇CP重傳和流控問題。其中，TCP重傳的特點說明如下:
[0154]I)、接收端在接收到SN大于期望值的數(shù)據(jù)包時，將立即回ACK(確認信息幀)，其中帶上期望的SN號；
[0155]2)源端連續(xù)接收到3個攜帶相同SN的ACK，將認為需要重傳，并進行擁塞控制。
[0156]本實施例九根據(jù)上述TCP重傳的特點，可以在分流時設計方法，以避免接收端連續(xù)給源端發(fā)送3個ACK即可。具體方法可以如下:
[0157]對于同一數(shù)據(jù)流，“數(shù)據(jù)分發(fā)/匯聚”模塊不會在同一RAT中連續(xù)發(fā)送超過2個數(shù)據(jù)包，例如:
[0158]1、先在LTE鏈路和WLAN鏈路中各發(fā)送I個或2個數(shù)據(jù)包；
[0159]I1、哪個RAT先發(fā)送數(shù)據(jù)包成功，則在該RAT種繼續(xù)發(fā)送數(shù)據(jù)包；
[0160]II1、如果在某一個RAT中已經(jīng)發(fā)送兩個數(shù)據(jù)包，但是另一個RAT中數(shù)據(jù)包尚未發(fā)送成功，則在成功發(fā)送數(shù)據(jù)包的RAT中重發(fā)另一 RAT中未發(fā)成功的數(shù)據(jù)包。
[0161]本實施例九提供的數(shù)據(jù)流整形方法可以避免TCP重傳和流控問題，也不必將同一數(shù)據(jù)流束縛在同一個承載中。
[0162]實施例十、數(shù)據(jù)流整形方法三:
[0163]與實施例八、實施例九不同的是，本實施例十允許在WLAN鏈路和LTE鏈路上亂序，由接收端在遞交給上層之前進行排序。其中，排序就得有依據(jù)，這個依據(jù)就是序列號SN。本實施例十的具體方法說明如下:
[0164]I)、“數(shù)據(jù)分發(fā)/匯聚”模塊在收到IP數(shù)據(jù)包并做分流時，給每個IP數(shù)據(jù)包打上一個
SN；
[0165]2)、這些打上SN的IP數(shù)據(jù)包經(jīng)過WLAN鏈路和LTE鏈路分別傳輸?shù)骄W(wǎng)絡側(cè)(如eNB)，網(wǎng)絡側(cè)(如eNB)的“數(shù)據(jù)分發(fā)/匯聚”模塊根據(jù)每個IP數(shù)據(jù)包的SN進行排序，然后發(fā)送給上層；
[0166]3)、在實際網(wǎng)絡中，這種帶SN的協(xié)議很多，比如H)CP、GTPU等等，可以選擇一個最簡單的協(xié)議即可，甚至可以自定義一個簡單的協(xié)議層；
[0167]4)、關于SN的設定，因為這些IP數(shù)據(jù)包在LTE、SAE核心網(wǎng)中傳輸?shù)臅r候采用的是GTPU隧道，在GTPU包頭中實際上是有GTPU的SN的，網(wǎng)絡側(cè)(如eNB)可以根據(jù)這些GTPU的SN和TEID來打上標簽。
[0168]本實施例九提供的數(shù)據(jù)流整形方法可以避免TCP重傳和流控問題，而且對分流影響較小。
[0169 ]實施例^^一、數(shù)據(jù)流在WLAN鏈路和LTE鏈路中分流的調(diào)度算法支持一:
[0170]如圖4、圖5所示，在本發(fā)明實施例中，“數(shù)據(jù)流分發(fā)/匯聚”模塊可以完成將同一數(shù)據(jù)流分在不同RAT中，也可以從不同RAT中接收數(shù)據(jù)流并進行匯聚。其中，“數(shù)據(jù)流分發(fā)/匯聚”模塊對數(shù)據(jù)流進行分流可以由一定的調(diào)度算法進行控制。為了靈活性，本發(fā)明實施例盡可能支持各種調(diào)度算法。但是，任何調(diào)度算法都需要以下兩方面的輸入信息:
[0171]I)、調(diào)度策略信息；
[0172]2)、調(diào)度反饋信息。
[0173]本發(fā)明實施例中，可以由網(wǎng)絡側(cè)(如eNB)制定調(diào)度策略，UE通過與網(wǎng)絡側(cè)(如eNB)進行調(diào)度策略協(xié)商來獲得調(diào)度策略。具體的調(diào)度策略協(xié)商過程可以參考圖7，包括:
[0174]A、UE發(fā)送調(diào)度策略協(xié)商請求消息(Policy Request)至網(wǎng)絡側(cè)(如eNB);
[0175]B、UE接收網(wǎng)絡側(cè)(如eNB)返回的策略命令(Policy Command)，該策略命令中攜帶有調(diào)度策略；
[0176]C、UE獲得調(diào)度策略，并向網(wǎng)絡側(cè)(如eNB)發(fā)送調(diào)度策略協(xié)商確認消息(Po I i cyConfirm)。
[0177]實施例十二、數(shù)據(jù)流在WLAN鏈路和LTE鏈路中分流的調(diào)度算法支持二:
[0178]本實施例十二給