KR101446086B1 - Gps를 이용한 차량위치추적시스템 및 방법 - Google Patents

Abstract

본 발명은 GPS를 이용한 차량 추적에 있어서 RMA와 RCP간 데이터 교환 중 다른 RCP접근시 자동적으로 여러 RCP를 관리하고, 신속한 요청 및 응답이 가능하며 RM과 RMA간의 다중 세션 처리를 구현하여 RSU와 OBU간의 다양한 서비스를 구현하는 것에 목표를 둔다. 또한 다중 세션 처리시 각각의 RMA가 제공하는 서비스들에 대하여 독립적인 세션을 구성하여 하나의 RSU에서 다양한 서비스를 구현할 수 있는 GPS를 이용한 차량위치추적시스템에 관한 것이다.

Description

GPS를 이용한 차량위치추적시스템 및 방법{VEHICLE LOCATION TRACKING SYSTEM AND METHOD USING GLOBAL POSITIONING SYSTEM}

본 발명은 차량위치추적에 관한 것으로, 더욱 상세하게는 GPS를 이용하여 차량의 GPS 위치 정보를 수집하여 다양한 서비스를 제공할 수 있는 GPS를 이용한 차량위치추적시스템 및 방법에 관한 것이다.

교통정보시스템(ITS: Intelligent Transport System)은 기존의 교통체계에 전자, 정보, 통신, 제어 등의 지능형 기술을 접목시켜 교통 시설을 효율적으로 운영, 관리하여 교통사고와 혼잡을 감소시키고자 하는 일종의 교통부문 정보 인프라 구축사업이다. 인프라 구성 요소는 크게 차량에 설치되는 차량용 통신단말기(OBU, On Board Unit), 도로변에 설치되는 도로측장치(RSU, Road Side Unit), 교통관제센터로 구분할 수 있다. 교통관제센터는 도로측 장치를 통하여 다수의 통신단말기로부터 교통정보를 수집하여 교통 흐름을 제어하고, 도로측장치를 통하여 통신단말기로 실시간 교통정보를 제공하여 운전자가 복잡한 교통 상황에 좀 더 효율적으로 대처할 수 있도록 돕게 된다.

우리나라는 2001년에 ''ITS 기본계획 21'을 발표하여 2010년까지 전국에 교통정보시스템을 구축할 계획이다. 교통정보시스템용 통신망으로는 여러 방식이 검토되고 시험 운영중에 있으나 그 중 ADSRC(Advanced Dedicated Short Range Communication) 방식이 전송속도, 통신 가능 반경, 비용 면에서 우수하여 널리 이용될 것으로 예상된다.

이러한 교통정보시스템은 단거리 전용통신 기술을 사용함에 따라 통신 가능 반경이 넓지 않으므로, 일반적으로 교통정보시스템 망에 접속 가능한 범위는 도심지 도로 주변으로 한정된다. 따라서, 망 자체가 가지고 있는 특성상 많은 음영지역을 포함하게 됨으로써 차량이 비상사태에 처하게 되는 등의 경우 자신의 상황을 적절히 알릴 수 없는 문제가 발생한다.

따라서, 지능형 교통정보시스템은 차량 또는 운전자에게 긴급 상황이 발생했을 때 해당 상황을 적절히 수신할 수 있을 뿐 아니라, 차량의 위치를 파악하여 긴급구조 등의 서비스를 제공할 수 있도록 발전해야 한다.

대한민국 공개특허번호 10-2003-0018461호는 지능형 교통망 시스템에서 지리정보 및 교통정보 제공방법에 관한 것으로, 차량탑재장치에서 지리정보 요청 메시지를 노변기지국으로 전송하는 단계; 상기 노변기지국에서 수신한 지리정보 요청 메시지를 지역서버로 전송하여, 상기 지역서버에서 상기 지리정보요청 메시지에 포함된 목적지 정보에 따른 지리정보를 준비하는 단계; 상기 지역서버에서 상기 목적지까지의 경로에 포함되는 노변기지국의 통신영역에 따른 지리정보를 분할하는 단계; 상기 분할된 지리정보를 각각의 노변기지국으로 전송하는 단계; 상기 차량의 진행방향에 위치한 노변기지국에서 미리 전송받은 지리정보를 차량탑재장치로 전송하는 단계;를 포함하여 구성되는 것을 특징으로 하는 지능형 교통망 시스템에서 지리정보 및 교통정보 제공방법을 제공한다. 이러한 지능형 교통망 시스템을 이용하여 지리정보 및 교통정보를 동시에 받을 수 있고, 교통정보의 경우 실시간으로 그래픽을 이용한 정보 제공을 가능하게 함으로써 운전자가 좀더 교통정보를 파악하는데 용이하고, 다양한 종류의 교통정보를 제공받을 수 있도록 하는 장점이 있으나, 다중 세션을 처리하는 것에 대한 방안이 없다는 단점이 있었다.

본 발명은 GPS를 이용한 차량 추적에 있어서 RMA와 RCP간 데이터 교환 중 다른 RCP접근시 자동적으로 여러 RCP를 관리하고, 신속한 요청 및 응답이 가능하며 RM과 RMA간의 다중 세션 처리를 구현하여 RSU와 OBU간의 다양한 서비스를 구현하는 것에 목표를 둔다. 또한 다중 세션 처리시 각각의 RMA가 제공하는 서비스들에 대하여 독립적인 세션을 구성하여 하나의 RSU에서 다양한 서비스를 구현할 수 있는 GPS를 이용한 차량위치추적시스템을 제공하는데 그 목적이 있다.

본 발명은 상기 과제를 해결하기 위해 리소스 map을 가지고 있어, RM 에 접속이 이루어지면, 해당 RMA 로부터 보내온 명령을 받아 UI 컨트롤이나 리소스에 대한 접근을 처리하고, GPS 안테나(230)로부터 GPS데이터를 수신하여, 위치 정보와 시간 정보를 제공하며, GIS 서비스를 제공하기 위하여 GIS App client 프로그램이 설치되고, Low MAC, PHY 계층이 구현되어 있으며, OFDM 기술 방식을 사용하고, 공통 BPSK, QPSK, QAM 변조 방식 중 하나를 사용하고, IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원하는 WAVE통신 모뎀과 GPS 안테나를 갖추고, 도로변에 설치된 RSU와 데이터를 주고 받는 차량에 장착된 OBU(200); 상기 OBU에서 보내온 데이터를 수집하여 가공하는 App 서버(300); 및 Low MAC, PHY 계층이 구현되어 있으며, OFDM 기술 방식을 사용하고, 채널 대역은 5.850 ~ 5.920GHz의 범위 내에서 채널 당 10MHz를 사용하며, 공통 BPSK, QPSK, QAM 변조 방식 중 하나를 사용하고, IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원하는 WAVE Module(121)로 구성된 WAVE 보드(120)와, RM 모듈(112)이 구성되어 리소스 관리자로서 애플리케이션 레벨에서 RMA(Resource Manager Application) 와 RCP 의 메시지를 중계하는 역할을 하고, RMA 가 OBU(200) 로부터 필요한 리소스를 등록시켜 OBU(200) 가 접속이 이루어지면 해당 리소스에 접근할 수 있도록 RMA 에게 알림을 보내어 둘 사이의 명령을 처리하여 이동 중인 차량의 OBU 와 통신하여 무선 데이터를 중계하며 상기 App Server(300) 로 수집한 데이터를 보내는 RSU(100);를 포함하여 구성됨을 특징으로 하는 GPS를 이용한 차량위치추적시스템을 제공한다.

