LTE-V2X 協議棧開發及通信測試①

郭 星, 劉建蓓, 張志偉, 惠 飛, 杜繹如, 阮仕峰, 唐書宇

1(長安大學 信息工程學院, 西安 710064)

2(中交第一公路勘察設計研究院有限公司, 西安 710065)

通信技術與智能交通系統的迅速發展使得車聯網(Internet of vehicles, IoV)成為目前的研究熱點. 車聯網能夠借助新一代通信技術, 使得車與車(vehicle to vehicle,V2V)、車與人(vehicle to pedestrian, V2P)、車與路邊設施(vehicle to infrastructure, V2I)能夠實現全方位動態信息實時交互, 即實現V2X 通信(vehicle to everything,V2X)[1], 進一步提升汽車智能化水平, 實現智能、高效、安全的智能運輸系統. 車聯網環境下, 汽車在分享自身信息的同時也接收其他汽車的信息及路況信息, 從而增強自身的環境感知能力達到協同控制, 對駕駛員提前預警潛在的危險, 減少交通事故、交通堵塞的發生.

目前, 行業內對于V2X 通信技術路線包括兩條,一條是基于IEEE1609 系列標準的車載環境無線接入(wireless access in vehicular environment, WAVE)技術,是一種由IEEE 制定的專用于車聯網環境中的無線接入技術. WAVE 理論研究發展較早, 目前在歐美、日本積極開展了相關的技術研究以及測試工作. 另一條技術路線是由我國主導推動的基于3GPP R14 的長期演進車對外界信息交互技術LTE-V2X (long term evolutionvehicle to everything)[2,3]. 2017 年3 月, 3GPP完成了Release 14 版本的LTE-V2X 標準化[4], 其作為面向車路協同的通信綜合解決方案, 在高速移動環境中實現低時延、高可靠、高速率、安全的通信, 滿足車聯網的多種應用. 而目前在國內, 正處于LTE-V2X 相關標準制定階段, 主要以大唐、華為、高通等通信產業鏈企業、車企和電信運營商為主的產業陣營推進發展[5].

LTE-V2X 對LTE 蜂窩網絡環境下的車輛主動安全應用進行了通信優化, 采用蜂窩方式與直通方式相結合的方式, 支持包括V2I、V2V、V2P 等各類場景應用. 蜂窩式利用基站作為集中式的控制中心和數據信息轉發中心, 來完成集中式調度、擁塞控制和干擾協調[6], 用戶設備通過上行鏈路(uplink, UL)向基站傳輸V2X 消息, 基站再通過下行鏈路(downlink, DL) 將V2X 消息傳輸給其他用戶設備, 用戶設備與基站之間通過Uu 接口通信. 直通式加入了副鏈路(sidelink,SL)的概念, 使得車輛消息不需要經過基站的轉發, 通過設備到設備通信接口PC5 完成車車之間的直接通信. LTE-V2X 中, 可以設置普通路側單元(road side unit, RSU)和基站類型的RSU, 兩種RSU 與用戶設備通信所使用的接口不同, 從而進一步增強對各類V2X操作場景的支持. 如圖1 為LTE-V2X 的應用場景, 在該場景中, 基站類型RSU 發揮中繼功能作用, 通過基站轉發無線蜂窩數據, 在車輛間進行數據交換, 這種方式采用LTE-V2X-Cell 相關協議, 而當需要車車直接進行通信時, 采用LTE-V2X-Direct 相關協議完成數據交換.

圖1 LTE-V2X 車聯網場景

