위치를 측정하기 위해 사용되는 인공위성은 과거에는 미국의 GPS(Global Positioning System) 뿐이었으나, 현재 가용한 측위위성은 미국의 GPS뿐만 아니라 러시아의 GLONASS(GLobal NAvigation Satellite System), 중국의 BeiDou, 유럽의 Galileo, 일본의 QZSS(Quazienioth Satellite System)등 그 수가 점차 늘어나고 있다. 측위정확도를 높이기 위한 서비스 중 하나인 Differential GPS는 GPS 뿐이던 과거와 달리 늘어난 측위위성들 모두에 대한 보정정보를 서비스해야 하게 되었다.

이들 측위위성을 통칭하여 GNSS(Global Navigation Satellite System)라 부르며 GNSS들에 대한 보정정보서비스를 DGNSS(Gifferential GNSS) 서비스라 한다. 과거에는 GPS만을 위한 보정정보 서비스만 수행하면 되었고, 이 보정정보 서비스를 위한 국제 표준은 RTCM(Radio Technical Commission for Maritime Services)에서 정의한 RTCM Recommended Standards for Differential GNSS Service version 2.3(RTCM 2.3)이었다. 한국에서는 이 보정정보 전송 표준을 이용한 DGPS 서비스를 사용자에게 제공하고 있다[1].

그러나, 이 RTCM 2.3은 GPS와 GLONASS만을 위한 표준으로, 그외의 GNSS에 대한 보정정보는 제공할 수가 없다[2]. 이에 RTCM에서는 기타 GNSS에 대한 보정정보 서비스를 제공할 수 있도록 하기 위한 새로운 RTCM Recommended Standards for Differential GNSS Service 표준을 제정하고 있으며, 그 버전을 2.4로 결정하였다. RTCM version 2.4는 모두 5개의 GNSS에 대한 보정정보 서비스가 가능하도록 설계되고 있다. 이들 GNSS는 GPS, GLONASS, Galileo, SBAS(Satellite Based Augmentation System), QZSS이며, 현재는 중국의 BeiDou까지 지원할 수 있도록 협의중에 있다.

여러개의 GNSS를 모두 지원할 수 있게 하기 위해서는 DGNSS 기준국의 보정정보 생성시 기존의 GPS 단일 서비스와는 크게 다른 생성 방법 및 스케쥴링이 필요하게 되었다. 이 표준을 이용해 Trimble사에서 New Beacon이라는 이름의 DGNSS 기준국 시스템을 제작하고 있으나, 표준이 아직 완성되지 않아 RTCM 2.4와 RSIM 1.3을 완전히 따르지 않고 있다[3,4].

이에 본 논문에서는 DGNSS 기준국의 구성요소중 보정정보를 생성하는 모듈인 소프트웨어 Reference Station(RS)에서, RTCM version 2.4를 이용하여 안정적으로 보정정보를 생성하고 서비스 하기 위한 RS의 보정정보 메시지 생성 아키텍처를 설계하였다.

DGNSS 기준국에서 사용자에게 제공하는 정보를 정의하고 있는 RTCM 메시지 표준은 버전이 달라진다고 하여 과거 버전의 메시지가 없어지는 것이 아니다. 사용 또는 불용에 대한 정의는 바뀔 수 있으나, 기본적으로 과거 버전에 존재 했던 RTCM 메시지는 유지되며, 계속해서 사용가능하다[5]. 따라서, 이 장에서는 RTCM 2.4에서도 계속해서 사용될 대표적인 기존 RTCM 2.3의 메시지 표준을 분석하였다. RTCM 2.3은 1번에서 63번까지, 모두 63개의 메시지가 정의되어 있다. 각 메시지는 각기 다른 정보를 사용자에게 제공할 수 있으며, 한국에서는 이들 메시지 중 대표적인 6가지 메시지를 서비스하고 있다[6].

한국에서 서비스중인 RTCM 2.3기반의 서비스는 표 1에서처럼 모두 6개의 메시지를 이용한다. 각 메시지의 의미는 다음과 같다.

