DOI QR코드

DOI QR Code

An Efficient Method to Track GPS L1 C/A and Galileo E1B CBOC(6,1,1/11) Signal Simultaneously using a Low Cost GPU in SDR

  • Park, Jong-Il (Ph.D. Candidate, Department of Control and Robotics Engineering, Chungbuk National University) ;
  • Park, Chansik (Professor, Department of Control and Robotics Engineering, Chungbuk National University)
  • Received : 2020.09.14
  • Accepted : 2020.11.03
  • Published : 2020.12.15

Abstract

In this paper, an efficient signal tracking method to simultaneously track both GPS L1 C/A and Galileo E1B CBOC(6,1,1/11) using a low cost GPU is proposed. In the existing method that each GNSS signal is processed within 1 ms, more than 2 ms processing time is required in GPU to process 4 ms CBOC signal. It means that real time operation is possible if only Galileo E1B CBOC signal is concerned. But when both GPS C/A and Galileo CBOC is required, it cannot process GPS C/A signal in real time. To process 1 ms GPS C/A and 4 ms Galileo CBOC signal in real time, 4 ms Galileo CBOC signal is divided into 4 by 1 ms signal block in the proposed method. Specially, a buffer that simultaneously manages 1 ms and 4 ms signals is designed. In addition, a module that accumulates the 1 ms correlation value of the Galileo CBOC by 4 ms and passes it to the PLL and DLL is implemented. The operation and performance are evaluated with real measurements in the GPU based SDR. The experimental results show that tracking of more than 16 satellites of GPS C/A and Galileo E1B is possible using the proposed method.

Keywords

1. INTRODUCTION

현재 Global Navigation Satellite System (GNSS)은 Global Positioning System (GPS), GLObal Navigation Satellite System (GLONASS), Beidou System (BDS)와 Galileo를 포함해 120개 이상의 위성으로 구성된다 (Kaplan & Hegarty 2017). 많은 위 성신호를 수신할수록 정밀한 사용자의 위치를 얻을 수 있어, 단일 GNSS 보다 많은 위성 신호를 수신할 수 있는 다중 GNSS를 수신 가능한 수신기가 요구된다 (Hobiger et al. 2010, Kaplan & Hegarty 2017, Teunissen & Montenbruck 2017). 최근의 수신기 설계는 반도체의 집적도 향상과 신호처리 기법의 발전으로 가능한 많은 위성을 이용하여 항법을 수행하여 높은 정확도와 가용성을 가지는 추세이다 (Septentrio 2020, Novatel 2020).

각각의 GNSS는 주파수 사용의 효율을 극대화하면서 다른 시스템과의 간섭 문제를 최소화하는 방향으로 설계되어 서로 다른 신호구조를 가진다 (Tran 2017). Table 1에 대표적인 L1 대역 GNSS의 중심주파수, 코드 주기, 데이터 속도, 변조방식을 나타냈다. 다중 GNSS를 효율적으로 수신하기 위해서 대부분의 수신 기에서는 각 신호구조에 맞게 신호처리 프로세스를 변경할 수 있는 Field Programmable Gate Array (FPGA)를 사용한 소프트웨 어 기반의 기법이 사용된다 (GNSS SDR 2019). 최근에는 General Purpose Graphic Processing Unit (GPGPU)의 발전으로 하드웨 어 변경없이 소프트웨어 변경만으로 신호처리 프로세스를 쉽게 변경 및 업데이트 할 수 있는 소프트웨어 기반 수신기(Software Defined Radio, SDR) 연구가 많이 진행되고 있다 (Hobiger et al. 2010, Principe et al. 2011, Huang et al. 2013, Curran et al. 2013).

Table 1. GNSS L1 signal characteristics (Tran 2017).

  GPS L1 C/A GLONASS G1 Galileo E1 BDS B1I
IF (MHz) 1575.42 1598.0625~1605.375 1575.42 1561.098
Code period (ms) 1 1 4 1
Bit rate (bps) 50 50 250 50
Modulation BPSK BPSK CBOC(6, 1, 1/11) BPSK

 

충북대학교 센서 및 항법 시스템 연구실에서 구현한 수신기 Software Receiver of Chungbuk National University (SRC) (Park et al. 2014)는 GPU 기반의 SDR이며 Kepler 구조를 갖는 GTX TITAN을 사용한다 (Smith & Garg 2013). L1. SRC는 L1대역의 GPS L1 C/A, GLONASS G1, BDS B1I 및 Galileo E1B 신호를 모두 사용하여 실시간으로 항법을 수행하는 SDR로 개발되고 있다. 현재는 코드주기가 1 ms인 GPS L1 C/A, GLONASS G1 및 BDS B1I 는 동시 수신을 지원하고 있으며 (Park 2019), 4 ms의 코드주기를 갖는 Galileo E1B CBOC(6,1,1/11)은 단일 수신이 가능하나 코드주기가 1 ms 인 신호와 동시 수신은 지원되지 않는다 (Park & Park 2019).

