KR20060095868A

KR20060095868A - 노차간 통신 시스템

Info

Publication number: KR20060095868A
Application number: KR20067007142A
Authority: KR
Inventors: 마사히코 이카와; 유키오 고토; 히로유키 구마자와; 요시아키 츠다
Original assignee: 미쓰비시덴키 가부시키가이샤
Priority date: 2003-10-15
Filing date: 2004-10-01
Publication date: 2006-09-04
Also published as: JP4396639B2; JP2009077422A; CN1846375A; US20060193282A1; CN1846375B; US7843869B2; KR100733196B1; WO2005039075A1; JP4697490B2; JPWO2005039075A1

Abstract

도로상을 주행하는 이동국과, 도로상에 설치된 기지국 장치 사이에서 행해지는 노차간 통신을 이용하여, 이동국에 대하여 응용 서비스를 제공하는 노차간 통신 시스템에 있어서, 주행중에 있더라도 여러 가지의 애플리케이션을 실행 가능한 메카니즘을 구비한 비(非)네트워크형의 통신 프로토콜을 제공하는 것을 목적으로 한다. 본 발명의 노차간 통신 시스템은, 복수의 애플리케이션간의 데이터 전송을 위한 메카니즘을 제공하는 전송 서비스 처리부, 및 미달(未達) 데이터의 재송신 기구와, 메시지 단위의 데이터 송수신 기구와, 메시지의 분할ㆍ조립 기구를 갖고, 단방향의 데이터 송신과 요청ㆍ응답형의 트랜잭션 서비스를 제공하는 트랜잭션 관리부로 구성된다.

Description

노차간 통신 시스템{BETWEEN-LOAD-AND-VEHICLE COMMUNICATION SYSTEM}

본 발명은 도로상을 주행하는 이동국과, 도로상에 설치된 기지국 장치 사이에서 행해지는 노차간 통신을 이용하여, 상기 이동국에 대하여 응용 서비스를 제공하는 노차간 통신 시스템에 관한 것이다.

종래의 노차간 통신 시스템의 일례로서는, 사단법인 전파 산업회에서 정해진 표준 규격 「협역 통신(DSRC) 시스템 표준 규격 ARIB STD-T75」(2001년 9월 6일 책정)가 알려져 있다. 이 표준 규격은 통신 구역(zone)을 한정한 스폿 통신(spot communication)에 의한 노차간 통신 방식을 정한 것으로서, 애플리케이션마다 AID라고 불리는 식별자를 이용함으로써 멀티 애플리케이션에 대응하고 있다.

그러나, 상기 종래 기술에서는, 항상 기지국이 마스터, 이동국이 슬레이브이고, 마스터ㆍ슬레이브형의 애플리케이션밖에 실현할 수 없어, 이동국측으로부터 통신을 기동하거나, 이동국과 기지국이 대등하게 통신하는 애플리케이션에는 적용할 수 없었다. 또한, 이 AID라고 불리는 식별자는 32개밖에 규정할 수 없기 때문에, 애플리케이션의 종류가 증대한 경우에 대응이 곤란하다는 문제도 있었다. 또한, 한번에 송수신 가능한 데이터 사이즈가 수백 바이트 정도로 작아, 수십 킬로바이트 이상의 대용량의 데이터 통신을 필요로 하는 애플리케이션에 이용하는 것은 곤란하였다.

이들 과제를 해결하기 위한 수법의 일례로서, 상기 표준 규격(협역 통신(DSRC) 시스템 표준 규격 ARIB STD-T75)상에, 쌍방향으로 통신 가능한 프로토콜인 확장 통신 제어 프로토콜(ASL-ELCP)을 배치하여, 기지국이 정기적으로 이동국으로부터의 통신의 유무를 폴링(polling)함으로써, 이동국으로부터의 통신을 실현하고 있다. 또한, 상기 확장 통신 제어 프로토콜(ASL-ELCP)에 액세스점 식별자라고 불리는 식별자를 정의하여, 상기 표준 규격(협역 통신(DSRC) 시스템 표준 규격 ARIB STD-T75)과 상기 확장 통신 제어 프로토콜(ASL-ELCP)로 이루어지는 계층상에 복수의 프로토콜의 동작을 가능하게 하고, 이 복수의 프로토콜의 하나로서 인터넷 프로토콜을 이용함으로써, 멀티 애플리케이션으로의 대응을 실현하고 있다. 또한, 대량 전송이라고 불리는 분할ㆍ조립 기구를 갖음으로써, 최대 50킬로바이트 정도의 메시지의 송수신이 가능하다. 또한, 동보 통신에 있어서는, 동일 데이터를 복수회 연속해서 송신함으로써 통신의 오류율을 작게 억제하는 것을 실현하고 있다(예컨대, 비특허 문헌 1 참조).

비특허 문헌 1: 정보처리학회 ITS 연구회 「DSRC(ARIB STD-T75 준거) 시스템의 실장 및 평가」(2002-ITS-10-10)

발명의 개시

발명이 해결하고자 하는 과제

그러나, 상기 종래 기술에서는, 멀티 애플리케이션을 실현하기 위해서, 상기 확장 통신 제어 프로토콜(ASL-ELCP)상에서, 네트워크형의 프로토콜인 인터넷 프로토콜을 이용하므로, IP 어드레스의 할당이나 TCP의 셋업에 필요한 시간 등의 초기 접속에 관계되는 오버헤드의 문제 때문에, 주행중의 애플리케이션에 대하여 적용이 곤란하다는 문제가 있었다. 또한, 마찬가지의 문제에 의해, 주행중에 송신하는 데이터 사이즈가 100킬로바이트를 초과하는 애플리케이션으로의 적용은 여전히 곤란하였다. 또한, 상기 대량 전송 기능에서는, 데이터를 단순히 분할하고 있을 뿐이기 때문에, 분할 데이터의 재송을 하위층인 DSRC에 의존하고 있어, DSRC 통신 이외의 이유에 의해 누락된 데이터에 대한 대응에 문제가 있었다. 또한, 섀도잉(shadowing)이나 전파가 약한 등, 소정의 시간 통신 불가능한 영역에서는, 재송한 각각의 데이터나 연속해서 송신한 데이터 전부가 누락될 가능성이 있기 때문에, 오류율을 개선할 수 없다는 문제가 있었다.

본 발명은 이러한 문제점을 해결하기 위해서 이루어진 것으로, 도로상을 주행 및 정지하는 이동국과, 상기 도로상에 설치된 기지국 장치 사이에서 행해지는 노차간 통신을 이용하여, 상기 이동국에 대하여 응용 서비스를 제공하는 노차간 통신 시스템에 있어서, 주행중에 있더라도 여러 가지의 애플리케이션을 실행 가능하게 하기 위해서, 복수의 애플리케이션간의 데이터 전송을 위한 메카니즘과, 100킬로바이트를 초과하는 대용량의 데이터 송신의 메카니즘과, 일정 시간 통신할 수 없 는 경우에 있어서도, 통신 오류율을 개선 가능한 메카니즘을 구비한 비(非)네트워크형의 통신 프로토콜을 제공하는 것이다.

과제를 해결하기 위한 수단

본 발명에 따른 노차간 통신 시스템은, 도로상을 주행하는 이동국과, 상기 도로상에 설치된 기지국 장치 사이에서 행해지는 노차간 통신을 이용하여, 상기 이동국에 대하여 응용 서비스를 제공하는 노차간 통신 시스템에 있어서, 복수의 애플리케이션간의 데이터 전송을 위한 메카니즘을 제공하는 전송 서비스 처리부, 및 미달(未達) 데이터의 재송신 기구와, 메시지 단위의 데이터 송수신 기구와, 메시지의 분할ㆍ조립 기구를 갖고, 단방향의 데이터 송신과 요청ㆍ응답형의 트랜잭션 서비스를 제공하는 트랜잭션 관리부를 구비하는 것이다.

발명의 효과

본 발명에 따른 노차간 통신 시스템은, 기지국 장치 및 이동국내의 쌍방의 로컬 애플리케이션이 비네트워크형의 프로토콜을 이용하여 통신을 행하는 시스템으로서, 상기 비네트워크형의 프로토콜을 전송 서비스 처리부와 트랜잭션 관리부로 구성했기 때문에, 주행중에 있더라도 여러 가지의 애플리케이션이 실행 가능해진다. 또한, 일정 시간 통신할 수 없는 경우에 있어서도, 통신 오류율이 개선 가능해진다.

또한, 전송 서비스 처리부와 트랜잭션 관리부를 각각 독립된 구성으로 했기 때문에, 가장 단순한 애플리케이션에서는 전송 서비스 처리부를 직접 사용함으로써 실현이 가능하여, 고속 접속성, 낮은 오버헤드라고 한 주행중의 노차간 통신에 필요한 요건을 만족할 수 있다. 또한, 프로토콜을 확장할 때에는 확장 개소를 트랜잭션 관리부로 국소화할 수 있어, 확장을 용이하게 실행할 수 있다.

전송 서비스 처리부에서는, 송수신 쌍방의 애플리케이션을 식별하기 위해서 포트 번호를 이용한다. 이에 따라, 복수의 애플리케이션간의 데이터 전송을 실현할 수 있다. 또한, 이 포트 번호는 65536종류가 있어, 금후의 애플리케이션 종류의 증대에도 충분히 대응이 가능하다.

트랜잭션 관리부에서는, 애플리케이션으로부터 지정된 식별자(송신 데이터 식별자)에 의해 송신 데이터의 단위를 식별한다. 또한, 이 프로토콜은 송신 데이터 단위가 하위층의 프로토콜에 의해 한번에 송신 가능한 사이즈보다도 큰 경우에는, 송신 가능한 사이즈로 분할하여, 순서 번호를 부여해서 송신하고, 수신측에서 그 순서 번호를 기초로 조립하는 기능을 갖는다. 이 때, 개별 통신의 경우에는, 최종 데이터의 수신시에 미수신 데이터의 순서 번호를 송신측에 통지함으로써, 송신측은 미수신 데이터만을 재송신한다. 이에 따라, 통신 오류율을 개선할 수 있다.

또한, 개별 통신ㆍ동보 통신의 경우에는, 송신원의 애플리케이션 식별자(송신원 포트 번호)와 그 애플리케이션이 지정한 송신 데이터 식별자의 세트가 동일한 경우에는, 수신측에서 기수신된 동일 식별자의 데이터와 동일한 데이터로서 취급한다. 이에 따라, 송신측은 임의의 타이밍에서 데이터의 재송신이 가능해져, 일정 시간 통신할 수 없는 경우에 있어서도, 통신 오류율을 개선할 수 있다.

도 1은 본 발명의 실시예 1에 따른 노차간 통신 시스템에 있어서의 연결 식별의 개념을 나타내는 도면,

도 2는 로컬 포트 번호의 분류를 나타내는 도면,

도 3은 데이터그램 전송 서비스의 예를 나타내는 도면,

도 4는 프리미티브 종별을 나타내는 도면,

도 5는 파라미터 종별을 나타내는 도면,

도 6은 데이터 전송 서비스의 논리 관계를 나타내는 도면,

도 7은 전송 프리미티브의 정의를 나타내는 도면,

도 8은 관리 서비스 인터페이스의 논리 관계를 나타내는 도면,

도 9는 이벤트 통지 프리미티브의 정의를 나타내는 도면,

도 10은 포트 생성 프리미티브의 정의를 나타내는 도면,

도 11은 포트 파기 프리미티브의 정의를 나타내는 도면,

도 12는 수신 가능 포트 리스트의 구성예를 나타내는 도면,

도 13은 통신 제어 정보의 구성예를 나타내는 도면,

도 14는 데이터 전송 메시지의 형식을 나타내는 도면,

도 15는 LPCP의 프로토콜 식별자를 나타내는 도면,