國內對于車聯網研究起步相對較晚, 但發展勢頭迅猛. 為實現車聯網通信, 行業內一些相關的車企及終端設備廠商也紛紛推出各自支持國標協議棧的V2X通信終端, 如萬集科技、東軟、星云互聯以及高新興等. 然而由于在技術標準中相關規定較泛化, 導致不同企業在開發過程中對標準的理解有偏差, 出現定位信息不準確、通信設備底層硬件不兼容、消息幀結構不一致、通信性能不穩定等問題[7], 產品體系結構間存在差異, 因此目前還不能實現全面互聯互通, V2X 通信產品的商業化規模應用仍需努力推進. 國內一些高校和科研機構也在車聯網方面展開研究, 這些研究主要集中在理論分析與模型仿真中[8], 也有部分試驗場內部測試[9]與車聯網終端設計[10,11], 但都缺少LTE-V2X 協議棧的設計與實現以及針對協議棧的通信測試. 因此, 設計一款滿足協議要求、實現可靠通信的LTE-V2X 協議棧對于推進車聯網設備成熟落地具有重要意義.

1 LTE-V2X 協議棧總體設計

LTE-V2X 協議棧是實現V2X 通信的前提, 采集到的車輛狀態信息和位置信息由協議棧進行編碼封裝,并通過不同的空中接口發送到其他車輛設備、路側設備或基站. 根據3GPP 發布的TS22.185[12]、TR 36.885[13]以及中國IMT-2020(5G)推進組[14]對LTE-V2X 協議棧的性能要求, LTE-V2X 協議棧應滿足的主要性能要求如表1 所示.

表1 LTE-V2X 協議棧性能要求

協議棧總體分層如圖2 所示, LTE-V2X 協議棧應該包括應用層、網絡層、數據鏈路層和物理層. 相比于WAVE 系統協議棧[15], LTE-V2X 協議棧網絡層有著明顯變化. 在WAVE 中無線資源按照信道劃分來分別提供不同的業務, 而在LTE 系統中, 無線資源都在資源池中, 發送消息時選取空閑的資源塊進行發送, 以此提高資源的利用率[16]. 因此LTE 系統沒有信道概念,即沒有WAVE 系統中信道切換相關內容, 而是增添適配層對協議棧原語進行適配.

圖2 協議棧總體分層

其中, 協議棧各層的功能為:

1) 應用層. 主要包括用戶應用和消息層, 消息層即不同的應用程序中所使用的短程無線接入專用通信消息的數據幀和數據元素的集合, 向上支持用戶應用, 向下對接網絡層.

2) 網絡層. 網絡層由數據子層和管理子層兩部分構成. 數據子層傳輸應用間的數據流, 以及不同管理實體間或管理實體與用戶應用間的數據流. 管理子層主要實現系統配置與維護功能.

2 硬件平臺設計

通過對協議棧總體功能以及協議棧各層進行分析,協議棧硬件平臺設計應包含兩部分: 搭載協議棧的主控平臺和通信模組. 其中, 網絡層以上的相關協議在主控平臺運行, 網絡層以下的數據發送與傳輸由通信模組實現.

考慮到車聯網主控平臺需要具備優異處理能力以及低功耗低成本等特性, 本文采用恩智浦處理器平臺IMX6QP 搭建協議棧主控平臺. 該處理器是基于Cortex A9 架構的4 核ARM 芯片, 運行頻率可達1.2 GHz, 性能優越, 并且該平臺提供高清多媒體接口(high definition multimedia interface, HDMI)、全球定位系統(global positioning system, GPS)接口、千兆以太網接口及用于汽車應用的車輛控制器局域網(controller area network,CAN)接口等, 滿足擴展需求, 適合汽車應用開發.

通信模組采用中興通訊的ZM8350 通信模組, 該模組支持5.9 GHz 頻段的單PC5 接口, 可驅動V2V,V2I 以及V2P 的信息交換, 并支持高精度定位. 定位模塊采用北斗接收機, 可接收北斗系統和GPS 系統的定位數據. 設備整體圖與具體硬件組成如圖3 所示, 其中通信模組與主控平臺固定置于設備內部.

圖3 設備硬件組成

3 LTE-V2X 協議棧設計