기존의 연구에서 Tsinghua 대학과 Calgary 대학에서 Galileo E1B 신호와 GPS L1 C/A를 동시에 수신하는 GPU 기반의 실시간 SDR를 구현했다 (Petovello et al 2008, Curran et al. 2013, Huang et al. 2013). Tsinghua 대학은 PC에서 신호처리를 모두 수행하는 GPU 기반 SDR을 구현했으며, Calgary 대학은 FPGA를 사용해 신호처리부를 구현했다. 두 대학의 SDR은 모두 Galileo 신호의 설계가 완성되기 이전에 만들어져 5~8 Msps의 표본화 주파수를 사용했다. 이는 4 MHz 대역을 갖는 BOC(1,1) 신호를 수신하는데는 문제가 없으나 15 MHz 대역의 BOC(6,1)과 4 MHz 대역의 BOC(1,1)의 합으로 만들어지는 CBOC(6,1,1/11) 변조방식의 신호를 손실 없이 수신할 수 없는 구조이다. CBOC(6,1,1/11) 신호를 손실 없이 수신하기 위해서 30 Msps 이상의 표본화가 요구된다. 이에 따라 Tsinghua 대학이나 Calgary 대학에서 수행한 Maxwell 구조의 GPU를 이용하여 5~8 Msps의 표본에 대한 실시간 동작이 30 Msps의 표본에는 실시간 동작이 담보되지 않는다.

본 논문은 30 Msps의 이상의 표본에서 GPS L1 C/A, Galileo E1B CBOC(6,1,1/11)을 동시에 수신하는 신호 추적 알고리즘을 구현했다. 실시간 다중 수신을 위해 SRC에서 GNSS 데이터를 받기 위해 필요한 표본화 주파수 설정하고, 코드 주기가 다른 신호를 동시에 처리하기 위해 표본화 데이터 저장 및 처리를 위한 버퍼 관리 설계했다. 그리고 버퍼에 저장된 다중 신호를 동시에 처리 하기 위해 신호 처리 주기를 고려한 신호 추적부를 설계했다.

다중 수신을 위해 수신할 GNSS 신호 대역을 Fig. 1과 같이 설계했다. Fig. 1은 다운컨버터 국부 발진기의 주파수를 1567 MHz 로 설정한 Intermediate Frequency (IF) 주파수 계획을 나타낸다. 여기서 Galileo E1B와 GPS L1 C/A 신호를 동시에 수신하려면 약 25 MHz의 대역폭이 필요하다. 이는 50 MHz 이상의 표본화 주파수를 요구하며 이에 따라 현재 구현하는 SDR의 표본화 주파수는 50 MHz로 설정했다.

Fig1.png 이미지

Fig. 1. IF plan of GNSS L1-band.

Galileo E1B CBOC(6,1,1/11) 신호와 GPS L1 C/A 신호를 실시간으로 수신하기 위해 본 논문에서는 50 Msps의 표본을 지원하는 GPU 기반 신호추적 구조를 제안한다. 1 ms 주기의 C/A와 4 ms 주기의 CBOC(6,1,1/11) 신호를 동시에 수신하기 위해 4 ms 신호를 1 ms 길이로 나누어 4번 상관하고 그 결과를 누적하여 신호추적에 적용한다. 따라서 C/A 신호는 1 ms 주기로, CBOC(6,1,1/11)는 4 ms 주기로 처리할 수 있게 된다. 먼저 2장에서 기존 구현된 SRC 의 구조를 살펴보고 문제점을 분석하며, 3장에서 제안한 신호수 신구조를 신호 버퍼와 상관기로 나누어 설명하고 적용하며, 4장에서는 제안한 구조를 SRC에 적용하여 실시간으로 GPS L1 C/A 와 Galileo E1B CBOC(6,1,1/11) 신호를 수신하는 것을 확인하였다.

2. 기존 신호추적 구조

Fig. 2에 현재까지 구현된 SRC의 동작을 나타냈다. 1 ms 코드 주기를 갖는 GPS L1 C/A, GLONASS G1, BDS B1I의 신호 추적은 모두 동일한 버퍼를 갖고 동일 방식으로 수행되어 대표적으로 GPS L1 C/A 신호만으로 표현했다. Fig. 2의 신호추적 동작은 크게 Central Processing Unit (CPU)와 GPU부분으로 나누어진다. CPU에서는 GNSS signal receive와 signal buffer 관리, Phase Lock Loop (PLL), Delay Lock Loop (DLL), bit extraction, Navigation message 획득을 수행한다. 반면 GPU는 간단하며 반복적인 연산을 수행하는 replica generation과 correlator의 동작을 수행한다. Fig. 2에서 처음 안테나에서 받은 GNSS 신호는 매 1 ms 마다 4 ms signal buffer와 1 ms signal buffer에 동시에 저장된다. 1 ms signal buffer는 GPS L1 C/A 신호를 추적하기 위한 버퍼, 4 ms signal buffer는 Galileo E1B CBOC(6,1,1/11) 신호를 추적하기 위한 버퍼이다. 버퍼에 들어있는 신호 데이터는 mode에 따라 1 ms 코드 주기를 갖는 신호를 추적하거나 4 ms 신호 주기를 갖는 신호를 추적하는데 사용한다. Mode에 따라 CPU에 있는 각각의 버퍼가 가득 차는 시간인 1 ms와 4 ms 주기로 GPU 로 데이터를 넘겨주고, GPU에서는 각 주기마다 1 ms 길이의 GPS L1 C/A, GLONASS G1, BDS B1I 와 4 ms 길이의 Galileo E1B CBOC(6,1,1/11) 레플리카 신호를 생성한다. 상관기에서 레플리카 신호와 GNSS 신호로 상관값을 구하고 CPU 부분으로 전달한다. 상관값으로부터 도플러 주파수와 코드 위상을 구하고 이를 이용하여 PLL과 DLL 갱신하여 신호추적이 계속 유지되도록 한다. 또 상관값을 이용해 비트를 추출하고, 얻은 비트를 이용해 항법메시지를 획득한다. 최종적으로 코드 위상으로 구한 의사거리와 항법메시지로부터 구한 위성 위치를 이용하여 항법을 수행한다.