또한, 본 발명은 상기 과제를 해결하기 위해 Low MAC, PHY 계층이 구현되어 있으며, OFDM 기술 방식을 사용하고, 5.850 ~ 5.920GHz의 채널대역과, 공통 BPSK, QPSK, QAM 변조 방식을 사용하고, IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원하며, RM은 리소스 관리자로서 애플리케이션 레벨에서 OBU 가 서비스하는 리소스를 접근할 수 있도록 RMA 와 RCP 사이에 메시지를 중계하는 역할을 하고, RMA 가 OBU 로부터 필요로 하는 리소스를 등록시켜 OBU 가 접속이 이루어지면 OBU가 서비스하고 있는 리소스에 접근할 수 있도록 RMA 에게 알림을 보내어 둘 사이의 명령을 처리하는 RSU(100); 차량에 탑재되어 이동식으로 운영되고 서비스하고 있는 Resource Map(511)을 가지고 있어, RM 에 접속이 이루어지면, 해당 RMA 로부터 보내온 명령을 받아 UI 컨트롤이나 Resource에 대한 접근을 처리하고, OBU의 서비스에 해당하며 고유의 Resource 주소를 가지고 있어 해당 주소의 데이터를 처리하는 OBU(200); 및 UDP소켓을 사용하여 RM과 연결 및 연결 유지, OBU(200)들의 세션 생성 및 해제, 데이터 송수신을 담당하고, RCP로부터 전송받은 데이터를 가공 및 저장하며, 상기 OBU(200)가 상기 RSU(100)에 접근하면 상기 RSU(100)로부터 오는 알림에 대하여 상기 OBU(200)별로 세션을 나누고, 상기 OBU(200)로부터 전송받는 데이터를 가공하여 서비스에 맞게 처리하는(임의의 Dummy Data로 저장하는) 다수의 RMA로 구성되는 RMA(500);를 포함하여 구성됨을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템을 제공한다.

본 발명은 다음과 같은 효과가 있다.

첫째, GPS 위치 정보를 이용하여 차량의 위치와 진행 방향에 따라 차량 추적 서비스, 실시간 도로 상황 서비스, 물류 이동 추적 서비스, 관제 및 오퍼레이션 서비스 등 다양한 서비스가 가능하다.

둘째, 하나의 RMA에서 여러 개의 RM(RSU)들과 연결될 수 있어 더욱 넓은 지역에서 효과적으로 데이터를 수집 및 가공할 수 있고, 사용자에게 표현하기 적합한 형태로 변환이 가능하다.

셋째, 데이터 교환 중에 다른 RCP가 접근하게 되었을 때, 별도의 세션처리로 여러 RCP를 관리할 수 있고, 데이터 교환이 이루어지며 생성되는 GPS 데이터는 해당 RCP의 고유 번호(OBU 시리얼)를 사용하여 저장되며, 이 데이터는 차후 Web GIS 서비스에서 사용자에게 보여지기 위하여 사용되는데, 사용자가 선택하였을 때 처리 결과를 빠르게 전달하기 위하여 파일을 생성할 때, 주로 사용되는 데이터만이 저장되므로 신속한 요청 및 응답이 가능하다.

넷째, RMA 하나에 RM(RSU) 이 여러 대 접속 할 수 있으며 또 하나의 RM 에는 RCP(OBU) 단말기가 여러 대 접속 할 수 있는데, Auto-Command 부분에 RCP 에게 자신의 일련번호와 같은 Unique ID 를 읽어 전송하는 명령을 추가하도록 하여 RCP 는 어느 RM 으로 접속이 이루어지더라도 RMA 에게 유일한 RCP 임을 구분할 수 있게 되어 세션의 연속성을 유지한 채로 RMA 는 RCP 가 접속시 해당 OBU 의 일련번호를 읽어 개별적으로 원하는 서비스가 가능하게 된다.

도 1은 본 발명 제1실시예에 따른 GIS 서비스를 위한 시스템 망 구성도이다.
도 2는 본 발명에 따른 GIS 서비스를 위한 기기간 통신 프로토콜 구성도이다.
도 3은 본 발명에 따른 RSU 시스템 기능별 구성도이다.
도 4는 본 발명에 따른 OBU 시스템 기능별 구성도이다.
도 5는 본 발명에 따른 GIS 서버 시스템 구성도이다.
도 6은 본 발명 제2실시예에 따른 GIS 서비스를 위한 시스템 개발 구성도이다.
도 7은 도 6에 나타낸 RSU 측면에서의 데이터 송수신 흐름도이다.
도 8은 도 6에 나타낸 GIS Server 측면에서의 데이터 송수신 흐름도이다.
도 9는 본 발명 제2실시예에 따른 GIS 서비스 시현 결과 저장된 로그 파일을 나타낸 도면이다.
도 10은 본 발명에 따른 RM 다중세션 시스템 망 구성도이다.
도 11은 도 10에 나타낸 RM 다중세션 시스템에서 OBU 시스템 기능별 구성도이다.
도 12는 도 10에 나타낸 RM 다중세션 시스템에서 Dummy App 서버 시스템 구성도이다.
도 13은 도 10에 나타낸 RM 다중세션 시스템에서 RM 과 통신하는 RSU 의 LLC 이하의 메시지 처리 과정을 가상의 시뮬레이터 개발 구성도이다.
도 14는 도 10에 나타낸 RM 다중세션 시스템에서 RSU 측면에서의 데이터 송수신 흐름도이다.
도 15는 도 10에 나타낸 RM 다중세션 시스템에서 Multi App server측면에서의 데이터 송수신 흐름도이다.
도 16은 도 10에 나타낸 RM 다중세션 시스템에서 실제 OBU 의 RCP 애플리케이션으로 개발RM 다중세션 시스템 망 구성도이다.
도 17은 도 10에 나타낸 RM 다중세션 시스템에서 Multi session 시현 결과 저장된 각 RMA Database이다.
도 18은 도 10에 나타낸 RM 다중세션 시스템에서 Multi session 시현 결과저장된 Dummy Data이다.
도 19는 1609.1 스펙에 설명된 RM 시스템의 메시지 전달과정이다.
도 20은 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법 중 각 구간별 세션 구분을 설명하기 위한 도면이다.
도 21은 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법 중 RCP 에 Unique ID 추가를 설명하기 위한 도면이다.
도 22는 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법 중 Unique ID 전달 과정을 설명하기 위한 도면이다.
도 23은 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법을Ticket 발급 개념으로 절차를 설명하기 위한 도면이다.

본 발명에 따른 GPS를 이용한 차량위치추적시스템의 실시예를 하기 첨부된 도면을 참조하여 설명하도록 한다.

본 발명은 각 차량들의 GPS 위치 정보를 수집하여 여러 방면의 서비스를 제공하기 위한 GIS server 구축 및 전송에 대한 것으로, 차량에 장착된 OBU에서 GPS정보 데이터를 저장하게 되고, 도로변에 설치된 RSU와 WAVE(차량간 무선통신)통신 기술을 이용하여 GPS데이터를 전송한다. RSU에서 수집된 데이터는 GIS server로 전송되어 DB에 저장되어, 각 차량에서 수집된 GPS 데이터를 근간으로 용도에 맞는 유저 서비스를 제공하도록 한다.

GPS 데이터를 활용하여 제공될 2차 서비스는 차량의 위치와 진행 방향에 따라 차량 추적 서비스, 실시간 도로 상황 서비스, 물류 이동 추적 서비스, 관제 및 오퍼레이션 서비스 등 다양하다

도 1은 본 발명 제1실시예에 따른 GIS 서비스를 위한 시스템 망 구성도이다.

