車用環境無線存取(WAVE)/專用短程通訊(DSRC)標準規範已逐漸進入最後討論階段，國際間各家車廠與通訊廠商無不摩拳擦掌積極開發相關技術，期望可以在趨勢來臨前取得關鍵領導地位。
然而，在開發階段除大量閱讀標準規格書外，學習先進者的經驗也是一個很重要的管道。本文將分享針對WAVE/DSRC開發上的寶貴經驗，並依據不同協定所需要的重要概念加以說明，期望藉由閱讀本文可以讓後進者快速掌握開發要件。
車載資通訊備受各國重視
車載資通訊(Telematics)的概念在近年來受到廣泛討論與研究，其主要的精神就是透過通訊(Telecommunication)技術將相關重要的資訊(Information)帶進車輛，給予駕駛人或行車電腦有更多的資訊以提早作出適當判斷，並提供加值服務給車上乘客使用。
試想不久後的將來，駕駛人可以使用長距離通訊技術存取公司檔案並參與線上會議討論，行車過程中還可以透過短波通訊進行身分認證採買餐點，而車上行車電腦也會自動根據其他車輛或系統發送出來的資訊，建議駕駛人進行適當的反應以避免發生交通事故。而這當中又以行車安全相關議題最受關注，因此這也促成WAVE/DSRC相關國際規範的誕生。
然而，在推動WAVE/DSRC導入車內行車電腦前，往往會遭遇到軟硬體技術不成熟以及車與車之間無法互通的問題，因此許多國際車廠與研究單位紛紛共組聯盟並投入龐大的資源與人力，以期讓行車安全概念早日落實在現實環境中。這其中又以美國車廠與政府所組成的防撞系統合作團隊(Crash Avoidance Metrics Partnership, CAMP)及歐洲C2C(Car-2-Car)、GeoNet最為著名。
由上述討論可以嗅出國際間對於行車安全議題非常重視，且能早日參與開發的組織將可能獲得勝出並領導市場走向。有鑑於此，以下將針對相關開發工作應注意事項作簡略說明，掌握本文說明的細節可有助於後進者避免不必要的錯誤產生。
IEEE 1609.2實作挑戰重重
IEEE 1609.2標準規範在無線車載環境下，應用及管理訊息所需的安全服務(Security Service)，並於2011年6月發布第九版草案。在車載環境下，WAVE/DSRC系統與訊息比起有線環境更容易受到攻擊。因此除了必須可抵禦竊聽、偽造、修改與重送等類型攻擊外，同時還得考慮到個人資料的隱私安全，防止個資洩漏。透過將訊息加密及簽章的方式，可達到以上安全需求。
IEEE 1609.2的功能至少包括以下三種，一為應用程式簽章、認證、加密、解密、及資料萃取(Data Extraction)，二為WAVE管理實體(WAVE Management Entity, WME)之WAVE服務廣播(Wave Service Advertisements, WSA)訊息簽章及認證，三則是將簽章資訊儲存於安全資料儲存(Security Data Stores, DSS)中。由於在目前規範中，所有簽章資訊都得透過本身憑證管理實體(Certificate Management Entity, CME)模組向憑證授權中心(Certificate Authority, CA)取得，所以必須有一外部介面對CA連線。
但標準訂定僅止於此，若於實際應用時，目前仍尚未有可提供車載認證的CA單位。憑證撤銷清單(Certificate Revoke List, CRL)的發布機制與頻率，亦未定義，但此關係到如何快速察覺出有問題的惡意訊息，亦為標準可以改進之處。
目前標準仍處於草案第九版中，雖與之前相比已有很多改進，但實際實作並與國外大廠互聯測試時，仍發覺許多對標準解讀不一之處，有待相關業者積極討論改進。該標準正式版本預計2011年底可以制訂完成。
IEEE 1609.3/4規範訊息傳遞方式
IEEE 1609.3標準規範網路層與傳輸層的協定與服務，提供WAVE/DSRC系統的定址(Addressing)與資料傳遞(Data Delivery)服務，讓上層應用層得以存取WAVE通訊服務，以達到WAVE設備間的多頻道運作(Multiple Channel)的功能。
目前IEEE 1609.3標準已於2010年12月釋出最後修訂版。針對IEEE 1609.3各部分在實作上須要注意的事項詳列說明。其一，WSA為IEEE 1609.3所制定的重要資料結構，其功用為公告目前提供的服務如語音或影像。在實作IEEE 1609.3最少接收WAVE服務公告數目(Minimum Number of Received WSAs)過程中，由於標準草案對於最少接收WAVE服務公告數目的設計上並無具體的討論與定義。因此，為了使最少接收WAVE服務公告數目更具彈性及真實，於是提出WSA Count Threshold Interval設計概念，亦即根據WSA內的建議門檻值比對所接收的WSA數量是否符合其建議值，依標準所述建議門檻值的區間可介於100毫秒(ms)至數秒(s)，可以使用數學式子表示：
如果不符合門檻值則系統視為服務品質不佳，因此不提供此服務。同時於程式中所有WME-ProviderService.request的訊息內新增WSA Count Threshold Interval參數。新增的參數將使得最少接收WAVE服務公告數目更具有彈性，並適用於車載環境下使用。
其二，亦針對WSA Count Threshold Interval參數，提出多項相關欄位與程序的新增與修正，以促進各家通訊設備實作一致性。提出的建議包含於WME-ProviderService.request primitive中加入WSA Count Threshold Interval參數與相關描述；於WME MIB表中的ProviderServiceRequestTalbeEntry加入ProviderWsaCountThresholdInterval參數；於WME MIB表中的ASN.1編碼中加入ProviderWsaCountThresholdInterval的編碼方式；於WSA範例中新增WSA Count Threshold Interval欄位與範例值。
緊接著，在2011年2月，IEEE 1609.4標準也修訂完成，在該版本中增強IEEE 802.11p標準中媒介存取控制層的功能與服務，以提供WAVE設備間的多頻道運作，其中包含頻道切換、頻道路由、資料傳輸優先權、頻道協調(Channel Coordination)與頻道存取(Channel Access)等部分。
在實作IEEE 1609.4標準面臨兩大問題，第一個問題為頻道切換時，造成頻道壅塞(Channel Congestion)情況發生，導致封包遺失，因此必須對802.11p的晶片驅動程式(Driver)與韌體(Fireware)做修改。
目前IEEE 1609.4標準規範單一天線以50毫秒來回切換於CCH與SCH，然而實作多台WAVE Vehicle在執行頻道切換時可能會遭遇到頻道壅塞的情形，這是由於在CCH Interval底下多輛車同時選取到相同的Random Back-off Slot值，導致車輛間發生碰撞的情形。
為了解決上述的問題，因而提出動態位移間隔機制(Adaptive Offset Slot, AOS)。此機制的主要概念為每輛車先利用廣播Hello訊息封包估計鄰近車輛的數目，之後計算期望的位移間隔值，並預先加到原始MAC Contention Window之前。
透過AOS機制，可降低封包碰撞情況，並改善傳輸的效能。此機制的最大優點為相容於現存802.11 MAC機制，並僅須對802.11p的驅動程式與韌體做小幅修改。
第二個問題是市面上的802.11a的網路卡驅動程式使用5GHz操作模式，因此用於高速移動的802.11p車載環境仍有相當的困難，在尚未有大量投產的前提下，採用超頻(Overclocking)與修改軟體的方式支援至5.9GHz操作頻率是目前可行的方向之一，然而，此一做法須注意網卡運作的穩定度與耐用度。
SAE J2735定義互通格式
SAE J2735標準文件主要規範傳送在WAVE/DSRC環境中的應用層訊息格式，其目的是讓所有基於DSRC通訊技術下的使用者，能透過這些統一標準化的訊息格式來達到相互溝通。
此標準根據不同的車載應用情境需求，分別定義了十五種訊息格式。其中每種訊息格式由資料訊框(Data Frame)及資料單位(Data Element)組成，且根據資料的性質，將資料訊框及資料單位定義為必要(Mandatory)或非必要的(Optional)。如果資料訊框或資料單位被定義為非必要，則表示各家廠商可視需求決定是否在訊息中提供此非必要的資訊；反之，如果是定義成必要，則表示每一個訊息皆須要將此必要資料訊框或資料單位包進封包中。
SAE J2735規範將車載應用依照情境需求分類，並定義各種不同的訊息格式，其中基本安全訊息(Basic Safety Message, BSM)主要被廣泛應用在各種行車安全的應用上，如十字路口發生碰撞警告，此訊息根據應用情境上所需的發送頻率，週期的廣播給鄰近的車輛。
除了上述的SAE J2735可提供行車安全訊息外，IEEE 1609.3/4也容許客製化應用層軟體透過DSRC傳送。為清楚說明實作應用層所需要的相關概念，以下使用兩個實作情境來加以說明。第一個情境使用SAE J2735來實作電子煞車系統提供駕駛人及時的預警資訊以縮減反應時間，第二個情境為使用車對車技術達成影音串流技術。
電子煞車燈提供及時預警資訊
BSM主要用來作為車與車之間(V2V)互相傳遞車載安全等相關訊息，其訊息格式主要分為Part I與Part II兩部分，其中Part I的資料訊框與資料單位皆被定義為必要，主要包含基本的安全訊息內容，因此每個BSM封包皆必須包含Part I的部分，而Part II的資料訊框與資料單位則被定義為非必要，主要包含特殊需求會用到額外的安全相關訊息，因此使用者可以視傳送端應用需求選擇性加入BSM封包中。
在傳統煞車燈設計下，駕駛者易受視線阻擋等問題導致發生視線死角，而造成連環追撞的車禍，然而電子煞車燈的設計，可以即早讓駕駛者知悉前車臨時緊急煞車事件，而達到降低追撞事故發生。
其中，電子煞車燈的應用情境主要是利用到BSM訊息格式中Part II的一個非必要資料單位DE_EventFlag，DE_EventFlag可用來夾帶事件的觸發，如警示燈啟動的觸發事件(eventHazardLights)、防鎖死煞車系統(ABS)啟動的觸發事件(eventABSactivated)與緊急煞車的觸發事件(eventHardBraking)等等，每種事件都有其觸發的條件，而以緊急煞車的觸發事件則是以車子的減速是否大於0.4g來判定是否該處發此事件。車機如果偵測到此事件觸發後，則會將事件與其他相關資訊封裝成BSM格式封包緊急廣播給鄰近的車機(圖1)。
 |