도 16은 이벤트 통지 메시지의 형식을 나타내는 도면,

도 17은 이벤트 코드(Event Code)의 내용을 나타내는 도면,

도 18은 LPCP의 초기 접속 순서의 일례를 나타내는 도면,

도 19는 LPCP의 통신 종료 순서의 일례를 나타내는 도면,

도 20은 LPCP의 메시지 전송 순서를 나타내는 도면,

도 21은 DSRC가 접속되어 있지 않은 경우의 처리 순서를 나타내는 도면,

도 22는 송신처 포트 번호가 유효하지 않은 경우의 메시지 전송 순서를 나타내는 도면,

도 23은 LPP의 개념을 나타내는 도면,

도 24는 LPP에서의 트랜잭션간 데이터 교환예를 나타내는 도면,

도 25는 데이터 송신 서비스의 예를 나타내는 도면,

도 26은 요청ㆍ응답형 트랜잭션 서비스의 예를 나타내는 도면,

도 27은 데이터 재송의 예를 나타내는 도면,

도 28은 중복 수신 체크의 예를 나타내는 도면,

도 29는 메시지의 분할ㆍ조립 처리의 예를 나타내는 도면,

도 30은 선택적 재송 처리의 예를 나타내는 도면,

도 31은 최종 패킷의 재송 처리의 예를 나타내는 도면,

도 32는 트랜잭션 재실행의 예를 나타내는 도면,

도 33은 트랜잭션 파기 통지의 예를 나타내는 도면,

도 34는 프리미티브 종별을 나타내는 도면,

도 35는 파라미터 종별을 나타내는 도면,

도 36은 Invoke 프리미티브의 인수를 나타내는 도면,

도 37은 Abort 프리미티브의 인수를 나타내는 도면,

도 38은 Abort Type=0의 경우(시스템 에러)의 Abort Code 일람을 나타내는 도면,

도 39는 Connect 프리미티브의 인수를 나타내는 도면,

도 40은 Disconnect 프리미티브의 인수를 나타내는 도면,

도 41은 Register Port 프리미티브의 인수를 나타내는 도면,

도 42는 Deregister Port 프리미티브의 인수를 나타내는 도면,

도 43은 PDU 종별 일람을 나타내는 도면,

도 44는 로컬 포트 프로토콜의 프로토콜 데이터 유닛의 기본 구조를 나타내는 도면,

도 45는 Invoke PDU의 헤더 정보를 나타내는 도면,

도 46은 Result PDU의 헤더 정보를 나타내는 도면,

도 47은 Acknowledgement PDU의 헤더 정보를 나타내는 도면,

도 48은 Abort PDU의 헤더 정보를 나타내는 도면,

도 49는 Invoke Segment PDU의 헤더 정보를 나타내는 도면,

도 50은 Result Segment PDU의 헤더 정보를 나타내는 도면,

도 51은 Nack PDU의 헤더 정보를 나타내는 도면,

도 52는 수신 가능 포트 리스트 통지에 있어서의 프로토콜 데이터 유닛을 나타내는 도면,

도 53은 송신 불가 포트 통지에 있어서의 프로토콜 데이터 유닛을 나타내는 도면,

도 54는 로컬 포트 프로토콜의 초기 접속 순서를 나타내는 도면,

도 55는 고속 접속 애플리케이션의 초기 접속 순차의 예를 나타내는 도면,

도 56은 데이터 송신 트랜잭션 서비스의 처리 순차의 예를 나타내는 도면,

도 57은 요청ㆍ응답형 트랜잭션 서비스의 기본 처리 순차의 예를 나타내는 도면,

도 58은 Result 타이머가 타임아웃한 경우의 처리 순차의 예를 나타내는 도면,

도 59는 재송 처리가 유효한 경우의 데이터 전송 순서(기본 순차)를 나타내는 도면,

도 60은 재송 처리 순서(재송 성공시)를 나타내는 도면,

도 61은 재송 처리 순서(재송 실패시)를 나타내는 도면,

도 62는 분할ㆍ조립 처리가 유효한 경우의 순차의 예를 나타내는 도면,

도 63은 분할ㆍ조립 처리가 유효한 경우의 순차의 예(선택적 재송 처리)를 나타내는 도면,

도 64는 분할ㆍ조립 처리가 유효한 경우의 순차의 예(최종 세그먼트가 미달시의 경우)를 나타내는 도면,

도 65는 DSRC 절단시의 순서를 나타내는 도면,

도 66은 트랜잭션 파기 순서를 나타내는 도면.

발명을 실시하기 위한 최선의 형태

(실시예 1)

도 1은 본 발명의 실시예 1에 따른 노차간 통신 시스템에 있어서의 연결 식별의 개념을 나타내는 도면이다. 또한, 도 3은 본 발명의 실시예 1에 따른 노차간 통신 시스템에 있어서의 데이터 흐름의 개요를 나타내는 도면이다. 도 1, 도 3을 이용하여, 기지국 장치와 이동국의 기본 구성을 설명한다.

기지국 장치 및 이동국에서 사용하는 통신 프로토콜은 협역 통신(DSRC) 프로토콜(ARIB STD-T75)과, 쌍방향으로 통신 가능한 프로토콜인 확장 통신 제어 프로토콜(ASL-ELCP)과, 전송 서비스 처리부(로컬 포트 제어 프로토콜(LPCP: Local Port Control Protocol))와, 트랜잭션 관리부(로컬 포트 프로토콜(LPP: Local Port Protocol))로 이루어지는 계층 구조를 하고 있으며, 이 통신 프로토콜상에서 복수의 애플리케이션이 실행된다.

전송 서비스 처리부는 협역 통신(DSRC) 프로토콜(ARIB STD-T75) 및 확장 통신 제어 프로토콜(ASL-ELCP)상에서 애플리케이션의 다중화를 실현하기 위한 제어 프로토콜이며, 멀티 애플리케이션을 실현하기 위한 최소한의 기능을 갖고 있다.

한편, 트랜잭션 관리부는 상기 전송 서비스 처리부와 애플리케이션 사이에 개재하여, 전송 서비스 처리부의 통신 서비스를 확장하는 통신 프로토콜이며, 대용량 데이터 통신 등과 같은 고도의 통신 서비스를 애플리케이션에 대하여 제공한다.

이하에서는, 이 전송 서비스 처리부와 트랜잭션 관리부에 대해서 상세하게 설명한다.

1. 전송 서비스 처리부(로컬 포트 제어 프로토콜)

1.1 개요

이하에 전송 서비스 처리부(로컬 포트 제어 프로토콜)에 대해서 상세하게 설명한다. 로컬 포트 제어 프로토콜(LPCP)은, 비네트워크계 애플리케이션에 통신 수단을 제공하기 위해서, 애플리케이션 등의 상위 프로토콜에 대하여 데이터 전송을 위한 데이터 전송 서비스와, 관리 제어를 위한 관리 서비스를 제공하는 제어 프로토콜이다.

전송 서비스 처리부에서는, 로컬 포트 번호라고 부르는 식별자를 이용하여, 송신원 및 송신처의 애플리케이션을 식별한다. 또한, 상위층인 애플리케이션이나 트랜잭션 관리부 등의 상위층 프로토콜에 대하여 데이터 전송과 관리 서비스를 위한 서비스 프리미티브(인터페이스)를 제공한다. 또한, 내부 데이터로서 데이터 전송 서비스 및 관리 서비스를 실현하기 위한 제어 정보를 갖고, 또한, 노차의 전송 서비스 처리부간에서 수수(授受)되는 데이터(PDU)에도 제어 정보를 부가함으로써 각종 서비스를 실현하고 있다.

1.2 로컬 포트 번호

1.2.1 액세스점 식별

발신원으로 되는 애플리케이션으로부터 대향하는 애플리케이션에 대하여 정확하게 데이터를 전달하기 위해서, 로컬 포트 제어 프로토콜(LPCP)에서는 도 1에 나타내는 바와 같이 LPCP상의 애플리케이션을 식별하기 위한 액세스점으로서 로컬 포트 번호를 마련하고, 차량 ID(링크 어드레스 등)와 로컬 포트 번호의 세트로, 각각의 애플리케이션에 대하여 상대편과의 접속을 식별한다.

1.2.2 로컬 포트 번호의 분류

도 2는 로컬 포트 번호의 분류의 예를 나타내는 도면이다. 로컬 포트 번호는 비네트워크계 애플리케이션에서의 연결 식별자로서 사용되고, 로컬 포트 번호를 이하와 같이 규정한다. 0~0x0FFF를 번호 예약 포트, 0x1000~0xFFFF를 임의 포트라고 한다. 이와 같이 포트 번호를 규정함으로써, 65536종류의 포트 번호를 규정할 수 있어, 금후의 애플리케이션 종류의 증대에도 충분히 대응이 가능해진다.

1.2.3 애플리케이션과 로컬 포트 번호의 관계

애플리케이션과 앞선 단락에서 규정된 로컬 포트 번호와의 관계를 설명한다.

애플리케이션의 형태는 클라이언트/서버 모델 및 피어투피어 모델을 전제로 한다. 따라서, 클라이언트/서버 모델에서는 대역적으로 유일한 서버 프로세스의 포트는 번호 예약 포트, 국내(局內)에서 유일한 클라이언트 프로세스의 포트는 임의 포트를 이용하는 것을 기본으로 한다. 또한, 피어투피어 모델에서는 쌍방의 프로세스가 번호 예약 포트를 이용하는 것을 기본으로 한다. 독자(獨自) 어플리케이션의 경우는, 임의 포트를 서버ㆍ클라이언트 모두가 사용하는 것도 가능하다.

1.2.4 로컬 포트 번호의 번호 설정

로컬 포트 번호의 번호 설정에 대해서는 이하의 규칙을 따른다.

(1) 예약 번호에 대해서는 전역적으로 중복이 없는 번호를 붙이는 것.

(2) 애플리케이션은 복수의 수신 포트를 가질 수 있다.

(3) 기지국, 이동국을 단위로 하고, 각 애플리케이션은 국내에서 중복이 없도록 수신 포트 번호를 사용하는 것.

(4) 송신원의 특정이 불필요한 경우나 송신원이 기지의 경우에는, 송신원 포트를 생략할 수 있다.

1.3 LPCP의 기능

다음에, LPCP의 기능에 대해서 상세하게 설명한다.

1.3.1 데이터 전송 기능 데이터그램 전송 서비스

도 3은 데이터그램 전송 서비스의 예를 나타내는 도면이다. DSRC-ASL에서의 로컬 포트계 애플리케이션의 구성은 LPCP상에 복수의 애플리케이션이 존재하는 계층 구조로 되어 있어, LPCP는 데이터의 전송처 애플리케이션의 식별을 할 필요가 있다.

그래서, LPCP에 송신원 및 송신처 포트 번호를 부여하고, 이에 따라 데이터의 전송처를 결정한다.

또한, LPCP가 제공하는 통신 서비스는 고속, 낮은 오버헤드의 비연결형의 데 이터그램 전송 서비스로서, LPCP와 애플리케이션(상위층 프로토콜) 사이에서의 구체적인 동작은 이하와 같다.

1: 데이터를 수취하는 수신 포트를 애플리케이션(상위층 프로토콜)이 LPCP에 의뢰하여 새롭게 작성하고,

2: 그 수신 포트를 통해서 LPCP로부터 차량 ID(링크 어드레스 등), 송신원 포트 번호 및 수신 데이터를 수취하고,

또한, 반대로

3: 애플리케이션(상위층 프로토콜)은 송신 데이터, 링크 어드레스 및 송수신 포트 번호를 LPCP에게 넘겨주어, LPCP가 그 정보로부터 LPCP 데이터그램을 생성해서 상대에게 송신한다.

1.3.2 관리 서비스