차세대 차량 통신 규격인 IEEE 1609를 활용하여 각 차량의 이동 경로를 수집하려는 목적으로 GIS 서버를 통해 차량 별 이동 경로를 지도를 통해 추적할 수 있다. GIS 서비스 구성은 도 1에 나타낸 바와 같이, OBU, RSU, GPS server로 구성된다.

차량에 장착된 OBU는 WAVE통신 모뎀과 GPS 안테나를 갖추어야 하며, 도로변에 설치된 RSU와 데이터를 주고 받는다. OBU의 WAVE 안테나는 무지향성 안테나로 반경 1km까지 지원되며 RSU는 무지향성, 혹은 방향성 안테나로 1Km까지 지원되어야 한다.

이 시스템은 App Server, RSU, OBU 의 3가지를 기본 구성 요소를 가진다.

각각 App Server 는 차량에서 보내온 데이터를 수집하여 가공하는 역할을 하고, RSU 는 이동 중인 차량의 OBU 와 통신하여 무선 데이터를 중계하며 App Server 로 수집한 데이터를 보내는 역할을 한다. OBU 는 차량에 설치되며 RSU 와 통신하여 구동하고 있는 애플리케이션에 따라 차량의 정보를 수집하는 역할을 한다.

개발에 사용한 규격은 1609.4, 1609.3, 1609.1 을 따른다. 각 요소들의 애플리케이션은 1609.1 에 따라 RMA/RM/RCP 모델을 통해 통신한다. App Server 는 OBU 가 서비스하는 리소스에 접근하기 위해 RMA/RM/RCP 를 통해 원하는 데이터에 접근하게 된다.

도 2는 본 발명에 따른 GIS 서비스를 위한 기기간 통신 프로토콜 구성도이다.

본 발명에서의 통신 프로토콜 구성도는 도 2와 같은데, RSU, OBU, App Server는 WAVE 규격을 따른다.

도 3은 본 발명에 따른 RSU 시스템 기능별 구성도이다.

우선, 기지국형태의 RSU는 이동하는 OBU 와 통신하는 역할을 하고, OBU 와 연결 가능한 무선 부분과, 외부의 Server 와 통신하는 유선 부분으로 구성된다. 현 시스템에는 GIS 서비스를 위한 RM 애플리케이션이 내장되어 있어 App Server 와 OBU 사이에 메시지 중계 역할을 한다.

이러한 RSU AP(100)은 RM board(110)와, WAVE board(120)로 구성되며, 주요 기능 4가지로 나뉜다.

RF Modem(121)은 Low MAC, PHY 계층이 구현되어 있으며, 802.11p에 명시된 OFDM 기술 방식을 사용한다. 채널 대역은 5.850 ~ 5.920GHz의 범위 내로 권고하며, 채널 당 10MHz를 사용한다. 대부분의 RSU는 공통 BPSK, QPSK, QAM 변조 방식을 사용 한다.

WAVE Module(121)은 IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원해야 한다.

RM board(110)은 RM 모듈(112)이 구성되어 리소스 관리자로서 애플리케이션 레벨에서 RMA(Resource Manager Application) 와 RCP 의 메시지를 중계하는 역할을 하고 RMA 가 OBU 로부터 필요한 리소스를 등록시켜 OBU 가 접속이 이루어지면 해당 리소스에 접근할 수 있도록 RMA 에게 알림을 보내어 둘 사이의 명령을 처리한다.

APP register(111)는 RM에 귀속되는 기능이며, 지원 가능한 애플리케이션 서비스 정보들이 저장된다.

도 4는 본 발명에 따른 OBU 시스템 기능별 구성도이다.

OBU(200)는 차량에 탑재되어 이동식으로 운영된다. 현 시스템에는 GIS 서비스를 위해 외부의 명령을 처리하는 RCP 서비스가 구동되어 있으며 위치 정보를 리소스 형태로 저장하는 GPS Logger 와 함께 동작한다.

RF Modem(222), WAVE Module(221), APP register(213)는 RSU(100)에서와 동일한 기능을 수행하므로 상세한 설명은 생략한다.

RCP Module(214)은 OBU 내에서 서비스하고 있는 리소스 map을 가지고 있어, RM 에 접속이 이루어지면, 해당 RMA 로부터 보내온 명령을 받아 UI 컨트롤이나 리소스에 대한 접근을 처리한다.

GPS driver(212)는 GPS 안테나(230)로부터 GPS데이터를 수신하여, 위치 정보와 시간 정보를 제공한다.

APP service client entity(211)는 RCP 리소스 맵을 사용하는 여러 애플리케이션이 설치되는 공간이며, GIS 서비스를 제공하기 위하여 GIS App client 프로그램이 설치되어야 한다.

도 5는 본 발명에 따른 GIS 서버 시스템 구성도이다.

RMA(320)는 Connect To RM Module(321), Send & Receive Thread Module(322) 및 Create GPS Log File Module(322)로 구성되어, UDP소켓을 사용하여 Connect To RM Module(321)이 RM(110)과 연결, Send & Receive Thread Module(322)에서 OBU들의 세션 생성, 데이터 송수신을 담당한다. 또한 RCP로부터 전송받은 데이터를 가공하는 작업도 RMA(320)에서 수행한다. OBU가 RSU에 접근하면 RSU(100)로부터 알림이 오게 되는데, 이때 RMA(320)가 OBU별로 세션을 나누고, OBU로부터 전송받는 데이터를 저장할 준비 작업을 한다.

OBU로부터 전송되는 GPS 데이터는 GPRMC(Recommended Minimum Data)와 GPGGA(Global Positioning System Fix Data)의 2가지 메시지의 집합으로, 각 두 메시지는 하나의 쌍을 이룬다. 두 메시지들로부터 날짜, 시간, 경위도, 속도, 방위각, 고도를 추출하여 Create GPS Log File Module(322)에서 GPS Log File로 저장하는 역할을 하며 이 데이터를 기반으로 Web Server(310)에서 GIS정보를 제공한다.

Web Server(310)는 크게 Web-GIS 서비스(311)와 사용자 관리 서비스(312)를 제공한다. 사용자로부터 접근이 있을 경우 사용자 관리 서비스를 통해 회원 가입 혹은 로그인을 수행하게 되고, 인증된 사용자의 경우 저장되어 있던 정보를 Web-GIS 화면에 출력한다. 사용자는 이를 직접 Web-GIS의 Map화면에서 확인할 수 있고, 자신이 원하는 날짜만을 검색하여 확인할 수도 있다.

GIS Server에서 사용하는 Database는 크게 MySQL Server Database(330)와 GPS Log(File) Database(340)이다. MySQL Server Database(330)에는 각 사용자들에 대한 정보, OBU에 대한 등록 번호 등이 저장되어 있으며, 로그인 및 회원가입에 사용된다. 회원가입 시 만약 이 MySQL Server Database(330)에 저장되어 있지 않은 OBU 번호라면 Reject시키며, 로그인의 경우에도 저장된 사용자가 아닌 경우 확인할 수 없도록 조치한다.

GPS Log(File) Database(340)는 GPS 로그들을 뜻하며, 각 로그들은 OBU 번호로 생성되는 디렉터리 안에 날짜와 시간을 사용하여 분류되어 있다. 사용자의 로그인이 있을 경우에 사용자가 등록한 OBU 번호에 맞는 모든 저장된 Log를 로드하여 사용자가 선택할 수 있도록 출력한다. 또한, RMA(320)에서 GPS Log를 저장할 때, 해당 OBU 번호에 맞는 디렉터리 내에 정해진 형식대로 Log File을 저장한다.

