제2장

현재 과제

개요

2.1 네 가지 통신 유형과 메시지 계열

WIA-COMM-003이 다루는 V2X(Vehicle-to-Everything)는 차량이 통신하는 상대에 따라 네 가지로 나뉩니다. 차량 간(V2V), 인프라와의(V2I), 보행자와의(V2P), 네트워크와의(V2N) 통신입니다. 각 유형은 서로 다른 메시지 계열과 지연 요구를 가집니다. 따라서 이 표준이 풀어야 할 첫 번째 과제는 이 유형들을 하나의 일관된 체계로 묶는 일입니다.

유형상대대표 메시지·기능
V2V다른 차량협력 인지(CAM), 분산 환경 통지(DENM), 집단 인지(CPM)
V2I신호등·도로 시설신호 위상·시간(SPaT), 지도 데이터(MAP), RSU 통신
V2P보행자·자전거보행자 감지, 자전거 인지, 긴급 차량 경고
V2N클라우드교통 관리, 원격 모니터링, OTA 업데이트

표준은 이 구조를 다음 목표에 연결합니다.

스펙의 철학 항목은 이 목표를 홍익인간(弘益人間)의 정신으로 설명합니다. 표준화된 차량 통신으로 교통사고를 줄이고 정체를 완화하며, 모든 도로 이용자에게 더 안전한 환경을 제공한다는 뜻입니다.

기본 용어도 정리해 둡니다.

BSM과 CAM이 서로 다른 표준 계열에서 나왔다는 점은 뒤에서 다룰 상호운용 과제와 직결됩니다.

기술적 기초

2.2 DSRC와 C-V2X: 두 갈래의 무선 기술

이 표준은 무선 접속 기술을 하나로 고정하지 않고 DSRC와 C-V2X를 모두 지원합니다. 어느 한쪽만 선택하면 이미 보급된 장비나 지역별 정책과 충돌하기 때문입니다. 이것이 현재 가장 큰 현실적 과제입니다.

DSRC(IEEE 802.11p)의 스펙 기술은 다음과 같습니다.

C-V2X는 LTE-V2X와 5G NR-V2X를 포함하는 셀룰러 기반 기술입니다. 동작 모드는 두 가지입니다.

스펙은 C-V2X의 특징을 향상된 신뢰성과 통신 범위로 요약합니다.

2.3 주파수 할당, 채널, 통신 계층

V2X는 ITS 전용 5.9 GHz 대역을 사용하지만, 지역마다 할당 범위가 다릅니다. 이것이 상호운용 과제의 또 다른 축입니다.

지역할당 범위폭
미국5.850 – 5.925 GHz75 MHz
유럽5.875 – 5.905 GHz30 MHz
일본5.770 – 5.850 GHz80 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)

통신 스택은 아래에서 위로 다음과 같이 구성됩니다.

  1. 물리 계층: 5.9 GHz 무선
  2. 접속 계층: DSRC(802.11p) 또는 C-V2X
  3. 네트워크·전송 계층: IPv6, TCP/UDP
  4. 보안 계층: 인증과 암호화
  5. 퍼실리티 계층: 메시지 생성과 처리
  6. 응용 계층: V2X 응용

접속 계층만 교체하면 상위 계층을 재사용할 수 있는 구조입니다. DSRC와 C-V2X를 함께 지원하는 근거가 여기에 있습니다.

메시지별 전송 빈도와 지연 목표는 스펙에서 다음과 같이 정해져 있습니다.

메시지빈도용도지연
BSM10 Hz위치, 속도, 방향<10 ms
CAM1~10 Hz차량 상태<100 ms
DENM이벤트 발생 시위험 경고<10 ms
SPaT10 Hz신호등 정보<100 ms
MAP1 Hz도로 기하 정보<500 ms

충돌 회피 같은 핵심 안전 응용에는 10 ms 미만의 초저지연이 요구됩니다. 이 요구가 메시지 크기와 전송 주기의 상한을 정합니다. 스펙이 성능 요구를 데이터 형식과 함께 정의하는 이유가 여기에 있습니다.

구현 고려사항

2.4 SDK와 CLI로 보는 구현 모델

표준은 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);
});

이 예에서 확인할 구현 포인트는 세 가지입니다.

CLI는 현장 점검과 시험에 쓰입니다. 주요 명령은 다음과 같습니다.

지연 측정 명령이 따로 있다는 점은 앞의 지연 요구를 실제로 검증할 수 있어야 한다는 설계 의도를 보여 줍니다.

요약

2.5 이 장의 정리와 다음 장으로의 연결

이 장에서 다룬 과제는 세 가지로 모입니다.

표준은 계층형 스택으로 접속 기술을 분리하고, 메시지별 빈도와 지연 목표를 명시하며, SDK와 CLI로 검증 수단을 제공하는 방식으로 이 과제에 대응합니다.

다음 장에서는 이 개관을 바탕으로 메시지의 실제 구조, 곧 BSM과 CAM 등의 데이터 형식을 살펴보겠습니다. 이 장에서 본 전송 빈도와 지연 목표가 필드 구성과 인코딩에 어떤 제약을 주는지도 함께 다룹니다.