| 圖1 電子煞車系統示意圖 |
 |
| 圖2 位置辨識演算法 |
各車機收到鄰車BSM中夾帶的Event訊息時，則可利用位置辨識演算法(Position Recognition Algorithm)判斷是否為所行車道前方不遠處所發生的緊急煞車的事件。若是，則發出警告提醒駕駛人，反之則將此訊息丟棄不加以處理。
位置辨識演算法如圖2所示，其中黑色箭頭標示車輛的行車方向，當第二輛車輛因故緊急煞車時，該車會發出緊急煞車訊息給鄰近車輛，而第一輛車輛收到後會依據位置演算法判斷為無效訊息並丟棄，而第四輛車輛則判斷為有效訊息並顯示警告給駕駛人。
車對車技術達成影音串流技術
現今市面上的影音串流技術大多採用IP-based或P2P-based方式傳送，因此這類技術需要後端基礎建設(Infrastructure)的支援，無法直接在高速移動的環境中傳送影音片段給特定的車輛使用，這也受限了許多應用的開發。
在此提出一個簡易的車對車影音串流服務，這服務採用WAVE簡訊通訊協定(WAVE Short Message Protocol, WSMP)技術傳送影音封包，而為了讓影音串流服務能夠接取WSMP，在WSMP上開發轉換(Converter)功能，這功能可以負責將傳輸層的通訊埠(Port)對應至特定的IEEE 802.11p頻道與供應者服務識別碼(Provider Service Identifier, PSID)，其系統運作概念如圖3。
 |