사용자는 GIS 서비스를 사용하는 사용자를 뜻하며, 외부에서 PC(400)를 사용하여 Web Server에 접속하는 주체이다. 사용자는 Web Server(310)에 접속하여 자신이 운전한 경로를 확인할 수 있다. 자신의 OBU 번호를 사용하여 Log Database의 접근이 가능하고, Web-GIS에서 지원하는 위성사진 서비스와 경로추적 서비스, 날짜 별 검색 서비스를 이용할 수 있다.

도 6은 본 발명 제2실시예에 따른 GIS 서비스를 위한 시스템 개발 구성도이다.

1차 개발 시스템에서 RSU와 GIS Server가 일방적인 TCP 연결이었다면, 2차 개발 시스템에서는 RSU(100)와 GIS Server(300)가 유기적으로 이어진다. 즉, 하나의 RMA에서 여러 개의 RM(RSU(100))들과 연결될 수 있다는 말이다. 이는 더욱 효과적으로 데이터를 수집 및 가공할 수 있고, 사용자에게 표현하기 적합한 형태로 변환이 가능하다.

RM은 RMA와 연결될 때, RMA가 필요로 하는(서비스하는) 명령어를 받는다. RSU로 OBU가 접근할 때, RCP는 RM에게 자신이 해당하는 데이터를 가지고 있음을 알린다(ResponseToPST Message 사용). 이 메시지를 수신한 RM은 RMA에게 해당 접속에 대한 내용을 알리고, RCP와 RMA간을 서로 연결시킨다.

도 7은 도 6에 나타낸 RSU 측면에서의 데이터 송수신 흐름도이고, 도 8은 도 6에 나타낸 GIS Server 측면에서의 데이터 송수신 흐름도이다.

GIS Server(300)에 있는 RMA는 구동될 때 RSU(100)의 RM과 연결된다. 연결 후 RMA는 RCP의 접근을 알리는 Notify Message를 받을 때까지 기다린다. 만약, Notify Message를 수신한다면, 접속한 RCP와의 연결을 관리할 세션을 생성하고, 해당 RCP에게 데이터 교환을 요청하는 메시지를 만들어 RM에게 전달한다. 이 방식은 만약 데이터 교환 중에 다른 RCP가 접근하게 되었을 때, 자동적으로 여러 RCP를 관리할 수 있게 한다. 데이터 교환이 이루어지며 생성되는 GPS 데이터는 해당 RCP의 고유 번호(OBU 시리얼)를 사용하여 저장되며, 이 데이터는 차후 Web GIS 서비스에서 사용자에게 보여지기 위하여 사용된다.

사용자가 선택하였을 때 처리 결과를 빠르게 전달하기 위하여 파일을 생성할 때, 주로 사용되는 데이터만이 저장되며, 이로 인해 신속한 요청 및 응답이 가능하게 된다.

도 9는 본 발명 제2실시예에 따른 GIS 서비스 시현 결과 저장된 로그 파일을 나타낸 도면이다.

GIS 서비스 시현 결과 드라이브 테스트 후 각 OBU 관련 디렉터리에 데이터가 정확히 저장되는 것을 확인할 수 있었다. Web GIS에서 확인하기 위하여 각 OBU별 아이디를 생성한 후 확인하였다.

도 10은 본 발명에 따른 RM 다중세션 시스템 망 구성도이다.

본 발명에 따른 RM 다중세션 시스템 망은 RM과 RMA간의 다중 세션 처리를 구현하여 RSU와 OBU간의 다양한 서비스를 구현하기 위한 것으로, 다중 세션 처리시 각각의 RMA가 제공하는 서비스들에 대하여 독립적인 세션을 구성하여 하나의 RSU에서 다양한 서비스를 구현하기 위함이다.

목표 세션 처리량은 특별히 제한 필요는 없지만 30개 세션을 대상으로 하였다, RMA는 각각 30개로 구현한 후 접근하고자 하는 OBU의 서비스 리소스들을 RM에 등록하게 되고, OBU가 근접했을 때 이 서비스 리소스를 연결시켜, 각각의 세션을 구성한다, RM은 RMA와 RCP사이의 명령어를 중계 및 교환하는 역할을 하여, 각 서비스 세션이 안정적으로 제공될 수 있도록 한다.

각각의 APP Server들은 RSU에 등록 과정을 거치고 각각의 서비스 세션을 만들어 낸다. RSU는 등록된 APP 정보들을 자신의 무선 커버리지에 (802.11p. WAVE) 방송하게 된다. 근접한 OBU는 방송된 정보를 읽고, OBU 자신이 서비스 제공 가능한 리스트를 RSU의 RM에 전달하게된다. 이후 RM은 RCP와 RMA 사이에 중계 및 교환자 역할을 하여 각각의 서비스가 각각의 세션에서 통신될 수 있도록 역할을 한다.

이러한 RM 다중세션 시스템 통신 프로토콜 역시 RSU, OBU, App Server는 WAVE 규격을 따른다.

기지국 형태의 RSU 는 이동하는 OBU 와 통신하는 역할을 하고, OBU 와 연결 가능한 무선 부분과 외부의 Server 와 통신하는 유선 부분을 가지고 있다. 현 시스템에는 APP 서비스를 위한 RM 애플리케이션이 내장되어 있어 다수의 App Server 와 OBU 사이에 메시지 중계 역할을 한다.

RSU AP의 주요 기능은 4가지로 나뉜다.

RF Modem은 Low MAC, PHY 계층이 구현되어 있으며, 802.11p에 명시된 OFDM 기술 방식을 사용한다. 채널 대역은 5.850 ~ 5.920GHz의 범위 내로 권고하며, 채널 당 10MHz를 사용한다. 대부분의 RSU는 공통 BPSK, QPSK, QAM 변조 방식을 사용 한다. WAVE Module은 IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원해야 한다.

RM 은 리소스 관리자로서 애플리케이션 레벨에서 OBU 가 서비스하는 리소스를 접근할 수 있도록 RMA 와 RCP 사이에 메시지를 중계하는 역할을 하고 RMA 가 OBU 로 부터 필요로 하는 리소스를 등록시켜 OBU 가 접속이 이루어지면 해당 리소스에 접근할 수 있도록 RMA 에게 알림을 보내어 둘 사이의 명령을 처리한다.

도 11은 도 10에 나타낸 RM 다중세션 시스템에서 OBU 시스템 기능별 구성도이다.

OBU(500)는 차량에 탑재되어 이동식으로 운영되고 크게 5가지 기능으로 WAVE board(520)에 구성되는 RF Modem(522), WAVE Module(521)과, RCP-APP board(510)에 구성되는 RCP Module(513), Resource Map(511), Resource Application(512)이 있다.

RCP Module(513)은 OBU 내에서 서비스하고 있는 Resource Map(511)을 가지고 있어, RM 에 접속이 이루어지면, 해당 RMA 로부터 보내온 명령을 받아 UI 컨트롤이나 Resource에 대한 접근을 처리한다.

Resource Application(512) 은 OBU의 서비스에 해당하며 고유의 Resource 주소를 가지고 있어 해당 주소의 데이터를 처리한다.

도 12는 도 10에 나타낸 RM 다중세션 시스템에서 Dummy App 서버 시스템 구성도이다.

Application Server 구조는 크게 Multi RMAs, Server, Database, 사용자로 구성된다.

RMA는 UDP소켓을 사용하여 RM과 연결 및 연결 유지, OBU들의 세션 생성 및 해제, 데이터 송수신을 담당한다. 또한 RCP로부터 전송 받은 데이터를 가공 및 저장하는 작업도 RMA에서 수행한다. OBU가 RSU에 접근하면 RSU로부터 알림이 오게 되는데 이 때 RMA가 OBU별로 세션을 나누고, OBU로부터 전송 받는 데이터를 저장할 준비 작업을 한다. OBU로부터 전송 되는 APP 데이터는 Test용으로 임의의 Dummy Data가 사용된다.

