1. 목적 및 적용 범위
1.1 목적
ㆍ 이 기술기준은 교통시설 및 서비스 이용요금을 현금ㆍ수표 등이 아닌 전자거래로 지불하는 징수체계(Electronic Toll Collection System, 이하 'ETCS'라 함)의 핵심기술인 단거리 전용통신(Dedicated Short Range Communication, 이하, ‘DSRC’라 함) 규약의 표준화된 응용 인터페이스 방식 및 정보형식을 정의함으로써 국가차원의 상호운용성과 호환성을 확보하고, ETCS의 전국 확산과 활용을 지원하기 위함이다.
1.2 적용 범위
ㆍ 이 기술기준은 DSRC를 이용한 전자요금징수 환경에서 노변장비(Road Side Equipment, 이하 ‘RSE’라 함)와 차내장비(On-Board Equipment, 이하 ‘OBE’라 함) 사이에서 요금을 주고받는 시스템에 적용된다.
ㆍ 이 기술기준은 DSRC 매체방식(적외선, 전파 등)의 차이에 관계없이 적용될 수 있다.
ㆍ 이 기술기준은 고속도로 등 유료도로의 요금소 뿐만 아니라 주차장, 주유소 등 차량을 이용하는 교통시설 또는 서비스에 대해 DSRC 기술을 기반으로 요금을 징수하고자 할 때 사용된다.
2. 용어 정의 및 약어
ㆍ 차량탑재장치(On-Board Unit)
- 차량 내에 장착되어 노변장비(RSE)와의 정보 교환을 지원하기 위한 장치로서 간단한 보호 정보를 포함하는 차내장비(OBE)의 최소 구성요소
ㆍ 전자카드(IC Card)
- 금전적 가치가 전자적 장치에 정보로 저장되어 있어 재화 또는 용역을 구입하고 그 대가를 지급하는데 사용되는 카드
ㆍ 차내장비(On-Board Equipment)
- 노변장비(RSE)와 통신 및 정보교환을 통해 거래를 수행하기 위해 차량 내에 장착되어 있는 장비로 차량탑재장치(OBU)와 전자카드로 구성됨
ㆍ 노변장비(Road Side Equipment)
- 차내장비(OBE)와 통신 및 정보교환을 목적으로 징수지점에 설치되어 도로전송네트워크의 고정된 위치에 있는 장비
ㆍ 처리(Transaction)
- 노변장비(RSE)와 차내장비(OBE) 사이에서 DSRC를 이용하여 ETCS 운영을 실행하는데 필요한 정보교환의 전체 과정
※ 처리는 입구세션 및 출구세션과 같이 하나 이상의 세션을 요구할 수 있음
ㆍ 서비스 프리미티브(Service Primitive)
- 응용서비스 계층 프로토콜이 응용서비스 프로세스에 제공하는 기초적인 통신 서비스
※ 응용서비스 프로세스의 기초서비스 증빙은 절대적으로 더 낮은 프로토콜 계층에서 제공된 서비스를 요구하고 사용함
ㆍ 서비스 (Service)
- 보통 인프라의 형식으로 서비스 이용자에게 제공되는 도로, 주차장 등 서비스 공급자가 제공하는 편의시설로써 서비스 이용자는 이용을 위해 요금을 지불해야 하는 경우도 있음
ㆍ 서비스 공급자(Service Provider)
- 사용자의 지불 수단을 수용하고 나서 서비스 이용자에게 도로 사용 등의 서비스를 제공하는 운영자
ㆍ 서비스 이용자(User)
- 약정된 조건에 따라 서비스 공급자가 제공한 이동 서비스를 이용하는 실체
ㆍ 속성(Attribute)
- 하나 또는 연속적인 데이터 요소에 의해 형성된 응용서비스 정보. Transaction의 구현을 위해 사용된 서로 다른 종류의 액션이 관리함
ㆍ 약정(Contract)
- 도로, 주차장 등 인프라의 사용에 관계된 둘이나 그 이상의 단체 사이의 합의
ㆍ 암호화(Cryptography)
- 정보내용을 숨기거나 발견되지 않은 수정사항을 예방하고 또는 허가 없는 사용을 막기 위해 데이터를 변형하는 원리, 수단, 방법을 구체화하는 규칙[ISO/IEC 7498-2]
ㆍ 약어
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
3. 기준 구성
3.1 기술기준의 범위
ㆍ 이 기술기준의 범위는 아래 <그림 1>의 3가지 부분에 대하여 정의한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ DSRC 응용 인터페이스(API) 형식
ㆍ ETC 응용프로그램의 요금처리 절차 (ETC-Debit Transaction flow)
ㆍ ETC 응용프로그램이 이용하는 정보 형식 (Message format)
3.2 기술기준의 구성
ㆍ DSRC 응용 인터페이스(API)는 ISO 14906 표준에서 정의하는 5가지 기본적인 명령어를 사용한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
- 동작수행명령(Action)은 ETCS에 적합하도록 다시 15개의 서브함수(sub-function)로 재 정의하고 있으며 본 기준에서는 아래 3가지 서브함수를 사용한다.
ㆍ Action-Debit : OBE에 요금차감을 수행하도록 요청
ㆍ Action-Set-Secure : OBE에 정보를 안전하게 쓰기
ㆍ Action-Transfer-channel : RSE가 카드에게 명령을 직접 전달
ㆍ ETC 응용프로그램의 요금처리 절차(ETC-Debit Transaction flow)는 아래와 같이 3단계로 구분하여 수행한다.
- 초기화 단계(Initialization phase) : OBE가 카드를 초기화하고 RSE에게 통신영역의 진입을 통보하는 단계
- 징수 단계(Transaction phase) : RSE가 카드 및 OBU 내에 기록된 기본등록정보 및 교통관련 추가정보를 읽고 요금을 계산한 후, 카드의 요금차감을 수행하는 단계
- 후속처리 단계(Post transaction phase) : 요금차감 후 처리결과를 OBU 및 카드에 기록하는 단계
ㆍ ETC 응용프로그램이 이용하는 정보형식은 OBU와 카드에 대한 등록정보 및 애플리케이션 정보의 포맷을 의미하는 것으로 본 기준은 이를 표준화하는 것이다. 이때 모든 정보는 속성파일(Attribute) 형태로 지정된다.
3.3 다양한 카드의 처리 방안
ㆍ 실시간 요금징수가 가능한 고속처리 알고리즘(FTA, Fast Transaction Algorithm)을 탑재하고 있고 다양한 요금체계(개방식, 폐쇄식, 접속식)를 반영하도록 설계된 카드 및 OBU에 대하여 최적화되도록 정의한다.
- 기존의 교통카드(예: 버스카드 등)나 금융카드(예: 후불신용카드) 등 다른 카드는 RSE의 Action 명령어 중 Transfer-channel 서브함수를 이용하여 카드요금을 차감한다.
- 이 서브함수를 사용하면 OBU는 단순히 무선통신과 유선통신을 변환하는 프로토콜 컨버터(protocol converter) 역할만 수행하게 되며 실질적인 요금처리는 기존 카드의 징수처리절차에 따라 RSE가 카드를 직접 제어토록 한다. 다만, 이 경우 카드처리 절차의 복잡도 및 수행능력으로 인해 발생되는 요금징수 처리시간의 지연에 대비한 보완처리절차를 수행하여야 한다.
ㆍ 위의 모든 카드사용을 위해서 OBU에서는 사용자가 ETCS 제휴카드 이외의 카드를 사용할 경우 새로운 EID를 생성하며, 카드의 구분을 위한 Context Mark를 파라미터로 할당한다. 이 정보는 초기화절차에서 OBU가 VST를 통해 RSE에게 통보한다. 이 때 RSE에서 카드종류의 분석은 VST내의 Context Mark를 통해 구분한다.
※ Context Mark는 KS X ISO 14906의 CONTRACT 데이터 그룹을 참조하여 국토교통부에서 부여ㆍ관리토록 한다. 이 기술기준을 적용하여 요금을 징수하고자 하는 자는 해당 사업계획을 제출하여 Context Mark를 부여받아야 한다.
- 단, 단순화되거나 다른 속성(Attribute)을 이용하여 요금징수를 처리하고자 하는 자는 희망사항을 사업계획에 추가하여 국토교통부의 승인을 득하여야 하며, 국토교통부는 해당사항을 반영하여 적절한 절차에 따라 기술기준을 갱신할 수 있다.
4. DSRC 응용 인터페이스(API) 형식
4.1 DSRC와 ETCS 응용 프로세스의 관계
ㆍ 이 기술기준에서 정의하는 ETCS 응용 인터페이스는 DSRC 응용 계층의 서비스 프리미티브를 이용하여 요금의 자동인식 및 징수에 대한 정보를 수집ㆍ처리ㆍ제공하는 서비스를 의미한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ 즉, <그림 2>에서 보듯이 DSRC의 응용 계층과 ETCS 응용 프로세스 간에 서비스 프리미티브를 이용한 정보교환을 의미하는 것으로 다음과 같은 서비스(또는 기능)를 제공한다.
- INITIALIZATION : 사용자가 이 서비스를 호출하게 되면, 아직 RSE와 통신이 이루어지지 않은 각각의 OBU와 RSE 간에 통신 초기화를 시도하게 된다. INITIALIZATION 서비스는 초기화 모듈에서만 사용한다.
- GET : 사용자는 이 서비스를 호출함으로써, 상대방의 정보검색을 통해 필요한 정보를 얻을 수 있다. 이 서비스는 확인 모드에서만 서비스 요청이 가능하며, 요청에 대해서는 반드시 응답하여야 한다.
- SET : 사용자는 이 서비스를 호출함으로써, 상대방의 정보를 수정한다. 이 서비스는 확인/비확인 모드 둘 다 서비스 요청이 가능하며, 확인 모드에서는 요청에 대해 반드시 응답하여야 한다. 브로드캐스트와 같은 특별한 상황에서는 비확인 모드에서 서비스 요청만 수행할 수 있다.
- ACTION : 사용자는 이 서비스를 호출함으로써, 상대방으로 하여금 원하는 동작을 수행하게끔 할 수 있다. 이 서비스는 확인/비확인 모드 둘 다 서비스 요청이 가능하며, 확인 모드에서는 요청에 대해 반드시 응답하여야 한다.
- EVENT-REPORT : 사용자는 이 서비스를 호출함으로써, 상대방에 이벤트(Event)를 던지게 된다. 이 서비스는 확인/비확인 모드 둘 다 서비스 요청이 가능하며, 확인 모드에서는 요청에 대해 응답하여야 한다.
4.2 DSRC 응용계층의 사용방법
ㆍ 앞서 4.1에서 정의한 DSRC 응용계층의 각 서비스를 ETCS에서는 다음과 같이 사용한다.
- INITIALIZATION 서비스는 다음 각각에 대하여 ETC사양의 초기화 메커니즘을 실현하기 위해 사용한다.
ㆍRegister Application RSE (RSE 측)
ㆍNotify Application Beacon (RSE 측)
ㆍReady Application (RSE 측)
ㆍRegister Application OBE (OBE 측)
ㆍNotify Application Vehicle (OBE 측)
- GET 서비스는 ETC의 속성을 검색하는데 이용한다.
- SET 서비스는 ETC의 속성을 수정하는데 이용한다.
- ACTION 서비스는 TRANSFER_CHANNEL, SET_MMI, ECHO, DEBIT 등과 같은 ETCS 응용처리를 지원하기 위해 필요한 부가된 ETCS 특별기능을 구현하는데 이용한다.
4.3 ETCS의 기능 및 서비스 프리미티브
ㆍ ETCS는 DSRC 응용계층과의 연결을 통해 교환되는 서비스 프리미티브를 이용하여 기능을 구현하며 이는 다음과 같은 기본 패턴을 따른다.
- 요구(xxx.Request): 서비스 이용자가 기능을 호출하는 프리미티브로 본 기준에서는 RSE 응용의 DSRC 응용계층에 의해 수행한다.
- 지시(xxx.Indication): 서비스 공급자가 기능을 호출하기 위해 또는 서비스 접근점에서 기능이 호출되었음을 지시하기 위해서 사용되는 프리미티브로 본 기술기준에서는 DSRC 응용계층의 OBU 응용에 의해 발행한다.
- 응답(xxx.Response): 서비스 이용자가 지시에 의하여 이미 호출된 기능을 완료시키기 위해서 사용되는 프리미티브로 OBU 응용의 DSRC 응용계층에 의해 수행한다.
- 확인(xxx.Confirm): 서비스 공급자가 요구에 의하여 이미 호출된 기능을 완료시키기 위해서 사용되는 프리미티브로 DSRC 응용계층의 RSE 응용에 의해 발행한다.
ㆍ 마지막 두 단계는 의무적이거나 또는 선택적이며, 서비스 프리미티브의 성격에 기초하거나 모드(Mode) 파라미터 값의 설정에 의해 정해진다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
※ 이 기술기준을 이용하여 ETCS를 구현할 경우에 필요한 모든 ETCS의 기능과 서비스 프리미티브의 구성은 KS X ISO 14906에 따른다.
5. ETCS를 이용한 요금징수절차
ㆍ ETCS를 이용하여 요금을 징수하는 절차는 <그림 4>와 같이 초기화, 요금징수, 후속처리의 3단계로 구성되며, 각각의 단계에서는 다음과 같은 역할을 수행하도록 한다.
- 초기화 단계 : RSE가 OBE에 대해서 ID, 카드와 트랜잭션 등에 대한 정보를 요청하고 이에 대한 응답을 체크함으로써 요금징수가능 여부를 판단하는 역할을 수행한다.
- 요금징수 단계 : RSE가 OBE에 대해서 카드와 카드소지자, 최근 트랜잭션 정보 등을 요청하고 이에 대한 응답을 확인 한 후에 해당 OBE를 통하여 카드의 금액을 차감하고 처리여부에 대한 응답을 확인하는 역할을 수행한다. 이 요금징수과정에서는 요금관련 데이터 이외에 적절한 보안데이터를 포함하여야 한다.
- 후속처리 단계 : RSE가 OBE에 대해서 최근 트랜잭션 정보와 함께 거래내역과 거래종료에 대한 정보를 요청ㆍ확인함으로써 최종 요금징수여부를 체크하고 처리결과를 해당 OBE에 전송하는 역할을 수행한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ 이 기술기준을 적외선 DSRC에 적용할 경우에 요금징수절차에서의 속성(Attribute)값은 다음과 같다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ 이 기술기준을 전파 DSRC에 적용할 경우에 요금징수절차에서의 속성(Attribute)값은 다음과 같다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
※ 요금징수절차에 따른 ETCS 기능에 대한 세부사항은 [부록 A]를 참조한다.
6. ETCS 정보형식(속성) 정의
ㆍ 본 기준에 수록된 ETCS를 위한 정보형식(속성) 중에서 카드의 발급, 관리, 정산 등 카드와 관련되어 필요한 모든 내용은 KS X 6923, KS X ISO 17573, KS X ISO 14816의 정의를 준용하며, 세부적인 구조정의나 관리절차는 필요에 따라 별도로 정한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ 본 기준에 수록된 ETCS를 위한 정보형식(속성)은 기본적으로 관련 국제표준에서 정의한 형태 및 규칙을 따르도록 하며, 실제 데이터는 아래 보는 바와 같이 Container의 octetstring에 인코딩되어 들어간다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.1 카드정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.2 최근 카드 트랜잭션 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.3 카드 소지자 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.4 OBU 기본정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.5 최근 OBU 트랜잭션 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.6 OBU 추가 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.7 거래종료 정보 1
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.8 거래종료 정보 2
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.9 거래내역 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.10 Reserved
* Attributte ID #10은 향후 확장을 위한 영역임
6.11 카드 관련 상세 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.12 OBU ID 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.13 트랜잭션 상세 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
6.14 OBU 구성 정보
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
7. 정보형식(속성)의 ID 및 관리번호 부여방법
ㆍ Attribute ID #1의 카드정산센터 ID 및 카드서비스 ID 지정 방법
- Attribute ID #1의 카드정산센터 ID는 DSRC를 이용한 ETCS 정산업무를 수행하는 기관이 지정한 ID를 사용함
- Attribute ID #1의 카드서비스 ID는 카드의 서비스 구분 또는 보안을 위해 사용할 수 있는 공간으로 아래와 같은 형태로 사용할 수 있음 (※발급기관에 따라 사용하지 않을 수 있음)
ㆍ 사례1) 카드의 종류에 따른 서비스 구분을 위해 사용할 경우에는 발급기관 ID와 같은 체계를 사용하되, 마지막 1바이트를 서비스의 종류구분자로 사용함
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ 사례2) 카드보안을 위해 사용할 경우에는 카드의 유형(1바이트)과 암호 알고리즘에 의해 산출된 서명값(8바이트) 중 특정 2바이트의 조합을 사용함
ㆍ Attribute ID #2, #5의 운영기관 관리번호 부여 방법
- ETCS를 이용한 요금징수 운영기관 관리번호는 정산업무 수행기관에서 관리ㆍ부여함
ㆍ Attribute ID #3의 카드번호 지정 방법
- Attribute ID #3의 카드번호는 총 8바이트로 카드 발급기관 ID(3바이트)와 카드번호(5바이트)로 구성됨
ㆍ 카드 발급기관 ID :
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ 카드번호 : 카드발급시 부여된 고유 ID, 각 정산센터별로 일련번호 (5바이트, Hex) 형태로 구성됨
ㆍ Attribute ID #4의 OBU 등록번호 지정 방법
- OBU 등록번호는 요금징수기관 또는 운영기관에서 운영관리의 용이성을 확보하기 위하여 부여함
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ Attribute ID #4의 OBU 제조번호 지정 방법
- OBU 제조번호는 전체 8바이트이며, 전자요금징수시스템 단말기 인증기관(1바이트), 제조사(1바이트), 모델(1바이트)과 일련번호(3바이트)로 구성됨
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
ㆍ Attribute ID #14의 OBU 제조사 ID 지정 방법
- Attribute ID #4의 OBU 제조번호에서 인증기관(1바이트)과 제조사(1바이트)를 조합하여 사용함
ㆍ 요금징수용 노변장비(RSE) ID 부여 방법
- RSE ID는 두 개의 옥텟으로 나누어 구성
- 상위 16비트는 안테나(노변장비(RSE)) 제조와 관련된 정보, 나머지 27비트는 운영을 위한 고유 ID로 구성
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
8. 재검토기한
ㅇ 국토교통부장관은 이 고시에 대하여 「훈령ㆍ예규 등의 발령 및 관리에 관한 규정」에 따라 2024년 7월 1일 기준으로 매 3년이 되는 시점(매 3년째의 6월 30일까지를 말한다)마다 그 타당성을 검토하여 개선 등의 조치를 하여야 한다.