Fig2.png 이미지

Fig. 2. Brief operation of SRC.

Fig. 2의 신호추적 동작 중에서 시간을 가장 많이 차지하는 부분은 다음 두 가지이다. 첫째, CPU 부분의 신호 버퍼에 저장된 데이터를 GPU로 넘겨주는 과정, 둘째 GPU에서 레플리카 신호를 생성 후 상관값을 계산 과정이다. Fig. 3에서 CPU에서 1 ms와 4 ms 길이의 GNSS 신호를 GPU로 전달하는 전달시간과 1 ms GPS L1 C/A, GLONASS G1, BDS B1I 신호와, 4 ms 길이인 Galileo E1B CBOC(6,1,1/11) 신호를 생성하고 상관값을 구하는 시간을 나타냈다. 실시간으로 수신기가 동작하기 위해서 신호추적에 필요한 연산은 신호 주기보다 짧은 시간 안에 처리되어야 한다.

Fig3.png 이미지

Fig. 3. GPS C/A & Galileo E1B tracking time. (a) GPS L1 C/A (b) Galileo E1B

Fig. 3에서 GPS L1 C/A, GLONASS G1, BDS B1I 은 CPU에서 GPU로 데이터 전송하는 시간이 0.25 ms, GPU 동작시간이 약 0.5 ms로 모두 0.75 ms 이내에 처리되며, 이는 1 ms 이내로 수신기가 실시간으로 동작하는데 문제없음을 보여준다. Galileo E1B CBOC(6,1,1/11) 신호 또한 CPU에서 GPU로 데이터 전송시간은 약 0.5 ms, GPU 동작시간은 2 ms로 모두 2.5 ms 이내에 처리되며, 이는 요구조건인 4 ms 이내로 실시간으로 신호를 추적할 수 있음을 알 수 있다. 그러나 GPS L1 C/A, GLONASS G1, BDS B1I 와 Galileo E1B CBOC(6,1,1/11)를 동시에 추적할 경우 실시간 동작이 불가능하다. 그 이유는 GPS L1 C/A, Galileo E1B CBOC(6,1,1/11) 은 같은 스레드에서 추적을 수행하기 때문이다. GPS L1 C/A의 상관이 끝났다 해도 매 4 ms마다 Galileo E1B의 상관이 끝날 때까지 대기해야 하며, 총 상관시간이 1 ms를 넘기 때문에 Galileo E1B CBOC(6,1,1/11)은 실시간으로 동작이 가능하나 GPS L1 C/A의 실시간 동작은 불가능하다.

이를 해결하는 한가지 방법으로 GPS L1 C/A, GLONASS G1, BDS B1I 와 Galileo E1B CBOC(6,1,1/11) 신호를 모두 4 ms 주기로 처리하는 방법을 생각할 수 있다. 그러나 이는 1 ms 신호를 제 시간에 처리하지 못한다는 문제와 다른 주기를 갖는 GNSS 신호, 예를 들면 10 ms의 주기를 갖는 GPS L1C 와 같은 신호를 동시에 처리해야하는 경우 처리 주기가 더 길어지는 문제가 있다. 따라서 본 모든 GNSS 신호를 제 주기에 맞추어 처리하는 방법이 필요하다.

3. 제안하는 신호추적 구조

본 논문에서는 4 ms 주기를 갖는 Galileo E1B CBOC(6,1,1/11) 신호를 1 ms로 나누어 1 ms 주기인 GPS L1 C/A와 동시에 신호처리를 수행하는 구조를 제안한다. GLONASS G1, BDS B1I는 GPS L1 C/A와 같은 주기를 가지고 있어 같은 신호 추적구조를 갖기 때문에 GPS L1 C/A에 포함하여 설명한다.

식 (1)에서 Sgal[n]은 수신한 Galileo E1B CBOC(6,1,1/11) 신호를 SR[n]는 수신기에서 생성한 레플리카 신호를 나타낸다. 식에서 C, D는 코드와 데이터를 나타내며, fIF, fDopp, fs , Ts , δn는 각각 IF 주파수, 도플러 주파수, 표본화 주파수, 표본화 주기 그리고 코드 지연을 나타낸다. fIF와 fs 는 수신기의 초기 설정에서 설정한 값을 나타내며, fDopp와 δn의 초기 값은 신호획득을 통해 얻을 수 있다.