관리 서비스 처리에서는, 이하의 서비스를 애플리케이션이나 상위층 프로토콜에 대하여 제공한다.

ㆍASL-ELCP(확장 통신 제어 프로토콜)의 관리 서비스에서 통지되는 에러나 이벤트(통신의 접속, 비접속의 통지 등)를, 자국(自局)의 애플리케이션에 대하여 투과적으로 통지하는 서비스

ㆍLPCP내에서 발생한 에러나 이벤트를 상대국이나 자국의 애플리케이션에 대하여 통지하는 서비스

LPCP와 애플리케이션(또는, 상위층 프로토콜) 사이에서의 구체적인 동작은 이하와 같다.

1. 이벤트를 수취하는 포트를 애플리케이션(또는, 상위층 프로토콜)이 LPCP에게 의뢰하여 새롭게 작성하고,

2. 그 포트를 통해서 LPCP로부터 링크 어드레스, 상태 식별자, 이벤트 부가 정보를 수취한다.

1.4 애플리케이션과의 인터페이스

다음에, LPCP와 애플리케이션과의 인터페이스에 대해서 설명한다.

1.4.1 기법의 설명

본 발명에서 규정되는 프리미티브 종별의 일람을 도 4에, 프리미티브의 정의 테이블에서 이용되는 파라미터 종별의 일람을 도 5에 나타낸다.

1.4.2 데이터 전송 서비스 인터페이스

도 6에 데이터 전송 서비스의 논리 관계를 나타낸다.

로컬 포트 제어 프로토콜은 데이터 전송 서비스로서, 애플리케이션(또는, 상위층 프로토콜)에 대하여 이하의 1종류의 프리미티브를 준비한다.

1.4.2.1 전송 프리미티브(Transfer Data)

본 프리미티브는 DSRC-ASL의 ELCP와 비(非)IP 애플리케이션이나 상위층 프로 토콜 사이에서 데이터 전송을 실행하기 위한 프리미티브이다. 도 7에 전송 프리미티브의 정의를 나타낸다. 도 7에서,

Link Address: 본 송신에서 사용하는 DSRC의 LID 또는 LID와 1대1로 맵핑 가능한 ID

Source Port: 송신원 애플리케이션의 포트 번호

Destination Port: 송신처 애플리케이션의 포트 번호

User Data: 전송 데이터 본체

User Data Size: 전송 데이터 사이즈

1.4.3 관리 서비스 인터페이스

도 8에 관리 서비스 인터페이스의 논리 관계를 나타낸다. 로컬 포트 제어 프로토콜은 관리 서비스로서, 애플리케이션(또는, 상위층 프로토콜)에 대하여, 이하의 3종류의 프리미티브를 준비한다.

ㆍEvent Report(이벤트 통지 프리미티브)

ㆍOpen Port(포트 생성 프리미티브)

ㆍClose Port(포트 파기 프리미티브)

1.4.3.1 이벤트 통지 프리미티브(Event Report)

본 프리미티브는 비IP 애플리케이션이나 상위층 프로토콜에 대하여 이벤트의 발생이나 에러를 보고하기 위한 프리미티브이다. ASL-ELCP의 관리 서비스에서 통 지된 이벤트를 로컬 포트 프로토콜에 대하여 투과적으로 전송하는 것과, 상대국의 관리 서비스로부터의 통지를 투과적으로 전송하는 것의 2종류가 있다. 도 9에 이벤트 통지 프리미티브의 정의를 나타낸다. 도 9에서,

Link Address: 통지 상대가 사용하는(동안의) LID를 지정한다.

Event Code: 이벤트 코드로서 상태 식별자(도 17)를 저장한다.

Extention Parameter: 각 이벤트 코드에 대응하는 이벤트 부가 정보.

1.4.3.2 포트 생성 프리미티브(Open Port)

본 프리미티브는 LPCP에 대하여 데이터 및 이벤트의 수신 포트를 생성하기 위한 프리미티브이다. 도 10에 포트 생성 프리미티브의 정의를 나타낸다. 도 10에서,

Port: 통지를 요구하는 포트 번호

Type: 통지가 필요한 프리미티브 종별의 지정

1: Transfer Data

2: Event Report

이 파라미터가 생략된 경우는, 모든 프리미티브 통지를 요구한다.

Code: Type=2(Event Report)의 경우에 통지가 필요한 이벤트의 종별

이 파라미터가 생략된 경우는 모든 이벤트의 통지를 요구한다.

이벤트 종별의 상세한 것은 도 17을 참조.

1.4.3.3 포트 파기 프리미티브(Close Port)

본 프리미티브는 포트 생성 프리미티브로 생성한 수신 포트를 파기하기 위한 프리미티브이다.

도 11은 포트 파기 프리미티브의 정의를 나타내는 도면이다. 도 11에서,

Port: 파기하는 포트 번호

1.5 제어 정보

1.5.1 개요

다음에, 상기 관리 서비스에서 이용하는 LPCP의 제어 정보에 대해서 설명한다.

LPCP의 관리 서비스에서는, LPCP에서 사용하는 통신 파라미터를 관리한다.

LPCP의 관리 서비스에서는 이하의 정보를 관리한다.

(1) 수신 가능 포트 리스트

(2) 통신 제어 정보

1.5.2.1 수신 가능 포트 리스트

기지국/이동국이 수신 가능한 포트 번호의 정보에서, 수신 포트 생성 프리미티브 수신시에 리스트에 추가하고, 수신 포트 파기 프리미티브 수신시에 리스트로부터 삭제한다.

수신 가능 포트 리스트의 구성예를 도 12에 나타낸다.

1.5.2.2 통신 제어 정보

기지국/이동국에서 통신중인 애플리케이션에 관한 정보에서, ASL-ELCP의 통신 제어 관리로부터의 DSRC 접속 통지의 수신시에 리스트에 추가하고, DSRC 절단 통지의 수신시에 리스트로부터 삭제한다. 통신 제어 정보의 구성예를 도 13에 나타낸다.

약어 해설:

LID: 링크 어드레스

Port No: 수신 가능 포트 번호

Primitive Type: 수신하는 프리미티브 종별

Event Code: 수신하는 이벤트 코드의 종별

Equipment ID: 차량 탑재기 고유 정보

1.6 프로토콜 데이터 유닛(PDU)

다음에, 데이터그램 전송 서비스 및 관리 서비스에서 이용되는 LPCP의 프로토콜 데이터 유닛(PDU)에 대해서 설명한다.

LPCP의 PDU는 로컬 포트 제어 프로토콜 헤더와 애플리케이션 데이터부로 구성된다.

1.6.1 데이터그램 전송 서비스의 프로토콜 데이터 유닛

도 14에 데이터그램 전송 서비스에서 이용되는 LPCP의 PDU의 형식을 나타낸 다.

액세스점 식별자: 네트워크 제어 프로토콜을 식별하기 위한 식별자. 항상 local Port Control(1)를 저장한다.

프로토콜 식별자: PDU 종별을 나타낸다. 데이터그램 전송 서비스에서는, message(0)를 저장한다. 상세한 것은 도 15를 참조.

송신원 포트 번호: 송신원 애플리케이션의 포트 번호

송신처 포트 번호: 송신처 애플리케이션의 포트 번호

사용자 데이터부의 길이: 후속하는 사용자 데이터부의 데이터 길이를 지시한다. 단위는 옥텟. 또한, 이 에어리어의 사이즈는 ASN.1 부호화 규칙에 따라 확장한다. 부가하는 사용자 데이터가 없는(NULL의) 경우, 이 영역에 0이 지정된다. 또한, LPCP가 ASL-ELCP에 넘겨 줄 수 있는 데이터의 최대 길이, LPCP의 MTU(Maximum Transmission Unit)는 522옥텟(액세스 제어 정보를 포함함)으로 한다.

사용자 데이터부의 내용: 전송 데이터 본체. OCTET STRING형의 부정 길이(undefined-length) 데이터를 저장한다.

도 15는 LPCP의 프로토콜 식별자를 나타내는 도면이다.

1.6.2 관리 서비스의 프로토콜 데이터 유닛

도 16에 관리 서비스에서 이용되는 LPCP의 PDU의 형식을 나타낸다. 이하에 나타내는 PDU는 상대국의 LPCP로 이벤트 통지를 실행하는 경우에 이용되는 것이다.

도 16은 이벤트 통지의 메시지 형식을 나타내는 도면이다.

프로토콜 식별자: PDU 종별을 나타낸다. 관리 서비스에서는, 항상 event Report(1)를 저장한다.

이벤트 코드: 발생한 이벤트 내용을 지시하는 식별자. 0~127은 통신 제어 프로토콜의 상태 식별자이고, 128~255가 LPCP의 상태 식별자이다. 도 17은 이벤트 코드(event Code)의 내용을 나타내는 도면이다.

이벤트 부가 정보의 길이: 후속하는 이벤트 부가 정보의 데이터 길이를 지시한다. 단위는 옥텟. 또한, 이 에어리어의 사이즈는 ASN.1 부호화 규칙에 따라 확장한다. 부가하는 이벤트 정보가 없는(NULL의) 경우, 이 영역에 0이 지정된다.

이벤트 부가 정보의 내용: 이벤트 부가 정보의 내용. OCTET STRING형의 부정 길이 데이터를 저장한다.

1.7 처리 순서

LPCP에서의 처리 순서에 대해서 설명한다.

1.7.1 초기 접속 순서

(a) 애플리케이션이 LPCP에 대하여, 포트 생성 프리미티브에 의해, DSRC 접속 통지의 요구를 미리 실행해 놓는다.

(b) 차량의 DSRC 영역으로의 진입에 의해, ASL-ELCP의 관리 서비스 이벤트 통지 프리미티브(Event Information.ind)로 상태 「통신 접속의 통지」를 수령한다.

(c) 포트 생성 프리미티브로 DSRC 접속 통지를 요구되고 있는 포트에 대하여, 이벤트 통지 프리미티브(Event Report.ind)로 이벤트 코드 「DSRC 접속 통지(96)」를 통지한다.

도 18에 DSRC 접속시의 처리 순차예를 나타낸다.

1.7.2 통신 종료 순서

(a) 애플리케이션이 LPCP에 대하여, 포트 생성 프리미티브에 의해, DSRC 절단 통지의 요구를 미리 실행해 놓는다.

(b) ASL-ELCP의 관리 서비스 이벤트 통지 프리미티브(Event Information.ind)로 상태 「통신 절단의 통지」를 수령한다.

(c) LPP의 접속 관리 서비스에 대하여, 이벤트 통지 프리미티브(Event Report.ind)로 이벤트 코드 「DSRC 절단 통지」를 통지한다.

도 19에 통신 종료시의 처리 순차예를 나타낸다.

1.7.3 메시지 전송 순서

(1) 송신 처리

(a) 데이터 전송 요구 프리미티브(Transfer Data.req)가 발행된다.

(b) 통신 제어 정보를 참조하여, 지정된 Link Adress가 프라이빗 링크 어드 레스이며, 또한 그 링크 어드레스로 DSRC가 접속되어 있지 않은 경우는, 데이터 전송 요구 프리미티브로 지정되어 있었던 송신원 포트 번호에 대하여, 상태 식별자가 「DSRC가 접속되어 있지 않음(128)」인 이벤트 통지 프리미티브를 발행하여, 송신 처리를 완료한다. 단, 이 순서는 로컬 포트 생성 프리미티브에 의해, 이벤트 통지의 요구가 행해지고 있었던 경우로 하고, 이벤트 통지의 요구가 행해지고 있지 않은 경우에는, 상위 프로토콜에 대한 이벤트 통지는 실행하지 않는다. 이벤트 통지의 유무는 수신 가능 로컬 포트 리스트에 의해 판별한다.

