[發(fā)明專利]一種多連接通信的分流方法

在審

• 申請(qǐng)?zhí)枺?/td>: 202011040214.3
• 申請(qǐng)日: 2020-09-28
• 公開(kāi)（公告）號(hào): CN112187654A
• 公開(kāi)（公告）日: 2021-01-05
• 發(fā)明（設(shè)計(jì)）人: 湯德龍
• 申請(qǐng)（專利權(quán)）人: 太倉(cāng)市同維電子有限公司
• 主分類號(hào): H04L12/801
• 分類號(hào): H04L12/801;H04L12/807;H04L12/26;H04W28/10
• 代理公司: 北京天奇智新知識(shí)產(chǎn)權(quán)代理有限公司 11340
• 代理人: 劉黎明

本發(fā)明公開(kāi)了一種多連接通信的分流方法，包括以下步驟：UE和CU通過(guò)多個(gè)DU建立無(wú)線鏈路，并通過(guò)這些無(wú)線鏈路進(jìn)行數(shù)據(jù)收發(fā)；在UE和CU進(jìn)行數(shù)據(jù)收發(fā)的同時(shí)，CU周期向DU發(fā)送時(shí)延探測(cè)報(bào)文，探測(cè)報(bào)文有唯一標(biāo)識(shí)和發(fā)出報(bào)文的時(shí)間戳T1；DU收到CU的時(shí)延探測(cè)報(bào)文，回應(yīng)響應(yīng)報(bào)文，響應(yīng)報(bào)文有對(duì)應(yīng)探測(cè)報(bào)文的唯一標(biāo)識(shí)和接收探測(cè)報(bào)文的時(shí)間戳T2，以及發(fā)出響應(yīng)報(bào)文的時(shí)間戳T3；CU收到響應(yīng)報(bào)文，記錄收到響應(yīng)報(bào)文的時(shí)間戳T4，計(jì)算每個(gè)周期的T2?T1和T4?T3的值并記錄，若當(dāng)前的T2?T1和T2?T1最小值相差超過(guò)第一閾值或當(dāng)前的T4?T3和T4?T3最小值相差超過(guò)第二閾值，則CU停止向這條鏈路收發(fā)數(shù)據(jù)。本發(fā)明通過(guò)監(jiān)控F1接口報(bào)文傳輸時(shí)延的變化情況，間接推斷F1接口的傳輸質(zhì)量，并優(yōu)化分流策略，從而使UE獲得整體最佳吞吐率。

技術(shù)領(lǐng)域

本發(fā)明涉及通信技術(shù)領(lǐng)域，具體是指一種多連接通信的分流方法。

背景技術(shù)

參見(jiàn)3GPP(3rd Generation Partnership Project，第三代合作伙伴計(jì)劃)協(xié)議38.425等，當(dāng)UE(User Equipment，用戶設(shè)備)通過(guò)多個(gè)無(wú)線鏈接(這些無(wú)線鏈接可以是不同制式的不同頻段，當(dāng)然，也可以是相同制式和頻段)接入無(wú)線系統(tǒng)時(shí)，UE可以在多個(gè)無(wú)線鏈接上進(jìn)行數(shù)據(jù)收發(fā)。在此過(guò)程中，因?yàn)槎鄺l無(wú)線鏈路傳輸特性的相互牽制，有可能UE實(shí)際獲得的吞吐率還不如單條鏈路獲得的吞吐率。3GPP協(xié)議定義了一些流程和規(guī)范對(duì)此進(jìn)行優(yōu)化，但是未能很好的解決所有問(wèn)題，例如，現(xiàn)有協(xié)議針對(duì)UE接入一個(gè)CU(Centralized Unit，中央單元)下多個(gè)DU(Distributed Unit，分布式單元)的場(chǎng)景，CU和DU之間F1接口(專有名詞，特指CU/DU之間接口)的傳輸鏈路的傳輸質(zhì)量不穩(wěn)定的情況就沒(méi)有很好的解決措施。一般的，地面?zhèn)鬏旀溌窅夯紫润w現(xiàn)為傳輸報(bào)文RTT(Round-Trip Time，往返時(shí)延)的惡化，當(dāng)傳輸鏈路表現(xiàn)良好時(shí)，RTT相對(duì)比較穩(wěn)定；當(dāng)傳輸鏈路因?yàn)閾砣蚋蓴_等原因變差時(shí)，RTT會(huì)相對(duì)劇烈波動(dòng)甚至整體拉長(zhǎng)。當(dāng)傳輸鏈路RTT劇烈變化和拉長(zhǎng)時(shí)，傳輸鏈路質(zhì)量變差，此時(shí)UE通過(guò)多鏈接獲得的吞吐率有可能還不如單鏈接獲得的吞吐率。

參見(jiàn)附圖1：UE和CU建立雙鏈接，分別是DU1和DU2。一般的，我們稱CU到DU的數(shù)據(jù)流向?yàn)橄滦校粗疄樯闲小?/p>

基于這個(gè)組網(wǎng)，做一個(gè)簡(jiǎn)化的量化的具體的場(chǎng)景假設(shè)：

--假設(shè)CU和DU1之間的傳輸鏈路的帶寬為100Mbps(Million bits per second，兆位每秒)，CU和DU2之間的帶寬為1Gbps(Giga bits per second，吉位每秒)，正常時(shí)延都是100ms(millisecond，毫秒)。

--假設(shè)UE在空口的帶寬不受限，例如UE和DU1之間的空口帶寬遠(yuǎn)大于100M，UE和DU2之間的帶寬遠(yuǎn)大于1G。

--假設(shè)UE、DU1、DU2、CU以及其它的組件都處于理想狀態(tài)，時(shí)延為0，資源不受限，沒(méi)有任何故障。

--假設(shè)UE和CU之間傳輸?shù)膱?bào)文為T(mén)CP報(bào)文。

基于這個(gè)場(chǎng)景，有如下推論：

--當(dāng)CU和UE之間數(shù)據(jù)傳輸正常時(shí)，UE和CU之間的總吞吐率應(yīng)該在1.1G左右。

--當(dāng)CU和DU1之間的傳輸鏈路逐漸惡化的時(shí)候，UE和CU之間的總吞吐率會(huì)逐漸下降

--當(dāng)CU和DU1之間的傳輸鏈路持續(xù)惡化，UE和CU之間的總吞吐率會(huì)降到1G以下。

產(chǎn)生這個(gè)現(xiàn)象的原因在于：

--TCP(Transmission Control Protocol，傳輸控制協(xié)議)客戶端和服務(wù)器之間有一個(gè)擁塞控制機(jī)制，會(huì)通過(guò)一個(gè)發(fā)送窗口控制TCP服務(wù)器發(fā)出且未被TCP客戶端確認(rèn)收到的數(shù)據(jù)量。這個(gè)窗口是一個(gè)測(cè)量值，近似的等于TCP客戶端和服務(wù)器之間瓶頸帶寬和TCP客戶端和服務(wù)器之間傳輸時(shí)延的積。