\(\begin{array}{l} S_{\text {Gal }}[n]=C_{\text {Gal }}\left(n T_{s}+\delta n_{\text {Gal }} T_{s}\right) D_{\text {Gal }}\left(n T_{s}+\delta n_{\text {Gal }} T_{s}\right) \sin \left(2 \pi\left(f_{I F}+f_{Dopp_{Gal}}\right) n T_{s}\right) \\ S_{R}[n]=C_{\text {Gal }}\left(n T_{s}+\delta n_{R} T_{s}\right) \sin \left(2 \pi\left(f_{I F}+f_{Dopp_{R} }\right) n T_{s}\right) \end{array}\)       (1)

수신한 신호와 신호획득에서 얻은 파라미터를 이용해 만든 레플리카 신호를 이용해 식 (2)와 같이 상관 값을 구하고, PLL과 DLL을 이용해 정확한 \(f_{Dopp_{R}}\) 와 δnR를 갱신한다. 만약 DLL이 정상 적으로 동작한다면 δnR와 δnGal이 일치한다. 마찬가지로 PLL이 정상적으로 동작한다면 \(f_{Dopp_{R}}\)\(f_{Dopp_{Gal}}\) 이 일치한다. 그렇지 않고 δnR\(f_{Dopp_{R}}\) 가 δnGal\(f_{Dopp_{Gal}}\) 점점 달라지면 잘못된 레플리카 생성 으로 인해 신호 추적에 실패하게 된다.

\(\begin{aligned} \operatorname{Corr}_{G a l} &=\sum_{n=0}^{4 m s \times f_{s}} S_{G a l}[n] S_{R}[n] \\ &=\sum_{n=0}^{1 m s x f_{s}} S_{G a l}[n] S_{R}[n]+\sum_{n=1 m s \times f_{s}}^{2 m s \times f_{s}} S_{G a l}[n] S_{R}[n] \\ &+\sum_{n=2 m s x f_{s}}^{3 m s \times f_{s}} S_{G a l}[n] S_{R}[n]+\sum_{n=3 m s \times f_{s}}^{4 m s x f_{s}} S_{G a l}[n] S_{R}[n] \end{aligned}\)       (2)

식 (2)는 레플리카 신호와 수신신호의 상관 값을 나타내며 Galileo E1B CBOC(6,1,1/11) 신호는 4 ms 주기를 가지므로 4 ms 의 표본화 개수의 상관값을 누적해야 하며, 이는 1 ms 길이의 신호를 4번 누적하는 것과 같은 결과임을 보여준다. 따라서 실시간으로 GPS L1 C/A와 Galileo E1B CBOC(6,1,1/11) 신호를 동시에 수신하기 위해 Fig. 4와 같은 신호추적 구조를 제안한다. Fig. 2의 기존 1 ms와 4 ms 길이의 신호버퍼로 C/A와 CBOC(6,1,1/11) 신호를 관리했던 구조를 여기서는 단일 1 ms 길이의 신호버퍼로 관리하는 구조로 변경하였다. 또한, 변경된 버퍼 구조에 따라 CPU에 서 GPU로 C/A와 CBOC(6,1,1/11) 신호 데이터를 넘겨주는 주기도 매 1 ms로 변경된다. 1 ms마다 상관값을 구하기 위하여 1 ms마다 1 ms 길이의 C/A와 CBOC(6,1,1/11)의 레플리카 신호를 생성한다. 상관 값은 CPU 부분에 있는 Accumulator에 저장되며 GNSS 신호의 코드 주기에 따라 누적 주기가 달라진다. GPS L1 C/A 신호 는 코드 주기가 1 ms이므로 1 ms의 상관값을 누적하여 출력하고, Galileo E1B CBOC(6,1,1/11)는4 ms의 코드 주기를 갖기 때문에 코드 시작 부분부터 1 ms씩 4번의 상관값을 누적하여 출력한다. 구체적인 동작은 이어지는 절에서 자세히 설명한다.

 Fig4.png 이미지

Fig. 4. Proposed SDR structure.

3.1 GPS L1 & Galileo E1B의 신호버퍼 구조

기존 SDR의 신호버퍼 구조는 Fig. 2에서와 같이 GPS L1과 Galileo E1B로 나뉘어 구성되어 있다. 반면 Fig. 4에 제안한 구조에서는 한 개의 버퍼로 구성된다. 그림에서 버퍼의 크기는 생성 하는 레플리카 신호 길이의 2배의 크기를 가지며, 그 이유는 각각의 위성 신호는 다른 코드지연을 갖고, 또한 다른 코드 지연 때문에 위성 신호의 코드가 시작부분이 수신기에 도착하는 시간이 서로 다르며 코드가 끝나는 시간도 달라지기 때문이다. 이는 Fig. 2 의 신호 버퍼에서도 마찬가지이며, 기존의 방법에서 4 ms 주기를 갖는 Galileo E1B의 레플리카 신호를 생성하기 위해 2배 길이의 버퍼가 필요하다. 그러나 Fig. 4에서는 1 ms의 레플리카 신호를 생성하기 때문에 2 ms 길이의 버퍼가 필요하다. 따라서 제안하는 방법에서는 Galileo E1B CBOC(6,1,1/11)에 대하여 기존 방법에 비하여 1/4에 해당하는 버퍼만으로 처리할 수 있다.