(c) DSRC가 접속하고 있는 경우는, 액세스점 식별자가 local Port Protocol(1), 프로토콜 식별자가 message(0)인 패킷을 생성하고, ASL-ELCP의 데이터 전송 프리미티브(Send Unit Data.req)로 송신하여, 송신 처리를 완료한다.

(d) 송신 처리 완료 후, 데이터 전송 메시지를 송신한 상대국으로부터 이벤트 통지 메시지를 수령한 경우에는, 그 메시지로 전달된 이벤트 코드를 확인하여, 이벤트 코드의 내용이 「송신처 로컬 포트가 유효하지 않음」인 경우, 그 메시지의 이벤트 부가 정보에 지정되어 있는 송신원 로컬 포트 번호에 대하여, 이벤트 통지 프리미티브(Event Report.ind)에 의해 「송신처 로컬 포트가 유효하지 않음」을 통지한다. 단, 이 순서는 로컬 포트 생성 프리미티브에 의해, 이벤트 통지의 요구가 행해지고 있었던 경우로 하고, 이벤트 통지의 요구가 행해지고 있지 않은 경우에는, 상위 프로토콜에 대한 이벤트 통지는 실행하지 않는다. 이벤트 통지의 유무는 수신 가능 로컬 포트 리스트에 의해 판별한다.

(2) 수신 처리

(a) 애플리케이션이 LPCP에 대하여, 포트 생성 프리미티브에 의해, 전송 통지의 요구를 하여, 수신 포트를 오픈한다.

(b) ASL-ELCP로부터 데이터 전송 통지 프리미티브(Send Unit Data.ind)로, 프로토콜 식별자가 message(O)인 패킷을 수신하면, 그 패킷으로부터, 프로토콜 식별자, 송신처 로컬 포트 번호, 송신원 로컬 포트 번호, 사용자 데이터를 출력한다.

(c) 수신 가능 포트 리스트를 참조하여, (b)에서 수신한 송신처 포트 번호가 유효한 경우는, 송신처 포트 번호로 지정된 상위 엔티티에 대하여, 데이터 전송 프리미티브(Transfer Data.ind)로 상대국으로부터의 데이터의 수신을 통지하고, 수신 처리를 완료한다.

(d) 링크 어드레스가 프라이빗 어드레스이며, 또한 (b)에서 수신한 송신처 포트 번호가 유효하지 않은 경우는, 프로토콜 식별자가 event Report(1), 상태 식별자가 「송신처 포트가 유효하지 않음(129)」인 패킷을 작성하여, ASL-ELCP의 데이터 전송 프리미티브로 상대국에 송신하고, 수신 처리를 완료한다. 즉, 상대국으로부터의 메시지 수신시에 자국에 송신처 애플리케이션이 존재하지 않는 경우는, 그 취지를 상대국에 대하여 바로 통지한다. 또한, 링크 어드레스가 그룹 동보 어드레스이며, 또한 (b)에서 수신한 송신처 포트 번호가 유효하지 않은 경우는, 수신 데이터를 파기하고, 수신 처리를 완료한다.

도 20에 메시지 전송의 기본 처리 순차예를, 도 21에 DSRC가 접속되어 있지 않은 경우의 처리 순차예를, 도 22에 송신처 로컬 포트 번호가 유효하지 않은 경우 의 처리 순차예를 나타낸다.

2. 트랜잭션 관리부(로컬 포트 프로토콜)

이하에, 트랜잭션 관리부(로컬 포트 프로토콜)에 대해서 상세하게 설명한다.

2.1 개요

로컬 포트 프로토콜(LPP: Local Port Protocol)은 로컬 포트 제어 프로토콜(LPCP)과 비네트워크계 애플리케이션 사이에 개재하여, 로컬 포트 제어 프로토콜의 기능을 확장하고, DSRC 차량 탑재기/노측기(路側機)상의 비네트워크계 애플리케이션에 대하여, 이하의 트랜잭션 서비스와 접속 관리 서비스를 제공함으로써, 애플리케이션 구축의 효율화를 도모하는 것을 목적으로 한 트랜잭션 지향의 프로토콜이다(도 23 참조). 본 프로토콜은 로컬 포트 제어 프로토콜의 통신 기능을 확장하는 트랜잭션 서비스 처리부와, 초기 접속이나 절단 등의 통신 상황을 관리하는 접속 관리 서비스 처리부로 구성되어 있다. 각 서비스 처리부가 갖는 기능은 이하와 같다.

트랜잭션 서비스 처리부

ㆍ트랜잭션 단위의 데이터 교환 기능

ㆍ단방향 데이터 송신 트랜잭션 서비스

ㆍ요청ㆍ응답형 트랜잭션 서비스

ㆍ데이터 재송 기능

ㆍ메시지의 분할ㆍ조립 기능

ㆍ트랜잭션의 파기 기능

접속 관리 서비스 처리부

ㆍDSRC 접속 문의 서비스

ㆍDSRC 절단 통지 서비스

ㆍ수신 가능 포트 문의 서비스

또한, 트랜잭션 관리부는 애플리케이션에 대하여 상기 기능을 이용하기 위한 서비스 프리미티브(애플리케이션과의 인터페이스)를 제공한다. 또한, 상기 기능을 실현하기 위해서, 노차의 트랜잭션 관리부간에서 수수되는 데이터(PDU)의 구조를 규정하고 있다. 트랜잭션 관리부에서는, 송신측이 서비스 프리미티브로 요구된 기능(또는, 트랜잭션 관리부 내부에서 발생한 이벤트)에 따른 제어 정보를 부가하고, 또한, 수신측에서는 PDU에 부가된 제어 정보를 해석, 이용함으로써 상기 기능을 실현한다.

2.2 LPP의 기능

다음에 상술한 LPP에서의 각 서비스 처리부의 기능에 대해서 각각 상세하게 설명한다.

2.2.1 트랜잭션 서비스 처리

2.2.1.1 트랜잭션 단위의 데이터 교환 기능

로컬 포트 프로토콜에서는, 트랜잭션 단위로 애플리케이션 데이터를 교환한다.

트랜잭션 ID에 의해, 각각의 트랜잭션을 구별한다(도 24 참조). 이에 따라, 동일 애플리케이션간에서 복수 트랜잭션이 동시에 존재하는 상황에 대한 대응도 가능하게 된다.

도 24는 LPP에서의 트랜잭션간 데이터 교환예를 나타내는 도면이다.

또한, 트랜잭션 ID의 번호 부여 방식은 이하와 같이 한다.

(1) 16 비트 구성

(2) 선두 비트는 트랜잭션의 개시예를 나타낸다(차량 탑재측이 0, 노측이 1).

(3) 트랜잭션의 발행(Invoke.req)마다 1인크리먼트된다.

2.2.1.2 2종류의 트랜잭션 서비스 제공 기능

본 프로토콜은 이하의 2종류의 트랜잭션 서비스를 제공한다.

ㆍ단방향 데이터 송신 트랜잭션 서비스

ㆍ요청ㆍ응답형 트랜잭션 서비스

이들 각 트랜잭션 서비스는 애플리케이션 각각의 통신 요건에 따라서 필요한 레벨인 것이 이용되어, 애플리케이션마다 최적의 통신 서비스를 이용할 수 있다.

2.2.1.2.1 기본 트랜잭션

(1) 데이터 송신 서비스

노차 쌍방의 비네트워크계 애플리케이션에 대하여, 데이터 송신 서비스를 제공한다(도 25 참조). 도 25는 데이터 송신 서비스의 예를 나타내는 도면이다.

(2) 요청ㆍ응답형 트랜잭션 서비스

메시지를 상대에 대하여 통지하고, 또한, 그 메시지에 대한 반환값을 취득한다. 리모트 스테이션에 대한 메소드 호출 등의 용도에 이용한다(도 26 참조).

도 26은 요청ㆍ응답형 트랜잭션 서비스의 예를 나타내는 도면이다.

2.2.1.2.2 데이터 재송 기능

본 기능은 통신의 신뢰성을 확보하기 위한 기능으로서, 재송 타이머와 재송 카운터에 의해 재송의 제어를 실행한다. 재송 타이머의 타임아웃시에 재송을 실행함으로써(최대 재송 횟수 이하), 통신의 신뢰성을 확보한다(도 27 참조). 데이터의 송신이나 회신에 적용이 가능하고, 적용할지 여부는 애플리케이션이 지정한다. 처리 순차를 이하에 나타낸다.

도 27은 데이터 재송의 예를 나타내는 도면이다.

ㆍ패킷 송신시에, 재송 타이머를 시작시키고, 재송 카운터를 0으로 세트한다.

ㆍ재송 타이머의 타임아웃 전에 응답 데이터를 수신할 수 없었던 경우에는 재송 카운터를 인크리먼트하여, 패킷을 재송한다.

ㆍ재송 카운터가 최대 재송 횟수를 초과한 경우에는, 트랜잭션을 종료하고, 그 취지를 애플리케이션에 통지한다.

또한, 데이터 재송 기능을 사용하는 트랜잭션에 있어서는, 송달 확인의 미도달 등의 이유에 의해, 이전에 수신한 PDU를 재차 수신할 가능성이 있다. 이 중복 수신은 트랜잭션 ID을 이용하여 검지한다(도 28 참조). 구체적인 체크 방법에 관해서는, 실장 요건으로 하고, 여기서는 특별히 규정하지 않는다.

도 28은 중복 수신 체크의 예를 나타내는 도면이다.

2.2.1.2.3 메시지 분할ㆍ조립 기능

본 기능은 메시지의 분할ㆍ조립 처리를 실행함으로써, 애플리케이션에 대하여, LPCP의 MTU를 초과하는 메시지의 송신 인터페이스의 제공을 가능하게 하는 기능이다.

도 29는 분할ㆍ조립 기능을 이용한 메시지 통신의 순서를 나타낸 것이다. LPP는 애플리케이션으로부터 LPCP의 MTU를 초과하는 메시지를 수취한 경우에는, LPP내에서 PDU를 LPCP의 MTU 사이즈로 분할하여, 순차적으로 LPCP에게 넘겨주도록 조작한다. 이에 따라 분할된 패킷은 DSRC-ASL의 송신 큐에 쌓아 올려져, 순차적으로 레이어 7에 전송된다. 이 때, DSRC-ASL의 송신 큐가 오버플로우하는 것이 상정되기 때문에, LPP에서는 송신을 실패한 패킷의 재송이나, 흐름 제어를 실행함으로써, 모든 패킷이 송신되는 것을 보증한다.

수신측은 LPCP로부터 받은 분할된 패킷을 순차적으로 취입하여, 수신측의 애 플리케이션이 준비한 수신 큐로 쌓아 올린다. 이 때, 레이어 2의 재송 처리 등의 요인에 의해, 수신 큐에는 송신 순서대로 각 패킷이 저장되는 보증은 없어, 수신측은 각 패킷에 번호 부여된 순차 번호로 조립 순서를 판별하여 PDU로 조립한다. 수신측에서는, 모든 패킷을 수신 후, 송신측에 대하여 도달 확인을 보낸다.

또한, DSRC-ASL에서의 수신 큐 오버플로우나 DSRC에서의 데이터의 누락 등에 의해 패킷의 누락이 발생하는 것이 상정되어, 송신된 모든 패킷이 상대국의 LPP까지 도달되는 보증은 없다. 이 경우, 하나의 패킷 누락이 메시지 전체의 데이터 누락으로 되어 버리기 때문에, 최종 패킷 수신시에 수신되어 있지 않은 패킷을 부정 응답에 의해 통지하고, 누락된 패킷의 재송을 실행하는(선택적 재송 처리) 것에 의해, 메시지 전체의 도착을 보증한다. 또한, 최종 패킷의 누락에 대해서는, 통상의 재송 처리에 의해 도달을 보증한다. 또한, 선택적 재송에 의해서 송신하는 패킷 그룹에 대해서도 마찬가지의 제어를 실행한다. 도 30에 선택적 재송 처리의 예를 나타낸다.