Database는 OBU의 메모리로부터 전송받은 Dummy Data를 각각의 RMA가 저장하는 저장소로써, 각 RMA마다 서로 다른 공간을 사용한다. 서로 다른 공간을 사용하므로 만약 혼선이나 잘못된 데이터가 전송된 경우 검사하기 용이하도록 설계되었다.

도 13은 도 10에 나타낸 RM 다중세션 시스템에서 RM 과 통신하는 RSU 의 LLC 이하의 메시지 처리 과정을 가상의 시뮬레이터 개발 구성도이다.

개발의 효율성을 높이기 위해 우선적으로 RM과 도 12에 나타낸 Multi RMAs간의 다중 세션 개발을 우선하고, RSU 하위 계층 및 RCP를 포함한 OBU 계층은 시뮬레이터로 구성하여 개발하였다.

다중 세션 접근 테스트를 위한 RM 과 멀티RMA의 완벽한 동작 테스트를 위해 RM 과 통신하는 RSU 의 LLC 이하의 메시지 처리 과정을 가상의 시뮬레이터로 구성하였다. 이러한 구성에서 멀티 RMA 각각은 서로 중복되지 않는 고유의 리소스 번호를 RM 에 등록하여 시뮬레이터의 동작이 시작되면 각기 다른 RMA 의 리소스 데이터 요청에 시뮬레이터가 응답 메시지를 생성하여 전달한다.

도 14는 도 10에 나타낸 RM 다중세션 시스템에서 RSU 측면에서의 데이터 송수신 흐름도이고, 도 15는 도 10에 나타낸 RM 다중세션 시스템에서 Multi App server측면에서 데이터 송수신 흐름도이다.

각각의 RMA(500)들은 구동될 때 RSU(100)의 RM과 연결된다. RMA(500)와 RM이 연결될 때 RMA(500)는 자신이 접근할 데이터가 위치하는 RCP 메모리맵의 리소스(파티션/페이지)와 접속 초기에 작업할 명령을 담은 메시지를 RM에게 전송한다. RMA(500) 는 RM으로부터 RCP(200)의 접근을 알리는 Notify Message를 받을 때까지 기다린다.

만약, Notify Message를 수신한다면, 접속한 RCP(200)와의 연결을 관리할 세션을 생성하고, 해당 RCP(200)에게 데이터 교환을 요청하는 메시지를 만들어 RM에게 전달한다. RM 은 RMA(500)의 데이터 교환 요청을 받아 리소스 접근 명령만을 추려 LLC시뮬레이터로 보내게 된다. 시뮬레이터는 해당 명령을 읽어 리소스 에 해당하는 응답 메시지를 구성한 후 다시 RM 에게 전달하고 RM 은 RMA(500) 로 전달하여 데이터 교환 트랜잭션이 완료된다.

RMA(500)에서 사용중인 수신 데이터 처리 방식은 RM으로부터 수신한 데이터에 따라 작업을 선택하여 진행하는 방식이다. 이 방식을 사용하여 데이터 교환이 이루어지고 있는 와중에 만약 다른 RCP(200)의 접근을 알리는 Notify 메시지를 수신하더라도 새로운 세션을 생성하여 다른 RCP(200)와의 데이터 교환 준비를 한다. 이러한 방식으로 각 RCP(200)의 세션을 관장하고, 각 RCP(200)들과 데이터 전송 작업을 실행한다. 만약 더 이상 수신할 데이터가 없을 시, 해당 세션을 끝낼 수 있도록 RM에게 Terminate Session 메시지를 전송하여 RM에게 더 이상 이 RCP(200)에서 할 작업이 없음을 알린다.

RM 은 내부적으로 LLC 와의 연결부터 RCP(200) 데이터 전송까지 메시지 처리를 시뮬레이션하는 LLC 시뮬레이터와 통신을 하게 된다. RM 은 각각의 RMA(500) 세션을 App-ID 별로 Connection-ID 를 발급해 RMA(500) 를 구분하고 OBU(200) 의 구분은MAC 주소에 따라 Link-ID 를 생성하여 구분한다.

테스트에서는 단일 OBU(200)에 여러 리소스 접근 세션이 접속하여 각 세션 별로 Link-ID 는 동일하기 때문에 OBU(200)의 메시지를 멀티플렉스 처리하기 위해 각 명령 별로 Command 헤더에 고유의 Transaction-ID 를 부여해 각 Command 세션을 구분한다.

도 16은 도 10에 나타낸 RM 다중세션 시스템에서 실제 OBU 의 RCP 애플리케이션으로 개발RM 다중세션 시스템 망 구성도이고, 도 17은 도 10에 나타낸 RM 다중세션 시스템에서 Multi session 시현 결과 저장된 각 RMA Database이고, 도 18은 도 10에 나타낸 RM 다중세션 시스템에서 Multi session 시현 결과저장된 Dummy Data이다.

실제 개발(2차 개발)에서는 개발 목표에 도달하기 위해서, RSU(100) 하위 계층 및 RCP를 포함한 OBU(200) 계층의 시뮬레이터를 제외하고, 이전에 개발되어 있는 RCP를 다중 세션에 맞게 추가 개발하였다. 따라서 실제 RSU 하위 계층 및 RCP를 포함한 OBU 계층을 사용하였다.

전체 동작 구성은 이전의 시뮬레이터 부분을 실제 OBU(200)의 RCP 애플리케이션으로 개발하여, 테스트 환경에 맞게 동시에 여러 리소스에 대한 접근 명령을 처리할 수 있도록 기능을 추가하였다.

각각의 RMA(500) 들은 단일 OBU(200) 내에 서비스하고 있는 서로 다른 리소스에 대한 접근을 요청하여 그에 대한 응답을 개별 Log 로 기록하며 체크하도록 개발되어 있고, RM 은 RMA(500) 와 OBU(200) 간의 세션관리 및 메시지 중계 기능을 가지고 있다. OBU(200) 의 RCP 에서는 RM 으로부터 전달받은 명령을 읽어 그에 해당하는 응답을 하도록 개발되었다.

이번 세션 테스트에서는 리소스 0002/0001 ~ 0002/0030 까지 총 30개의 리소스 데이터를 읽어 동시에 30 세션의 데이터 전송을 발생시키도록 하였으며 그에 해당하는 응답은 더미 데이터에 별도의 헤더를 작성하여 메시지가 정확히 전달되었는지 확인할 수 있는 Sequence 번호를 추가하였다.

도 19는 1609.1 스펙에 설명된 RM 시스템의 메시지 전달과정이다.

일반적인 RM 시스템은 RMA-RM-RCP 의 3가지 구성요소를 가지고 있다. RMA 는 App-ID 를 가지고 특정한 목적을 가진 애플리케이션 서버역할을 하고, RM 은 중간에서 RCP 와 RMA 을 데이터를 연결해주는 역할을 한다.

이러한 RM 시스템이 실제 도입될 경우 RMA 하나에 RM(RSU) 이 여러 대 접속 할 수 있으며 또 하나의 RM 에는 RCP(OBU) 단말기가 여러 대 접속 할 수 있다.

여기서 문제가 되는 것은 1609.1 현 규격상 RMA 가 하위 RM 에서 올라오는 각각의 RCP 메시지를 구분할 수 있는 체계가 없는 것인데, 이를 해결하기 위한 방법을 도 20 내지 도 22에서 설명한다.