Fig. 5에 기존의 신호버퍼 관리 기법을 자세히 나타냈다. 그림에서 50 K [sample]은 1 ms 동안 50 Msps 표본을 저장하기 위한 50 K 버퍼를 나타낸다. 그림의 오른편 GPS L1 C/A에서 1 ms 측 정치의 2배에 해당하는 신호 버퍼가 초록색으로 표시되어 있다. 신호 추적이 진행되는 동안에는 채널별 코드지연(code delay)을 알고 있으므로 전달해야 할 최소 샘플수 NCA만큼 GPU로 전달한다. NCA은 그림에서 보는 바와 같이 최대 코드지연을 갖는 채널의 한 주기가 끝나는 지점과 최소 코드지연을 갖는 채널의 한 주기 시작점의 차를 나타낸다. Galileo E1B CBOC(6,1,1/11)도 같은 방법으로 처리하며 4 ms 주기에 대하여 NCBOC개의 샘플을 GPU로 전달한다.

Fig5.png 이미지

Fig. 5. Existing buffer management structure of SDR.

위의 구조는 GPS L1 C/A와 Galileo E1B CBOC(6,1,1/11)에 각각 NCA와 NCBOC가 별도로 생성되어 GPU로 2번의 데이터 전달이 필요하다. 만약 주기가 다른 GNSS의 신호가 더 추가될 경우 추가된 GNSS 신호구조에 따른 신호버퍼 관리와, GPU로의 데이터 전달 시간이 증가하게 된다.

이러한 문제를 해결하기 위해 Fig. 6과 같이 4 ms 주기를 갖는 Galileo E1B CBOC(6,1,1/11) 신호를 GPS L1 C/A 신호의 주기인 1 ms 단위로 나누어 관리하는 신호버퍼 구조를 제안한다. 1 ms 길이로 나누어진 Galileo E1B CBOC(6,1,1/11) 신호는 1부터 4까지 일련 번호로 지정해서 관리하며, 일련 번호가 같은 주기의 신호인지를 확인하기 위해 epoch 번호를 추가하여 관리한다. 일련 번호 와 epoch 번호는 CPU에서 관리하며 GPU로 샘플과 함께 전달한다. GPU로 전달할 샘플 개수 NCC는 기존 방식과 같이 버퍼에 저장된 신호들 중에 코드 지연이 가장 짧은 채널과 긴 채널을 선택하여 정한다. 기존의 방식에서는 GPS 채널과 Galileo 채널이 구분되어 있지만 제안한 방식에서는 GPS와 Galileo를 구분하지 않으므로 채널관리가 용이하다.

Fig6.png 이미지

Fig. 6. Proposed buffer structure.

신호 버퍼는 다중 스레드 구조에서 동작하기 때문에 신호추적 부 뿐만 아니라 신호획득부에서도 고려하여 설계해야 한다. 신호 획득부는 각 채널의 도플러 주파수와 코드 지연을 구해 신호추적부에 전달하지만, 신호획득부의 동작 시간은 수십 ms가 소요되어 GPS L1 C/A나 Galileo E1B CBOC(6,1,1/11) 신호 주기 보다 많이 길다. 신호획득부의 동작시간은 항상 Galileo E1B CBOC(6,1,1/11) 코드 주기인 4 ms의 배수로 소요되지 않는다. 만약 신호획득 이후 신호추적을 개시할 때 4 ms 주기를 갖는 Galileo E1B CBOC(6,1,1/11) 코드의 첫 부분인 일련번호 1을 상관하지 않는다면, 4 ms씩 누적하는 구조에서 다른 주기의 코드의 상관 값도 누적되기 때문에 신호추적에 문제가 생긴다. 그래서 4 ms의 코드주기를 갖는 Galileo E1B CBOC(6,1,1/11)의 다른 일련번호의 신호 버퍼의 샘플을 사용하지 않고 기다리다 일련 번호 1의 샘플이 들어오면 동작을 누적을 해야 한다.

자세한 SDR 초기동작을 Fig. 7에 나타냈다. 그림에서 Thread 0은 버퍼관리, Thread 1은 신호획득, Thread 2는 신호추적의 동작을 나타낸다. Galileo E1B CBOC(6,1,1/11) 신호를 획득하기 위하여 Thread 0에서 4 ms의 샘플을 Thread 1으로 전달한다. Thread 1에서 신호획득을 하는데 delay만큼 시간이 소요된다. 그때 Thread 2는 일련번호를 처리하고 일련번호 3번의 데이터를 전달 받을 때까지 기다리며, 다음 번에는 일련 번호가 3인 샘플을 처리하게 된다. 그러나 새로 획득한 위성의 추적은 이 샘플로 시작하지 못하고 기다리다 (n+1) epoch 번호의 일련번호 1인 샘플이 도착하면 신호 추적을 시작한다. 이때 시간 지연에 따른 코드 위상과 도플러 주파수의 변화는 무시할 수 있다. 하지만 integration time이 늘어나면 신호획득의 동작시간이 늘어나고, 신호추적에 사용되는 데이터와 신호획득에서 사용할 데이터는 동작시간만큼 차이나는 데이터를 사용하게 된다. 1 ms일 경우 동작시간은 평균 31 ms가 걸리며 4 ms 신호는 평균 51 ms가 걸린다. Park et al. (2016)에 따르면 200 ms 이후에 신호추적에 영향을 끼치기 때문에 4 ms로 integration time을 늘려도 동작하는데 문제 없다.

Fig7.png 이미지

Fig. 7. SDR thread operation.

