一種車載音視頻傳輸方法及系統(tǒng)、車載終端、服務器的制造方法
【專利摘要】本發(fā)明公開了一種車載音視頻傳輸方法及系統(tǒng)、車載終端、服務器，該方法包括車載終端通過獲取服務器發(fā)送的音視頻傳輸請求，根據(jù)音視頻傳輸請求，通過多條物理鏈路與服務器建立連接，接收服務器發(fā)送的多個音視頻數(shù)據(jù)包，將多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行解碼輸出。通過車站終端與服務器之間的多條物理鏈路，可以接收到服務器發(fā)送的多個音視頻數(shù)據(jù)包，最后將該多個音視頻數(shù)據(jù)包進行合并成一路音視頻數(shù)據(jù)流。與現(xiàn)有技術中的一路音視頻數(shù)據(jù)流通過一條物理鏈路進行傳輸相比，本發(fā)明實施例提高了車載音視頻的傳輸速度，物理鏈路越多，傳輸速度也就越高。
【專利說明】
一種車載音視頻傳輸方法及系統(tǒng)、車載終端、服務器
技術領域
[0001] 本發(fā)明涉及通訊技術領域，尤其涉及一種車載音視頻傳輸方法及系統(tǒng)、車載終端、 服務器。
【背景技術】
[0002] 隨著社會的發(fā)展，人們已經越來越不滿足于透過文字或圖片等靜態(tài)的手段了解獲 取信息，而隨著互聯(lián)網技術的普及和發(fā)展，透過視頻來直觀的高效的了解、獲取知識勢必是 未來發(fā)展之趨勢。
[0003] 目前在汽車領域，都是通過2G (第二代移動通信）、3G (第三代移動通信）的車載 模塊進行數(shù)據(jù)傳輸，受2G、3G車載模塊的數(shù)據(jù)傳輸速度的限制，無法實現(xiàn)觀看高清視頻或 實時的視頻會議?，F(xiàn)有技術中也有采用4G(第四代移動通信）模塊進行數(shù)據(jù)傳輸?shù)募夹g方 案，但是此種方案下的車載終端都只設置有一個4G模塊，所有的數(shù)據(jù)傳輸都是通過該4G模 塊進行的，如果進行大數(shù)據(jù)的傳輸，會造成鏈路的擁堵，造成數(shù)據(jù)傳輸?shù)男实拖隆?br>[0004] 因此，亟需一種車載音視頻傳輸方法，用以實現(xiàn)車載視頻的高速傳輸。
【發(fā)明內容】
[0005] 本發(fā)明實施例提供一種車載音視頻傳輸方法及系統(tǒng)、車載終端、服務器，用以實現(xiàn) 車載視頻可以實時高速的傳輸。
[0006] 本發(fā)明實施例提供的一種車載音視頻傳輸方法，包括：
[0007] 車載終端獲取服務器發(fā)送的音視頻傳輸請求；
[0008] 所述車載終端根據(jù)所述音視頻傳輸請求，通過多條物理鏈路與所述服務器建立連 接；
[0009] 所述車載終端接收所述服務器發(fā)送的多個音視頻數(shù)據(jù)包；
[0010] 所述車載終端將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行解碼 輸出。
[0011] 相應地，本發(fā)明實施例還提供了一種車載音視頻傳輸方法，包括：
[0012] 服務器向車載終端發(fā)送音視頻傳輸請求；
[0013] 所述服務器通過多條物理鏈路與所述車載終端建立連接；
[0014] 所述服務器根據(jù)每條所述物理鏈路的鏈路參數(shù)，向所述車載終端發(fā)送多個音視頻 數(shù)據(jù)包。
[0015] 相應地，本發(fā)明實施例提供了一種車載終端，包括：
[0016] 獲取單元，用于獲取服務器發(fā)送的音視頻傳輸請求；
[0017] 連接單元，用于根據(jù)所述音視頻傳輸請求，通過多條物理鏈路與所述服務器建立 連接；
[0018] 接收單元，用于接收所述服務器發(fā)送的多個音視頻數(shù)據(jù)包；
[0019] 處理單元，用于將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行解 碼輸出。
[0020] 相應地，本發(fā)明實施例還提供了一種服務器，包括：
[0021] 第一發(fā)送單元，用于向車載終端發(fā)送音視頻傳輸請求；
[0022] 連接單元，用于通過多條物理鏈路與所述車載終端建立連接；
[0023] 第二發(fā)送單元，用于根據(jù)每條所述物理鏈路的鏈路參數(shù)，向所述車載終端發(fā)送多 個音視頻數(shù)據(jù)包。
[0024] 相應地，本發(fā)明實施例還提供了一種車載音視頻傳輸系統(tǒng)，包括上述車載終端和 上述服務器。
[0025] 本發(fā)明實施例表明，車載終端通過獲取服務器發(fā)送的音視頻傳輸請求，根據(jù)所述 音視頻傳輸請求，通過多條物理鏈路與所述服務器建立連接，接收所述服務器發(fā)送的多個 音視頻數(shù)據(jù)包，將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行解碼輸出。通 過車站終端與服務器之間的多條物理鏈路，可以接收到服務器發(fā)送的多個音視頻數(shù)據(jù)包， 最后將該多個音視頻數(shù)據(jù)包進行合并成一路音視頻數(shù)據(jù)流。與現(xiàn)有技術中的一路音視頻數(shù) 據(jù)流通過一條物理鏈路進行傳輸相比，本發(fā)明實施例提高了車載音視頻的傳輸速度，物理 鏈路越多，傳輸速度也就越高。可以實現(xiàn)乘客在乘車時進行高清視頻觀看或者是進行視頻 會議等需要高速傳輸數(shù)據(jù)的車載活動。
【附圖說明】
[0026] 為了更清楚地說明本發(fā)明實施例中的技術方案，下面將對實施例描述中所需要使 用的附圖作簡要介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本 領域的普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其 他的附圖。
[0027] 圖1為本發(fā)明實施例中提供的一種車載音視頻傳輸?shù)南到y(tǒng)架構圖；
[0028] 圖2為本發(fā)明實施例中提供的一種車載音視頻傳輸方法的流程示意圖；
[0029] 圖3為本發(fā)明實施例中提供的一種車載音視頻傳輸方法的流程示意圖；
[0030] 圖4為本發(fā)明實施例中提供的一種UDP鏈路協(xié)議示意圖；
[0031] 圖5為本發(fā)明實施例中提供的一種TCP鏈路協(xié)議示意圖；
[0032] 圖6為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0033] 圖7為本發(fā)明實施例中提供的一種服務器的結構示意圖；
[0034] 圖8為本發(fā)明實施例中提供的一種車載音視頻傳輸系統(tǒng)的結構示意圖；
[0035] 圖9為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0036] 圖10a為本發(fā)明實施例中天線模組的結構示意圖一；
[0037] 圖10b為本發(fā)明實施例中天線模組的結構示意圖二；
[0038] 圖10c為本發(fā)明實施例中天線模組的結構示意圖三；
[0039] 圖10d為本發(fā)明實施例中天線模組的結構示意圖四；
[0040] 圖11為本發(fā)明實施例中提供的一種LTE模塊的結構示意圖；
[0041] 圖12為本發(fā)明實施例中提供的一種LTE模塊安裝位置示意圖；
[0042] 圖13為本發(fā)明實施例中提供的一種LTE模塊安裝位置示意圖；
[0043] 圖14為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0044] 圖15為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0045] 圖16為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0046] 圖17為本發(fā)明實施例中提供的一種天線模塊的結構示意圖；
[0047] 圖18為本發(fā)明實施例中提供的一種天線模塊的結構示意圖；
[0048] 圖19為本發(fā)明實施例中提供的一種天線模塊的結構示意圖；
[0049] 圖20為本發(fā)明實施例中提供的一種天線模塊安裝位置示意圖；
[0050] 圖21為本發(fā)明實施例中提供的一種天線模塊安裝位置示意圖；
[0051] 圖22為本發(fā)明實施例中提供的一種天線模塊安裝位置示意圖；
[0052] 圖23為本發(fā)明實施例中提供的一種天線模塊安裝位置示意圖；
[0053] 圖24為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0054] 圖25為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0055] 圖26為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0056] 圖27為本發(fā)明實施例中提供的一種車載終端的結構示意圖；
[0057] 圖28為本發(fā)明實施例中提供的第一種多鏈路數(shù)據(jù)傳輸?shù)姆椒ㄊ疽鈭D；
[0058] 圖29A為本發(fā)明實施例中提供的第二種多鏈路數(shù)據(jù)傳輸?shù)姆椒ㄊ疽鈭D；
[0059] 圖29B為本發(fā)明實施例中提供的第三種多鏈路數(shù)據(jù)傳輸?shù)姆椒ㄊ疽鈭D；
[0060] 圖30為本發(fā)明實施例中提供的一種多鏈路數(shù)據(jù)傳輸?shù)脑O備結構圖。
【具體實施方式】
[0061] 為了使本申請的目的、技術方案和優(yōu)點更加清楚，下面將結合附圖對本申請作進 一步地詳細描述，顯然，所描述的實施例僅僅是本申請一部份實施例，而不是全部的實施 例?；诒旧暾堉械膶嵤├?，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的 所有其它實施例，都屬于本申請保護的范圍。
[0062] 如圖1所示，本發(fā)明實施例所適用的一種系統(tǒng)架構，基于該系統(tǒng)架構可實現(xiàn)車載 音視頻的傳輸。本發(fā)明實施例提供的車載音視頻傳輸?shù)南到y(tǒng)架構中包括服務器101和車載 終端102。
[0063] 車載終端102上的4G模塊可以通過INTERNET網絡與服務器101進行通信，也可 以通過 GSM(Global System for Mobile Communications，全球移動通信系統(tǒng)）、LTE(long term evolution，長期演進）系統(tǒng)等移動通信系統(tǒng)與服務器101進行通信。車載終端102 上設有多個4G模塊，每個4G模塊與服務器101之間存在一條物理鏈路。
[0064] 該車載終端102中可以安裝APP(Application，應用程序），乘客可以通過車載終 端102上的APP觀看高清視頻或者是進行視頻會議。該車載終端102也可以是乘客在乘車 時使用的手持終端，如：手機、筆記本、掌上電腦等可以安裝APP的終端。
[0065] 該服務器101可以是移動、聯(lián)通、電信等通信運營商的服務器。
[0066] 上述車載音視頻傳輸?shù)南到y(tǒng)架構還可以包括CPU(Central Processing Unit， 中央處理器）、顯示裝置、電源、音視頻解碼單元等結構，其中多個4G模塊通過USB Hub (Universal SerialBus Hub，通用串行總線集線器）與CPU進行連接。
[0067] 基于上述描述，圖2示出了本發(fā)明實施例中一種車載音視頻傳輸方法的流程，該 流程可以由車載終端或者車載音視頻傳輸系統(tǒng)執(zhí)行。
[0068] 如圖2所示，該流程具體步驟包括：
[0069] 步驟S201，車載終端獲取服務器發(fā)送的音視頻傳輸請求。
[0070] 步驟S202,所述車載終端根據(jù)所述音視頻傳輸請求，通過多條物理鏈路與所述服 務器建立連接。
[0071] 步驟S203,所述車載終端接收所述服務器發(fā)送的多個音視頻數(shù)據(jù)包。
[0072] 步驟S204,所述車載終端將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù) 流，進行解碼輸出。
[0073] 在步驟S201中，服務器在傳輸音視頻時，需要向車載終端發(fā)送音視頻傳輸請求， 表示服務器需要進行音視頻傳輸了，車載終端需要獲取該音視頻傳輸請求。該音視頻傳輸 請求用于請求與車載終端進行音視頻傳輸。
[0074] 在步驟S202中，車載終端在獲取音視頻傳輸請求之后，可以根據(jù)該音視頻傳輸請 求，通過每一條物理鏈路與服務器進行握手認證，從而與服務器建立連接。
[0075] 該車載終端與服務器進行握手認證的步驟可以如下：
[0076] 車載終端向服務器發(fā)送發(fā)現(xiàn)報文，該發(fā)現(xiàn)報文中包括服務器的約定的接入識別信 息。
[0077] 服務器在收到發(fā)現(xiàn)報文后，通過驗證約定的接入識別信息后，向車載終端發(fā)送提 供報文。
[0078] 車載終端在收到服務器發(fā)送的提供報文后，向服務器發(fā)送接入請求報文，服務器 接收到請求報文后，向車載終端發(fā)送確認報文，該確認報文中包括該可以接入該服務器的 識別標識及密碼。
[0079] 車載終端在收到服務器發(fā)送的確認報文后，根據(jù)該確認報文與該服務器建立連 接。
[0080] 在步驟203中，在成功與服務器建立連接后，該車載終端可以接收到服務器發(fā)送 的多個音視頻數(shù)據(jù)包，一個音視頻數(shù)據(jù)流可以被分成多個音視頻數(shù)據(jù)包，該音視頻數(shù)據(jù)包 可以通過多條物理鏈路傳輸至車載終端?，F(xiàn)有技術中是一個音視頻數(shù)據(jù)流通過一條物理鏈 路傳輸，而本發(fā)明實施例是將音視頻數(shù)據(jù)流進行分包處理，然后將多個音視頻數(shù)據(jù)包進行 分發(fā)，每條物理鏈路都參與了傳輸，物理鏈路的信道質量好的接收的音視頻數(shù)據(jù)包也就越 多。該信道質量可以通過計算RTT(Round Trip Time，往返時延）確定的，RTT的數(shù)值越低 表示信道質量越好。
[0081] 在步驟204中，車載終端接收到服務器發(fā)送的多個音視頻數(shù)據(jù)包后，需要將該多 個音視頻數(shù)據(jù)包合并為一路音視頻數(shù)據(jù)流。在接收的每個音視頻數(shù)據(jù)包上都設有標識字 段，屬于同一路音視頻數(shù)據(jù)流的多個音視頻數(shù)據(jù)包上的標識字段相同，因此，車載終端將具 有同一標識字段的多個音視頻數(shù)據(jù)包進行合并處理，從而恢復出原有的一路音視頻數(shù)據(jù) 流，然后對該音視頻數(shù)據(jù)流進行解碼輸出。
[0082] 上述實施例表明，通過車站終端與服務器之間的多條物理鏈路，可以接收到服務 器發(fā)送的多個音視頻數(shù)據(jù)包，最后將該多個音視頻數(shù)據(jù)包進行合并成一路音視頻數(shù)據(jù)流。 與現(xiàn)有技術中的一路音視頻數(shù)據(jù)流通過一條物理鏈路進行傳輸相比，本發(fā)明實施例提高了 車載音視頻的傳輸速度，物理鏈路越多，傳輸速度也就越高?？梢詫崿F(xiàn)乘客在乘車時進行高 清視頻觀看或者是進行視頻會議等需要高速傳輸數(shù)據(jù)的車載活動。
[0083] 基于相同的技術構思，圖3示出了一種車載音視頻傳輸?shù)牧鞒?，該流程可以由?務器或者車載音視頻傳輸系統(tǒng)執(zhí)行。
[0084] 如圖3所示，該流程具體步驟包括：
[0085] 步驟S301，服務器向車載終端發(fā)送音視頻傳輸請求。
[0086] 步驟S302,所述服務器通過多條物理鏈路與所述車載終端建立連接。
[0087] 步驟S303,所述服務器根據(jù)每條所述物理鏈路的鏈路參數(shù)，向所述車載終端發(fā)送 多個音視頻數(shù)據(jù)包。
[0088] 在步驟S301中，服務器在發(fā)送音視頻數(shù)據(jù)流前，先向車載終端發(fā)送音視頻傳輸請 求，表示要開始傳輸音視頻數(shù)據(jù)流，讓車載終端做好準備工作。
[0089] 在步驟S302中，服務器通過與車載終端之間的多條物理鏈路與該車載終端建立 連接，服務器與車載終端是通過握手認證的方式進行建立連接的，該握手認證的具體步驟 見上述步驟S202中描述的具體步驟。服務器與車站終端之間的每一條物理鏈路都有會建 立連接。
[0090] 在步驟S303中，服務器在發(fā)送音視頻數(shù)據(jù)流前，需要先將音視頻數(shù)據(jù)流進行切片 分包處理，分成多個音視頻數(shù)據(jù)包，然后將該多個音視頻數(shù)據(jù)包通過多條物理鏈路分發(fā)出 去。如圖4所示的UDP (User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）鏈路協(xié)議，多個音視頻 數(shù)據(jù)包首先到達虛擬網絡設備然后該虛擬網絡設備根據(jù)當前每條物理鏈路的鏈路參數(shù)來 選擇每條物理鏈路傳輸?shù)臄?shù)據(jù)包的個數(shù)，向車載終端發(fā)送多個音視頻數(shù)據(jù)包，信道質量越 好的物理鏈路，被分配發(fā)送的音視頻數(shù)據(jù)包也就越多。
[0091] 如圖5所不，在TCP (Transmission Control Protocol，傳輸控制協(xié)議）鏈路協(xié)議 圖中，通過采用多路徑TCP技術，根據(jù)物理鏈路的個數(shù)將單個的TCP鏈路切分成多個TCP子 鏈路。多路徑TCP技術在TCP層之上增加了自己鏈路維護的字段，同樣在車載終端側也加 入了對多路徑TCP的支持。
[0092] 在服務器進行音視頻數(shù)據(jù)包分發(fā)時，若在一條物理鏈路中遇到阻塞，此時可以無 縫調度，選擇其他的信道質量好的物理鏈路進行傳輸。
[0093] 上述物理鏈路參數(shù)可以包括下述參數(shù)之一或任意組合：
[0094] 往返時延、鏈路帶寬、鏈路類型。
[0095] 上述實施例表明，通過服務器與車載終端之間的多條物理鏈路，可以向車載終端 發(fā)送多個音視頻數(shù)據(jù)包。與現(xiàn)有技術中的一路音視頻數(shù)據(jù)流通過一條物理鏈路進行傳輸相 比，本發(fā)明實施例提高了車載音視頻的傳輸速度，物理鏈路越多，傳輸速度也就越高?？梢?實現(xiàn)乘客在乘車時進行高清視頻觀看或者是進行視頻會議等需要高速傳輸數(shù)據(jù)的車載活 動。
[0096] 基于相同的發(fā)明構思，圖6示出了本發(fā)明實施例提供的一種車載終端的結構，該 車載終端可以執(zhí)行車載音視頻傳輸?shù)牧鞒獭?br>[0097] 如圖6所示，該車載終端具體包括：
[0098] 獲取單元601，用于獲取服務器發(fā)送的音視頻傳輸請求；
[0099] 連接單元602,用于根據(jù)所述音視頻傳輸請求，通過多條物理鏈路與所述服務器建 立連接；
[0100] 接收單元603,用于接收所述服務器發(fā)送的多個音視頻數(shù)據(jù)包；
[0101] 處理單元604,用于將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行 解碼輸出。
[0102] 優(yōu)選地，所述連接單元602具體用于：
[0103] 根據(jù)所述音視頻傳輸請求，通過每一條物理鏈路與所述服務器進行握手認證，建 立連接。
[0104] 優(yōu)選地，所述處理單元604具體用于：
[0105] 根據(jù)每個音視頻數(shù)據(jù)包中的標識字段，將具有同一標識字段的所述多個音視頻數(shù) 據(jù)包合并為一路音視頻數(shù)據(jù)流。
[0106] 基于相同的發(fā)明構思，圖7示出了本發(fā)明實施例提供的一種服務器，該服務器可 以執(zhí)行車載音視頻傳輸?shù)牧鞒獭?br>[0107] 如圖7所示，該服務器具體包括：
[0108] 第一發(fā)送單元701，用于向車載終端發(fā)送音視頻傳輸請求；
[0109] 連接單元702,用于通過多條物理鏈路與所述車載終端建立連接；
[0110] 第二發(fā)送單元703,用于根據(jù)每條所述物理鏈路的鏈路參數(shù)，向所述車載終端發(fā)送 多個音視頻數(shù)據(jù)包。
[0111] 優(yōu)選地，第二發(fā)送單元703具體用于：
[0112] 所述服務器根據(jù)每條所述物理鏈路的鏈路參數(shù)，選擇每條所述物理鏈路傳輸?shù)乃?述音視頻數(shù)據(jù)包的個數(shù)，向所述車載終端發(fā)送多個音視頻數(shù)據(jù)包。
[0113] 優(yōu)選地，所述物理鏈路參數(shù)包括下述參數(shù)之一或任意組合：
[0114] 往返時延、鏈路帶寬、鏈路類型。
[0115] 基于相同的發(fā)明構思，圖8示出了本發(fā)明實施例提供的一種車載音視頻傳輸系 統(tǒng)，該車載音視頻傳輸系統(tǒng)可以執(zhí)行車載音視頻傳輸?shù)牧鞒獭?br>[0116] 如圖8所示，該車載音視頻傳輸系統(tǒng)具體包括：
[0117] 車載終端801和服務器802。
[0118] 該車載終端801與服務器802進行車載音視頻傳輸?shù)牧鞒桃言谏鲜鰧嵤├忻?述，不再贅述。
[0119] 在本發(fā)明實施例中，車載終端與服務器進行通信的裝置可以是4G模塊，即 LTE (Long Term Evolution，長期演進）模塊。通過多個LTE模塊與服務器進行通信可以為 車輛提供高速網絡傳輸，實現(xiàn)在車輛中進行車載視頻通話、觀看高清視頻的活動。
[0120] 為了更好的解釋本發(fā)明實施例，車載終端的具體結構可以參照如下實施例車載系 統(tǒng)中的結構。
[0121] 在下面的實施例中給出了兩種車載終端的結構，其中圖9至圖15為針對第一種車 載終端的描述，圖16至圖27為針對第二種車載終端的描述。
[0122] 圖9示出了一種車載終端的結構，如圖9所示，上述4G模塊為本發(fā)明實施例中的 LTE模塊，通過LTE模塊可以與服務器進行高速網絡傳輸。該車載終端包括：
[0123] 中控單元902和多個LTE模塊901，該LTE模塊901包括一個LTE模組9011和至 少一個天線模組9012,其中，LTE模組9011與天線模組9012連接，該中控單元902與每個 LTE模塊901連接。
[0124] 本發(fā)明實施例通過多個LTE模塊901通信可以為車輛提供高速網絡傳輸，實現(xiàn)在 車輛中進行車載視頻通話、觀看高清視頻的活動。
[0125] 該LTE模塊901中的LTE模組9011可以進行2G、3G、4G的通信，該LTE模組9011 可以通過其對應的天線模組9012接收和發(fā)射信號進行與外網的通信。
[0126] 如圖9所示，多個LTE模塊901，每個LTE模塊901對應一個LTE模組9011，該LTE 模組9011與兩個天線模組9012連接，該LTE模組9011也可以與一個天線模組9012連接， 連接的天線模組9012的個數(shù)越多，LTE模組9011的通信性能越好。
[0127] 在只有一個LTE模塊901的場景下，該車載終端的網絡傳輸速度可以比2G模式和 3G模式下的天線系統(tǒng)的網絡傳輸速度要快。在多個LTE模塊901的場景下，由于多載波聚 合，通過車載終端中的多個LTE模塊901可以為車輛提供高速網絡傳輸，從而實現(xiàn)在車輛中 進行車載視頻通話、觀看高清視頻的活動。與現(xiàn)有技術相比，本發(fā)明實施例提高了網絡傳輸 速度。
[0128] 該LTE模組9011可以設置在PCB (Printed Circuit Board，印制電路板）上，將 LTE模組9011集成到PCB上，天線模組9012的天線饋腳可以壓接在該PCB上的天線饋點 上，然后通過PCB上的走線與其對應的LTE模組9011進行電連接。
[0129] 天線模組9012的制作工藝有多種，本發(fā)明實施例中的天線模組9012的制作工藝 至少包括以下幾種：
[0130] 方案一
[0131] 天線模組9012固定在PCB的天線支架上，通過天線支架支撐該天線模組9012,天 線支架固定在PCB上，天線模組9012的天線饋腳可以壓接在該PCB上的天線饋點上。
[0132] 方案二
[0133] 天線模組9012通過刻蝕FPC(Flexible Printed Circuit，柔性電路板）形成的。 通過對使用具有天線圖形的掩膜板遮掩的FPC進行曝光，然后對曝光后的FPC上的金屬層 進行刻蝕，制作成迷宮型的天線模組9012。FPC工藝制作的天線模組9012,結構空間小，便 于安裝，可以將該FPC通過背膠粘貼在結構殼體上，如LTE模塊901的外殼上，可以是模塊 外殼非金屬部分的外側，也可以是外殼非金屬部分的內側，還可以是非金屬中殼的面上，也 可以將FPC粘貼在PCB上。這種天線模組9012,具有配線密度高，重量輕，易彎折等優(yōu)點。
[0134] 方案三
[0135] 天線模組9012是通過LDS (Laser Direct Structuring，激光直接成型技術）錯雕 在結構件的殼體上形成的。使用LDS工藝將金屬粉鐳雕至任意的結構件的殼體上，如LTE模 塊901的外殼上，可以是模塊外殼非金屬部分的外側，也可以是外殼非金屬部分的內側，還 可以是非金屬中殼的面上。這種天線模組9012可以任意設計天線圖形，鐳雕在任意形狀的 結構件的殼體上，不受產品結構形態(tài)的限制，靈活性較大，不僅可以避免與LTE模塊901內 的金屬干擾，還可以減小LTE模塊901的體積。
[0136] 相應地，本發(fā)明實施例還提供了幾種天線模組9012的結構示意圖，如圖10a至圖 10d所示。圖10a示出了一種天線模組1012的剖視圖，天線模組9012的截面圖，從圖10a 中可以看出，天線模組1012的圖形結構，該天線模組9012的圖形結構是印制在FPC上的。 圖10b示出了一種由FPC制作而成的天線模組9012,圖中的黑點為天線饋腳。圖10c和圖 l〇d分別示出了兩種天線模組9012的天線圖形，分別是圓環(huán)形結構和回形結構。在制作天 線模組9012時，可以設計成這兩種圖形，在FPC上按照圖形進行刻蝕得到天線模組9012,或 者是使用金屬粉通過LDS鐳雕成這兩種圖形。天線模組9012的圖形在實際應用時，可以自 由設計。
[0137] 上述三種制作天線模組9012的方案，僅是本發(fā)明實施例用以示例，不表示該天線 模組9012的制作工藝僅限于上述方案，本發(fā)明實施例不對此做限制。
[0138] 本發(fā)明實施例中的每個LTE模塊901可以設計成在一個單獨模塊盒子，圖11示出 了一種LTE模塊901成型的示意圖。如圖11所示，將天線模組9012使用LDS鐳雕在該盒 體的頂部，如天線圖形1103。而LTE模塊901中的LTE模組9011通過USB線束可以與中 控單元902進行互聯(lián)通信，每個盒子包括盒體1102,預留USB接口 1101，該USB接口可以兼 容各種USB版本，本發(fā)明實施例使用的是USB3. 0版本，LTE模塊901與中控單元902通過 USB3. 0線束進行通信和供電。在該模塊盒子中還包括LTE模組9011的主路天線和輔路天 線，用于收發(fā)信號。天線可以設計成輻射角小于等于180°的定向天線，這樣可以根據(jù)不同 的安裝位置的周邊環(huán)境判定天線的實際設計輻射面位置。
[0139] 每個盒子的外觀可以根據(jù)實際應用進行設計，并不限于長方體。同時，也可以根據(jù) 實際應用，將天線模組9012鐳雕在該模塊盒子的四個邊上，將天線設計為定向天線，可以 根據(jù)不同的安裝位置的設計天線模組9012的輻射面。本發(fā)明實施例中，優(yōu)選地，將天線模 組9012的位置設置在模塊盒子面對乘客的一面的區(qū)域，即將天線模組9012鐳雕在該模塊 盒子的頂部，或是設置在模塊盒子側面四個面的位置。
[0140] 為了更好的使得車載終端進行高速通信，可以將多個LTE模塊901安裝在車輛的 不同的位置，如圖12所示LTE模塊901安裝位置，可以將LTE模塊901安裝在車輛的A柱、 B柱、C柱、D柱內。然后通過USB總線分別連接到車輛中控臺的中控單元902上，與中控單 元902進行通信。
[0141] 本發(fā)明實施例中LTE模塊901還可以位于車輛的車頂外部、車輛的車門內側、車輛 前擋風玻璃底部的平臺、車輛后擋風玻璃底部的平臺、車輛后視鏡中的位置之一或者任意 組合。如果車輛需要的LTE模塊901數(shù)量多，同一位置可以放置多個，使用的LTE模塊901 的數(shù)量越多，進行高速通信的質量越好。如圖13所示，LTE模塊901可以安裝在圖13中粗 黑色線區(qū)域的車輛的車頂外部、車輛的車門內側。
[0142] 圖9中包括N個LTE模塊901，該N個LTE模塊901都分別與中控單元902連接， 與中控單元902連接的LTE模塊901的數(shù)量越多，該車載終端的性能越優(yōu)，可以是實現(xiàn)高速 通信，如10Gb/s，20Gb/s的高速通信功能。LTE模塊901接收到的信號發(fā)送給該中控單元 902進行處理。
[0143] 本發(fā)明實施例中，該中控單元902是通過USB (Universal Serial Bus，通用串行總 線）總線與每個LTE模塊901連接的。中控單元902和LTE模塊901都設有USB接口，該 USB總線分別連接中控單元902和LTE模塊901的USB接口。
[0144] 由于現(xiàn)有技術中的車輛的天線系統(tǒng)都是單天線設計方案，如果需要接收到各類信 號，就需要將多個天線同時安裝在車輛上，這些天線需要安裝在車輛的車頂外部，這就增加 了車輛的不穩(wěn)定性。而與現(xiàn)有技術相比，本發(fā)明實施例將LTE模組9011和天線模組9012 集成在LTE模塊中，該LTE模塊901可以將設置在車輛的多個位置，無需只安裝在車輛的車 頂外部，從而提高了車輛的穩(wěn)定性。
[0145] 如圖14所示，本發(fā)明實施例提供了 一種中控單元902與LTE模塊901的連接方 式。每個LTE模塊901通過USB總線與中控單元902中的USB接口相連接，一個LTE模塊 901對應一個USB接口。在中控單元902中，多個USB接口與USB集線器連接，每個USB集 線器可以連接Y個USB接口，Y大于等于1，如可以4個USB接口連接一個USB集線器。該 USB集線器有X個，X大于等于1，該X個USB集線器匯總到一個USB集線器上，通過這個總 的USB集線器與中控單元902的CPU連接。
[0146] 在本發(fā)明實施例中，進行組網需要時，可以使用更多的LTE模塊901進行組合，將 多個LTE模塊901分散到車輛的各個位置，降低了車載終端中的天線系統(tǒng)的組裝難度，便于 隨意組合。在需要時，只需將設計的LTE模塊901盒子與中控臺中的中控單元902進行連 接即可。同時使用USB總線與中控單元902進行通信，與傳統(tǒng)設計相比，能夠有效降低由同 軸線引入的射頻功率損耗，提高射頻性能，且能夠降低LTE模塊901和中控單元902之間線 束長度的約束，使得LTE模塊901安裝位置選擇更靈活。
[0147] 相應地，本發(fā)明實施例還提供了一種車載終端的結構，如圖15所示的結構，該車 載終端包括：中控單元1502和多個LTE模塊1501，該LTE模塊1501包括一個LTE模組15011 和至少一個天線模組15012,其中，LTE模組15011與天線模組15012連接，該中控單元1502 與每個LTE模塊1501連接。
[0148] 本發(fā)明實施例通過多個LTE模塊1501通信可以為車輛提供高速網絡傳輸，實現(xiàn)在 車輛中進行車載視頻通話、觀看高清視頻的活動。
[0149] 該中控單元 1502 的 PCB 上設置了 CPU15021，F(xiàn)M(Frequency Modulation，調 頻）模塊 15022、GPS (Global Positioning System，全球定位系統(tǒng)）模塊 15023、WiFi/ BT(WIreless_Fidelity/Bluetooth，無線高保真 / 藍牙）模塊 15024、CMMB(China Mobile Multimedia Broadcasting，中國移動多媒體廣播）模塊15025,該車載終端還包括與FM模 塊 15022、GPS 模塊 15023、WiFi/BT 模塊 15024、CMMB 模塊 15025 對應的 FM 天線、GPS 天線、 WiFi/BT天線和CMMB天線。該FM天線、GPS天線、WiFi/BT天線和CMMB天線依次通過同軸 線通過端子與中控單元1502連接。
[0150] 該中控單元1502是通過USB (Universal Serial Bus，通用串行總線）總線與每個 LTE模塊1501連接的。中控單元1502和LTE模塊1501都設有USB接口，該USB總線分別 連接中控單元1502和LTE模塊1501的USB接口。
[0151] 基于相同的發(fā)明構思，本發(fā)明實施例還提供了一種汽車，該汽車包括上述車載終 端，具體結構以在上述實施例中描述，不再贅述。
[0152] 本發(fā)明實施例通過多個LTE模塊和中控單元連接，實現(xiàn)車載終端的高速通信的功 能，LTE模組與天線模組為一體化結構，可以將多個LTE模塊進行靈活安裝，避免多個LTE模 組集中在中控單元而導致通信干擾的問題。
[0153] 如下針對另一種車載終端的結構進行詳細描述。
[0154] 圖16示出了一種車載終端的結構，如圖16所示，該車載終端包括：
[0155] 中控單元1602和多個天線模塊1601，中控單元1602包括：CPU16022、多個LTE模 塊16021，中控單元1602中每個LTE模塊16021與至少一個天線模塊1601連接，多個LTE 模塊16021分別與CPU16022連接。
[0156] 本發(fā)明實施例通過多個LTE模塊16021通信可以為車輛提供高速網絡傳輸，實現(xiàn) 在車輛中進行車載視頻通話、觀看高清視頻的活動。
[0157] 該LTE模塊16021可以進行2G、3G、4G的通信，每個LTE模塊16021可以通過其對 應的天線模塊1601接收和發(fā)射信號進行與外網的通信。
[0158] 如圖17所示，多個LTE模塊16021，每個LTE模塊16021與兩個天線模塊1601連 接，分別是主路天線和輔路天線。該LTE模塊16021也可以與一個天線模塊1601連接，連 接的天線模塊1601的個數(shù)越多，LTE模塊16021的通信性能越好。
[0159] 在只有一個LTE模塊16021的場景下，該車載終端的網絡傳輸速度可以比2G模 式和3G模式下的天線系統(tǒng)的網絡傳輸速度要快。在多個LTE模塊16021和多個天線模塊 1601的場景下，由于多載波聚合，通過車載終端中的多個LTE模塊16021和多個天線模塊 1601可以為車輛提供高速網絡傳輸，從而實現(xiàn)在車輛中進行車載視頻通話、觀看高清視頻 的活動。與現(xiàn)有技術相比，本發(fā)明實施例提高了網絡傳輸速度。
[0160] 本發(fā)明實施例中，天線模塊1601的制作工藝有多種，本發(fā)明實施例中的天線模塊 1601的制作工藝至少包括以下幾種：
[0161] 第一種
[0162] 如圖18所示，將天線模塊1601印刷在第一 PCB上，通過刻蝕的方法刻蝕第一 PCB 的金屬層，獲取天線模塊1601。也可以將天線模塊1601的圖形印刷在第一 PCB上。該天線 模塊1601通過RF(Radio Frequency，射頻）傳輸線連接至RF接口上，RF接口與LTE模塊 16021連接。LTE模塊16021通過該天線模塊1601進行收發(fā)信號。這種天線模塊1601整 體結構簡單，便于安裝。
[0163] 第二種
[0164] 如圖19所示，天線模塊1601通過刻蝕FPC形成的。通過對使用具有天線圖形的 掩膜板遮掩的FPC進行曝光，然后對曝光后的FPC上的金屬層進行刻蝕，制作成迷宮型的天 線模塊1601。FPC工藝制作的天線模塊1601，結構空間小，便于安裝，可以將該FPC通過背 膠粘貼在中控臺殼體上，如中控臺的外殼上，可以是中控臺外殼非金屬部分的外側，也可以 是中控臺非金屬部分的內側，也可以將FPC粘貼在第二PCB上。該天線模塊1601通過RF 電纜連接至RF接口上，RF接口與LTE模塊16021連接。這種天線模塊1601，具有配線密度 高，重量輕，易彎折等優(yōu)點。
[0165] 第三種
[0166] 如圖20所示，天線模塊1601是通過LDS鐳雕在結構件的殼體上形成的。使用LDS 工藝將金屬粉鐳雕至任意的結構件的殼體上，如中控臺的外殼上，可以是中控臺的外殼非 金屬部分的外側，也可以是外殼非金屬部分的內側。這種天線模塊1601可以任意設計天線 圖形，鐳雕在任意形狀的結構件的殼體上，不受產品結構形態(tài)的限制，靈活性較大，不僅可 以避免與LTE模塊16021內的金屬干擾，還可以減小LTE模塊16021的體積。該天線模塊 1601通過RF電纜連接至RF接口上，RF接口與LTE模塊16021連接。
[0167] 本發(fā)明實施例中的可以將天線模塊1601設置在中控臺中，如圖21所示，可以使用 LDS工藝將天線模塊1601的圖形鐳雕在中控臺的外殼上，可以鐳雕在中控臺的外殼外側， 也可以鐳雕在中控臺的外殼內側。如果中控臺的外殼是與中控主屏幕前后疊加組裝，外殼 單獨安裝，則將天線模塊1601設置在該外殼面對乘客一面的四個邊上。
[0168] 具體的，如圖21所示的天線模塊1601的安裝位置的結構，圖21中粗黑實體線標 注的區(qū)域為天線模塊1601可以安裝的位置，即在中控臺的外殼的四條側邊的四個角的位 置。在四個角共8個位置擺放4個天線模塊1601 (包括主路天線和輔路天線），四個角的天 線模塊1601之間距離最遠。每個角的天線模塊1601中的主路天線和輔路天線雖然距離不 是最遠，但是主路天線和輔路天線之間由于是"一橫一豎"的安裝位置，有利于極化方向隔 離，同樣可以做到兩個天線之間的隔離度很好，保證通信性能。
[0169] 如圖22所示的天線模塊1601的安裝位置的結構，圖22中粗黑實體線標注的區(qū)域 為天線模塊1601可以安裝的位置，即在中控臺的外殼的四條側邊的上，在每個側邊的1/3 位置處，共8個位置擺放4個天線模塊1601 (包括主路天線和輔路天線），這樣每個天線之 間的距離可以做到間隔最遠，從而保證每個天線之間的隔離度，保證通信性能。
[0170] 如圖23所示的天線模塊1601的安裝位置的結構，圖23中粗黑實體線標注的區(qū)域 為天線模塊1601可以安裝的位置。該中控臺的形狀為橢圓形，在中控臺的外殼的側邊上等 距離劃分8個位置，在這8個位置擺放4個天線模塊1601 (包括主路天線和輔路天線），這 樣每個天線之間的距離可以做到間隔最遠，從而保證每個天線之間的隔離度，保證通信性 能。如果中控臺的形狀為圓形，則依據(jù)上述方法進行安裝。
[0171] 由于現(xiàn)有技術中的車輛的天線系統(tǒng)都是單天線設計方案，如果需要接收到各類信 號，就需要將多個天線同時安裝在車輛上，這些天線需要安裝在車輛的車頂外部，這就增加 了車輛的不穩(wěn)定性。而與現(xiàn)有技術相比，本發(fā)明實施例可以將天線模塊1601設置在車輛的 中控臺上，無需安裝在車輛的外部，從而提高了車輛的穩(wěn)定性。
[0172] 上述天線模塊1601中的主路天線和輔路天線可以設計成輻射角小于等于180° 的定向天線。與傳統(tǒng)的汽車外置天線相比，定向天線的增益較大，可以提升輻射效率。可以 人為設計各天線的輻射角度和方向，根據(jù)實際中控單元1602在車體的位置，以及天線在中 控臺中的位置，將各個天線的輻射方向設計朝向車窗等無金屬遮擋的區(qū)域。與全向天線相 比，信號傳輸效率更高，通訊效果更好。
[0173] 本發(fā)明實施例中，中控臺的殼體的周邊可以是方形殼體的四個側邊，也可以是圓 形或橢圓形殼體的側邊。本發(fā)明實施例的中控臺的殼體不限于上述形狀，僅是示例作用。
[0174] 圖16所示，中控單元1602可以設置在第二PCB上，將多個LTE模塊16021和 CPU16022設置在第二PCB上，該多個LTE模塊16021通過第二PCB上的走線與CPU16022 連接。該LTE模塊也可以設置在第三PCB上，該LTE模塊可以通過MiniPCIE (Mini Peripheral Component Interconnect Express，小型特快外設組件互聯(lián)）接口或者其它 PCI (Peripheral Component Interconnect，外設組件互聯(lián)）接口與第二PCB上的中控單元 1602 中的 CPU16022 連接。
[0175] 中控單元1602包括N個LTE模塊16021，該N個LTE模塊16021都分別與CPU16022 連接，與CPU16022連接的LTE模塊16021的數(shù)量越多，該車載終端的性能越優(yōu)，可以是實 現(xiàn)高速通信，如10Gb/s，20Gb/s的高速通信功能。LTE模塊16021接收到的信號發(fā)送給該 CPU16022進行處理。
[0176] 在本發(fā)明實施例中，將天線模塊1601和中控單元1602設置在中控臺中，天線模塊 1601與中控單元1602之間的走線設計簡單，線束少且短，能夠減少高頻能量傳輸過程的損 耗，保證優(yōu)異的性能。
[0177] 相應地，本發(fā)明實施例還提供了一種車載終端，如圖24所示的結構，該車載終端 包括：中控單元2402和多個天線模塊2401，中控單元2402包括：CPU24022、多個LTE模塊 24021，中控單元2402中每個LTE模塊24021與至少一個天線模塊2401連接，多個LTE模 塊24021分別與CPU24022連接。
[0178] 本發(fā)明實施例通過多個LTE模塊24021通信可以為車輛提供高速網絡傳輸，實現(xiàn) 在車輛中進行車載視頻通話、觀看高清視頻的活動。
[0179] 該中控單元2402的第二PCB上設置了 CPU24022，F(xiàn)M模塊24023、GPS模塊24024、 WiFi/BT模塊24025、CMMB模塊24026,該車載終端還包括與FM模塊24023、GPS模塊24024、 WiFi/BT模塊24025、CMMB模塊24026對應的FM天線、GPS天線、WiFi/BT天線和CMMB天 線。該FM天線、GPS天線、WiFi/BT天線和CMMB天線依次通過RF傳輸線與中控單元2402 連接。
[0180] 圖25至圖27分別示出了天線模塊2401的三種設計工藝下的車載終端的結構，圖 25中的結構為天線模塊2401是PCB工藝的車載終端的結構。圖26中的結構為天線模塊 2401是FPC工藝的車載終端的結構。圖27中的結構為天線模塊2401是LDS工藝的車載終 端的結構。圖25至圖27中車載終端的具體結構已在上述實施例中描述，在此不再贅述。
[0181] 基于相同的發(fā)明構思，本發(fā)明實施例還提供了一種汽車，該汽車包括上述車載終 端，具體結構以在上述實施例中描述，在此不再贅述。
[0182] 本發(fā)明實施例提供的車載終端，通過多個天線模塊和中控單元的多個LTE模塊連 接，實現(xiàn)車載天線的高速通信的功能，LTE模塊設置在中控單元中，減少了線束的長度，可以 減少信號衰減，提升傳輸效率，減少功耗。
[0183] 以上實施例是從硬件的角度描述的具體的實施方式，本發(fā)明的技術構思還可以以 軟件的方式來實施，下面將從軟件的角度來描述本發(fā)明實施例的【具體實施方式】。
[0184] 本發(fā)明實施例提供了一種多鏈路數(shù)據(jù)傳輸?shù)姆椒?，包括發(fā)送端在與接收端進行握 手認證通過后，為握手認證過程中通知給接收端的IP (Internet Protocol，互聯(lián)網協(xié)議） 地址對應的物理鏈路建立虛擬鏈路并更新虛擬鏈路和物理鏈路的綁定關系；發(fā)送端從多條 虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路，并根據(jù)虛擬鏈路和物理鏈路的綁定關系，確 定選擇的虛擬鏈路對應的物理鏈路；發(fā)送端通過確定的物理鏈路向所述接收端發(fā)送數(shù)據(jù) 包；其中，數(shù)據(jù)包中含有虛擬鏈路對應的IP地址，多條所述虛擬鏈路對應的IP地址相同。
[0185] 其中，本發(fā)明實施例虛擬鏈路和物理鏈路的綁定關系可以設置后固定不變；也可 以根據(jù)硬件升級或用戶需要對虛擬鏈路和物理鏈路的綁定關系進行更新，具體包括但不限 于下列中的一種或多種：
[0186] 增加虛擬鏈路和/或物理鏈路；
[0187] 刪除虛擬鏈路和/或物理鏈路；
[0188] 修改虛擬鏈路和/或物理鏈路。
[0189] 本發(fā)明實施例中，發(fā)送端與接收端之間的虛擬鏈路和物理鏈路的綁定關系更新 后，發(fā)送端需要從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路。如圖28所示，本發(fā)明 實施例的第一種多鏈路數(shù)據(jù)傳輸?shù)姆椒ㄊ疽鈭D。
[0190] S2801，發(fā)送端從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；
[0191] S2802,發(fā)送端根據(jù)虛擬鏈路和物理鏈路的綁定關系，確定選擇的虛擬鏈路對應的 物理鏈路；
[0192] S2803,發(fā)送端通過確定的物理鏈路向所述接收端發(fā)送數(shù)據(jù)包；其中，數(shù)據(jù)包中含 有虛擬鏈路對應的互聯(lián)網協(xié)議IP地址，多條所述虛擬鏈路對應的IP地址相同。
[0193] 本發(fā)明實施例中，若發(fā)送端是終端時，貝接收端為VPN(Virtual Private Network，虛擬專用網）服務器；若發(fā)送端是VPN服務器時，則接收端為終端。下面分別進行 介紹。
[0194] 情況一、若發(fā)送端是終端，則接收端為VPN服務器。
[0195] 本發(fā)明實施例的終端可以是上述圖1所示的車載終端102, VPN服務器可以是上述 圖1所示的服務器101。通過圖1所示的車載終端102和服務器101可以實現(xiàn)多鏈路數(shù)據(jù) 傳輸，進行車載高速網絡傳輸，從而實現(xiàn)乘客乘車時進行高清視頻觀看或進行視頻會議等 活動。
[0196] 本發(fā)明實施例第二種多鏈路數(shù)據(jù)傳輸?shù)姆椒ㄊ疽鈭D如圖29A所示。終端在與VPN 服務器進行握手認證通過后，為握手認證過程中通知給VPN服務器的IP地址對應的物理鏈 路建立虛擬鏈路；在VPN服務器通過與通知的IP地址對應的物理鏈路建立虛擬鏈路后，終 端更新虛擬鏈路和物理鏈路的綁定關系，并將更新后的虛擬鏈路和物理鏈路的綁定關系發(fā) 送給VPN服務器，以使VPN服務器根據(jù)更新后的綁定關系更新VPN服務器內的虛擬鏈路和 物理鏈路的綁定關系；終端從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；終端根據(jù) 虛擬鏈路和物理鏈路的綁定關系，確定選擇的虛擬鏈路對應的物理鏈路并向VPN服務器發(fā) 送數(shù)據(jù)包；其中，數(shù)據(jù)包中含有虛擬鏈路對應的IP地址，多條虛擬鏈路對應的IP地址相同。
[0197] 本發(fā)明上述實施例中，在終端與VPN服務器的握手認證過程中，終端向VPN服務 器發(fā)送虛擬鏈路連接請求消息，其中虛擬鏈路連接請求消息中包含虛擬鏈路對應的源端IP 地址、目的端VPN服務器的IP地址及密鑰，在虛擬鏈路連接請求消息到達VPN服務器之后， 在VPN服務器中對虛擬鏈路請求消息中的源端IP地址、目的端VPN服務器的IP地址及密 鑰進行握手認證，在握手認證合法后，終端與VPN服務器之間握手認證通過，并將VPN服務 器端認證通過后的與虛擬鏈路連接請求消息對應的響應消息發(fā)送給終端，其中，響應消息 中包含認證通過消息。
[0198] 例如，若終端虛擬鏈路請求消息為{源端IP1，密鑰1，目的端IP2}，且VPN服務器 內的配置信息為{源端IP2,密鑰1，目的端IP1}，則指示需要與終端建立虛擬鏈路的目的端 地址為IP2且終端自身的IP地址為IP1，能夠與VPN服務器建立虛擬鏈路的目的端地址為 IP1且VPN服務器自身的IP地址為IP2,其中終端與VPN服務器之間的認證密鑰為密鑰1， 所以在進行握手認證的過程中，終端對于VPN服務器來說，屬于合法用戶之間的握手認證， 即終端與VPN服務器之間的握手認證通過。
[0199] 本發(fā)明上述實施例中，若終端虛擬鏈路請求消息為{源端IP3,密鑰1，目的端 IP2}，且VPN服務器內的配置信息為{源端IP2,密鑰1，目的端IP1}，則指示需要與終端建 立虛擬鏈路的目的端地址為IP2且終端自身的IP地址為IP1，能夠與VPN服務器建立虛擬 鏈路的目的端地址為IP1且VPN服務器自身的IP地址為IP2,雖然終端與VPN服務器之間 的認證密鑰為密鑰1，由于能夠與VPN服務器之間建立虛擬鏈路的目的端地址為IP1而不 是IP3,所以在進行握手認證的過程中，終端對于VPN服務器來說，屬于非法用戶進行的握 手認證，故終端在VPN服務器內的握手認證不合法，即終端與VPN服務器之間的握手認證失 敗。
[0200] 本發(fā)明上述實施例中，若終端虛擬鏈路請求消息為{源端IP1，密鑰1，目的端 IP2}，且VPN服務器內的配置信息為{源端IP2,密鑰2,目的端IP1}，則指示需要與終端建 立虛擬鏈路的目的端地址為IP2、密鑰為密鑰1且終端自身的IP地址為IP 1，能夠與VPN服 務器建立虛擬鏈路的目的端地址為IP 1、密鑰為密鑰2且VPN服務器自身的IP地址為IP2， 雖然終端與VPN服務器之間的握手認證的身份認證通過，由于需要與終端建立虛擬鏈路的 目的端之間的密鑰為密鑰1，能夠與VPN服務器之間建立虛擬鏈路的目的端之間的密鑰為 密鑰2而不是密鑰1，所以在進行握手認證的過程中，終端與VPN服務器之間建立虛擬鏈路 的密鑰不同，不能通過握手認證進行虛擬鏈路的建立，故終端與VPN服務器之間的握手認 證不通過，即終端與VPN服務器之間的握手認證失敗。
[0201] 在本發(fā)明實施例中，終端與VPN服務器之間的握手認證通過后，終端收到來自VPN 服務器的虛擬鏈路連接請求消息的響應消息，其中響應消息中包含握手認證通過信息，終 端根據(jù)響應消息攜帶的VPN服務器自身的IP地址對應的物理鏈路建立虛擬鏈路同時更新 虛擬鏈路和物理鏈路的綁定關系并將更新后的虛擬鏈路和物理鏈路的綁定關系發(fā)送給VPN 服務器，以使VPN服務器更新虛擬鏈路和物理鏈路的綁定關系。
[0202] 可選地，所述虛擬鏈路和物理鏈路的綁定關系為虛擬鏈路的標識和物理鏈路的IP 地址的綁定關系。
[0203] 例如，本發(fā)明實施例中的更新后的終端虛擬鏈路和物理鏈路的綁定關系如表1所 示。終端內的物理鏈路1的IP地址為IP1，與在物理鏈路1上建立的對應的虛擬鏈路的標 識為Tunnel4,所以，虛擬鏈路Tunnel4和與物理鏈路1的綁定關系為{IPl-Tunnel4};終 端內的物理鏈路2的IP地址為IP2,與在物理鏈路2上建立的對應的虛擬鏈路的標識為 Tunnel7,所以，虛擬鏈路Tunnel7和物理鏈路2的綁定關系為{IP2-Tunnel7};終端內的物 理鏈路3的IP地址為IP3,與在物理鏈路3上建立的對應的虛擬鏈路的標識為Tunnel9， 所以，虛擬鏈路Tunnel9和物理鏈路3的綁定關系為{IP3-Tunnel9}。虛擬鏈路Tunnel4、 Tunnel7、Tunnel9 的 IP 地址均為 IPn。
[0204] 表1終端虛擬鏈路和物理鏈路的綁定關系
[0205]
[0206] 在實施中，一個虛擬鏈路標識可以對應一個物理鏈路的IP地址，也可以對應多個 物理鏈路的IP地址。
[0207] 本發(fā)明實施例中，終端將與VPN服務器之間的虛擬鏈路和物理鏈路的綁定關系更 新后，終端需要從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；終端根據(jù)虛擬鏈路和 物理鏈路的綁定關系，確定選擇的虛擬鏈路對應的物理鏈路；終端通過確定的物理鏈路向 所述VPN服務器發(fā)送數(shù)據(jù)包；其中，數(shù)據(jù)包中含有虛擬鏈路對應的IP地址，多條所述虛擬鏈 路對應的IP地址相同。
[0208] 可選的，終端根據(jù)虛擬鏈路對應的鏈路質量值，從多條虛擬鏈路中選擇需要發(fā)送 數(shù)據(jù)包的虛擬鏈路時，虛擬鏈路對應的鏈路質量值是根據(jù)所述虛擬鏈路對應的物理鏈路的 鏈路參數(shù)確定的。
[0209] 需要說明的是，本發(fā)明實施例中，虛擬鏈路的物理鏈路的鏈路參數(shù)可以為以下參 數(shù)的一種或任意組合：鏈路帶寬、鏈路丟包率、鏈路延時等，以上鏈路參數(shù)指示舉例說明，并 不局限于以上幾種鏈路參數(shù)，其他能夠指示物理鏈路的鏈路參數(shù)的參數(shù)信息都將使用于本 發(fā)明實施例。
[0210] 例如，若虛擬鏈路的物理鏈路的鏈路參數(shù)只有一種鏈路參數(shù)，即鏈路帶寬，則虛擬 鏈路對應的鏈路質量值為鏈路帶寬；若虛擬鏈路的物理鏈路的鏈路參數(shù)含有2種參數(shù)時， 即鏈路帶寬與鏈路丟包率時，根據(jù)鏈路帶寬與鏈路丟包率計算鏈路帶寬與鏈路丟包率的加 權值，得到的加權值即為鏈路質量值；若虛擬鏈路的物理鏈路的鏈路參數(shù)含有3種參數(shù)時， 亦通過計算著三種參數(shù)的加權值作為鏈路質量值，并根據(jù)虛擬鏈路的物理鏈路的鏈路質量 值選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路，并根據(jù)虛擬鏈路對應的物理鏈路發(fā)送數(shù)據(jù)包。
[0211] 本發(fā)明實施例中，假設虛擬鏈路的物理鏈路的鏈路質量值僅由鏈路帶寬確定時。 若需要發(fā)送數(shù)據(jù)包1的帶寬為1. 5M，物理鏈路1的鏈路帶寬為1M，物理鏈路2的帶寬為2M， 物理鏈路1的鏈路帶寬為3M，為了使物理鏈路的鏈路帶寬得到有效利用且在不影響數(shù)據(jù)包 的傳輸速率的時候達到節(jié)省網絡帶寬的目的，本發(fā)明實施例選擇鏈路帶寬為2M的物理鏈 路2對應的虛擬鏈路進行數(shù)據(jù)包的封裝，并通過2M的物理鏈路2發(fā)送數(shù)據(jù)包。
[0212] 本發(fā)明實施例中，假設虛擬鏈路的物理鏈路的鏈路質量值由2種鏈路參數(shù)確定 時，假設這兩種參數(shù)為鏈路帶寬與鏈路丟包率。若需要發(fā)送數(shù)據(jù)包的數(shù)量不止一個數(shù)據(jù)包， 假設需要發(fā)送6個數(shù)據(jù)包且每個數(shù)據(jù)包的數(shù)據(jù)帶寬為1M時，即按照對數(shù)據(jù)包安全性傳輸?shù)?排序為：數(shù)據(jù)包1、數(shù)據(jù)包2、數(shù)據(jù)包3、數(shù)據(jù)包4、數(shù)據(jù)包5和數(shù)據(jù)包6,其中終端只有3條物 理鏈路，即物理鏈路1、物理鏈路2和物理鏈路3,其中物理鏈路1的丟包率為0. 01%，物理 鏈路2的丟包率為0. 005%，物理鏈路3的丟包率為0. 007%，且這3條物理鏈路對應的鏈 路帶寬均為1M，根據(jù)上述6個數(shù)據(jù)包對數(shù)據(jù)安全性的要求，選擇物理鏈路2、物理鏈路3及 物理鏈路1分別傳輸數(shù)據(jù)包1、數(shù)據(jù)包2及數(shù)據(jù)包3 ;然后繼續(xù)選擇物理鏈路2、物理鏈路3 及物理鏈路1分別傳輸數(shù)據(jù)包4、數(shù)據(jù)包5及數(shù)據(jù)包6 ;通過終端與VPN服務器之間的多條 物理鏈路對數(shù)據(jù)包的傳輸實現(xiàn)了默認網絡路由下的多鏈路數(shù)據(jù)傳輸，有效地利用了網絡鏈 路資源。若需要發(fā)送的數(shù)據(jù)包只有一個，則按照物理鏈路的丟包率與鏈路帶寬的加權值，確 定選擇物理鏈路2進行數(shù)據(jù)包的發(fā)送，節(jié)省傳輸數(shù)據(jù)的網絡資源。
[0213] 本發(fā)明實施例中，終端在通過確定的物理鏈路向VPN服務器發(fā)送數(shù)據(jù)包之前，還 需要對需要發(fā)送的數(shù)據(jù)包通過L1TP (Layer 2Tunneling Protocol，二層隧道協(xié)議）協(xié)議進 行封裝，將封裝后的數(shù)據(jù)包通過虛擬鏈路對應的物理鏈路進行數(shù)據(jù)的傳輸。
[0214] 需要說明的是，本發(fā)明實施例的上述對需要發(fā)送數(shù)據(jù)包的封裝協(xié)議只是舉例說 明，并不局限于上述封裝協(xié)議，其他能夠對需要發(fā)送的數(shù)據(jù)包的封裝協(xié)議都適用本發(fā)明實 施例。
[0215] 下面以通過L2TP協(xié)議對數(shù)據(jù)包進行封裝為例進行說明。終端通過L2TP協(xié)議為需 要傳輸?shù)臄?shù)據(jù)幀添加 L2TP報頭，需要傳輸?shù)臄?shù)據(jù)幀封裝成L2TP數(shù)據(jù)幀，并為L2TP數(shù)據(jù)幀 添加 UDP報頭，形成UDP報文；將UDP報文添加終端公網IP報頭，將UDP報文封裝成在VPN 虛擬鏈路上傳輸?shù)墓WIP報文，通過在物理鏈路上建立的L2TP虛擬鏈路對應的物理鏈路 將UDP報文作為終端數(shù)據(jù)從終端側傳輸至VPN服務器側，VPN服務器將收到的UDP報文依 次去UDP報頭和L2TP報頭得到需要傳輸?shù)臄?shù)據(jù)幀；其中，UDP報文中包含公網IP報文；公 網IP報文中含有終端的IP地址和目的端VPN服務器IP地址，還含有所選物理鏈路的IP 地址，以及虛擬鏈路的標識。通過物理鏈路對應的虛擬鏈路傳輸所述IP報文至服務器。
[0216] 其中，本發(fā)明實施例中終端的IP地址為虛擬鏈路對應的IP地址，本發(fā)明實施例虛 擬鏈路對應的IP地址對應至少一條物理鏈路的實際IP地址。本發(fā)明實施例終端通過VPN 服務器的IP地址可以準確定位到對應的VPN服務器。
[0217] 高層通過虛擬鏈路對應的IP地址可以將需要發(fā)送的數(shù)據(jù)發(fā)送給對應的虛擬網 卡。每個網卡對應至少一個虛擬鏈路的標識，虛擬網卡根據(jù)虛擬鏈路的標識和物理鏈路的 IP地址的綁定關系，可以確定高層的數(shù)據(jù)需要通過哪個物理鏈路發(fā)送。
[0218] 可選的，在終端檢測到物理鏈路對應的虛擬鏈路飽和后，將該虛擬鏈路對應的數(shù) 據(jù)包通過其他虛擬鏈路對應的物理鏈路發(fā)送，并在飽和的虛擬鏈路恢復后，將恢復的虛擬 鏈路對應的數(shù)據(jù)包通過恢復的虛擬鏈路對應物理鏈路發(fā)送。
[0219] 其中，虛擬鏈路飽和為虛擬鏈路當前傳輸?shù)臄?shù)據(jù)量達到虛擬鏈路設定的數(shù)據(jù)量的 上線。
[0220] 情況二、若發(fā)送端是VPN服務器，則接收端為終端。
[0221] 本發(fā)明實施例的終端可以是上述圖1所示的車載終端102, VPN服務器可以是上述 圖1所示的服務器101。通過圖1所示的車載終端102和服務器101可以實現(xiàn)多鏈路數(shù)據(jù) 傳輸，進行車載高速網絡傳輸，從而實現(xiàn)乘客乘車時進行高清視頻觀看或進行視頻會議等 活動。
[0222] 本發(fā)明實施例第三種多鏈路數(shù)據(jù)傳輸?shù)姆椒ㄈ鐖D29B所示。VPN服務器在與終端 進行握手認證通過后，為握手認證過程中通知給終端的IP地址對應的物理鏈路建立虛擬 鏈路；在終端通過與通知的IP地址對應的物理鏈路建立虛擬鏈路后，VPN服務器更新虛擬 鏈路和物理鏈路的綁定關系，并將更新后的虛擬鏈路和物理鏈路的綁定關系發(fā)送給終端， 以使終端根據(jù)更新后的綁定關系更新終端內的虛擬鏈路和物理鏈路的綁定關系；VPN服務 器從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；VPN服務器根據(jù)虛擬鏈路和物理鏈 路的綁定關系，確定選擇的虛擬鏈路對應的物理鏈路并向終端發(fā)送數(shù)據(jù)包；其中，數(shù)據(jù)包中 含有虛擬鏈路對應的IP地址，多條虛擬鏈路對應的IP地址相同。
[0223] 本發(fā)明上述實施例中，在VPN服務器與終端的握手認證過程中，VPN服務器向終 端發(fā)送虛擬鏈路連接請求消息，其中虛擬鏈路連接請求消息中包含虛擬鏈路對應的源端IP 地址、目的端VPN服務器的IP地址及密鑰，在虛擬鏈路連接請求消息到達終端之后，在終端 中對虛擬鏈路請求消息中的源端IP地址、目的端終端的IP地址及密鑰進行握手認證，在握 手認證合法后，VPN服務器與終端之間握手認證通過，并將終端認證通過后的與虛擬鏈路連 接請求消息對應的響應消息發(fā)送給VPN服務器，其中，響應消息中包含認證通過消息。其 中，VPN服務器與終端之間進行握手認證的具體實施過程與情況一相同，這里不再贅述。
[0224] 在本發(fā)明實施例中，VPN服務器與終端之間的握手認證通過后，VPN服務器收到來 自終端的虛擬鏈路連接請求消息的響應消息，其中響應消息中包含握手認證通過信息，VPN 服務器根據(jù)響應消息攜帶的終端自身的IP地址對應的物理鏈路建立虛擬鏈路同時更新虛 擬鏈路與物理鏈路的綁定關系并將更新后的虛擬鏈路與物理鏈路的綁定關系發(fā)送給終端， 以使終端更新虛擬鏈路與物理鏈路的綁定關系。
[0225] 可選地，所述虛擬鏈路和物理鏈路的綁定關系為虛擬鏈路的標識和物理鏈路的IP 地址的綁定關系。
[0226] 本發(fā)明實施例中，更新后的VPN服務器虛擬鏈路和物理鏈路的綁定關系與情況一 表1中的虛擬鏈路和物理鏈路的綁定關系一致，這里不再舉例贅述。本發(fā)明實施例中，VPN 服務器將與終端之間的虛擬鏈路與物理鏈路的綁定關系更新后，VPN服務器需要從多條虛 擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；VPN服務器根據(jù)虛擬鏈路和物理鏈路的綁定關 系，確定選擇的虛擬鏈路對應的物理鏈路；VPN服務器通過確定的物理鏈路向所述終端發(fā) 送數(shù)據(jù)包；其中，數(shù)據(jù)包中含有虛擬鏈路對應的IP地址，多條所述虛擬鏈路對應的IP地址 相同。
[0227] 可選的，VPN服務器根據(jù)虛擬鏈路對應的鏈路質量值，從多條虛擬鏈路中選擇需要 發(fā)送數(shù)據(jù)包的虛擬鏈路時，虛擬鏈路對應的鏈路質量值是根據(jù)所述虛擬鏈路對應的物理鏈 路的鏈路參數(shù)確定的。
[0228] 在實施中，本發(fā)明實施例的終端可以是移動設備，比如手機、平板電腦等；還可以 是車載移動設備。采用本發(fā)明實施例的方案應用于車載移動設備中，可以通過多個虛擬鏈 路發(fā)送數(shù)據(jù)，提高了車載系統(tǒng)中帶寬的利用率，該車載天線系統(tǒng)的網絡傳輸速度可以比2G 模式和3G模式下的天線系統(tǒng)的網絡傳輸速度要快，從而可以為車輛提供高速網絡傳輸，實 現(xiàn)在車輛中進行車載視頻通話、觀看高清視頻的活動。
[0229] 本發(fā)明實施例中，VPN服務器根據(jù)虛擬鏈路對應的物理鏈路的鏈路參數(shù)確定虛擬 鏈路的鏈路質量值的確定方法與情況一中確定虛擬鏈路的鏈路質量值的方法相同，這里不 再詳細贅述。
[0230] 本發(fā)明實施例中，VPN服務器在通過確定的物理鏈路向終端發(fā)送數(shù)據(jù)包之前，還需 要對需要發(fā)送的數(shù)據(jù)包通過L1TP協(xié)議進行封裝，將封裝后的數(shù)據(jù)包通過虛擬鏈路對應的 物理鏈路進行數(shù)據(jù)的傳輸。
[0231] 本發(fā)明實施例中，VPN服務器對訪問到的網絡數(shù)據(jù)包在發(fā)送給終端之前需要通過 L2TP協(xié)議進行數(shù)據(jù)包的封裝，由于VPN服務器對訪問到的網絡數(shù)據(jù)包通過L2TP協(xié)議封裝的 方法與情況一中的對需要訪問網絡數(shù)據(jù)包的封裝方法是相同的，這里不再贅述。
[0232] 可選的，在VPN服務器檢測到虛擬鏈路飽和后，將該虛擬鏈路對應的數(shù)據(jù)包通過 其他虛擬鏈路對應的物理鏈路發(fā)送，并在飽和的虛擬鏈路恢復后，將恢復的虛擬鏈路對應 的數(shù)據(jù)包通過恢復的虛擬鏈路對應物理鏈路發(fā)送。
[0233] 本發(fā)明的上述實施例中，VPN服務器在與終端之間的多條物理鏈路上建立對應的 虛擬鏈路，并將虛擬鏈路和物理鏈路的綁定關系分別放入到VPN服務器與終端；VPN服務器 在接收到與需要發(fā)送的數(shù)據(jù)包時，從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；VPN 服務器根據(jù)虛擬鏈路和物理鏈路的綁定關系，確定選擇的虛擬鏈路對應的物理鏈路；VPN 服務器通過確定的物理鏈路向終端發(fā)送數(shù)據(jù)包；其中，數(shù)據(jù)包中含有虛擬鏈路對應的IP地 址，多條虛擬鏈路對應的IP地址相同。在進行數(shù)據(jù)包的傳輸時，利用了每條物理鏈路的鏈 路帶寬，使VPN服務器的網絡帶寬為每條物理鏈路的鏈路帶寬的總和，并利用建立的與物 理鏈路對應的虛擬鏈路保證了數(shù)據(jù)連接的穩(wěn)定性；由于VPN服務器通過根據(jù)虛擬鏈路和物 理鏈路的綁定關系確定選擇的虛擬鏈路對應的物理鏈路向終端發(fā)送數(shù)據(jù)包，使得默認路由 下的多網絡接口通過與虛擬鏈路對應的物理鏈路實現(xiàn)數(shù)據(jù)的多鏈路傳輸，從而有效利用多 鏈路網絡資源，提高數(shù)據(jù)傳輸速率。
[0234] 為了使本發(fā)明所解決的技術問題、技術方案以及有益效果更加清楚明白，以下結 合附圖及實施例，對本發(fā)明進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以 解釋本發(fā)明，并不用于限定本發(fā)明。
[0235] 本發(fā)明實施例中，假設終端設備可以同時接入三個運營商的無線網絡，分別為聯(lián) 通、移動、電信，當終端向VPN服務器撥號完成后，終端設備中有三個物理網卡。在上述三個 物理網卡上建立L2TP虛擬網卡，并建立管理L2TP虛擬網卡中各接口的接口列表；將建立成 功的接口加入到接口列表中，為L2TP虛擬網卡增加一條發(fā)送及接收數(shù)據(jù)的虛擬鏈路。在接 口列表中指定虛擬網卡的數(shù)據(jù)發(fā)送函數(shù)及接收函數(shù)；其中，發(fā)送函數(shù)實現(xiàn)對接口列表的網 卡遍歷，并從接口列表中選擇一個L2TP虛擬網卡進行數(shù)據(jù)的封包發(fā)送；接收函數(shù)實現(xiàn)對數(shù) 據(jù)包進行解包，解析出真實的目的IP地址并進行數(shù)據(jù)轉發(fā)。在需要對數(shù)據(jù)進行轉發(fā)之前， 需要建立網絡鏈路相關操作進行網卡數(shù)據(jù)的便利，并增加網卡狀態(tài)監(jiān)聽事件；其中，當遍歷 到的網卡且監(jiān)聽到UP事件的網卡，對所述網卡進行虛擬鏈路及接口的建立；當監(jiān)聽到DOWN 事件，則進行虛擬鏈路及接口的釋放。
[0236] 本發(fā)明上述實施例中，若各網卡分別向一個VPN服務器進行L2TP撥號，其中，配置 VPN服務器虛擬網卡IP地址為10. 252. 1. 1，在VPN服務器虛擬網卡上開啟DHCP (Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議）服務器對VPN服務器配置虛擬網卡 IP地址。在終端虛擬網卡上啟動DHCP用戶端，若在終端虛擬網卡中的接口列表中有到VPN 服務器的虛擬鏈路，終端虛擬網卡就會獲取到10. 252. 1. 1的IP地址，并從終端虛擬網卡中 選擇相應的虛擬鏈路進行數(shù)據(jù)包的轉發(fā)。終端根據(jù)虛擬鏈路對應的物理網卡的網絡質量值 來選擇相應的虛擬鏈路；其中通過各物理網卡的網絡參數(shù)的加權值得到虛擬鏈路對應的網 絡質量值。若需要發(fā)送的數(shù)據(jù)包為2. 5M數(shù)據(jù)，假設聯(lián)通物理網卡、移動物理網卡及電信物 理網卡的鏈路帶寬均為1M，若需要發(fā)送的數(shù)據(jù)包為2. 5M數(shù)據(jù)，則采用這三個物理網卡同時 對數(shù)據(jù)包進行轉發(fā)，即此時發(fā)送數(shù)據(jù)包的物理網卡的鏈路帶寬為這三個物理網卡帶寬之和 3M，使得需要發(fā)送的數(shù)據(jù)包通過終端虛擬網卡中的這三個物理網卡實現(xiàn)了對數(shù)據(jù)的多鏈路 傳輸，從而有效利用多鏈路網絡資源，提高數(shù)據(jù)傳輸速率。
[0237] 本發(fā)明上述實施例中，假設假設聯(lián)通物理網卡、移動物理網卡及電信物理網卡的 鏈路帶寬均為1M，且上述物理網卡對應的虛擬鏈路的丟包率和鏈路延時的加權值分別為 0.07、0.05、0.01，若需要發(fā)送的數(shù)據(jù)有6個數(shù)據(jù)包，其中每個數(shù)據(jù)包帶寬為說且數(shù)據(jù)包1 至數(shù)據(jù)包6對數(shù)據(jù)可靠性傳輸?shù)囊髲母叩降蜑閿?shù)據(jù)包1、數(shù)據(jù)包2、數(shù)據(jù)包3、數(shù)據(jù)包4、數(shù) 據(jù)包5、數(shù)據(jù)包6,則根據(jù)網絡鏈路質量值選擇相應的虛擬鏈路對應的物理網卡實現(xiàn)對數(shù)據(jù) 的傳輸，則有通過電信物理網卡傳輸數(shù)據(jù)包1，移動物理網卡傳輸數(shù)據(jù)包2,聯(lián)通物理網卡 傳輸數(shù)據(jù)包3,再通過電信物理網卡傳輸數(shù)據(jù)包4,移動物理網卡傳輸數(shù)據(jù)包5,聯(lián)通物理網 卡傳輸數(shù)據(jù)包6,從而通過上述三個物理網卡實現(xiàn)對數(shù)據(jù)包的多鏈路傳輸，有效利用多鏈路 網絡資源，提高數(shù)據(jù)傳輸速率。
[0238] 基于相同的技術構思，本發(fā)明實施例提供一種多鏈路數(shù)據(jù)傳輸?shù)脑O備，所述設備 可執(zhí)行上述方法實施例。本發(fā)明實施例一種多鏈路數(shù)據(jù)傳輸?shù)脑O備結構圖如圖30所示。
[0239] 本發(fā)明實施例提供的一種多鏈路數(shù)據(jù)傳輸?shù)脑O備，該設備包括：
[0240] 處理模塊3001，用于從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；
[0241] 確定模塊3002,用于根據(jù)虛擬鏈路和物理鏈路的綁定關系，確定選擇的虛擬鏈路 對應的物理鏈路；
[0242] 發(fā)送模塊3003,用于通過確定的物理鏈路向所述接收端發(fā)送數(shù)據(jù)包；其中，所述 數(shù)據(jù)包中含有虛擬鏈路對應的互聯(lián)網協(xié)議IP地址，多條所述虛擬鏈路對應的IP地址相同。
[0243] 本發(fā)明實施例中，若該設備為終端，則接收端為VPN服務器；若該設備是VPN服務 器，則接收端為終端。
[0244] 本發(fā)明實施例的終端可以是上述圖1所示的車載終端102, VPN服務器可以是上述 圖1所示的服務器101。通過圖1所示的車載終端102和服務器101可以實現(xiàn)多鏈路數(shù)據(jù) 傳輸，進行車載高速網絡傳輸，從而實現(xiàn)乘客乘車時進行高清視頻觀看或進行視頻會議等 活動。
[0245] 可選的，所述確定模塊3002具體用于：
[0246] 確定虛擬鏈路和物理鏈路的綁定關系為虛擬鏈路的標識和物理鏈路的IP地址的 綁定關系。
[0247] 可選的，所述處理模塊3001還用于：
[0248] 在與所述接收端進行握手認證通過后，確定握手認證過程中通知給所述接收端的 IP地址，并為確定的所述IP地址對應的物理鏈路建立虛擬鏈路；
[0249] 更新所述虛擬鏈路和物理鏈路的綁定關系，并將更新后的所述虛擬鏈路和物理鏈 路的綁定關系發(fā)送給所述接收端。
[0250] 可選的，所述處理模塊3001還用于：
[0251] 在需要為接收端進行握手認證后，對接收端進行握手認證，并將握手認證通過，且 確定能夠為所述接收端通知的IP地址對應的物理鏈路建立虛擬鏈路后，通知所述接收端；
[0252] 收到來自所述接收端更新后的所述虛擬鏈路和物理鏈路的綁定關系。
[0253] 可選的，所述確定模塊3002還用于：
[0254] 在檢測到虛擬鏈路飽和后，將該虛擬鏈路對應的數(shù)據(jù)包通過其他虛擬鏈路對應的 物理鏈路發(fā)送，并在飽和的虛擬鏈路恢復后，將恢復的虛擬鏈路對應的數(shù)據(jù)包通過恢復的 虛擬鏈路對應物理鏈路發(fā)送。
[0255] 可選的，所述確定模塊3002還用于：
[0256] 在所述接收端通知釋放的虛擬鏈路后，更新所述虛擬鏈路和物理鏈路的綁定關 系。
[0257] 可選的，所述處理模塊3001具體用于：
[0258] 根據(jù)虛擬鏈路對應的鏈路質量值，從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬 鏈路；其中，所述虛擬鏈路對應的鏈路質量值是根據(jù)所述虛擬鏈路對應的物理鏈路的鏈路 參數(shù)確定的。
[0259] 本發(fā)明的上述實施例中，VPN服務器在與終端之間的多條物理鏈路上建立對應的 虛擬鏈路，并將虛擬鏈路和物理鏈路的綁定關系分別放入到VPN服務器與終端；VPN服務器 在接收到與需要發(fā)送的數(shù)據(jù)包時，從多條虛擬鏈路中選擇需要發(fā)送數(shù)據(jù)包的虛擬鏈路；VPN 服務器根據(jù)虛擬鏈路和物理鏈路的綁定關系，確定選擇的虛擬鏈路對應的物理鏈路；VPN 服務器通過確定的物理鏈路向終端發(fā)送數(shù)據(jù)包；其中，數(shù)據(jù)包中含有虛擬鏈路對應的IP地 址，多條虛擬鏈路對應的IP地址相同。在進行數(shù)據(jù)包的傳輸時，利用了每條物理鏈路的鏈 路帶寬，使VPN服務器的網絡帶寬為每條物理鏈路的鏈路帶寬的總和，并利用建立的與物 理鏈路對應的虛擬鏈路保證了數(shù)據(jù)連接的穩(wěn)定性；由于VPN服務器通過根據(jù)虛擬鏈路和物 理鏈路的綁定關系確定選擇的虛擬鏈路對應的物理鏈路向終端發(fā)送數(shù)據(jù)包，使得默認路由 下的多網絡接口通過與虛擬鏈路對應的物理鏈路實現(xiàn)數(shù)據(jù)的多鏈路傳輸，從而有效利用多 鏈路網絡資源，提高數(shù)據(jù)傳輸速率。
[0260] 以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可 以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單 元，即可以位于一個地方，或者也可以分布到多個網絡單元上?？梢愿鶕?jù)實際的需要選擇其 中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性 的勞動的情況下，即可以理解并實施。
[0261] 通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到各實施方式可 借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件?；谶@樣的理解，上 述技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產品的形式體現(xiàn)出來，該 計算機軟件產品可以存儲在計算機可讀存儲介質中，如R0M/RAM、磁碟、光盤等，包括若干指 令用以使得一臺計算機設備（可以是個人計算機，服務器，或者網絡設備等）執(zhí)行各個實施 例或者實施例的某些部分所述的方法。
[0262] 最后應說明的是：以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡 管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解：其依然 可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替 換；而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明各實施例技術方案的精 神和范圍。
【主權項】
1. 一種車載音視頻傳輸方法，其特征在于，包括： 車載終端獲取服務器發(fā)送的音視頻傳輸請求； 所述車載終端根據(jù)所述音視頻傳輸請求，通過多條物理鏈路與所述服務器建立連接； 所述車載終端接收所述服務器發(fā)送的多個音視頻數(shù)據(jù)包； 所述車載終端將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行解碼輸 出。2. 根據(jù)權利要求1所述的方法，其特征在于，所述車載終端根據(jù)所述音視頻傳輸請求， 通過多條物理鏈路與所述服務器建立連接，包括： 所述車載終端根據(jù)所述音視頻傳輸請求，通過每一條物理鏈路與所述服務器進行握手 認證，建立連接。3. 根據(jù)權利要求1所述的方法，其特征在于，所述車載終端將所述多個音視頻數(shù)據(jù)包 進行合并為一路音視頻數(shù)據(jù)流，包括： 所述車載終端根據(jù)每個音視頻數(shù)據(jù)包中的標識字段，將具有同一標識字段的所述多個 音視頻數(shù)據(jù)包合并為一路音視頻數(shù)據(jù)流。4. 一種車載音視頻傳輸方法，其特征在于，包括： 服務器向車載終端發(fā)送音視頻傳輸請求； 所述服務器通過多條物理鏈路與所述車載終端建立連接； 所述服務器根據(jù)每條所述物理鏈路的鏈路參數(shù)，向所述車載終端發(fā)送多個音視頻數(shù)據(jù) 包。5. 根據(jù)權利要求4所述的方法，其特征在于，所述服務器根據(jù)每條所述物理鏈路的鏈 路參數(shù)，向所述車載終端發(fā)送多個音視頻數(shù)據(jù)包，包括： 所述服務器根據(jù)每條所述物理鏈路的鏈路參數(shù)，選擇每條所述物理鏈路傳輸?shù)乃鲆?視頻數(shù)據(jù)包的個數(shù)，向所述車載終端發(fā)送多個音視頻數(shù)據(jù)包。6. 根據(jù)權利要求4或5所述的方法，其特征在于，所述物理鏈路參數(shù)包括下述參數(shù)之一 或任意組合： 往返時延、鏈路帶寬、鏈路類型。7. -種車載終端，其特征在于，包括： 獲取單元，用于獲取服務器發(fā)送的音視頻傳輸請求； 連接單元，用于根據(jù)所述音視頻傳輸請求，通過多條物理鏈路與所述服務器建立連 接； 接收單元，用于接收所述服務器發(fā)送的多個音視頻數(shù)據(jù)包； 處理單元，用于將所述多個音視頻數(shù)據(jù)包進行合并為一路音視頻數(shù)據(jù)流，進行解碼輸 出。8. 根據(jù)權利要求7所述的車載終端，其特征在于，所述連接單元具體用于： 根據(jù)所述音視頻傳輸請求，通過每一條物理鏈路與所述服務器進行握手認證，建立連 接。9. 根據(jù)權利要求7所述的車載終端，其特征在于，所述處理單元具體用于： 根據(jù)每個音視頻數(shù)據(jù)包中的標識字段，將具有同一標識字段的所述多個音視頻數(shù)據(jù)包 合并為一路音視頻數(shù)據(jù)流。10. -種服務器，其特征在于，包括： 第一發(fā)送單元，用于向車載終端發(fā)送音視頻傳輸請求； 連接單元，用于通過多條物理鏈路與所述車載終端建立連接； 第二發(fā)送單元，用于根據(jù)每條所述物理鏈路的鏈路參數(shù)，向所述車載終端發(fā)送多個音 視頻數(shù)據(jù)包。11. 根據(jù)權利要求10所述的服務器，其特征在于，第二發(fā)送單元具體用于： 所述服務器根據(jù)每條所述物理鏈路的鏈路參數(shù)，選擇每條所述物理鏈路傳輸?shù)乃鲆?視頻數(shù)據(jù)包的個數(shù)，向所述車載終端發(fā)送多個音視頻數(shù)據(jù)包。12. 根據(jù)權利要求10或11所述的服務器，其特征在于，所述物理鏈路參數(shù)包括下述參 數(shù)之一或任意組合： 往返時延、鏈路帶寬、鏈路類型。13. -種車載音視頻傳輸系統(tǒng)，其特征在于，包括權利7至9任一項所述的車載終端和 權利要求10至12任一項所述服務器。
【文檔編號】H04L29/06GK105898471SQ201510767543
【公開日】2016年8月24日
【申請日】2015年11月11日
【發(fā)明人】吳超, 付銀剛
【申請人】樂卡汽車智能科技（北京）有限公司