V2X 消息構造以及消息內容填充是協議棧需要實現的主要功能. 上層應用通過協議棧接口對協議棧進行消息注入與傳出, 通過創建本地套接字方式進行通信. 圖4 為協議棧數據流, 其中車聯網相關信息由傳感器采集, 在消息層創建消息幀并填充, 消息幀編碼后送入網絡層, 網絡層根據消息類型對消息幀進行封裝并送入接入層, 接入層對數據包封裝后交給物理層由相應的空中接口發送. 在接收端, 接入層在指定頻段接收到數據包后先進行篩選, 拆封幀頭送入網絡層, 網絡層根據數據子層封裝的幀頭再次篩選, 剝離數據子層幀頭送入應用層解碼, 最終將信息交給上層應用.

圖4 協議棧數據流

協議棧各層之間均為模塊化設計, 每一層開發完成后都進行獨立封裝, 每層暴露相關接口與其他層進行交互.

3.1 協議棧網絡層設計

協議棧網絡層是協議棧核心內容, 包括數據子層和管理子層兩部分, 圖5 為管理子層與數據子層主要操作流程. 管理子層實現對消息訂閱者以及提供者的管理, 并對消息訂閱者及提供者發出的請求進行處理,生成專用業務公告(dedicated service advertisement,DSA)消息. 數據子層是協議棧的關鍵協議, 負責對應用層傳輸的消息進行封裝, 并對MAC 層的消息進行解封, 再按照消息中幀頭規定的參數對數據進行傳遞, 最終形成專用短消息(dedicated short message, DSM). 數據子層的設計中, 有關接入層的相關接口由通信模組提供. 管理子層和數據子層處于并列狀態, 管理子層和數據子層的具體設計需根據各自功能來完成.

圖5 管理子層與數據子層相關操作

3.1.1 管理子層設計

管理子層說明如何獲取消息傳輸時需要的參數,其中專用管理實體(dedicated management entity,DME)負責不同通信實體之間的調度, 包含4 項功能:應用注冊、根據應用要求發送或接收DSA、管理信息庫(management information base, MIB)配置與維護, 各項功能的具體設計如下.

1) 應用注冊

上層應用需先在DME 處注冊成為一個用戶應用后, 才可以使得DME 管理DSM.

2) 短消息服務管理

車聯網通信中, 上層應用需要發送DSM 到其他設備, DME 接受請求后, 在管理信息庫中生成對應的服務請求條目, 上層應用將相關數據傳入數據子層, 由專用短消息協議(dedicated short message protocol, DSMP)創建DSM 幀頭, 適配層創建適配層幀頭. 在接收端接收到DSM 時, DME 識別DSM 中的應用標識, 篩選收到的DSM 是否為上層應用所感興趣的, 從而決定是否采用該DSM 幀.

3) 業務公告服務管理

DSA 用于向車輛用戶廣播可選服務信息, 發送端上層應用向DME 發起服務請求, DME 在管理信息庫生成請求條目. 由于DME 不具備直接向接入層傳遞數據幀的能力, DME 根據請求生成DSA 并向DSMP 發起請求, 之后在數據子層由DSMP 進行下一步封裝,DSA 幀構建流程如圖6, DSA 幀頭定義為struct DME_DSA_Hdr, 包含DSA 幀頭定義及DSA 擴展域定義. DSA消息的幀包含幀頭和應用信息兩部分, 這些內容都應封裝在DSM 的data 部分, 與設置好的DSM 幀頭一同打包, 通過套接字發送. 在接收端想要接收感興趣的消息時, 同樣向DME 發起服務請求, 由DME 判斷該公告是否有感興趣的內容從而選擇是否采用.

圖6 DSA 幀構建流程

4) MIB 配置與維護

MIB 負責對協議棧的應用配置信息及狀態信息進行存儲與維護, DME 可通過發起查詢或設置請求對MIB進行操作. MIB 數據庫結構體定義為struct tDMEMIB,聲明數據庫中各項數據并存儲臨時MIB 數據. DME_MIB_Set()與DME_MIB_Get()函數分別用于將管理數據庫信息保存到MIB 文件或讀取MIB 文件, 業務的應用標識對應一個MIB 信息表.