도 20은 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법 중 각 구간별 세션 구분을 설명하기 위한 도면이고 도 21은 RM 애플리케이션에 접속되는 각각의 RCP를 구분하기 위한 방법 중 RCP 에 Unique ID 추가를 설명하기 위한 도면이며, 도 22는 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법 중 Unique ID 전달 과정을 설명하기 위한 도면이다.

RMA(500) 와 RM(100) 사이에는 RMA-ACTIVATE-REQUEST 를 통해 세션이 성립되는데 이때 RMA-RM 세션을 구분하는 Connection-ID 가 할당된다. 그리고 RM-RCP 사이에는 RCP(200)가 RM(100) 서비스 지역으로 진입하여 RM(100) 이 요청하는 리소스 번호를 RCP(200)가 갖고 있을 때 RCP(200)는 RM(100)에게 RM-RESPONSETOPST를 보내어 RCP 가 서비스 지역에 진입했다는 것을 알린다. 이때는 Link-ID 가 성립된다.

각 구간 별 세션 구분은 초기에는 RCP 가 접속할 때 생성되는 Link-ID 를 생성할 때 RCP(200)의 맥 어드레스를 읽어 해시 함수로 암호화한 4바이트의 키로 사용하였다. 그래서 RCP(200)가 RM(100) 사이를 핸드오버 하더라도 고유의 Link-ID 가 유지되어 RMA(500)가 각각의 RCP(200)를 구분하는 방법으로 사용하였다.

여기서 RCP(200)의 맥 어드레스를 암호화하기 위해 사용한 해시 함수는 SDBM (x65599) 이라고 하는 함수를 사용하였다. 이 해시함수는 버클리DB에서 사용하기도 한다.

하지만 추후 RCP 의 개수가 많아 질수록 해시가 중복되는 해시 충돌이 많아 질것으로 예상되어 한가지 방법을 더 추가하였다.

여기서 RCP(200)에 Unique ID 추가하는 방법은 RMA(500) 와 RM(100) 은 RMA-ACTIVATE-REQUEST 로 최초 접속을 시도할 때 Auto-Command를 넣어 RM(100) 이 해당 명령을 가지고 있다가 RCP(200)가 접속되면 자동으로 최초 명령을 내리는 구조로 되어 있는데 이 Auto-Command 부분에 RCP(200)에게 자신의 일련번호와 같은 Unique ID 를 읽어 전송하는 명령을 추가하도록 하였다.

그리고 Unique ID 전달 과정은 RCP(200)는 어느 RM(100)으로 접속이 이루어지더라도 RMA(500) 에게 유일한 RCP(200) 임을 구분할 수 있게 된다.

현재 규격상 RCP(200)의 일련번호에 해당하는 리소스는 정의되어 있지 않기 때문에 임의의 테스트망에서는 파티션 0001 에 페이지번호 0000 에 해당하는 리소스에 OBU 고유의 일련번호를 저장하도록 하였다.

이러한 방법을 통해 RMA 는 RCP 가 접속시 해당 OBU 의 일련번호를 읽어 개별적으로 원하는 서비스를 가능하게 한다.

한편 # Link-ID 를 생성하는 x65599 해시함수 코드는 다음과 같이 구현하였다.

unsignedintgenerateHash(const char *string, size_tlen)

