你開車接近一座沒有行動網路訊號的山區彎道，對向車輛仍可能直接送出行駛資訊。
回到市區後，車輛也能經由基地台連上應用伺服器，取得較大範圍的道路事件。
這兩條路徑看起來都叫 V2X，實際經過的通訊介面卻不一樣：
附近車輛直接交換
→ IEEE 802.11 車用通訊，或 3GPP PC5 sidelink
車輛經基地台連到後端
→ 3GPP Uu 與行動網路
接著再把 IEEE 802.11 家族與 3GPP 家族的名稱放進來，術語很快就會纏在一起。
今天要做的事不是宣布哪一種技術「全面勝出」，而是把每個名稱放回正確層次，回答：它屬於哪一個標準家族、走直接路徑還是網路路徑，又需要哪些基礎設施？
讀完這篇文章，你應該能夠：
Day 10 使用 V2V、V2I、V2P 與 V2N 分類「車輛和誰溝通」。
今天的 DSRC、ITS-G5 與 C-V2X 則在回答另一個問題：資料使用哪一套通訊技術送出去？
圖 1：DSRC／WAVE 與 ITS-G5 屬於 IEEE 802.11 車用通訊家族。C-V2X 則可以走 PC5 直接路徑，或經 Uu、基地台與核心網路連到應用伺服器
先用一張小表建立邊界：
| 名稱 | 它主要描述什麼 | 不要直接把它當成什麼 |
|---|---|---|
| V2V／V2I／V2P／V2N | 通訊對象或服務關係 | 特定 Radio 或訊息格式 |
| DSRC／WAVE | 美國 V2X 文件常見的 IEEE 802.11 車用通訊系統語境 | 全球唯一的 DSRC 用法 |
| ITS-G5 | ETSI C-ITS 架構中的 5 GHz Access 技術 | 完整的 C-ITS 應用與資安系統 |
| C-V2X | 3GPP 定義的 Cellular V2X 技術家族 | 只會走基地台的 V2N |
| PC5 | 裝置之間的 3GPP 直接通訊參考點 | 固定等於 LTE 或固定等於 5G |
| Uu | UE 與行動網路基地台之間的介面 | 鄰近車輛間的直接 Radio Link |
同一項十字路口警示可以使用不同 Access Technology。
反過來，同一套 C-V2X 裝置也可能依服務需求選擇 PC5 或 Uu。
所以比較技術時，第一步不是只看名稱中的 5G 或 Cellular，而是先畫出真正的資料路徑。
IEEE 802.11p-2010 是 **Wireless Access in Vehicular Environments（WAVE，車載環境無線存取）**相關的 IEEE 802.11 修正案。
它針對車輛高速移動、裝置快速相遇與短時間交換資料的情境，調整 IEEE 802.11 的 MAC 與 PHY 操作。
和一般使用者連上家中 Wi-Fi 的直覺相比，V2X 裝置需要在沒有傳統 Access Point 建立連線的情況下，快速交換附近道路資訊。
IEEE 802.11p 的內容後來已被納入後續整合版 IEEE 802.11 標準，因此原本的 IEEE 802.11p-2010 修正案在 IEEE 頁面上標示為 superseded。
不過，產業文件與教材仍常使用「802.11p」指稱這套車用無線存取基礎。
這裡要分清楚：
IEEE 802.11p
→ 主要處理無線 MAC／PHY 如何在車載環境運作
完整 V2X 系統
→ 還要加入網路與傳輸、訊息格式、安全服務及應用邏輯
只看到一張無線晶片支援 802.11p，不代表它已經具備完整的車輛憑證管理、道路訊息格式與互通測試結果。
DSRC 是 **Dedicated Short-Range Communications（專用短距通訊）**的縮寫。
在美國 Connected Vehicle 與 V2X 文件中，DSRC 常指以 IEEE 802.11 車用無線存取與 IEEE 1609 WAVE 標準家族組成的通訊系統。
WAVE 會再處理多項上層能力，例如：
因此把 DSRC = 802.11p 當成快速記憶可以理解，但更精確的說法是：
802.11p 是 DSRC／WAVE 系統採用的無線存取基礎之一，完整系統還包含 IEEE 1609 等上層規格。
還要注意，DSRC 這個詞在不同地區與年代也可能被用於電子收費等其他短距通訊情境。
本文只在美國 V2X／WAVE 的上下文中使用 DSRC，不把它當成全球所有短距車路通訊的單一技術名稱。
ITS-G5 是 ETSI 為智慧運輸系統定義的 Access Layer 技術。
ETSI EN 302 663 將它放在 5 GHz ITS 頻段的運作情境中，並以 IEEE 802.11 車用操作為基礎。
它同樣使用競爭式媒體存取概念。
節點會先監聽頻道，若頻道忙碌便依規則退避，再尋找傳送機會。
這種方法可以讓附近車輛與 RSU 在沒有行動網路基地台替每一筆訊息排程的情況下直接交換資料。
但 ITS-G5 不只是替 802.11p 換一個歐洲名字。
完整的歐洲 C-ITS Stack 還可能包含：
所以比較 DSRC／WAVE 與 ITS-G5 時，可以說它們共享 IEEE 802.11 車用無線存取的技術血緣，卻不能推論兩端只要「Radio 都是 802.11p」就一定能完成應用層互通。
先把共同點與差異分開：
| 比較項目 | DSRC／WAVE | ITS-G5 |
|---|---|---|
| 常見區域語境 | 美國 V2X 文件與部署 | 歐洲 ETSI C-ITS 架構 |
| 無線存取基礎 | IEEE 802.11 車用操作，傳統常稱 802.11p | ETSI Access Layer 以 IEEE 802.11 車用操作為基礎 |
| 直接通訊 | 可以，不必讓封包先經行動網路基地台 | 可以，不必讓封包先經行動網路基地台 |
| 上層生態 | IEEE 1609 WAVE 與地區訊息規格 | ETSI ITS Station、GeoNetworking 與 Facilities 規格 |
| 互通判斷 | 要確認頻段、頻道、上層協定、安全憑證與訊息 Profile | 同樣要檢查整個 Stack，不能只比 Radio 名稱 |
兩者都不是普通家用 Wi-Fi，也都不能只靠 CSMA／CA 證明訊息來源可信。
真正部署時還會受到各地頻譜規則、技術 Profile、認證與基礎設施政策影響。
因此閱讀規格或設備型錄時，要同時記錄地區、版本與完整協定組合。
C-V2X 是 Cellular Vehicle-to-Everything（蜂巢式車聯網通訊）。
它由 3GPP 行動通訊標準家族發展，包含兩條不同概念路徑：
PC5
→ UE 與 UE 直接交換 V2X 資料
Uu
→ UE 經基地台、核心網路與應用伺服器交換資料
在這裡，UE 是 User Equipment（使用者設備）。
它可以是車上的 C-V2X 裝置、RSU，或符合系統定義的道路使用者裝置。
「Cellular」表示技術來自 3GPP 行動通訊家族，不等於所有封包都必須由基地台中轉。
這也是 C-V2X 最常見的名稱陷阱。
PC5 是 3GPP 裝置間直接通訊的參考點，在 Radio 層也常稱為 Sidelink（側鏈路）。
以鄰近車輛的安全資訊為例，概念路徑是：
車輛 A 的 UE
↔ PC5 sidelink
車輛 B 的 UE
資料不需要先從車輛 A 上傳基地台，再由核心網路繞回車輛 B。
3GPP 的 LTE-V2X 架構也支援 UE 在 E-UTRAN 服務範圍內或不在服務範圍內使用 PC5。
但「不需要基地台轉送每一筆資料」不等於「完全不需要事先設定」。
裝置仍要取得允許使用的頻率、傳輸參數與授權政策。
當 UE 不在網路覆蓋內時，這些參數可以依規格與區域政策預先配置。
LTE-V2X 的直接通訊常以兩種資源配置方式建立概念：
| LTE sidelink 模式 | 資源如何取得 | 基本限制 |
|---|---|---|
| Mode 3 | 由行動網路協助排程 PC5 Radio Resource | 需要在適用的網路覆蓋與控制下 |
| Mode 4 | UE 依感測與預先配置規則自主選擇 Resource | 可支援覆蓋外直接通訊，但仍會受到負載與干擾影響 |
這兩種方式都還是 PC5 直接傳送。
基地台協助排程 Mode 3，不代表 V2X Payload 必須先送進核心網路再轉回另一台車。
Mode 4 可以覆蓋外運作，也不代表一定沒有碰撞或資源競爭。
Uu 是 UE 與基地台之間的行動通訊介面。
V2X 資料走 Uu 時，概念路徑可能是：
車輛 UE
→ Uu
→ 基地台
→ 核心網路
→ V2X Application Server
→ 將結果提供給相關車輛或交通管理端
它適合需要後端彙整、較大地理範圍或服務端運算的情境。
這條路徑和 Day 10 的 V2N 很容易對上，但仍不要把分類綁死。
一項 V2I 應用也可能透過網路型路徑連到服務特定區域的基礎設施或應用伺服器。
Uu 的端到端表現會受到更多元件影響：
所以「使用 5G Uu」不能單獨保證整個應用的固定低延遲。
仍要測量完整的 UE、網路、伺服器與回傳路徑。
3GPP 在 Release 14 完成初始 C-V2X 標準工作，讓 LTE 系統支援 V2X。
常見的 LTE-V2X 架構包含：
LTE PC5 特別針對車輛高速相對移動與高密度節點情境調整 sidelink 設計。
它和 IEEE 802.11p 的最大差異，不只是標準組織名稱不同。
兩者的 Radio Waveform、Channel Access、Resource Allocation 與協定 Stack 都不同，因此不能直接互收無線訊號。
要讓同一個 OBU 同時參與兩套生態，通常需要對應的多 Radio 能力與上層整合。
NR-V2X 是使用 **NR（New Radio，新無線電）**的 V2X 能力。
3GPP Release 16 為進階 V2X 服務加入 NR PC5，支援的直接通訊模式包含：
NR PC5 也加入更細緻的 QoS 與直接鏈路管理能力，讓系統能處理車輛編隊、協同駕駛與進階感測資訊分享等較複雜需求。
不過，這不代表 LTE-V2X 在 NR-V2X 出現後就自動消失。
3GPP 的架構會把 LTE PC5 與 NR PC5 視為不同的 Radio Access Technology（RAT，無線接取技術），再由政策把服務映射到 LTE PC5、NR PC5 或兩者。
因此比較世代時，較合理的說法是：
NR-V2X 擴充 C-V2X 能力，系統可能依服務與部署階段和 LTE-V2X 共存，不能假設兩種 sidelink 在空中介面上天然向下相容。
日常文章常把 5G-V2X 與 NR-V2X 互換使用，但閱讀技術文件時最好再拆一步。
| 名稱 | 較精確的理解 |
|---|---|
| NR-V2X／NR PC5 | 使用 5G NR sidelink 的直接 V2X Radio 能力 |
| 5G Uu V2X | UE 經 NR 基地台與 5G Core 使用網路型 V2X 服務 |
| 5G-V2X | 常用來統稱 5G 系統支援的 V2X 能力，實際範圍要看文件定義 |
一份文件若寫「5G-V2X」，可能在談 NR PC5，也可能在談 5G Uu 與 Edge Computing，還可能把兩者都算進去。
最安全的閱讀方式是繼續追問：
圖 2：DSRC／WAVE 與 ITS-G5 共享 IEEE 802.11 車用通訊基礎。LTE-V2X 與 NR-V2X 則屬於 3GPP C-V2X 的不同 Radio 世代，NR-V2X 是能力擴充，不應簡化成直接覆蓋所有既有技術
以下表格先比較「技術家族與路徑」，不把地區法規與特定產品效能混成一個排名。
| 技術 | 標準家族 | 主要直接路徑 | 網路型路徑 |
|---|---|---|---|
| DSRC／WAVE | IEEE 802.11 + IEEE 1609 | IEEE 802.11 車用直接通訊 | 不是 DSRC Radio 本身的核心路徑，可由系統另行整合 |
| ITS-G5 | ETSI ITS + IEEE 802.11 | ITS-G5 直接通訊 | 可由完整 ITS Station 整合其他 Access 技術 |
| LTE-V2X | 3GPP Release 14 起的 C-V2X | LTE PC5 | LTE-Uu |
| NR-V2X／5G-V2X | 3GPP Release 16 起的進階 V2X | NR PC5 | 5G Uu，實際架構也可能包含跨世代組合 |
如果要選技術，還要再看另一組問題：
| 評估面向 | 應該問什麼 |
|---|---|
| 覆蓋需求 | 服務在沒有基地台覆蓋時，是否仍要讓附近節點直接交換？ |
| 通訊模式 | 主要是附近廣播，還是需要群組、單播與後端協調？ |
| 頻譜與法規 | 部署地區允許哪些頻段、功率與技術 Profile？ |
| 擁塞處理 | 高密度節點如何取得傳送機會並控制頻道負載？ |
| 相容性 | OBU、RSU 與既有部署支援哪一套 Radio 及上層 Stack？ |
| 安全架構 | 憑證、訊息簽章、撤銷與誤用偵測如何實作？ |
| 維運 | 軟體、Radio Parameter、憑證與路側設備如何更新？ |
技術名稱本身不能替這些問題作答。
V2X 比較表很喜歡只列一個延遲數字，但真正的應用延遲至少包含：
感測與資料產生
→ 應用編碼與安全處理
→ 等待 Radio Resource
→ 無線傳輸
→ 接收、驗證與合理性檢查
→ HMI 或車內應用反應
走 Uu 時，還要加入基地台、核心網路、應用伺服器與回傳路徑。
走直接通訊時，頻道忙碌與 Radio Resource 選擇會影響傳送機會。
封包碰撞、重複傳送及接收端負載，也會拉長端到端時間。
因此「5G 一定比所有技術低延遲」和「直接通訊一定沒有延遲問題」都不夠精確。
應用必須以目標車流密度與車速作為測試條件，再加入遮蔽、干擾及失效情境完成端到端驗證。
IEEE 802.11、LTE PC5 與 NR PC5 都會處理 Radio 傳輸與媒體存取問題。
但成功收到 Frame 或 Transport Block，只能告訴我們通訊鏈路完成了某一層工作，不能直接證明：
不同生態會再加入自己的安全規格。
WAVE 有 IEEE 1609.2，ETSI C-ITS 有安全標頭與憑證 Profile，3GPP 則定義 LTE 與 NR V2X 的安全架構。
應用訊息也可能使用憑證與數位簽章保護來源、完整性及權限。
不過，Day 10 已經建立一條重要邊界：
簽章有效可以協助確認訊息來自持有有效憑證的裝置，仍不能保證裝置回報的位置與事件符合真實世界。
接收端還要檢查時間、位置、移動狀態與其他感測結果。
Day 21 會再把假位置、假事件與 Sybil Attack 放進這條信任鏈。
假設路口 RSU 只支援 ITS-G5，本車 OBU 只支援 LTE PC5。
即使兩者使用相近的 ITS 頻段，也不能因此直接交換 V2X 訊息。
它們的 Radio 與協定 Stack 不同，需要額外的多 Radio RSU、Gateway 或應用伺服器協助整合。
但 Gateway 轉換也不是把封包格式改掉就完成了。
它還要處理：
這些是 **Interoperability（互通性）**與信任轉換問題，不只是 Radio Coverage 問題。
一台設備同時支援兩種 Radio，也不代表兩套安全身分與應用 Profile 已經自動打通。
回到 Day 10 的智慧十字路口，可以把不同需求放進今天的技術地圖：
| 需求 | 候選路徑 | 判斷重點 |
|---|---|---|
| 橫向來車向附近車輛提供行駛狀態 | IEEE 802.11 車用直接通訊，或 LTE／NR PC5 | 不應依賴封包先繞到遠端後端，但仍要確認部署互通性 |
| RSU 向附近車輛提供路口資訊 | ITS-G5、DSRC／WAVE 或 PC5，依地區與部署而定 | 車輛與 RSU 必須支援同一 Radio、訊息與安全 Profile |
| 交通中心彙整全市道路事件 | LTE／5G Uu 到 Application Server | 要分析網路、後端、資料時效與回傳範圍 |
| 無基地台覆蓋時維持附近警示 | IEEE 802.11 直接通訊，或已正確配置的 PC5 覆蓋外模式 | Uu 不能單獨滿足覆蓋外需求 |
| 車隊進行較複雜的直接協調 | NR PC5 可提供 groupcast／unicast 等能力 | 仍要確認車隊成員授權、QoS 與失效處理 |
這不是特定城市或車款的部署建議。
真正選擇還要先符合當地頻譜政策，並評估設備成熟度與互通認證。
生命週期及安全需求也要納入架構決策。
下面是四段只用於教學的智慧十字路口需求：
A. 兩台相距很近的車要直接交換行駛狀態
B. 車輛要向全市交通服務取得十五分鐘前更新的施工資訊
C. 山區沒有基地台覆蓋，附近車輛仍要交換警示
D. 三台支援進階 C-V2X 的車輛要建立直接群組協調
請先回答：
先停在這裡，不要急著往下滑！
請先把「直接交換」與「經後端服務」分開，再往下對照作者的示範答案。
| 需求 | 作者的判斷 |
|---|---|
| A | 屬於附近直接交換，可考慮 IEEE 802.11 車用通訊或 LTE／NR PC5，不能只靠需求文字判定唯一 Radio |
| B | 需要全市資料彙整與服務端更新，適合經 LTE／5G Uu 連到 Application Server |
| C | 不能只依賴 Uu，可使用 IEEE 802.11 直接通訊，或已取得有效預先配置的 PC5 覆蓋外模式 |
| D | NR PC5 的 groupcast／unicast 能力適合納入評估，但仍要確認服務 Profile 與車隊授權 |
A 與 C 都表示資料要在附近節點間直接交換。
這項需求無法單獨告訴我們應該採用 DSRC／ITS-G5 或 C-V2X PC5，還要看地區政策、既有 RSU、OBU 能力與完整 Stack。
B 則明確依賴較大範圍的資料彙整，Uu 和後端服務是合理路徑。
D 顯示 NR PC5 支援更完整直接通訊模式的價值，但 Groupcast 本身不會自動完成車隊成員驗證與操作授權。
最後還要確認：
這份答案只示範如何選擇概念路徑，不代表任何特定道路、車款或電信網路採用相同架構。
安全與法律提醒： 無線封包傳送與頻譜測試只應在符合法規的隔離環境、模擬器、測試台或明確取得授權的場域進行。
不要對道路車輛、RSU、行動網路或公共交通設施進行未授權測試。
今天我們把 V2X 的通訊路徑分成 IEEE 802.11 車用直接通訊、3GPP PC5 與 Uu，也分清楚 LTE-V2X 和 NR-V2X 的世代關係。
Day 12 將打開真正交換的資料，認識 BSM、CAM 與 DENM 如何描述車輛位置、速度及道路事件，並說明訊息格式為什麼不能只靠 Radio 名稱判斷。
iThome鐵人賽
看影片追技術