3.1.2 數據子層設計

數據子層包括DSMP 和適配層. DSMP 主要功能是在不同通信實體間傳輸數據. 數據從一個通信實體發送, 通過請求原語request, 分別經過應用層、網絡層、數據鏈路層和物理層逐層完成數據的傳遞, 數據在底層通過空中接口發送, 到達接收端的接入層, 在接收端實體再經過逐層傳遞, 最終將數據傳輸到接收端的應用層, 交付給各個應用.

當數據從上層應用層接入之后, 首先封裝DSM 幀頭, DSM 幀頭用來標定數據在向上層以及下層傳輸的部分參數, 包括DSMP 版本、可選域指示、預留、擴展域、應用標識、數據長度以及數據, DSM 幀頭定義為struct DSMP_Hdr, 并嵌套DSMP 擴展域結構體struct DSMP_Ext, DSM 消息幀結構如圖7. 其中數據部分以及數據長度都是由應用層處理, 并進行數據的填充和封裝. 本文中DSMP 版本取值為0, DSMP 可選域指示取值為1 表示后面的擴展域出現, 取值為0 表示后面的擴展域不出現. 其中, 預留域的預留比特取值0,擴展域預留可用于其他信息, 包含其他信息標識、其他信息長度和其他信息內容3 部分, 應用標識AID 用于區分應用服務商的各種不同應用. 數據長度表示應用層數據實體的字節長度, 數據即為數據實體. 構建不同DSM 幀頭接口的定義見表2.

圖7 DSM 消息幀結構

表2 DSMP 幀頭創建相關接口

適配層的功能是提供底層接入技術與上層之間的傳輸適配, 接收由上層發來的DME 數據包或DSMP數據包, 根據待發送數據包所使用底層接口的不同, 將數據包傳輸到對應的底層接入接口并傳輸數據包, 或根據底層接入的數據包區分其相應的上層協議類型, 將數據包遞交給上層協議棧. 如果適配層無法區分接受到的數據包相應的上層協議類型, 則丟棄該數據包. 適配層幀包含適配層幀頭及適配層有效載荷, 適配層幀頭為協議類型, 用于指示上層數據包所使用的協議類型,適配層幀頭定義為struct ADA_Hdr, 適配層有效載荷封裝上層數據包, 創建適配層幀頭接口為CreatAdaHdr().

適配層幀頭、DSM 幀頭、DSM 消息體初始化完成后, 將以上內容放到同一緩沖區, 即形成一個完整的DSM 消息.

3.2 協議棧應用層開發

應用層處于協議棧的上層, 負責對頂級應用層和下層網絡層傳輸的消息分別進行封裝和解封, 按照其他幀頭規定的參數進行數據傳遞, 并在不同的通信實體間進行數據收發.

按照國標規定, 協議棧應用層分為用戶應用和消息層, 消息層需要完成5 類基本消息體數據結構的定義, 包括車輛基本安全信息(basic safety message, BSM),地圖消息(map message, MAP), 信號相位與時序消息(signal phase and timing message, SPAT), 路側單元信息(roadside information, RSI)路側安全信息(roadside safety message, RSM). 5 個消息體由專用于數據表示的抽象語法標記(abstract syntax notation one, ASN.1)語言進行描述, 適用于結構化數據傳輸[17], 遵循“消息集–數據幀–數據元素”的邏輯, 數據集編解碼采用非對齊壓縮編碼規則(unaligned packet encoding rules, UPER).

3.2.1 BSM 消息體設計

根據ASN.1 標準對于BSM 消息定義以及消息體數據集之間的嵌套關系, 結構體BSM 定義包含兩個部分: 結構體BSMRequired 和結構體BSMOptional.BSMRequired 包含位置、速度、高度、經緯度、航向角等車輛基本信息, BSMOptional 包含方向盤角度置信度、位置綜合精度、防抱死制動狀態、制動踏板狀態等. 這些信息由CAN 總線以及GPS 定位模塊獲取,CAN 總線信息及定位數據通過同步信號對齊, 存儲在消息層, 通過BSMCreate()函數創建BSM 并填充相關信息.