이 6개의 메시지 중에서 RTCM 2.4를 기반으로 한 DNGSS 서비스가 개시되더라도 계속해서 사용될 메시지는 3, 5, 7, 16번으로 이들 메시지는 위성의 보정정보가 아닌 DGNSS 기준국 및 GNSS 자체의 정보를 제공하는 메시지이다. 따라서 이들 메시지는 앞으로도 사라지지 않고 계속해서 사용될 것으로 예측된다.

사용자에게 GPS의 보정정보를 제공하는 가장 중요한 메시지인 1번과 9번은 RTCM 2.4 기반의 DGNSS 서비스가 시작될 경우 사용되지 않을 것이지만, 메시지의 구조가 다를 뿐 제공하는 정보는 매우 유사하여, 이 장에서는 RTCM Type 1 메시지의 구조 및 제공 정보를 분석하였다.

RTCM Type 1를 통해 사용자에게 제공되는 정보는 표 2와 같다. Satellite ID는 GPS 위성의 번호이며, PRC는 해당 GPS 위성의 Pseudorange에 대한 보정정보이고, RRC는 PRC의 변화량을 뜻한다. GPS 위성 하나에 대한 정보의 데이터량은 모두 40비트이고 위성 수 만큼 데이터는 늘어나게 된다.

즉, GPS 위성 10개에 대한 보정정보는 RTCM 메시지 헤더 및 Parity Bit를 제외하더라도 400bit, 50Byte의 데이터량을 발생시킨다.

RTCM 2.4는 2.3 버전에서 많은 부분이 수정, 보완되었고 새로운 메시지도 추가되었다. 새로운 메시지 중 사용자에게 GNSS들의 보정정보를 전송하기 위해 2.4버전에서 추가된 메시지가 41번과 42번이다.

41번 메시지는 위에서 언급한 것처럼, 모두 5가지 GNSS에 대한 보정정보를 사용자에게 제공하기 위해 만들어진 메시지이다. RTCM 2.4에서는 GPS, GALILEO, QZSS, GLONASS, SBAS와 BeiDou(예정)까지 모두 6개의 GNSS에 대한 보정정보를 서비스 할 수 있다. 이 GNSS들에 대한 보정정보는 41번 메시지에 포함되어 제공되며, 포함되는 정보 항목은 표 3, 4와 같다.

표 3과 4에서 보는 것처럼, 모든 지원가능한 GNSS에 대한 보정정보는 41번을 통해서 사용자에게 전달된다. 각 GNSS는 고유의 GNSS System ID를 통해 구분되며, 각 GNSS의 위성 번호는 GNSS Satellite ID를 통해 구분된다. RTCM 2.3과 다르게, RTCM 2.4에서는 Ionospheric Delay 필드를 신설하여 이온층 지연 정보를 사용자에게 제공할 수 있게 되었다.

만일, DGNSS 기준국이 RTCM 2.4에서 지원 가능한 모든 GNSS에 대한 보정정보를 서비스한다면 수많은 42번 메시지가 생성될 것이다. 42번 메시지는 한번에 최대 3개의 위성에 대한 보정정보를 포함하는 41번 apt지의 분할 메시지로, 보정정보는 이 42번 메시지에 포함되어 Radiobeacon을 통해 사용자에게 전송되게 된다. Radiobeacon의 전송율은 200bps로 정해져 있어 사용자에게 빠르게 전송되지 못한다. 가용위성이 GPS가 10개, GLONASS가 10개, BeiDou가 10개, QZSS가 1개, GALILEO가 1개라면 위성이 모두 32개가 되어, 수많은 위성 수와 느린 전송속도로 인해 하나의 위성에 대한 보정나이(Correction Age)가 크게 늘어나게 된다. 따라서 RTCM 2.4를 이용할 경우 사용자가 GPS를 연속 2번, 그리고 GLONASS를 1번, BeiDou를 2번 연속으로 전송하도록 설정하는 등 각 GNSS에 대한 전송 스케쥴을 자유롭게 제어할 수 있도록 보정정보 생성 아키텍처를 설계하여야 한다.

