제2장
WIA-COMM-003이 다루는 V2X(Vehicle-to-Everything)는 차량이 통신하는 상대에 따라 네 가지로 나뉩니다. 차량 간(V2V), 인프라와의(V2I), 보행자와의(V2P), 네트워크와의(V2N) 통신입니다. 각 유형은 서로 다른 메시지 계열과 지연 요구를 가집니다. 따라서 이 표준이 풀어야 할 첫 번째 과제는 이 유형들을 하나의 일관된 체계로 묶는 일입니다.
| 유형 | 상대 | 대표 메시지·기능 |
|---|---|---|
| V2V | 다른 차량 | 협력 인지(CAM), 분산 환경 통지(DENM), 집단 인지(CPM) |
| V2I | 신호등·도로 시설 | 신호 위상·시간(SPaT), 지도 데이터(MAP), RSU 통신 |
| V2P | 보행자·자전거 | 보행자 감지, 자전거 인지, 긴급 차량 경고 |
| V2N | 클라우드 | 교통 관리, 원격 모니터링, OTA 업데이트 |
표준은 이 구조를 다음 목표에 연결합니다.
스펙의 철학 항목은 이 목표를 홍익인간(弘益人間)의 정신으로 설명합니다. 표준화된 차량 통신으로 교통사고를 줄이고 정체를 완화하며, 모든 도로 이용자에게 더 안전한 환경을 제공한다는 뜻입니다.
기본 용어도 정리해 둡니다.
BSM과 CAM이 서로 다른 표준 계열에서 나왔다는 점은 뒤에서 다룰 상호운용 과제와 직결됩니다.
이 표준은 무선 접속 기술을 하나로 고정하지 않고 DSRC와 C-V2X를 모두 지원합니다. 어느 한쪽만 선택하면 이미 보급된 장비나 지역별 정책과 충돌하기 때문입니다. 이것이 현재 가장 큰 현실적 과제입니다.
DSRC(IEEE 802.11p)의 스펙 기술은 다음과 같습니다.
C-V2X는 LTE-V2X와 5G NR-V2X를 포함하는 셀룰러 기반 기술입니다. 동작 모드는 두 가지입니다.
스펙은 C-V2X의 특징을 향상된 신뢰성과 통신 범위로 요약합니다.
V2X는 ITS 전용 5.9 GHz 대역을 사용하지만, 지역마다 할당 범위가 다릅니다. 이것이 상호운용 과제의 또 다른 축입니다.
| 지역 | 할당 범위 | 폭 |
|---|---|---|
| 미국 | 5.850 – 5.925 GHz | 75 MHz |
| 유럽 | 5.875 – 5.905 GHz | 30 MHz |
| 일본 | 5.770 – 5.850 GHz | 80 MHz |
채널 배정은 다음과 같습니다. 채널 172(5.860 GHz)는 안전 필수 메시지를 위한 제어 채널(CCH)입니다. 채널 174부터 184까지(5.870~5.920 GHz, 2 단위 간격)는 서비스 채널입니다.
Channel 172: 5.860 GHz (Safety critical - CCH)
Channel 174: 5.870 GHz (Service channel)
...
Channel 184: 5.920 GHz (Service channel)
통신 스택은 아래에서 위로 다음과 같이 구성됩니다.
접속 계층만 교체하면 상위 계층을 재사용할 수 있는 구조입니다. DSRC와 C-V2X를 함께 지원하는 근거가 여기에 있습니다.
메시지별 전송 빈도와 지연 목표는 스펙에서 다음과 같이 정해져 있습니다.
| 메시지 | 빈도 | 용도 | 지연 |
|---|---|---|---|
| BSM | 10 Hz | 위치, 속도, 방향 | <10 ms |
| CAM | 1~10 Hz | 차량 상태 | <100 ms |
| DENM | 이벤트 발생 시 | 위험 경고 | <10 ms |
| SPaT | 10 Hz | 신호등 정보 | <100 ms |
| MAP | 1 Hz | 도로 기하 정보 | <500 ms |
충돌 회피 같은 핵심 안전 응용에는 10 ms 미만의 초저지연이 요구됩니다. 이 요구가 메시지 크기와 전송 주기의 상한을 정합니다. 스펙이 성능 요구를 데이터 형식과 함께 정의하는 이유가 여기에 있습니다.
표준은 TypeScript SDK(@wia/comm-003)와 CLI 도구를 제공합니다. 구현자는 이를 통해 메시지 송수신과 충돌 위험 판단의 기본 흐름을 확인할 수 있습니다. 아래는 SDK 사용 예를 줄여 옮긴 것입니다.
const v2x = new V2XCommunication({
vehicleId: 'VEH-123456',
technology: 'C-V2X',
securityLevel: 'high',
frequency: 5900 // MHz
});
const bsm: V2VMessage = {
type: MessageType.BSM,
position: { lat: 37.7749, lon: -122.4194, alt: 10 },
speed: 65, // km/h
heading: 270, // degrees
acceleration: { x: 0.5, y: 0, z: 0 },
timestamp: Date.now()
};
await v2x.sendV2V(bsm);
v2x.onV2V((message) => {
if (v2x.detectCollisionRisk(message)) {
console.warn('Collision warning!');
}
});
v2x.subscribeToInfrastructure('SIGNAL-001', (spat) => {
console.log('Traffic signal:', spat.phase, spat.timeRemaining);
});
이 예에서 확인할 구현 포인트는 세 가지입니다.
technology)과 보안 수준(securityLevel)을 초기화 시점에 지정합니다.CLI는 현장 점검과 시험에 쓰입니다. 주요 명령은 다음과 같습니다.
wia-comm-003 start --tech C-V2X --frequency 5900: 서비스를 시작합니다.send-bsm: 시험용 BSM을 전송합니다.monitor --type V2V: V2V 메시지를 감시합니다.test-rsu: RSU 연결을 시험합니다.measure-latency --target VEH-789 --count 100: 지연을 측정합니다.platoon --mode leader --max-vehicles 5 --spacing 10m: 군집주행을 구성합니다.지연 측정 명령이 따로 있다는 점은 앞의 지연 요구를 실제로 검증할 수 있어야 한다는 설계 의도를 보여 줍니다.
이 장에서 다룬 과제는 세 가지로 모입니다.
표준은 계층형 스택으로 접속 기술을 분리하고, 메시지별 빈도와 지연 목표를 명시하며, SDK와 CLI로 검증 수단을 제공하는 방식으로 이 과제에 대응합니다.
다음 장에서는 이 개관을 바탕으로 메시지의 실제 구조, 곧 BSM과 CAM 등의 데이터 형식을 살펴보겠습니다. 이 장에서 본 전송 빈도와 지연 목표가 필드 구성과 인코딩에 어떤 제약을 주는지도 함께 다룹니다.