在完成BSM 消息的構造后形成.asn 文件, 使用編解碼編輯器asnlc, 在BSMEncode_To_()函數中選擇UPER 編碼方式對.asn 文件進行編譯, 生成應用層設計所需要的消息體數據結構, 最終將BSM 填充到DSM中并發送.

3.2.2 其他消息體設計

其余4 類消息體(MAP、SPAT、RSI、RSM)構造與BSM 消息相同, 但消息傳輸機制不同. 這四類消息是通過RSU 廣播給車輛, 之后在車輛之間進行消息的傳輸. 車輛接收消息的過程為: RSU 填充消息報頭(信道號、優先級等), RSU 結合MAP 數據部分進行套接字傳輸, 對消息進行廣播. 消息的發送過程為: 車輛設置消息報頭, 車輛對消息進行套接字傳輸, 發送預定義的DSM 并進行廣播.

4 LTE-V2X 通信性能測試

LTE-V2X 協議棧開發完成后需要進行實際場景下的通信測試, 包括消息收發測試及通信性能測試. 測試需兩套協議棧分別作為發送端和接收端, 測試中使用Putty 軟件通過串口連接兩套設備進行操作.

4.1 消息收發測試

測試內容主要包括5 類消息集在協議棧上的發送與接收, 即協議棧支持發送端設置BSM、MAP、SPAT、RSM、RSI 五類消息類型. 測試主要面向車車通信, 因此在消息收發測試中使用BSM 消息進行測試, 發送端程序運行結果如圖8(a). 接收端運行接收消息程序, 監聽空中接口發來的消息, 結果如圖8(b).

圖8 消息收發測試

發送端構造BSM 消息后對消息體進行打印輸出,BSM 消息體具體內容見圖9, 主要包括用戶標識、當前車輛位置信息、車輛各類加速度信息、車輛檔位、剎車等狀態信息、車輛尺寸信息、劃分的車輛類型以及其他擴展信息. 消息填充完成之后調用底層接口發送消息, 接收端接收到BSM 消息后提取數據包中的消息體, 對消息體進行分割并打印消息體內容. 由測試結果可以看出發送端和接收端消息內容打印一致, 協議棧收發消息運行正常, 能夠實現基本消息的收發.

圖9 BSM 消息體具體內容

4.2 通信性能測試

為測試協議棧在不同真實場景下的通信能力, 本文選取靜止與直行兩種典型交通場景, 使用2 輛搭載協議棧的車輛開展通信測試. 在實際場景中車輛通信100 m 范圍以內的通信較為關鍵, 因此測試著重關注車輛運動狀態下100 m (半徑)范圍內的設備通信情況.

4.2.1 測試指標選取

本文選取時延(Delay)和丟包率(PER)兩個指標測試協議棧的通信能力. 其中時延是指從數據分組(或報文)從發送端應用層服務數據單元開始到達接收端應用層服務數據單元所需的單向傳輸時間. 一般情況下, LTE-V2X 的端到端時延與接入層參數、網絡擁塞狀況等相關, 最終影響時延、分組丟失率等一系列指標. 對于LTE-V2X 現階段的應用需求, 為了滿足實際車聯網應用, 端到端時延應保持在100 ms以內[18]. 丟包率是指在一定覆蓋范圍和信道質量條件下, 接收端丟失應當收到數據包的概率. 按照要求在規定覆蓋范圍內, 對于普通安全應用最大時延100 ms 的要求下接收可靠性不得低于80%.

4.2.2 測試場景及結果分析

1) 靜止場景下通信測試