DGNSS 보정정보를 생성하는 소프트웨어 RS의 일반적으로 그림 1과 같이 GNSS Receiver와 통신하는 Interface Module, 사용자의 제어 명령을 처리하는 Operating Module, 보정정보를 생성하는 Correction Generation Module, 그리고 RTCM 메시지를 생성하는 RTCM Format & Control Module로 구성되어 있다[3]. RTCM 2.3을 사용하는 RS에서는 GPS 보정정보가 담긴 RTCM Type 9를 생성함에 있어 별도의 스케쥴링이 필요하지 않았으나, RTCM 2.4에서는 다수의 GNSS에 대한 보정정보가 담긴 RTCM Type 42를 생성 해야 한다.

따라서 그림 1에 나타난 모듈 중 Operation Module, Correction Generating Module, 그리고 RTCM Format & Control Module의 세부 아키텍처를 다중 GNSS에 맞도록 설계해야 한다.

사용자는 GUI또는 특정 명령 메시지를 통해 소프트웨어 RS에 RTCM Type 42의 생성 제어를 할 수 있도록 설계하였다. 생성 제어에는 DGNSS RSIM(Reference Station & Integrity Monitor)의 제어, 모니터링에 사용되는 RSIM 1.3 표준을 적용하였다. RSIM 1.3에 정의된 메시지중 RTCM 메시지의 생성 및 스케쥴링에 관련된 메시지는 RSIM #117로, 세부 구조는 표 5에 나타내었다.

표 5에서 보는 것처럼, RS는 RSIM #117의 내용을 이용해 RTCM Type 42 한 메시지에 몇 개의 위성에 대한 보정정보를 넣을 것인지(C), 얼마나 자주 전송할 것인지(D), 우선순위는 어느정도인지(E) 등을 설정할 수 있도록 정의되어 있다. 따라서 Operating Module은 사용자의 명령을 입력받아 RSIM #117 메시지 형식으로 전환한 다음, 이를 RSIM 메시지 처리 모듈에서 처리하여 각 GNSS별 설정값이 저장되는 내부 저장소에 저장할 수 있도록 설계한다. 저장된 설정값은 RS를 구성하는 기타 모듈에서 언제든지 로드할 수 있도록 설계하며, 변경시 이력을 DB에 저장할 수 있도록 한다.

이와 같은 기본 조건을 충족할 수 있도록, 그림 2와 같이 Operation Module의 RTCM 생성 제어부분에 대한 아키텍처를 설계하였다.

그림 2는 Operation Module의 구조를 도식화 한 것이다. 각 부분의 주요 기능은 표 6에 나타내었다.

Command Processing에서는 사용자의 명령을 분류하여, 그 명령이 RTCM 메시지의 제어와 관련된 것일 경우 RSIM Formatter로 해당 명령과 관련된 Parameter를 전달한다. RSIM Formatter는 전달받은 Parameter를 기반으로 RTCM 메시지 스케쥴링 기능을 담당하는 RSIM #117 메시지를 생성해 낸 후, 이 메시지를 RTCM Manager로 전달한다. RTCM Manager는 RSIM #117 메시지에 있는 정보를 저장소에 저장하고, 그 정보를 바탕으로 RTCM 생성 모듈을 통해 RTCM Type 42를 생성할 수 있도록 Operation Module의 아키텍처를 설계하였다.

GNSS의 보정정보를 생성하는 Correction Generating Module은 Operation Module과는 별개의 프로세스로, 정지 없이 계속해서 동작하는 모듈이다. RTCM type 42는 5개 이상의 GNSS에 대한 보정정보를 제공할 수 있도록 설계되었으므로, GPS, GLONASS, GALILEO, BeiDou, QZSS의 보정정보를 병렬 프로세스를 통해 동시에 각각의 보정정보를 생성해 낼 수 있도록 설계해야 한다. 별개의 GNSS 보정정보 생성 프로세스가 생성해내는 데이터를 통합해서 저장하는 저장소가 두고, 이를 적절한 시간에 읽을 수 있는 타이머를 두어 사용자가 지정한 Interval 에 맞춰 RTCM 생성 모듈을 구동시킬 수 있어야 한다. 각 GNSS 보정정보 생성 프로세스는 GNSS 수신기로부터 전송받은 Raw Measurement 데이터가 저장된 저장소로부터 데이터를 각기 읽어 보정정보 생성에 사용할 수 있도록 해야 한다.