또한, 애플리케이션마다 필요하게 되는 수신 큐의 사이즈가 크게 상이한 것이 예상되므로, 본 기능에서는 수신 큐를 애플리케이션이 준비한다. 그 때문에, 분할ㆍ조립이 필요한 트랜잭션은 송신처(링크 어드레스와 송신처 포트 번호로 식별)마다, 동시에는 하나밖에 발행할 수 없는 것으로 한다.

또한, 동보 어드레스에 대한 데이터 송신의 경우에는, 도달 확인의 회신, 선택적 재송 처리나 최종 세그먼트의 재송 제어를 실행하지 않고, 트랜잭션의 재실행 요구에 의해, 필요로 되는 통신의 신뢰성을 확보한다. 도 32에 트랜잭션의 재실행 처리의 예를 나타낸다.

2.2.1.3 트랜잭션의 폐기 기능

요청ㆍ응답형의 트랜잭션에서는, 애플리케이션으로부터의 요구에 의해, 트랜잭션의 파기를 요구할 수 있다(도 33 참조). 요구시의 트랜잭션의 상태에 따라서, 이하의 처리가 실시된다.

ㆍ메시지가 송신되어 있지 않은 경우는, 그 메시지를 파기한다.

ㆍ메시지를 송신 완료 또는 송신중인 경우는, 그 트랜잭션에 관련되는 모든 데이터를 파기하고, 상대측에 대하여 그 트랜잭션이 파기된 것을 통지한다.

ㆍ상대측에서의 트랜잭션 파기 요구에 의해, 트랜잭션의 파기 요구를 수신한 경우는, 애플리케이션에 대하여, 트랜잭션 파기를 통지하고, 또한, 그 트랜잭션에 관련되는 모든 데이터를 파기한다.

도 33은 트랜잭션 파기 통지의 예를 나타내는 도면이다.

또한,

ㆍDSRC 통신로가 절단되어 있다.

ㆍ도착지 포트가 수신 가능 포트가 아니다.

라고 한 경우는, 불필요한 통신을 억제하기 위해서, 트랜잭션을 개시하지 않고, 요구가 실패한 것을 애플리케이션에 통지한다.

2.2.2 접속 관리 서비스 처리

접속 관리 서비스에서는, 이하의 서비스를 애플리케이션에 대하여 제공함으로써, 애플리케이션에 통신 개시ㆍ종료의 트리거를 제공한다.

ㆍDSRC의 접속 상황을 관리, 감시하고, 애플리케이션으로부터의 요구에 따라서 접속 상황의 보고나 신규 접속, 절단을 통지하는 서비스.

ㆍ노차간의 접속 관리 서비스간에서 수신 가능 포트 번호를 통지함으로써, 상대국이 갖는 수신 가능 포트 번호를 관리하고, 애플리케이션으로부터의 요구에 따라서 그들의 상황을 보고하거나, 어떤 포트가 수신 가능하게 된 것을 통지하는 서비스.

또한, 접속 관리 서비스는 로컬 포트 제어 프로토콜상의 애플리케이션과 마찬가지의 위치를 부여하고, 노차의 접속 관리 서비스간에서의 이벤트의 송수신은 로컬 포트 제어 프로토콜의 데이터 전송 서비스를 이용한다. 접속 관리 서비스가 이용하는 포트 번호는, 당면, 0x0FFF로 한다.

2.2.2.1 DSRC 접속 문의 서비스

DSRC가 접속하고 있는지 여부를 문의하는 기능.

문의시에 DSRC의 접속 상황을 바로 회답하는 참조 서비스와, 접속하고 있지 않은 경우에, 접속할 때까지 대기하여, 접속한 시점에서 통지를 하는 통지 서비스의 2종류의 서비스를 규정한다.

2.2.2.2 DSRC 절단 통지 서비스

절단 통지를 요구하는 애플리케이션에 대하여, DSRC의 절단을 통지하는 기능.

2.2.2.3 수신 가능 포트 문의 서비스

상대국에 소정의 수신 포트가 존재하고 있는지 여부를 문의하는 기능. 포트의 상태에는 이하의 3종류가 있다.

ㆍ수신 가능 포트: 상대국이 이 포트를 데이터 수신 포트로서 오픈하고 있는 포트.

ㆍ수신 불가 포트: 상대국이 이 포트를 데이터 수신 포트로서 오픈하고 있지 않은 포트.

ㆍ불명 포트: 상대국이 이 포트를 데이터 수신 포트로서 오픈하고 있는지 여부를 알 수 없는 포트. 초기 상태가 이 상태.

또한, 수신 가능 포트 문의 서비스에는, 문의시에 그 포트가 어떤 상태인가를 바로 회답하는 참조 서비스와, 문의한 포트가 수신 가능 포트로 될 때까지 대기하여, 상대국으로부터의 수신 가능 포트 통지를 수취한 시점에서 통지를 하는 통지 서비스(이미 문의한 포트가 수신 가능 포트인 것이 판명하고 있는 경우는 바로 회답함)의 2종류의 서비스를 규정한다.

상기 서비스를 가능하게 하기 위해서, 노차간의 로컬 포트 프로토콜의 관리 서비스는 DSRC 통신 접속시나 수신 가능 포트 변경시에 상대국에 대하여, 자국이 수신 가능한 포트 번호나 수신 불가로 된 포트 번호를 통지하는 기능을 갖는다.

2.3 애플리케이션과의 인터페이스

다음에, LPP와 애플리케이션의 인터페이스에 대해서 설명한다.

2.3.1 기법의 설명

본 발명에서 규정되는 프리미티브 종별의 일람을 도 34에 나타낸다.

또한, 본 발명에서의 프리미티브의 정의 테이블에서 이용되는 파라미터 종별의 일람을 도 35에 나타낸다.

2.3.2 트랜잭션 서비스 프리미티브

트랜잭션 서비스로서, LPP는 애플리케이션에 대하여, 이하의 2종류의 프리미티브를 준비한다.

ㆍInvoke: (트랜잭션 개시 프리미티브)

ㆍAbort: (트랜잭션 파기 프리미티브)

2.3.2.1 Invoke(트랜잭션 개시 프리미티브)

처리 개요:

Invoke 프리미티브는 새로운 트랜잭션을 생성하기 위한 프리미티브이다. 모든 트랜잭션은 이 프리미티브의 발행에 의해 개시된다.

정의:

도 36은 Invoke 프리미티브의 인수를 나타내는 도면이다.

Link Address: DSRC의 LID 또는 LID와 1대1로 맵핑 가능한 ID

Source Port: 송신원 애플리케이션의 포트 번호

Destination Port: 송신처 애플리케이션의 포트 번호

User Data Size: 송신 데이터 사이즈(옥텟 단위)

User Data: 송신 데이터 본체

Transaction Type: 트랜잭션 서비스의 타입

0: 데이터 송신 트랜잭션 서비스

1: 요청ㆍ응답형 트랜잭션 서비스

Require Ack: 재송 처리를 유효로 할지 여부의 플래그(0: 재송 처리 불필요, 1: 재송 처리 필요)

Result Timeout: 요청ㆍ응답형 트랜잭션 서비스에서 Result PDU 수신까지의 타임아웃 시간. Invoke.req 발행 후, 이 시간까지 Result PDU를 수신하지 않으면, 이 트랜잭션은 파기된다.

Handle: 로컬에서 트랜잭션을 구별하기 위한 ID. 애플리케이션으로부터 지정된다. 여기서 지정되는 Handle는 이하의 조건을 만족할 필요가 있다. Invoke.req의 발행측에서는, 트랜잭션 ID에 의해, Handle와 Source Port를 유일하게 특정할 수 있어야 한다. Invoke.res의 발행측에서는, Handle에 의해 Link Address, Source Port, 트랜잭션 ID를 유일하게 특정할 수 있어야 한다. 또한, 동 보 통신에 있어서, 직전의 실행 완료된 동보 통신과 동일한 Handle이 지정된 경우에는, 트랜잭션의 재실행 요구로서 취급된다.

2.3.2.2 Abort(트랜잭션 파기 프리미티브)

처리 개요:

Abort 프리미티브는 생성되어 있는 트랜잭션을 파기하기 위한 프리미티브이다.

정의:

도 37은 Abort 프리미티브의 인수를 나타내는 도면이다.

Abort Type: 파기 이유가 시스템 에러(0)인지, 사용자 요구(1)인지를 나타낸다.

Abort Code: 트랜잭션이 파기된 이유를 나타낸다(시스템 에러의 상세는 도 38을 참조).

Handle: 로컬에서 트랜잭션을 구별하기 위한 ID.

도 38은 Abort Type=0의 경우(시스템 에러)의 Abort Code 일람을 나타내는 도면이다.

2.3.3 접속 관리 서비스

접속 관리 서비스로서, LPP는 애플리케이션에 대하여, 이하의 4종류의 프리미티브를 준비한다.

ㆍConnect: (트랜잭션 개시 가능 문의/통지 프리미티브)

ㆍDisconnect: (DSRC 절단 통지 프리미티브)

ㆍRegister Port(포트 등록 프리미티브)

ㆍDeregister Port(포트 등록 삭제 프리미티브)

2.3.3.1 Connect(트랜잭션 개시 가능 문의/통지 프리미티브)

처리 개요:

Connect.req 프리미티브는 트랜잭션이 개시 가능한지 여부를 문의하기 위한 프리미티브이다. Connect.cnf 프리미티브는 Connect.req에 의한 문의에 대하여, DSRC의 접속과 LID 및 (그 LID가 지시하는) 상대국이 갖는 수신 가능 포트 번호를 문의원(query-source)의 애플리케이션에 통지하기 위한 프리미티브이다.

정의:

도 39는 Connect 프리미티브의 인수를 나타내는 도면이다.

Querist Port: 문의원의 Port 번호로, 문의를 한 애플리케이션을 특정하기 위해서 사용한다.

Query LID: 문의를 하는 LID. LID 지정시는, 기접속 완료된 링크에 대한 문의로서 취급한다. 한편, 지정이 없는 경우는, 신규 접속 대기로서 취급한다. Query Port와 함께 생략되었을 때는 DSRC 접속 후 즉시 Connect.cnf가 발행된다(고속 접속). 한편, Query Port가 지정된 경우는, 수신 가능 포트 통지 수신 후에 Connect.cnf가 발행된다(통상 접속).

Query Port: 문의를 하는 도착지 포트 번호.

Time Out: DSRC 미접속시에 Connect.cnf를 발행할 때까지의 대기 시간. 대기중에 접속된 경우는, 바로 Connect.cnf를 발행한다. 이 파라미터를 생략할 때는 타임아웃 시간=∞로서 취급한다.

Connected LID: Query LID가 지정되고, 또한 그 LID가 접속중인 경우는, Query LID와 동일한 LID가 지정된다. Query LID가 지정되고 또한 LID가 미접속의 경우, 및 Query LID가 미지정에서, Time Out 파라미터로 지정되는 시간내에 신규 접속이 없는 경우는 -1이 지정된다.

Accept Port: Connected LID로 표시되는 상대국이 갖는 수신 가능 포트 번호. Query Port로써 지정이 있었던 경우는, 그 포트 번호만을 통지한다. 또한, 지정된 Port 번호가 수신 거부 포트 번호의 경우는, -1이 지정된다. 또한, Query Port가 생략되어 있는 경우는, 0이 지정된다.

2.3.3.2 Disconnect(DSRC 절단 통지 프리미티브)

처리 개요:

DSRC의 절단을 애플리케이션에 통지하기 위한 프리미티브이다.

정의:

도 40은 Disconnect 프리미티브의 인수를 나타내는 도면이다.

2.3.3.3 Register Port(포트 등록 프리미티브)

처리 개요:

Register Port 프리미티브는 LPP에 대하여 수신 포트를 등록하기 위한 프리미티브이다.

정의:

도 41은 Register Port 프리미티브의 인수를 나타내는 도면이다.

Port No: 수신 포트 번호

Bulk Area: 분할된 메시지를 조립하는 에어리어

Bulk Area Size: Bulk Area의 사이즈

2.3.3.4 Deregister Port(포트 등록 삭제 프리미티브)

처리 개요:

Deregister Port 프리미티브는 LPP에 대하여 수신 포트를 삭제하기 위한 프리미티브이다.

정의:

도 42는 Deregister Port 프리미티브의 인수를 나타내는 도면이다.

Port No: 등록을 삭제하는 수신 포트 번호

2.4 프로토콜 데이터 유닛(PDU)

다음에, 트랜잭션 서비스 및 접속 관리 서비스에서 이용되는 LPP의 프로토콜 데이터 유닛(PDU)에 대해서 설명한다.

2.4.1 트랜잭션 서비스의 프로토콜 데이터 유닛

트랜잭션 서비스에서 이용되는, 프로토콜 데이터 유닛은 그 이용 장면에 따라서 도 43에 나타내는 7종류가 존재한다. 트랜잭션 서비스에서 이용되는 PDU는 PDU 종별마다 정의되는 헤더부와 애플리케이션 데이터가 저장되는 데이터부로 구성된다. PDU의 기본 구조를 도 44에 나타낸다.

2.4.1.1 Invoke PDU

도 45는 Invoke PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Invoke PDU에서는 항상 Invoke(1).

Version: 로컬 포트 프로토콜의 버전을 나타낸다. 현 버전은 0x00.

TT: Transaction Type의 약자. 트랜잭션의 타입을 지정한다. 0: 데이터 송신 트랜잭션 서비스, 1: 요청ㆍ응답형 트랜잭션 서비스.

RA: Require Ack의 약자. 재송 처리가 유효한지 여부를 나타내는 플래그. 재송 처리 유효시는 1.

RD: Retransmitted Data의 약자. 재송된 데이터인지 여부를 나타내는 플래그. 재송시는 1.

TID: 트랜잭션 ID.

RES: 예약.

2.4.1.2 Result PDU

도 46은 Result PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Result PDU에서는 항상 Result(2).

RD: 재송된 데이터인지 여부를 나타내는 플래그. 재송시는 1.

TID: 트랜잭션 ID.

RES: 예약.

2.4.1.3 Acknowledgement PDU

도 47은 Acknowledgement PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Acknowledgement PDU에서는 항상 Ack(3).

RD: 재송된 데이터인지 여부를 나타내는 플래그. 재송시는 1.

TID: 트랜잭션 ID.

RES: 예약.

2.4.1.4 Abort PDU

도 48은 Abort PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Abort PDU에서는 항상 Abort(4).

AT: 파기 이유가 시스템 에러(0), 사용자 요구(1)의 어느 쪽에 의한 것인지 를 나타내는 플래그.

TID: 트랜잭션 ID.

Abort Code: 트랜잭션의 파기 이유를 코드로서 지정(도 38을 참조).

RES: 예약.

2.4.1.5 Invoke Segment PDU

도 49는 Invoke Segment PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Invoke Segment PDU에서는 항상 Invoke Sgm(5).

FIN: 최종 세그먼트인지 여부를 나타내는 플래그. 최종 세그먼트에서는 1.

TID: 트랜잭션 ID.

Segment No: PDU의 순서 번호.

2.4.1.6 Result Segment PDU

도 50은 Result Segment PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Result Segment PDU에서는 항상 Result Sgm(6).

RD: 재송된 데이터인지 여부를 나타내는 플래그. 재송시는 1.

TID: 트랜잭션 ID.

RES: 예약.

Segment No: PDU의 순서 번호.

2.4.1.7 Nack PDU

도 51은 Nack PDU의 헤더 정보를 나타내는 도면이다.

PDU Type: PDU의 타입. Nack PDU에서는 항상 Nack(7).

RD: 재송된 데이터인지 여부를 나타내는 플래그. 재송시는 1.

TID: 트랜잭션 ID.

RES: 예약.

Num Seg: 미수신 PDU의 순서 번호의 수

Segment Number List: 미수신 PDU의 순서 번호의 리스트

2.4.2 접속 관리 서비스의 프로토콜 데이터 유닛

로컬 포트 프로토콜의 접속 관리 서비스는 DSRC의 신규 접속시나, 수신 가능 포트가 증감한 경우에, 상대국의 접속 관리 서비스에 대하여, 로컬 포트 제어 프로토콜의 전송 서비스를 이용하여, 수신 가능 포트 리스트나 수신 불가 포트를 통지한다. 이하에 나타내는 PDU는 이들 통지에서 이용되는 프로토콜 데이터 유닛으로 서, 로컬 포트 제어 프로토콜의 사용자 데이터부에 저장된다.

2.4.2.1 수신 가능 포트 리스트 통지에 있어서의 프로토콜 데이터 유닛

도 52는 수신 가능 포트 리스트 통지에 있어서의 프로토콜 데이터 유닛을 나타내는 도면이다.

Status: 이벤트의 종별을 나타낸다. 수신 가능 포트 리스트 통지의 경우는, accept Port List(1)를 항상 저장한다.

Num Ports: 수신 가능 포트 번호의 수를 저장한다.

Accept Port List: 수신 가능 포트 번호의 리스트를 저장한다.

2.4.2.2 수신 불가 포트 통지에 있어서의 프로토콜 데이터 유닛

도 53은 송신 불가 포트 통지에 있어서의 프로토콜 데이터 유닛을 나타내는 도면이다.

Status: 이벤트의 종별을 나타낸다. 수신 불가 포트 통지의 경우는, reject Port(2)를 항상 저장한다.

Reject Port: 수신 불가 포트 번호를 저장한다.

2.5 처리 순서

LPP에서의 처리 순서에 대해서 설명한다.

2.5.1 초기 접속 순서

(1) 통상 애플리케이션의 초기 접속 순서

도 54는 로컬 포트 프로토콜의 초기 접속 순서를 나타내는 도면이다.

(a) 이동국 및 기지국의 각 애플리케이션은 수신 가능한 포트 번호를 포트 등록 프리미티브(Register Port)를 이용하여, LPP에 등록한다.

(b) LPP는 접속 관리 테이블을 갱신하여, 상기 (a)에서 등록된 수신 가능 포트 번호 및 접속 관리 서비스 포트를 데이터 수신 포트로서 LPCP에 등록한다. 또한, 관리 서비스 포트는 이벤트 수신 포트로서도 LPCP에 등록한다.

(c) 각 애플리케이션은 Query LID 파라미터를 미지정, Query Port 파라미터를 지정하고, DSRC 접속 문의 프리미티브(Connect.req)를 발행하여, DSRC 접속을 대기한다(블록킹 호출).

(d) LPP의 접속 관리 서비스는 LPCP로부터 이벤트 통지 프리미티브(Event Report)로 이벤트 「DSRC 접속 통지(96)」를 수령한다.

(e) LPP의 접속 관리 서비스는 동일 프리미티브로 수신한 LID의 접속 관리 테이블을 작성하고, 또한, 상대국의 접속 관리 서비스 포트에 대하여, 수신 가능 포트 리스트를 송신한다.

(f) LPP의 접속 관리 서비스가 LPCP로부터 데이터 전송 프리미티브(Send Unit Data.ind)로 수신 가능 포트 리스트를 수령하면, 동일 프리미티브로 통지된 LID의 접속 관리 테이블에 수신 가능 포트를 등록한다. 이후는 동일 LID에 대한 트랜잭션 개시 요구는 이 수신 가능 포트에 대해서만 접수한다.

(g) 상기 (e)에서 수신한 수신 가능 포트 리스트에 포함되는 포트 번호에 대하여, DSRC 접속 문의 프리미티브(Connect.req)를 발행하고 있는 애플리케이션에 대하여, DSRC 접속 통지 프리미티브(Connect.cnf)로써, LID 및 송신 가능 포트 번호를 통지한다.

(h) 애플리케이션이 DSRC 접속 통지 프리미티브(Connect.cnf)로 통지된 LID 또는 동보 어드레스, 및 송신처 포트 번호에 대하여, 트랜잭션 개시 요구 프리미티브(Invoke.req)를 발행함으로써, 트랜잭션이 개시된다.

(2) 고속 접속 애플리케이션의 초기 접속 순서

고속 접속이란 초기 접속을 위한 처리를 일부 생략함으로써, 고속의 초기 접속을 실현하는 수법이다. 도 55는 고속 접속 애플리케이션의 초기 접속 순차예를 나타내는 도면이다.

(b) LPP는 접속 관리 테이블을 갱신하여, 수신 가능 포트 번호를 LPCP에 등록한다.

(c) 각 애플리케이션은 Query LID 및 Query Port를 모두 미지정으로, 트랜잭션 개시 가능 문의 프리미티브(Connect.req)를 발행하여, DSRC 접속을 대기한다.

(d) LPCP로부터 이벤트 통지 프리미티브(Event Report.ind)로 이벤트 「DSRC 접속 통지(96)」를 수령한다.

(e) LPP는 동일 프리미티브로 수신한 LID의 접속 관리 테이블을 작성한다. 고속 접속을 필요로 하는 애플리케이션 때문에, 이후, 상대국의 LPP 접속 관리 서비스로부터 상대국측의 수신 가능 포트 리스트를 수신할 때까지는, 이 LID 및 동보 어드레스의 모든 포트에 대한 트랜잭션의 개시 요구를 접수한다.

(f) DSRC 접속 문의 프리미티브(Connect.req)를 발행하고 있는 애플리케이션에 대하여, DSRC 접속 통지 프리미티브(Connect.cnf)로써, LID를 통지한다.

(g) 각 애플리케이션은 DSRC 접속 통지 프리미티브로 통지된 LID 또는 동보 어드레스에 대한 트랜잭션 개시 요구 프리미티브(Invoke.req)를 발행하여, 트랜잭션을 개시한다.

(h) 상기 (g)에서 지정한 포트 번호가 상대국에 존재하는 경우는, 이 트랜잭션은 성공한다. 상기 (g)에서 지정한 포트 번호가 상대국에 존재하지 않는 경우는, 상대국의 LPCP로부터 이벤트 통지 프리미티브로, 이벤트 「송신처 로컬 포트가 유효하지 않음(129)」이 통지되어, 이 LID의 접속 관리 테이블을 갱신한다. Transaction Type=1의 경우는, 해당하는 애플리케이션에 트랜잭션 파기 통지 프리미티브(Abort.ind)로 트랜잭션의 실패를 통지한다. 이후에, 이 LID와 포트의 세트에 대하여, Transaction Type=1의 트랜잭션 개시 요구(Invoke.req)가 있었던 경우는, 트랜잭션 파기 프리미티브(Abort.ind)로써 트랜잭션의 파기를 통지한다.

2.5.2 데이터 송신 트랜잭션 서비스의 데이터 전송 순서

(1) 송신 처리

(a) 애플리케이션이 Transaction Type=0에서 트랜잭션 개시 요구 프리미티브(Invoke.req)를 발행함으로써 데이터 송신 서비스의 트랜잭션이 개시된다.

(b) 지정된 LID와 송신원 포트 번호의 세트가 수신 거부 포트의 경우는, 애플리케이션에 대하여 Abort.ind로써 상태 「수신 거부 포트 통지」를 통지하고, 이 트랜잭션은 완료한다.