如圖10 所示兩輛測試車分別靜止停在直行道路上不同的位置, 其中一方為發送端另一方為接收端. 測試過程中發送端以10 Hz 頻率發送數據包大小為300 字節的BSM 消息, 每次發送200 個數據包共發送10 次, 消息發送方式為半靜態調度. 查詢并記錄發送端與接收端的日志, 分別計算每次實驗的時延與丟包率,實驗結果如圖11 所示. 最后將兩輛測試車分別靜止停在直行道路相距200 m 的位置上, 測試過程中發送端以10 Hz 頻率分別發送數據包大小為150 字節、300 字節、600 字節的BSM 消息, 每次發送200 個數據包共發送10 次, 計算不同數據包長度下的通信時延和丟包率, 實驗結果如圖12 所示.

圖10 靜止場景

圖11 靜止場景下不同距離協議棧通信性能測試

從測試結果可以看出, 在600 m 通信范圍內通信距離對通信時延影響不大, 每處平均值約為16 ms, 時延在5 ms 左右上下浮動, 上分位數值均在20 ms 以內.當通信距離增加至800 m 時, 通信時延較之前有所增大但變化不明顯, 平均值和上分位數分別在20 ms 和22 ms 左右. 丟包率在600 m 通信范圍內相對穩定, 平均值在3%左右, 總體值在4%以內. 隨著通信距離增至800 m, 丟包率較之前有明顯的增加, 平均值接近6%且數據上下浮動較大. 由靜止場景下通信性能測試結果可以看出, 通信距離為800 m 時通信時延與丟包率相對較大, 原因是LTE-V2X 其本身存在有效通信距離的限制. 而在數據包長度變化條件下, 由圖12 可以看出隨著數據包長度的增加, 通信時延略有增加且小于5 ms, 丟包率仍保持在3%左右, 由此可見數據包長度對于時延及丟包率的影響并不明顯.

圖12 靜止場景下不同數據包長度協議棧通信性能測試

2) 直行道路下通信測試

如圖13 所示, 兩輛測試車輛在直行道路上以相同的速度勻速行駛(跟馳), 車輛間距保持在50 m 左右,分別測試車速為20 km/h、40 km/h、60 km/h 的時延與丟包率. 其中, 前方車輛作為發送端, 后方跟馳車輛為接收端, 其他相關參數設置同靜止場景實驗, 跟馳場景下實驗結果如圖14.

圖13 跟馳場景

圖14 跟馳場景下協議棧通信性能測試

跟馳場景下, 通信時延隨速度增大而增大, 而丟包率受速度影響較小, 數據相對穩定, 平均丟包率均小于3%. 相較于靜止場景下, 動態場景下時延異常值增多,但總體數據特征相似, 平均值均小于20 ms.

上述兩種場景下的協議棧通信性能測試結果表明車輛距離對于時延與丟包率均有影響. 其中靜止場景測試中隨著車輛相距距離增大, 時延與丟包率都有所增加. 跟馳場景測試中隨著車速逐漸增加時延變化較為明顯, 而丟包率與速度呈弱相關. 除此之外, 在兩種不同場景下通信時延與丟包率雖有所波動, 但仍符合車聯網普通安全相關應用的需求, 說明協議棧總體通信性能良好.

5 結論與展望

本文針對目前車聯網通信需求以及標準要求, 為LTE-V2X 協議棧提供一套切實可行的系統硬件平臺和軟件解決方案, 并對設計的協議棧進行不同場景下的通信測試. 測試結果表明該協議棧能夠實現V2X 消息收發, 滿足實際車聯網場景的應用, 為車聯網通信終端落地提供現實借鑒意義. 然而, 本文協議棧設計中沒有考慮通信安全問題, 且測試指標選取與測試場景設置相對單一, 未能模擬真實道路路況或多車信號耦合干擾下系統的通信性能. 未來應進一步完善通信安全機制, 設計高速移動場景與包含遮蔽物場景下的多指標通信測試, 并考慮多車環境下的通信擁塞等問題.