그림 3은 언급한 설계 사항을 바탕으로 Correction Generating Module의 아키텍처를 도식화한 것이다. Correction Generating Module은 GNSS별 처리 프로세스들과 GNSS 수신기의 Raw measurement저장 버퍼, PRC 저장 버퍼, 그리고 RTCM 생성 타이밍에 따라 각 GNSS의 PRC를 읽어들이는 RTCM Generation Timer로 구성된다.

RTCM 메시지를 생성하는 모듈은 기존의 GPS 전용 보정정보 메시지인 RTCM Type 9를 생성할때와 달리, 매 타이밍 마다 각기 다른 GNSS 위성에 대한 보정정보를 생성할 수 있도록 해야 한다. 매 생성 시점에 각 GNSS가 순차적으로 교체되면서 생성되는 것을 기본으로 하나, RSIM #117 메시지를 통해 사용자가 GNSS에 대해 각각 우선순위(priority)를 설정한 경우 이를 반영할 수 있도록 모듈을 설계해야 한다. 사용자가 설정한 Interval 에 맞춰 GNSS 보정정보를 포함한 RTCM Type 42를 생성할 때, MSK 모듈레이터에의 전송버퍼에 데이터가 남아 있거나 해당 GNSS의 보정정보 전송 우선 순위가 낮으면, 전송이 완료될때까지 메시지 생성을 Pending한 후에 높은 우선순위의 GNSS에 대한 RTCM Type 42를 생성한다.

그림 4는 이와같은 설계사항을 바탕으로 RTCM Formatting & Control Module의 아키텍처를 도식화한 것이다. RTCM Type 42의 생성 시점이 되면 스케쥴링 설정값이 저장되어 있는 저장소로부터 우선순위 설정을 읽어 들이고, 동시에 각 GNSS의 보정정보가 저장되어 있는 저장소에서 데이터를 읽은 후 Type 42를 생성한다. 이때, Priority Checker가 우선순위 설정값을 바탕으로 결정한 GNSS에 대한 메시지를 생성한다. 생성된 특정 GNSS에 대한 RTCM Type 42 메시지는 MSK 모듈레이터에서 변조되어 사용자에 최종 전송될 수 있도록 설계하였다.

한국에서 서비스되고 있는 대표적인 GPS 보강서비스인 Differential GPS 서비스는 현재까지 GPS 위성에 대한 보정정보만을 서비스하고 있다. 그러나 미국의 측위위성인 GPS 뿐 아니라 세계 각국에서 자국의 측위위성을 지구 궤도에 쏘아올림에 따라 지금은 5개 이상의 측위위성을 사용할 수 있다.

이에 RTCM에서는 RTCM 메시지의 버전을 2.4로 올리면서 이들 GNSS에 대한 보정정보를 서비스 할 수 있도록 표준을 개정하였다. RTCM 2.4 버전이 대두됨에 따라 한국의 DGPS 기준국도 이를 지원할 수 있어야 하게 되었다. 이런 변화에 따라 본 논문에서는 먼저 과거의 버전인 RTCM 2.3과 새로이 제정된 2.4 버전을 분석하였다.

그리고 분석된 내용에 따라 DGNSS 기준국에서 사용되는 소프트웨어 Reference Station 이 RTCM 2.4의 Type 41과 42를 이용해 GPS, GLONASS, GALILEO, BeiDou, QZSS에 대한 보정정보를 무리없이 서비스할 수 있도록 RTCM 생성 모듈의 아키텍처를 RTCM 2.4 버전에 맞춰 새로이 설계하였다. 설계한 아키텍처는 위의 다섯가지 위성에 대해 우선순위 결정, 병렬 프로세스를 통한 RTCM 메시지 생성을 수행할 수 있도록 하였다.

본 논문에서 설계한 RTCM 2.4 메시지 생성 아키텍처는 향후 새로운 DGNSS 기준국 표준인 RSIM 1.3을 이용한 시스템을 제작할 때 그 시스템의 RTCM 메시지 생성 모듈의 아키텍처로써 이용가능하다.

이에 본 논문에서 설계한 아키텍처를 이용하여 소프트웨어 RSIM 아키텍처를 설계, 구현하고 DGNSS 기준국에서 실제 DGNSS 테스트 서비스를 수행하고, 그 결과를 분석할 예정이다.