(c) 지정된 메시지가 MTU를 초과하고 있고, 분할ㆍ조립 처리를 지원하고 있지 않은 경우는, 애플리케이션에 대하여 Abort.ind로써, 상태 「MTU 에러」를 통지하고, 이 트랜잭션은 완료한다. 분할ㆍ조립 처리를 지원하고 있는 경우의 처리에 대해서는 2.5.5절에 기술한다.

(d) 상기 (b)와 상기 (c) 이외의 경우는 TT=0인 Invoke PDU를 작성하고, LPCP의 전송 프리미티브(Transfer Data.req)를 이용하여, 상대국에 송신한다. 또한, 재송 처리가 유효한 경우의 처리에 대해서는 2.5.4절에 기술한다.

(2) 수신 처리

(a) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상기 (1)-(d)에서 송신된 Invoke PDU를 수신하면, 애플리케이션에 대하여, 트랜잭션 통지 프리미티브(Invoke.ind)를 이용하여, 수신 데이터를 통지한다.

도 56에 데이터 송신 트랜잭션 서비스의 데이터 전송 순서의 처리 순차예를 나타낸다.

2.5.3 요청ㆍ응답형 트랜잭션 서비스의 데이터 전송 순서

(1) 송신 처리

(a) 애플리케이션이 Transaction Type=1에서 트랜잭션 개시 요구 프리미티브(Invoke.req)를 발행함으로써, 요청ㆍ응답형 트랜잭션 서비스의 트랜잭션이 개시된다.

(b) 지정된 LID와 송신원 포트 번호의 세트가 수신 거부 포트인 경우는, 애플리케이션에 대하여 Abort.ind로써, 상태 「수신 거부 포트 통지」를 통지하여고, 이 트랜잭션은 완료한다.

(c) 동시에 실행 가능한 트랜잭션 수를 초과하는 경우는, 애플리케이션에 대하여 Abort.ind로써, 상태 「트랜잭션을 개시할 수 없었음」를 통지하고, 이 트랜잭션은 완료한다.

(d) 지정된 메시지가 MTU를 초과하고 있고, 분할ㆍ조립 처리를 지원하고 있지 않은 경우는, 애플리케이션에 대하여 Abort.ind로써, 상태 「MTU 에러」를 통지하고, 이 트랜잭션은 완료한다. 분할ㆍ조립 처리를 지원하고 있는 경우의 처리에 대해서는 2.5.5절에 기술한다.

(e) 상기 (b)와 상기 (c)와 상기 (d) 이외의 경우는 TT=1인 Invoke PDU를 작성하고, LPCP의 전송 프리미티브(Transfer Data.req)를 이용하여, 상대국에 송신 후, Result 타이머(Result 타이머의 타임아웃 값은 Invoke.req에 의해 지정)를 기동하여, 상대국으로부터의 Result PDU의 수신을 대기한다.

(f) 상기 (e)에서 기동한 Result 타이머가 타임아웃하면, AT=0, Abort Code=0x08인 Abort PDU를 생성하여, 상대국에 대하여 상태 「Result 타이머 타임아웃」을 통지하고, 또한, 트랜잭션 파기 통지 프리미티브(Abort.ind)로 트랜잭션의 실패를 애플리케이션에 대하여 통지한다.

(g) Result 타이머의 타임아웃 전에, LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상대국으로부터 송신된 Result PDU를 수신하면, 상기 (e)에서 기동한 Result 타이머를 정지하고, 또한, 응답 통지 프리미티브(Invoke.cnf)에 의해 응답 데이터를 애플리케이션에 대하여 통지한다.

(2) 수신 처리

(a) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상대국으로부터 송신된 Invoke PDU를 수신하면, 애플리케이션에 대하여, 트랜잭션 통지 프리미티브(Invoke.ind)를 이용하여, 수신 데이터를 통지하고, 애플리케이션으로부터의 응답 프리미티브(Invoke.res)의 수신을 기다린다.

(b) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상대국으로부터 송신된 Abort PDU를 수신한 경우는, 트랜잭션 파기 통지 프리미티브(Abort.ind)를 발행하여, 트랜잭션의 실패를 애플리케이션에 대하여 통지하고, 이 트랜잭션은 완료한다.

(c) 애플리케이션이 응답 프리미티브(Invoke.res)를 발행하여, LPP에 대하여 응답의 송신을 요구한다.

(d) Result PDU를 생성하여, LPCP의 전송 프리미티브(Transfer Data.req)에 의해, 상대국에 대하여 송신한다.

도 57에 요청ㆍ응답형 트랜잭션 서비스의 기본 처리 순차예를, 도 58에 Result 타이머가 타임아웃한 경우의 처리 순차예를 나타낸다.

2.5.4 재송 처리가 유효한 경우의 데이터 전송 순서

재송 처리는 Invoke.req 및 Invoke.res에서 Require Ack=1을 지정한 경우에 적용한다. 이하에서는 데이터 송신 트랜잭션의 Invoke.req에 재송 처리를 적용한 경우의 순차를 기술한다. 요청ㆍ응답형 트랜잭션 서비스에 있어서는, Invoke.res에 대해서도 마찬가지의 처리가 적용 가능하다.

(1) 송신 처리

(a) 애플리케이션이 Require Ack=1에서 트랜잭션 개시 요구 프리미티브(Invoke.req)를 발행함으로써, 재송 처리가 유효한 데이터 전송 서비스가 개시된다.

(b) RA=1인 Invoke PDU를 작성하고, LPCP의 전송 프리미티브(Transfer Data.req)를 이용하여, 상대국에 송신 후, 재송 타이머를 기동하여, 상대국으로부터의 Acknowledgement PDU의 수신을 기다린다.

(c) 상기 (b)에서 송신된 Invoke PDU가 도달하지 않는 등 어떠한 이유에 의해, Acknowledgement PDU 수신 전에, 상기 (b)에서 기동한 재송 타이머가 타임아웃한 경우는, 상기 (b)에서 송신한 Invoke PDU의 RD 플래그를 1로 세트하여, 상대국 에 재송신 후, 재송 타이머를 재기동하고, 재송 카운터를 인크리먼트한다.

(d) 몇 번 재송을 반복한 후, 재송 카운터가 최대 재송 횟수를 초과한 경우는, AT=0, Abort Code=0x07인 Abort PDU(2.4.1.4절 참조)를 생성하여, 상태 「재송 타이머 타임아웃」을 상대국에 대하여 통지하고, 또한, 트랜잭션 파기 통지 프리미티브(Abort.ind)로 트랜잭션의 실패를 애플리케이션에 대하여 통지하고, 이 트랜잭션을 완료한다.

(e) 재송 타이머의 타임아웃 전에, LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상대국으로부터 송신된 Acknowledgement PDU를 수신하면, 상기 (b) 또는 상기 (c)에서 기동한 재송 타이머를 정지하고, 이 트랜잭션을 완료한다.

(2) 수신 처리

(a) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, Invoke PDU를 수신하면, 애플리케이션에 대하여, 트랜잭션 통지 프리미티브(Invoke.ind)를 이용하여, 수신 데이터를 통지한다.

(b) 상기 (a)에서 수신한 PDU의 RA 플래그가 유효한 경우는, Acknowledgement PDU를 생성하고, LPCP의 전송 프리미티브(Transfer Data.req)에 의해, 상대국에 대하여 Acknowledgement PDU를 송신하여, 대기 타이머를 기동한다.

(c) 상기 (b)에서 송신한 Acknowledgement PDU가 도달하지 않는 등의 이유로, 상기 (a)에서 수신한 Invoke PDU를 재수신한 경우는, 이 PDU를 파기하여, 재차 Acknowledgement PDU를 생성하고, LPCP의 전송 프리미티브(Transfer Data.req)에 의해, 상대국에 대하여 송신하여, 대기 타이머를 재기동한다.

(d) 상기 (b) 또는 상기 (c)에서 기동한 대기 타이머가 타임아웃하면, 이 트랜잭션을 완료한다.

도 59에 재송 처리가 유효한 경우의 처리 순차예를, 도 60에 재송이 성공한 경우의 처리 순차예를, 도 61에 재송 처리가 실패한 경우의 처리 순차예를 나타낸다.

2.5.5 분할ㆍ조립 처리가 유효한 경우의 메시지 전송 순서

분할ㆍ조립 처리는 Invoke.req 및 Invoke.res에서 MTU를 초과하는 메시지를 지정한 경우에 적용한다. 이하에서는, Invoke.req에 분할ㆍ조립 처리를 적용한 경우의 순차를 기술한다.

(1) 송신 순서

(a) 애플리케이션이 MTU보다도 큰 사이즈의 메시지를 지정하여, 트랜잭션 개시 요구 프리미티브(Invoke.req)를 발행함으로써, 분할ㆍ조립 처리가 유효한 데이터 송신 서비스의 트랜잭션이 개시된다.

(b) 지정된 LID와 송신원 포트 번호의 세트가 수신 거부 포트인 경우는, 애플리케이션에 대하여 Abort.ind로써, 상태 「수신 거부 포트 통지」를 통지한다.

(c) 지정된 LID와 송신원 포트 번호의 세트에 대하여, 이미 분할ㆍ조립 처리가 필요한 트랜잭션이 실행되고 있는 경우는, 애플리케이션에 대하여 Abort.ind로 써, 상태 「분할 전송중」을 통지한다.

(d) 상기 (b)와 상기 (c) 이외의 경우, 송신 데이터를 선두부터 순서대로 MTU로 분할하여, 분할한 세그먼트마다 Invoke Segment PDU(2.4.1.5절 참조)의 규정에 따른 헤더를 부가하고, LPCP의 전송 프리미티브(Transfer Data.req)를 이용하여, 순차적으로 송신 요구를 실행한다.

(e) ASL의 송신 큐가 오버플로우하여, LPCP로부터 Event Report.ind로써, 상태 「송신 큐에 공간이 없어, 송신에 실패했음」이 통지되면, 일정 시간 대기하고, 송신이 실패한 데이터를 포함하여, 재차 송신을 개시한다.

(t) 최후의 세그먼트 데이터를 송신 후, 재송 타이머를 기동하여, 상대국으로부터의 Acknowledgement PDU(2.4.1.3절 참조) 또는 Nack PDU(2.4.1.7절 참조)의 수신을 기다린다.

(g) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상대국으로부터 송신된 Nack PDU를 수신하면, Nack PDU의 Segment Nmnber List에 지정되어 있는 세그먼트를 재송한다. 이 때, 재송하는 모든 세그먼트의 RD 플래그는 1로, 최후에 재송하는 세그먼트의 FIN 플래그는 1로 세트한다. 모든 세그먼트를 재송신 후, 재송 타이머를 기동하여, 상대국으로부터의 Acknowledgement PDU(2.4.1.3절 참조), 또는 Nack PDU의 수신을 기다린다.

(h) 상기 (f) 또는 상기 (g)에서 기동한 재송 타이머가 타임아웃한 경우는, 재차 최종 세그먼트를 송신하고, 재송 타이머를 재기동한다.

(i) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, 상대국으로부터 송 신된 Acknowledgement PDU를 수신하면, 상위 (f), 상기 (g), 또는 상기 (h)에서 기동한 재송 타이머를 정지하고, 이 트랜잭션을 완료한다.

(2) 수신 순서

(a) 애플리케이션이 포트 등록 프리미티브(Register Port)에 의해, 수신 데이터 조립 버퍼 영역을 지정해 놓는다.

(b) LPCP의 전송 프리미티브(Transfer Data.ind)에 의해, Invoke Segment PDU를 수신하면, 애플리케이션으로부터 지정된 수신 큐에 순차적으로 저장한다.

(c) 최종 세그먼트 데이터를 수신하면, 미수신의 세그먼트가 없는지 여부를 확인하여, 미수신의 세그먼트 데이터가 존재하는 경우는, Nack PDU(2.4.1.7절 참조)를 작성하고, LPCP의 전송 프리미티브(Transfer Data.req)를 이용하여, 상대국에 송신하며, 이후 받아야 될 최종 세그먼트 번호를 기억해 놓는다.