신호획득은 Galileo E1B CBOC(6,1,1/11) 신호의 주기 4 ms에 맞추어 동작하며 GPS L1 C/A의 경우 주기 1 ms 보다는 느리게 동작한다. 그러나 신호 획득이 수 ms의 지연이 중요하지 않고, 4 ms 길이의 신호를 사용해 적분시간(integration time)을 늘이면 신호 획득에 유리한 장점을 갖는다 (Ziedan 2006).

3.2 신호 상관 구조

Fig. 8은 GPS L1 C/A 신호와 Galileo E1B CBOC(6,1,1/11)를 동시에 추적하기 위한 과정을 나타낸다. Galileo E1B CBOC(6,1,1/11)는 상관시간을 1 ms 이내로 줄이기 위해 GPS L1 C/A와 같은 주기인 1 ms 로 신호를 나누어 상관을 수행한다. 1 ms 나누어 상관을 하면 GPS L1 C/A와 Galileo E1B CBOC(6,1,1/11)은 같은 버퍼를 사용할 수 있어 CPU에서 GPU로 데이터를 전송하는 시간이 감소했다. 또한 4 ms 주기를 갖는 Galileo E1B CBOC(6,1,1/11) 신호를 4 ms 길이의 레플리카와 상관을 한번에 수행하면 1 ms 이상의 상관시간을 갖는데, Fig. 8은 1 ms씩 나누어 상관을 수행해 1 ms 이내의 상관시간을 가질 수 있어 GPS L1 C/A와 Galileo E1B CBOC(6,1,1/11)를 동시에 수신할 수 있다. Galileo E1B CBOC(6,1,1/11)를 1 ms로 나누어 상관하기 위해서 신호추적에서 사용할 1 ms 길이의 신호데이터와 Fig. 6에서 나타낸 일련번호 i를 가져온다. Fig. 8에서 GPS L1 C/A는 1 ms 주기를 갖고 있어 매번 상관하여 PLL, DLL을 통해 δnR\(f_{Dopp_{R}}\)를 갱신한다. Galileo E1B CBOC(6,1,1/11) 신호는 실제로 4ms 주기를 갖기 때문에 1 ms 길이의 데이터를 이용해 신호추적을 하기 위해 1ms 신호를 4번 누적하는 구조를 설계했다.

Fig8.png 이미지

Fig. 8. Signal correlation structure.

Galileo E1B 신호는 GPS L1 C/A 신호와 달리 CBOC(6,1,1/11)방식으로 변조되어 있어 복조를 하기 위해 부반송파를 생성해주어야 한다. 부반송파는 실시간 동작을 위해서 SDR 동작 초기에 생성한 테이블을 사용해 생성한다 (Park & Park 2020). 생성한 레플리카 신호와 버퍼에서 가져온 신호데이터를 이용해 상관을 한다. GPS L1 C/A와 달리 상관을 수행할 때마다 PLL, DLL이 동작하지 않는다. 누적을 4번하고 누적한 데이터의 일련번호가 4일 경우에 PLL과 DLL이 동작한다. PLL과 DLL에서 δnR\(f_{Dopp_{R}}\)를 갱신하여 다음 신호추적에 사용한다. 이와 같은 순서로 GPS L1 C/A 신호와 Galileo E1B CBOC(6,1,1/11)를 동시에 수신한다.

4. 실험 및 결과

실험은 기존에 GPS L1 C/A, BDS BI1, GLONASS G1을 지원하는 SDR 수신기 (Park et al. 2014)에 Galileo E1B CBOC(6,1,1/11)을 처리하기 위한 구조를 추가하여 구현한 SDR을 이용하여, 2019년 6월 27일 16시에 충북대학교 E10동 옥상에서 NI USRP-2940R 과 Novatel사의 702-GG 안테나를 이용해 얻은 데이터를 사용했다. 수신기는 GPU로 NAVIDIA GTX TITAN, CPU로 Intel core i7, Visual studio 2013 C++, CUDA (Sanders & Kandrot 2011, Park et al. 2014)를 이용해 구현하였다.

제안한 방법의 실시간 동작을 확인하기 위하여, 버퍼에서 관리하는 1 ms 길이의 신호를 신호추적 알고리즘이 1 ms 이내에 연산 완료하는지를 보았다. Fig. 9는 50 MHz의 표본화 주파수로 설정한 SDR의 환경에서 GPS L1 C/A와 Galileo E1B CBOC(6,1,1/11) 신호를 동시에 추적했을 때 소요되는 시간의 평균값이며, 이는 GPU에서 GPU로 데이터 전달시간과 상관시간을 합한 값이다. 빨간 선은 0.75 ms의 기준선을 나타내며 0.25 ms의 동작시간을 갖는 PLL, DLL의 연산시간은 포함되지 않아 실시간으로 동작하려 면 0.75 ms 이내에 동작해야 한다. 그림에서 최대 16개의 채널을 0.71 ms로 수신할 수 있음을 확인할 수 있다. 즉 최대 16개의 위성을 동시에 추적할 수 있다.

Fig9.png 이미지

Fig. 9. Operation time of the proposed structure.