{

unsignedint hash = 0;

for(size_ti = 0; i<len; ++i)

{

hash = 65599 * hash + string[i];

}

return hash ^ (hash >> 16);

//}

도 23은 RM 애플리케이션에 접속되는 각각의 RCP 를 구분하기 위한 방법을Ticket 발급 개념으로 절차를 설명하기 위한 도면이다.

WAVE 의 Resource Manager (1609.1) 의 다중 OBU 환경의 데이터 세션 구분

1609.1 스펙에 정의된 Resource Manager에서 RM 과 RCP 의 초기 접속 절차 이후 데이터 교환에는 SCH 를 통해 UDP 프로토콜을 사용하여 데이터를 주고 받도록 되어 있다.

UDP 프로토콜 위에 1609.1 스펙에 정의된 포멧으로 데이터를 교환을 설명하면, RMA 는 RCP 가 접속이 완료되었다는 요청을 받으면 RMA 는 원하는 서비스 구현을 위해 RCP 에게 원하는 명령이 담긴 메시지를 RM 을 거쳐 RCP 로 전달한다.

RM 과 RCP 사이의 데이터 교환은 다음과 같은 [표1]과 [표2] 포멧의 데이타 구조로 이루어진다.

Auto-Command (RM -> RCP)

Bit		Header Field
1(Reserved)	7	Command Identifier
1(Reserved)	7	Command Transaction Identifier
8		Command Parameter Length
8
N		Command Parameter

Auto-Command Reply (RM <- RCP)

Bit		Header Field
1(Reserved)	7	Command Identifier
1(Reserved)	7	Command Transaction Identifier
8		Response Status
8		Response Length
8
N		Response Data

이 Auto-Command Transaction 구조에서 우리는 Command Transaction Identifier 를 변경하게 된다.

그런데 여기서 단일 RM 에 다중 OBU 의 RCP 가 통신한다거나 단일 RM 에 여러가지 애플리케이션이 구동되고 있는 RCP 환경에서는, RM 에 여러 Command 가 동시 전달되는 경우 각 Command 에 대한 메시지 Transaction 을 구분해야 하는데 여기서는 Transaction ID 를 사용하여 세션을 처리하는 방법에 대해 설명한다.

Auto-Command 의 메시지에서 각 Command 세션을 구분하는 Command Transaction Identifier 필드는 7 bit 로 공간을 가지고 있어 최대 128개의 세션을 동시에 구분할 수 있다.

모든 Auto-Command 의 시작은 RMA 로부터 시작하기 때문에 RM 은 Auto-Command 를 전달받으면 RM 은 Transaction ID 를 하나 발급하여 RCP 로 전달하고 RCP 가 같은 Transaction ID 로 응답데이터를 보내면 발급한 Transaction ID 를 회수하는 동작을 구현하였는데 이를 Ticket 개념으로 구현하였다.

이러한 동작은 RM 이 RMA 로부터 Auto-Command 를 전달받으면 자신이 가지고 있는 Ticket 의 남은 여분을 검색하여 비어있는 Ticket 번호를 찾아 해당하는 번호를 Auto-Command 내에 Transaction ID 에 넣고 Auto-Command Reply 가 오기를 기다렸다가 메시지를 받으면 Transaction ID 에 가지고 있던 Ticket 번호를 회수하는 형태로 세션을 구분하였다.

하지만 무선의 특성으로 인해 RM 가 RCP 사이에 메시지 교환중 손실이 발생하여 Ticket 회수가 올바르게 되지 않는 경우도 있기 때문에 각 Ticket 은 세션이 만기되는 Timeout 을 가지고 있어 Ticket 여분을 검색하는 도중 Timeout 된 Ticket 이 있다면 Ticket 을 다시 사용하는 방식을 사용하여 무선 혼잡으로 인해 Ticket 회수가 올바르게 되지 않더라도 일정 시간이 지나면 만료된 Ticket 을 재사용하는 방법으로 고갈되지 않도록 하였다.

Ticket 발급 절차는 다음과 같다.

RMA 는 RM 에게 데이터 전송 요청한다(S100).

RM 은 Command 세션 구분을 위해 자신의 여분 Ticket 검색한다(S120).

검색결과(S120) 여분의 Ticket 이 없을 경우 설정된 시간 동안 대기 후 다시 Ticket 검색한다.

검색결과(S120) 여분의 Ticket이 있는 경우 Ticket 번호를 방금 전달받은 Command 메시지에 Transaction ID 로 입력한다(S140).

그리고 RM 은 할당한 Ticket 번호를 사용 중으로 체크한다(S160).

그 다음 RM 은 정상적으로 Ticket 번호를 할당한 Command 를 RCP 에게 전달한다(S180).

이어 RM 은 RCP 로부터 Command-Reply 응답을 대기한다(S200).

그리고 RM 이 RCP 로부터 정상적인 Command-Reply 응답을 받았는지 여부를 판단한다(S220).

판단결과(S220) Command-Reply 를 받지 못하면 해당 Ticket 은 일정시간 대기 후 만료된 것으로 판단하여 사용 가능 표시한다(S240).

그러나 판단결과(S220) Command-Reply 를 받았다면 Ticket 번호 등을 참조하여 Ticket 번호에 해당하는 RMA 검색한다(S260).

그러면 RM 은 Command-Reply 를 재조립하여 RMA 에게 데이터 응답을 전송한다(S280).

본 발명을 첨부된 도면과 함께 설명하였으나, 이는 본 발명의 요지를 포함하는 다양한 실시 형태 중의 하나의 실시예에 불과하며, 당업계에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 하는 데에 그 목적이 있는 것으로, 본 발명은 상기 설명된 실시예에만 국한되는 것이 아님은 명확하다. 따라서, 본 발명의 보호범위는 하기의 청구범위에 의해 해석되어야 하며, 본 발명의 요지를 벗어나지 않는 범위 내에서의 변경, 치환, 대체 등에 의해 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함될 것이다. 또한, 도면의 일부 구성은 구성을 보다 명확하게 설명하기 위한 것으로 실제보다 과장되거나 축소되어 제공된 것임을 명확히 한다.

100 : RSU 200 : OBU
300 : 서버 400 : PC
500 : RMA

Claims (10)

1. 리소스 map을 가지고 있어, RM 에 접속이 이루어지면, 해당 RMA 로부터 보내온 명령을 받아 UI 컨트롤이나 리소스에 대한 접근을 처리하고, GPS 안테나(230)로부터 GPS데이터를 수신하여, 위치 정보와 시간 정보를 제공하며, GIS 서비스를 제공하기 위하여 GIS App client 프로그램이 설치되고, Low MAC, PHY 계층이 구현되어 있으며, OFDM 기술 방식을 사용하고, 공통 BPSK, QPSK, QAM 변조 방식 중 하나를 사용하고, IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원하는 WAVE통신 모뎀과 GPS 안테나를 갖추고, 도로변에 설치된 RSU와 데이터를 주고 받는 차량에 장착된 OBU(200);
   상기 OBU에서 보내온 데이터를 수집하여 가공하는 App 서버(300); 및
   Low MAC, PHY 계층이 구현되어 있으며, OFDM 기술 방식을 사용하고, 채널 대역은 5.850 ~ 5.920GHz의 범위 내에서 채널 당 10MHz를 사용하며, 공통 BPSK, QPSK, QAM 변조 방식 중 하나를 사용하고, IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원하는 WAVE Module(121)로 구성된 WAVE 보드(120)와, RM 모듈(112)이 구성되어 리소스 관리자로서 애플리케이션 레벨에서 RMA(Resource Manager Application) 와 RCP 의 메시지를 중계하는 역할을 하고, RMA 가 OBU(200) 로부터 필요한 리소스를 등록시켜 OBU(200) 가 접속이 이루어지면 해당 리소스에 접근할 수 있도록 RMA 에게 알림을 보내어 둘 사이의 명령을 처리하여 이동 중인 차량의 OBU 와 통신하여 무선 데이터를 중계하며 상기 App Server(300)로 수집한 데이터를 보내는 RSU(100);를 포함하여 구성됨을 특징으로 하는 GPS를 이용한 차량위치추적시스템.
   
2. 제 1항에 있어서,
   상기 App 서버(300)는
   Connect To RM Module(321), Send & Receive Thread Module(322) 및 Create GPS Log File Module(322)로 구성되어, UDP소켓을 사용하여 Connect To RM Module(321)이 RM(110)과 연결, Send & Receive Thread Module(322)에서 OBU들의 세션 생성, 데이터 송수신을 담당하고, RCP로부터 전송받은 데이터를 가공하는 작업을 수행하며, 상기 OBU가 상기 RSU(100)에 접근하면 상기 RSU(100)로부터 오는 알림을 OBU별로 세션을 나누고, OBU로부터 전송받는 데이터를 저장할 준비 작업을 하는 RMA(320)와,
   사용자로부터 접근이 있을 경우 사용자 관리 서비스를 통해 회원 가입 혹은 로그인을 수행하게 되고, 인증된 사용자의 경우 저장되어 있던 정보를 Web-GIS 화면에 출력하는 Web Server(310)와,
   사용자들에 대한 정보, OBU에 대한 등록 번호 등이 저장되어 있으며, 로그인 및 회원가입에 사용되는 MySQL Server Database(330)와,
   GPS 로그들을 뜻하며, 각 로그들은 OBU 번호로 생성되는 디렉터리 안에 날짜와 시간을 사용하여 분류되며, 사용자의 로그인이 있을 경우에 사용자가 등록한 OBU 번호에 맞는 모든 저장된 Log를 로드하여 사용자가 선택할 수 있도록 출력하고, GPS Log를 저장할 때, 해당 OBU 번호에 맞는 디렉터리 내에 정해진 형식대로 Log File을 저장하는 GPS Log(File) Database(340)로 구성됨을 특징으로 하는 GPS를 이용한 차량위치추적시스템.
   
3. 제 2항에 있어서,
   상기 OBU로부터 전송되는 GPS 데이터는 GPRMC(Recommended Minimum Data)와 GPGGA(Global Positioning System Fix Data)의 2가지 메시지의 집합으로, 각 두 메시지는 하나의 쌍을 이뤄 두 메시지들로부터 날짜, 시간, 경위도, 속도, 방위각, 고도를 추출하여 Create GPS Log File Module(322)에서 GPS Log File로 저장하는 역할을 하며 이 데이터를 기반으로 Web Server(310)에서 GIS정보를 제공하는 것을 특징으로 하는 GPS를 이용한 차량위치추적시스템.
   
4. Low MAC, PHY 계층이 구현되어 있으며, OFDM 기술 방식을 사용하고, 5.850 ~ 5.920GHz의 채널대역과, 공통 BPSK, QPSK, QAM 변조 방식을 사용하고, IP, WSMP, LLC, Upper MAC 계층이 구현되어 CCH, SCH 듀얼 채널을 지원하며, RM은 리소스 관리자로서 애플리케이션 레벨에서 OBU 가 서비스하는 리소스를 접근할 수 있도록 RMA 와 RCP 사이에 메시지를 중계하는 역할을 하고, RMA 가 OBU 로부터 필요로 하는 리소스를 등록시켜 OBU 가 접속이 이루어지면 OBU가 서비스하고 있는 리소스에 접근할 수 있도록 RMA 에게 알림을 보내어 둘 사이의 명령을 처리하는 RSU(100);
   차량에 탑재되어 이동식으로 운영되고 서비스하고 있는 Resource Map(511)을 가지고 있어, RM 에 접속이 이루어지면, 해당 RMA 로부터 보내온 명령을 받아 UI 컨트롤이나 Resource에 대한 접근을 처리하고, OBU의 서비스에 해당하며 고유의 Resource 주소를 가지고 있어 해당 주소의 데이터를 처리하는 OBU(200); 및
   UDP소켓을 사용하여 RM과 연결 및 연결 유지, OBU(200)들의 세션 생성 및 해제, 데이터 송수신을 담당하고, RCP로부터 전송받은 데이터를 가공 및 저장하며, 상기 OBU(200)가 상기 RSU(100)에 접근하면 상기 RSU(100)로부터 오는 알림에 대하여 상기 OBU(200)별로 세션을 나누고, 상기 OBU(200)로부터 전송받는 데이터를 가공하여 서비스에 맞게 처리하는 복수개의 RMA(500)들로 구성되는 RMA 그룹;을 포함하여 구성됨을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템.
   
5. 제 4항에 있어서,
   상기 OBU(200)로부터 전송받은 Data를 상기 RMA 그룹에 포함된 각각의 RMA(500)가 저장하는 저장소로써, 각각의 RMA마다 서로 다른 공간을 사용하도록 구성된 데이터베이스를 더 포함하는 것을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템.
   
6. 제 4항에 있어서,
   상기 RMA 그룹에 포함된 각각의 RMA(500)는 구동될 때 RSU(100)의 RM과 연결되어 RMA(500)와 RM이 연결될 때 RMA(500)는 자신이 접근할 데이터가 위치하는 RCP 메모리맵의 리소스(파티션/페이지)와 접속 초기에 작업할 명령을 담은 메시지를 RM에게 전송하고, RMA(500) 는 RM으로부터 RCP(200)의 접근을 알리는 Notify Message를 받을 때까지 기다려 Notify Message를 수신하는 경우, 접속한 RCP(200)와의 연결을 관리할 세션을 생성하고, 해당 RCP(200)에게 데이터 교환을 요청하는 메시지를 만들어 RM에게 전달하며, RM 은 RMA(500)의 데이터 교환 요청을 받아 리소스 접근 명령만을 추려 LLC시뮬레이터로 보내고, 시뮬레이터는 해당 명령을 읽어 리소스 에 해당하는 응답 메시지를 구성한 후 다시 RM 에게 전달하고 RM 은 RMA(500) 로 전달하여 데이터 교환 트랜잭션이 완료되는 것을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템.
   
7. 제4항에 있어서,
   상기 RMA 그룹에 포함된 각각의 RMA(500)에서 사용중인 수신 데이터 처리 방식은 RM으로부터 수신한 데이터에 따라 작업을 선택하여 진행하는 방식으로 다른 RCP(200)의 접근을 알리는 Notify 메시지를 수신하더라도 새로운 세션을 생성하여 다른 RCP(200)와의 데이터 교환 준비를 하여 각 RCP(200)의 세션을 관장하고, 각 RCP(200)들과 데이터 전송 작업을 실행하며, 더 이상 수신할 데이터가 없을 시, 해당 세션을 끝낼 수 있도록 RM에게 Terminate Session 메시지를 전송하여 RM에게 더 이상 이 RCP(200)에서 할 작업이 없음을 알리며,
   RM 은 내부적으로 LLC 와의 연결부터 RCP(200) 데이터 전송까지 메시지 처리를 시뮬레이션하는 LLC 시뮬레이터와 통신을 하게 되고, RM 은 각각의 RMA(500) 세션을 App-ID 별로 Connection-ID 를 발급해 RMA(500) 를 구분하며 OBU(200) 의 구분은MAC 주소에 따라 Link-ID 를 생성하여 구분하고, 각 명령 별로 Command 헤더에 고유의 Transaction-ID 를 부여해 각 Command 세션을 구분한 것을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템.
   
8. 제7항에 있어서,
   상기 각각의 RMA(500)는 단일 OBU(200) 내에 서비스하고 있는 서로 다른 리소스에 대한 접근을 요청하여 그에 대한 응답을 개별 Log 로 기록하며 체크하고, RM 은 RMA(500) 와 OBU(200) 간의 세션관리 및 메시지 중계 기능을 가지며, OBU(200) 의 RCP 에서는 RM 으로부터 전달받은 명령을 읽어 그에 해당하는 응답을 하며, 복수개의 리소스 데이터를 읽어 동시에 복수 세션의 데이터 전송을 발생시키도록 하며, 그에 해당하는 응답은 더미 데이터에 별도의 헤더를 작성하여 메시지가 정확히 전달되었는지 확인할 수 있는 Sequence 번호를 추가한 것을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템.
   
9. 제8항에 있어서,
   상기 각각의 RMA(500) 와 RM(100) 사이에는 RMA-ACTIVATE-REQUEST 를 통해 세션이 성립되고, RMA-RM 세션을 구분하는 Connection-ID 가 할당되며, RM-RCP 사이에는 RCP(200)가 RM(100) 서비스 지역으로 진입하여 RM(100) 이 요청하는 리소스 번호를 RCP(200)가 갖고 있을 때 RCP(200)는 RM(100)에게 RM-RESPONSETOPST를 보내어 RCP 가 서비스 지역에 진입했다는 것을 알려 Link-ID 가 성립되고,
   RCP 가 접속할 때 생성되는 Link-ID 를 생성할 때 RCP(200)의 맥 어드레스를 읽어 해시 함수로 암호화한 4바이트의 키로 사용하여 RCP(200)가 RM(100) 사이를 핸드오버 하더라도 고유의 Link-ID 가 유지되어 RMA(500)가 각각의 RCP(200)를 구분하도록 하되,
   RMA(500) 와 RM(100) 은 RMA-ACTIVATE-REQUEST 로 최초 접속을 시도할 때 Auto-Command를 넣어 RM(100) 이 해당 명령을 가지고 있다가 RCP(200)가 접속되면 자동으로 최초 명령을 내리는 구조로 되어 있으며, 이 Auto-Command 부분에 RCP(200)에게 자신의 일련번호와 같은 Unique ID 를 읽어 전송하는 명령을 추가하도록 하여 RCP(200)는 어느 RM(100)으로 접속이 이루어지더라도 RMA(500) 에게 유일한 RCP(200) 임을 구분할 수 있게 하는 것을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 시스템.
   
10. 청구항 4 내지 청구항 9 중 어느 한항의 GPS를 이용한 차량위치추적 다중세션 처리 시스템에서 다중 세션을 처리하는 방법에 있어서,
    RMA 는 RM 에게 데이터 전송 요청하는 단계(S100)와,
    RM 은 Command 세션 구분을 위해 자신의 여분 Ticket 검색하는 단계(S120)와,
    검색결과(S120) 여분의 Ticket 이 없을 경우 설정된 시간 동안 대기 후 다시 Ticket 검색하고, 검색결과(S120) 여분의 Ticket이 있는 경우 Ticket 번호를 방금 전달받은 Command 메시지에 Transaction ID 로 입력하는 단계(S140)와,
    RM 은 할당한 Ticket 번호를 사용 중으로 체크하는 단계(S160)와,
    RM 은 정상적으로 Ticket 번호를 할당한 Command 를 RCP 에게 전달하는 단계(S180)와,
    RM 은 RCP 로 부터 Command-Reply 응답을 대기하는 단계(S200)와,
    RM 이 RCP 로 부터 정상적인 Command-Reply 응답을 받았는지 여부를 판단하여(S220) Command-Reply 를 받지 못하면 해당 Ticket 은 일정시간 대기 후 만료된 것으로 판단하여 사용 가능 표시(S240)하고, Command-Reply 를 받았다면 Ticket 번호 등을 참조하여 Ticket 번호에 해당하는 RMA 검색하는 단계(S260) 및
    RM 은 Command-Reply 를 재조립하여 RMA 에게 데이터 응답을 전송하는 단계(S280)를 포함하여 RM 애플리케이션에 접속되는 각각의 RCP를 구분하는 것을 특징으로 하는 GPS를 이용한 차량위치추적 다중세션 처리 방법.

Images