(d) 상기 (c)에서 Nack PDU를 송신 후에, 도착 순서 변경 등의 이유로, RD 플래그가 세트되어 있지 않은 데이터를 수신한 경우는, 그 데이터를 파기한다.

(e) 최종 세그먼트 데이터를 수신시에, 모든 세그먼트 데이터를 수신하고 있으면, 트랜잭션 통지 프리미티브(Invoke.ind)를 이용하여, 애플리케이션에 대하여, 수신 데이터를 통지하고, 또한, Acknowledgement PDU를 생성하여, LPCP의 전송 프리미티브(TransterData.req)에 의해, 상대국에 대하여 송신한다.

도 62에 분할ㆍ조립 처리가 유효한 경우의 기본 처리 순차예를, 도 63에 분할 데이터의 일부가 누락되어, 선택적 재송 처리가 실행되는 경우의 처리 순차예 를, 도 64에 최종 세그먼트 데이터가 누락되어, 재송 처리가 실행되는 경우의 처리 순차예를 나타낸다.

2.5.6 통신 종료 순서

(a) LPCP로부터 이벤트 통지 프리미티브(EventReport.ind)로 이벤트 「DSRC 절단 통지(98)」를 수령한다.

(b) 당해 LID를 사용중인 애플리케이션에 대하여, DSRC 절단 통지 프리미티브(Disconnect.ind)를 발행한다.

(c) LPP는 동일 프리미티브로 수신한 LID의 접속 관리 테이블을 삭제한다. 이후, 동일 LID에 대한 트랜잭션 개시 요구는 접수하지 않는다.

도 65는 DSRC 절단시의 순서를 나타내는 도면이다.

2.5.7 트랜잭션의 파기 순서

로컬 포트 프로토콜에서는, 트랜잭션이 이하의 상태에 있을 때, 애플리케이션으로부터 트랜잭션의 파기를 요구할 수 있다.

도 66은 트랜잭션 파기 순서를 나타내는 도면이다.

송신측

ㆍ요청ㆍ응답형의 트랜잭션에서 Invoke.req 접수 후, Result PDU의 수신에 의해, Invoke.cnf를 발행할 때까지의 동안.

수신측

ㆍ요청ㆍ응답형의 트랜잭션에서 Invoke.ind 발행 후, Invoke.res 접수에 의해, Result PDU를 송신할 때까지의 동안.

이하에 처리 순차를 기술한다.

(a) 애플리케이션으로부터 트랜잭션 파기 요구 프리미티브(Abort.req)를 수신함으로써, 이 순차는 개시된다.

(b) LPP는 동일 프리미티브로 지정된 트랜잭션에 대한 Abort PDU를 생성하고, LPCP의 전송 요구 프리미티브(Transfer Data.req)를 이용하여, 상대국에 송신한다.

(c) 요구원의 애플리케이션에 대하여 트랜잭션 파기 통지 프리미티브(Abort.ind)를 발행하고, 트랜잭션의 파기 완료를 통지한다.

(d) LPP가 LPCP의 전송 통지 프리미티브(Transfer Data.ind)에 의해, Abort PDU를 수신하면, 자국내에 동일 PDU의 TID에 의해 지정된 트랜잭션이 실행중인 경우는, 그 트랜잭션에 관한 자원을 전부 파기한 후, 애플리케이션에 대하여, 트랜잭션 파기 통지 프리미티브(Abort.ind)를 발행하고, 트랜잭션 파기를 통지한다.

또한, 상기 실시예에서는, 협역 통신(DSRC) 프로토콜(ARIB STD-T75)과, 쌍방향으로 통신 가능한 프로토콜인 확장 통신 제어 프로토콜(ASL-ELCP)과, 전송 서비스 처리부(LPCP)와, 트랜잭션 관리부(LPP)로 이루어지는 계층 구조를 나타쟀지만, 확장 통신 제어 프로토콜(ASL-ELCP) 대신에 다른 쌍방향으로 통신 가능한 프로토콜을 이용해도 된다.

이상과 같이, 본 발명에 따른 노차간 통신 시스템은 노측 시스템 및 이동국내의 쌍방의 로컬 애플리케이션이 비네트워크형의 프로토콜을 이용하여 통신을 하는 시스템으로서, 본 발명에 따른 노차간 통신 시스템은 노측 시스템 및 이동국내의 쌍방의 로컬 애플리케이션이 비네트워크형의 프로토콜을 이용하여 통신을 하는 시스템으로서, 상기 비네트워크형의 프로토콜을, 멀티 애플리케이션을 실현하기 위한 전송 서비스 처리부와, 미달 데이터의 재송신 기구, 메시지 단위의 데이터 송수신 기구, 메시지의 분할ㆍ조립 기구를 갖고, 단방향의 데이터 송신과 요청ㆍ응답형의 트랜잭션 서비스를 제공하는 트랜잭션 서비스를 실행하는 트랜잭션 관리부로 구성하는 것을 특징으로 한다.

또한, 본 발명의 노차간 통신 시스템에 있어서는, 송수신 쌍방의 애플리케이션을 식별하기 위해서 포트 번호를 이용함으로써, 비네트워크형의 프로토콜에 있어서도, 복수의 애플리케이션의 동시 실행을 가능하게 한다.

또한, 가장 단순한 애플리케이션은 전송 서비스 처리부를 직접 사용함으로써 실현이 가능하고, 고속 접속성, 낮은 오버헤드라고 한 주행중의 노차간 통신에 필요한 요건을 만족할 수 있다.

또한, 정지중이나 저속 주행중 등에서는, 트랜잭션 관리부를 사용함으로써, 대용량 데이터의 송수신이나 요청ㆍ응답형의 서비스와 같은 고도의 통신 서비스를 필요로 하는 애플리케이션에 대해서도 용이하게 대응할 수 있게 된다.

또한, 프로토콜을 확장할 때에, 확장 개소를 트랜잭션 관리부에 국소화함으로써, 확장을 용이하게 할 수 있다.

또한, 애플리케이션으로부터 지정된 식별자(송신 데이터 식별자)에 의해 송신 데이터의 단위를 식별한다. 또한, 이 프로토콜은 송신 데이터 단위가 하위층의 프로토콜로 한번에 송신 가능한 사이즈보다도 큰 경우에는, 송신 가능한 사이즈로 분할하여, 순서 번호를 부여해서 송신하고, 수신측에서 그 순서 번호를 기초로 조립하는 기능을 갖는다.

이 때, 최종 데이터의 수신시에 미수신 데이터의 순서 번호를 송신측에 통지함으로써, 미수신의 데이터만을 재송신함으로써 통신 오류율을 개선한다.

또한, 송신원의 애플리케이션 식별자(송신원 포트 번호)와 그 애플리케이션이 지정한 송신 데이터 식별자의 세트가 동일한 경우에는, 수신측에서 기수신된 동일 식별자의 데이터와 동일한 데이터로서 취급함으로써, 임의의 타이밍에서의 데이터의 재송신을 가능하게 한다. 이 때문에, 일정 시간 통신할 수 없는 경우에 있어서도, 통신 오류율을 개선할 수 있다.

Claims

도로상을 주행하는 이동국과, 상기 도로상에 설치된 기지국 장치 사이에서 실행되는 노차간 통신을 이용하여, 상기 이동국에 대하여 응용 서비스를 제공하는 노차간 통신 시스템에 있어서,

복수의 애플리케이션간의 데이터 전송을 위한 메카니즘을 제공하는 전송 서비스 처리부, 및 미배달(undelivered) 데이터의 재송신 기구와,

메시지 단위의 데이터 송수신 기구와,

상기 메시지의 분할ㆍ조립 기구를 갖고, 단방향의 데이터 송신과 요청ㆍ응답형의 트랜잭션 서비스를 제공하는 트랜잭션 관리부

를 구비한 것을 특징으로 하는 노차간 통신 시스템.
제 1 항에 있어서,

전송 서비스 처리부는 복수의 애플리케이션의 식별에 포트 번호를 이용하는 것을 특징으로 하는 노차간 통신 시스템.
제 2 항에 있어서,

애플리케이션을 식별하는 포트 번호에 있어서, 전역적으로(globally) 유일한 예약 포트와 국내(局內)에서 유일한 임의 포트를 사용하는 것을 특징으로 하는 노차간 통신 시스템.
제 1 항에 있어서,

전송 서비스 처리부는 무선 통신의 확립 상태를 애플리케이션에 통지하는 것을 특징으로 하는 노차간 통신 시스템.
제 3 항에 있어서,

전송 서비스 처리부는 초기 접속시에 자국(自局)이 갖는 애플리케이션을 식별하는 포트 번호를 상대국에 통지하는 것을 특징으로 하는 노차간 통신 시스템.
제 5 항에 있어서,

전송 서비스 처리부 및 트랜잭션 관리부는 초기 접속 순서의 생략을 가능하게 하는 것을 특징으로 하는 노차간 통신 시스템.
제 2 항에 있어서,

전송 서비스 처리부는, 상대국으로부터의 메시지 수신시에 자국에 송신처 애플리케이션이 존재하지 않는 경우에, 상대국에 대하여 바로 통지하는 것을 특징으로 하는 노차간 통신 시스템.
제 1 항에 있어서,

트랜잭션 관리부는 트랜잭션의 단위를 식별하기 위해서 애플리케이션으로부터 지정된 식별자를 이용하는 것을 특징으로 하는 노차간 통신 시스템.
제 8 항에 있어서,

트랜잭션 관리부는 트랜잭션의 중복 확인을 트랜잭션에 할당된 식별자에 의해 실행하는 것을 특징으로 하는 노차간 통신 시스템.
제 8 항에 있어서,

트랜잭션 관리부는 트랜잭션의 파기를 트랜잭션에 할당된 식별자에 의해 실행하는 것을 특징으로 하는 노차간 통신 시스템.
제 8 항에 있어서,

트랜잭션 관리부는, 메시지를 복수의 데이터로 분할하여, 분할된 각 데이터에 트랜잭션을 식별하기 위한 식별자와 순서 번호를 부여하고, 수신측에서 상기 식별자가 동일한 각 데이터를 순서 번호를 기초로 조립 순서를 판별하여 원래의 메시지로 조립하는 것을 특징으로 하는 노차간 통신 시스템.
제 11 항에 있어서,

트랜잭션 관리부는 분할 송신시, 하위층의 송신 큐의 상태에 따라 송신 간격을 제어하는 것을 특징으로 하는 노차간 통신 시스템.
제 11 항에 있어서,

트랜잭션 관리부는, 분할된 메시지의 최종 데이터의 수신시에, 미수신 데이터의 순서 번호를 송신측에 통지하고, 송신측은 상기 미수신 데이터만을 재송신하는 것을 특징으로 하는 노차간 통신 시스템.
제 8 항에 있어서,

트랜잭션 관리부는, 트랜잭션의 단위를 식별하는 식별자가 수신 완료된 데이터와 동일한 경우에는, 기수신된 동일 식별자의 데이터와 동일한 데이터로서 취급하는 것을 특징으로 하는 노차간 통신 시스템.
제 11 항에 있어서,

트랜잭션 관리부는, 트랜잭션의 단위를 식별하는 식별자가 수신 완료된 데이터와 동일한 경우에는, 기수신된 동일 식별자의 데이터와 동일한 데이터로서 취급하는 것을 특징으로 하는 노차간 통신 시스템.
제 11 항에 있어서,

트랜잭션 관리부는 메시지의 조립을 실행하는 에어리어를 애플리케이션으로부터 지정되는 것을 특징으로 하는 노차간 통신 시스템.