| 圖3 V2V影音串流概念示意圖 |
解決實際部署各種狀況
除了設計與實作通訊協定軟體外，車用通訊單元要能夠具備在實際道路上使用的實用性，仍有不少挑戰待克服。眾所皆知，目前政府或產業界部署車用通訊網路的首要動機為增進車輛駕駛與行人的用路安全。為了達到此一目的，車輛與行人的重要資訊如車輛位置、車輛狀態、行人位置等，必須要能被即時傳遞。所以整個車用通訊安全應用系統要能達到實用化與商業化的成熟度，其所須要克服的挑戰，可分成四類討論：
| ‧ |
|
| |
目前較廣為流行的差分計算全球定位系統(Differential GPS)，其誤差水準大約為3～5公尺。可以預期在這樣的精確度水準下，不論是路口防撞警示系統或是電子煞車警示系統等各國正在研發推廣以車間通訊為基礎的安全應用，都不足以達到可以商業化的程度。其原因為如果車輛或行人的位置誤差已達到3～5公尺，其誤差本身已是車輛寬度的一倍或是行人寬度的數倍。在這種情形下，各種碰撞偵測演算法都有可能會發生極多誤判，因而對駕駛人或行人發出極多錯誤警告。 過多的錯誤警告會使得駕駛人與行人感到厭煩，排斥使用此類安全應用系統所發出的警告。更糟的是，有可能駕駛人與行人會因而不信任安全應用系統的警告，而退回既有的行車方法。這將使此類安全應用系統達不到原有提升行車用路安全的設計目標。
車載通訊安全系統要達到商業化，GPS的定位精準度為最重要的關鍵之一。目前，世界各地都在研發與部署下一世代的GPS，例如美國部分區域已部署的廣域增強系統(Wide Area Augmentation System, WAAS)、日本正在發展的多功能衛星增強系統(Multi-Functional Satellite Augmentation System, MSAS)，以及歐洲正在發展的歐洲同步衛星導航覆蓋系統(Euro Geostationary Navigation Overlay Service, EGNOS)。
WAAS系統宣稱已可將定位誤差降到約1.5公尺的水準，對於初期的防撞系統應用來說，此定位水準雖不完美，但對預測車輛間碰撞已達到尚可使用的精準度。
以目前而言，無論哪種GPS定位技術，皆無法提供百分之百的定位精準度，因此，下一代的防撞系統終將會仰賴其他感測器(如陀螺儀等)的協同合作，以降低誤差。
另外，GPS晶片提供資料的速率也是一大亟須克服的挑戰，現今市面上的GPS晶片大多提供1Hz的資料速率，也就是說每秒GPS晶片可供應一次地理位置資料給上層使用，然而在高速移動的環境中(尤其在高速公路)，1秒的時間將有可能造成約近30公尺的位置誤差，這問題也同樣會讓駕駛人對系統產生不信任感。因此唯有提升GPS晶片運作速度才能有效解決這問題。 |
| ‧ |
|
| |
未來的通訊協定仍有可能朝向多頻道發展，例如IEEE所制定的802.11p與1609.4即是一種多重頻道的設計。為了成本考量與部署性，即便在多頻道的網路環境下仍要考慮單一無線電設備(Single-radio Device)的運作可行性。單一無線電設備在多頻道網路下勢必會發展出頻道跳躍(Channel Hopping)或頻道切換(Channel Switching)的運作模式。在這種運作模式下，各車載設備(OBU)的時間同步必須要非常精準，才能維持網路的運作並降低不必要的封包碰撞。在正常情形下，各OBU都能透過GPS來校正時間，並且GPS也可以提供1PPS功能用以調整毫秒級的誤差，然而若遇到GPS訊號微弱的情況下，OBU的設備製造商必須要發展相應的軟硬體來維持整體網路的時間同步精準度。 |
| ‧ |
|
| |
當前發展的車載資通訊安全應用，其運作皆須仰賴各OBU所廣播的自身車輛資訊。如果OBU所送出的廣播訊息涵蓋率太低，或者很容易因為封包碰撞和通訊死角而收不到，那各個OBU都將無法取得正確的車輛與路網資訊，使得奠基於上的安全應用演算法都將不能正確地運作與產生正確的警示。此一議題已成為學術界的一個新興研究方向。 |
| ‧ |
|
| |
OBU必須要能定期廣播其自身所在車輛的各項資訊。然而，各家車廠所使用的車內元件連接網路都不相同。即便是目前公認最廣泛應用的控制區域網路(Controller Area Network, CAN)通訊協定，也僅是定義最底層共通的溝通方式。各家車廠對取得自己所搭載的感測器晶片資訊的溝通方式制訂，仍然是各自握有主導權，並未公開也未與其他車廠相容。此種各自為政的現象，將會造成OBU供應商在取得車內資料時的困擾，使得OBU的部署落入過去汽車產業常見的車廠與一級零件供應商互綁、相互依存，因而各自結盟的局面。此情形對於整體OBU部署的安排會是一項負面的因素。同時對國內的資通訊(ICT)廠商而言，想要打入車載資通訊市場，也因為缺乏與各大車廠長久合作的經驗，而形成一個不容易打破的藩籬。 |
不可否認地，行車安全及車上多媒體服務正逐漸受到政府部門、服務提供商及消費者的重視，各式各樣的先期研究在如火如荼地展開，隨著這些研究陸續結束，隨即而來的就是如何進行開發與導入至現有的環境中。本文基於目前的先期開發經驗分享實作WAVE/DSRC各階層可能會遭遇困難與注意事項，此外，也列舉一個使用WAVE/DSRC可行的應用給新進開發人員，透過閱讀本文，新進開發人員可更快速掌握要點，讓WAVE/DSRC相關應用早日實現在生活中。
(本文作者任職於工研院資通所車載通訊與網路部)