Fig. 10은 GPS L1 C/A와 Galileo E1B 신호를 동시에 16개 채널을 추적하고 있는 결과다. Fig. 10의 아래는 각 GNSS의 채널번호 를 나타내며 G는 GPS L1 C/A, E는 Galileo E1B를 의미한다. 막대의 위에 숫자는 C/N0를 나타내며 막대의 색은 각 채널의 추적 상태를 나타낸다. 노란색은 신호 획득 후 신호추적을 수행하고 있음을 뜻하고 분홍색은 추적에 성공하여 항법 메시지를 획득하는 중이며, 초록색은 획득한 항법 메시지로 수신기의 위치를 구하는 채널을 나타낸다. Fig. 11은 Fig. 10에서 추적하고 있는 채널의 항법 메시지를 이용해 수신기 위치를 계산한 결과를 보여준다. 노란색 상자로 표기한 부분이 충북대학교 E10동 건물이며, 빨간색 점은 위치해 결과를 나타낸다. 빨간 점은 GNSS 신호를 획득한 충북대학교 E10동 옥상을 표시하는 것을 확인할 수 있으며, 오차결과는 3.96 m (2drms)가 나왔다. 이는 Soderholm et al. (2016)에서 나온 결과와 유사함을 확인할 수 있었다.

Fig10.png 이미지

Fig. 10. Signal tracking state of SDR.

Fig11.png 이미지

Fig. 11. Navigation results of SDR.

5. 결론

본 논문에서는 저가의 GPU를 이용하여 1 ms 주기의 GPS L1 C/A와 4 ms 주기의 갈릴레오 E1B CBOC(6,1,1/11)신호를 효과적으로 수신하는 신호추적 구조를 설계했다. GPU에서 4 ms 주기 의 CBOC 신호를 처리하는데 2 ms의 시간이 소요되어 Galileo만 사용하는 경우 실시간 동작이 가능하지만 GPS C/A와 동시에 사용하는 경우 1 ms의 처리 요구 시간을 만족시키지 못한다. 본 논문에서는 GPS L1 C/A와 Galileo E1B CBOC(6,1,1/11) 신호를 동시에 수신하기 위해 4 ms 주기인 Galileo E1B CBOC(6,1,1/11) 신호를 4개의 1 ms 단위로 나누어 처리하는 기법을 제안하였다. 이를 위하여 1 ms 주기와 4 ms 주기의 신호를 동시에 관리하는 버퍼를 설계했다. 또 1 ms 단위로 구해지는 Galileo E1B신호의 상관값을 4 ms 만큼 누적해 PLL 과 DLL로 넘겨주는 구조를 추가했다. 설계한 신호 추적 구조를 GPU를 사용한 SDR에 적용해 실제 측정치를 이용하여 동작을 확인하였다. 실험 결과는 GPS L1 C/A와 Galileo E1B 신호를 동시에 추적했을 때 16개 이상의 채널을 실시간으로 수신할 수 있음을 보여주었다.

서로 주기가 다른 GPS L1 C/A 신호와 Galileo E1B 신호를 실시간으로 수신할 수 있는 구조를 구현했다. 기존 다른 주기를 갖는 신호를 따로 각 버퍼에 관리하여 신호를 처리하는 구조에서, 버퍼 구조와 상관기 구조를 주기가 서로 다른 신호를 동시에 수신할 수 있는 구조로 설계했다. 버퍼는 1 ms 주기의 GPS L1과 4 ms의 Galileo E1B를 1 ms로 나눈 신호를 동시에 관리해 GPU로 데이터를 전달하는 구조로 수정했다. 상관기 구조는 1 ms로 나눈 Galileo E1B 신호를 4 ms씩 누적하여 PLL, DLL로 상관값을 전 달하는 구조로 변경했다. 또한 다중 스레드 구조를 고려하여 신 호획득에 동작에 걸린 시간을 고려해 신호추적에 사용될 데이터를 선택하는 알고리즘을 구현했다. 제안한 구조를 기존 SRC에 적용해 채널 수 마다 동작시간을 확인했다. 동작결과로 GPS L1, Galileo E1B 신호를 동시에 수신했을 때 최대 16개의 채널을 평균 0.71 ms로 제안한 구조의 실시간동작을 확인했고, 제안한 구조가 정상동작 함을 확인했다. 제안한 구조는 GPS, Galileo E1B 신호 뿐만 아니라 다른 주기를 갖는 GNSS 신호에도 적용 가능해 여러 GNSS 신호를 동시에 실시간으로 수신하는데 적합하다.

ACKNOWLEDGMENTS

This research was a part of the project titled 'Development of Ground-based Centimeter-level Maritime Precise PNT Technologies', funded by the Ministry of Oceans and Fisheries, Korea.

AUTHOR CONTRIBUTIONS

The Manuscript with several authors, a short paragraph specifying their individual contributions must be provided. The following statements should be used “Conceptualization, J.-I.P. and C.P.; Software, J.-I. P.; Validation, J.-I.P.; Formal Analysis, J.-I.P. and C.P.; Investigation, J.-I.P. and C.P.; Resources, J.-I.P. and C.P.; Data Curation, J.-I.P.; Writing—Original Draft Preparation, J.-I.P.; Writing—Review and editing, J.-I.P. and C.P.; Visualization, J.-I.P.; Supervision, C.P.; Project Administration, J.-I.P. and C.P. Funding Acquisition, C.P.”. Authorship must be limited to those who have contributed substantially to the work reported.

CONFLICTS OF INTEREST

The authors declare no conflict of interest.

References

  1. Curran, J. T., Petovello, M., & Lachapelle, G. 2013, Design Paradigms for Multi-Constellation Multi-Frequency Software GNSS Receivers, in China Satellite Navigation Conference (CSNC) 2013 Proceedings, Lecture Notes in Electrical Engineering, vol.243 (Berlin, Heidelberg: Springer), pp.751-765. https://doi.org/10.1007/978-3-642-37398-5_69
  2. GNSS SDR, GNSS-SDR v0.0.11 released [internet], cited 2019 Jul 29, available from: https://gnss-sdr.org/gnsssdr-v0011-released/
  3. Hobiger, T., Gotoh, T., Amagai, J., Koyama, Y., & Kondo, T. 2010, A GPU Based Real-Time GPS Software Receiver, GPS Solut, 14, 207-216. https://doi.org/10.1007/s10291-009-0135-2
  4. Huang, B., Yao, Z., Guo, F., Deng, S., Cui, X., et al. 2013, STARx-A GPU Based Multi-System Full-Band Real-Time GNSS Software Receiver, in ION GNSS+ 2013, Nashville, TN, 16-20 Sep 2013, pp.1549-1559.
  5. Kaplan, E. D. & Hegarty, C. J. 2017, Understanding GPS/GNSS principles and applications, Third edition (Boston: Artech House Inc.)
  6. Korea Aerospace Research Institute (KARI), The 3rd Basic Plan for Space Development Promotion [Internet], cited 2018 Feb 6, available from: https://kari.re.kr/kor/sub04_02_03.do
  7. Novatel, OEM7 Installation and Operation User Manual [Internet], cited 2020 Jun, available from: https://docs.novatel.com/OEM7/Content/PDFs/OEM7_Installation_Operation_ Manual.pdf
  8. Park, J. & Park, C. 2019, Comparison of Galileo E1 signal processing performance with CBOC(6,1,1/11) and BOC(1,1), in KIMST 2019, Jeju, Korea, 13-14 Jun 2019
  9. Park, J. & Park, C. 2020, Implementation of the Method to Increase Number of Galileo E1B Receive Channel for Real-time GNSS SDR using LUT, in KICS 2020, Yongpyong, Korea, 12-14 Aug 2020
  10. Park, K. W. 2019, Multi-constellation GNSS Receiver Based on Cognitive Radio, Ph.D. dissertation, The University of Chungbuk, Cheongju, Korea.
  11. Park, K. W., Suh, J., Seo, B., Lee, M. J., & Park, C. 2016, Design of Signal Acquisition and Tracking Process Based on Multi-Thread for Real-Time GNSS Software Receiver, in ICL-GNSS, Barcelona, Spain, 28-30 Jun 2016
  12. Park, K. W., Yang, J. S., Lee, M. J., & Park, C. 2014, Implementation of GPGPU Based Real-Time Signal Acquisition and Tracking Module for Multi-Constellation GNSS Software Receiver, in ION GNSS+ 2014, Tampa, Florida, 8-12 Sep 2014, pp.1410-1416
  13. Petovello, M. G., O'Driscoll, C., Lachapelle, G., Borio, D., & Murtaza, H. 2008, Architecture and Benefits of an Advanced GNSS Software Receiver, Journal of Global Positioning Systems, 7, 156-168 https://doi.org/10.5081/jgps.7.2.156
  14. Principe, F., Bacci, G., Giannetti, F., & Luise, M. 2011, Software-Defined Radio Technologies for GNSS Receivers: A Tutorial Approach to a Simple Design and Implementation, International Jounal of Navigation and Observation, vol.2011, 27 pages. https://doi.org/10.1155/2011/979815
  15. Sanders, J. & Kandrot, E. 2011, CUDA by Example: An Introduction to General-Purpose GPU Proramming (Boston: Pearson Education Inc.)
  16. Septentrio, AsteRx-I S GNSS/INS positioning and attitude receiver datasheet [Internet], cited 2020 Jan, available from: https://www.septentrio.com/en/products/gnssreceivers/rover-base-receivers/gnss-ins-solutions/asterx
  17. Smith, R. & Garg, R. 2013, NVIDIA's GeForce GTX TITAN Review Part2:Titan's Performance Unveiled [Internet], cited 2013 Feb 21, available from: https://www.anandtech.com/show/6774/nvidias-geforce-gtx-titanpart-2-titans-performance-unveiled
  18. Soderholm, S., Bhuiyan, M. Z. H., Thombre, S., Ruotsalainen, L. & Kuusniemi, H. 2016, A multi-GNSSS softwaredefined receiver: design, implementation, and performance benefits, Annals of Telecommunications, 71, 399-410. https://doi.org/10.1007/s12243-016-0518-7
  19. Teunissen, P. J. G. & Montenbruck, O. 2017, Springer Handbook of Global Navigation Satellite System (Cham, Switzerland: Springer International Publishing)
  20. Tran, T. V. 2017, Dynamically Configurable Architectures for Multi-GNSS Receivers, Ph.D. dissertation, The University of New South Wales, Sydney, Australia.
  21. Ziedan, N. I. 2006, GNSS Receivers for Weak Signals (Boston: Artech House Inc.)