GNSS(전역 탐색 위성 시스템) 드라이버 아키텍처

GNSS(전역 탐색 위성 시스템) UMDF 2.0 드라이버 아키텍처, I/O 고려 사항에 대한 개요를 제공하고 여러 유형의 추적 및 수정 세션에 대해 설명합니다.

아키텍처 개요

다음 상위 수준 구성 요소 블록 다이어그램은 GNSS(전역 탐색 위성 시스템) UMDF 2.0 드라이버가 Windows 10 플랫폼과 통합되는 방법을 보여 줍니다.

다이어그램의 구성 요소는 다음과 같습니다.

• LBS 애플리케이션: Windows 10 플랫폼의 위치 기능을 사용하는 사용자 애플리케이션

• 테스트 애플리케이션: GNSS 기능을 테스트하기 위한 애플리케이션입니다.

• GNSS API: GNSS 디바이스의 기능을 위치 서비스의 내부 구성 요소에 노출하고 애플리케이션을 테스트하는 IGnssAdapter COM(구성 요소 개체 모델) 인터페이스입니다. 이 API의 정확한 모양은 이 문서의 scope 외부에 있습니다. Windows 구성 요소는 IGnssAdapter COM 인터페이스에 대해 프로그래밍하여 GNSS 디바이스를 사용합니다. GNSS API 집합은 위치 플랫폼 구성 요소(예: 위치 서비스 및 위치 테스트 애플리케이션)에 대한 프라이빗 API이며 다른 자사 또는 타사 애플리케이션에서는 사용할 수 없습니다.

• GNSS 어댑터:IGnssAdapter COM 인터페이스를 구현하는 싱글톤 COM 개체입니다. 위치 서비스의 테스트 애플리케이션 및 내부 구성 요소는 이 개체를 인스턴스화하고 IGnssAdapter 인터페이스를 통해 GNSS 디바이스를 사용합니다. 위치 서비스의 GNSS 위치 지정 엔진 구성 요소는 IGnssAdapter 인터페이스를 노출하는 COM 클래스를 구현합니다. 위치 서비스는 위치 서비스 내에서 GNSS 어댑터 COM 클래스의 싱글톤 COM 개체를 인스턴스화하기 위해 테스트하는 팩터리 메커니즘 및 기타 Out-of-process 애플리케이션을 노출합니다. Out-of-process 애플리케이션은 COM 인터페이스 포인터를 사용하여 GNSS 드라이버에 대해 프로그래밍합니다.

  COM은 애플리케이션이 IGnssAdapter 인터페이스 포인터를 in-process COM 개체로 처리하지만 호출이 실제로 위치 서비스 내의 싱글톤 GNSS 어댑터 개체에 의해 처리되도록 외부 프로세스 애플리케이션에 대한 인터페이스 포인터를 처리합니다.

  GNSS 위치 지정 엔진은 위치 서비스에 위치별 기능을 제공하기 위해 내부 GNSS 어댑터 개체를 사용합니다. GNSS 어댑터는 CreateFile API를 사용하여 GNSS 드라이버에 대한 파일 핸들을 연 다음, GNSS 네이티브 API 호출을 적절한 DeviceIoControl 호출로 래핑하고, GNSS 드라이버 개체를 사용하여 상태 머신을 유지 관리하고, 상위 계층에서 들어오는 다양한 요청의 상태를 유지 관리합니다. 이 구성 요소는 이 문서에 정의된 공용 GNSS IOCTL 인터페이스를 통해 기본 GNSS 디바이스 스택과 직접 상호 작용합니다. GNSS 디바이스는 논리적으로 배타적 리소스로 처리되므로 싱글톤 GNSS 어댑터는 GNSS 디바이스에 대한 모든 액세스를 제어합니다.

  특정 화이트 박스 드라이버 테스트 애플리케이션은 GNSS 프라이빗 API를 통해 GNSS 어댑터를 사용하는 대신 비프로덕션 환경에서 직접 GNSS 드라이버 IOCTL 인터페이스를 사용할 수도 있습니다. 그러나 이러한 테스트 애플리케이션은 GNSS 어댑터의 특정 기능을 모방하기 위해 자체 상태 머신 및 처리를 구현해야 합니다.

• GNSS 드라이버: UMDF 2.0을 사용하여 구현된 IHV 제공 드라이버입니다. GNSS 드라이버는 실제 GNSS 하드웨어와 상호 작용하여 GNSS DeviceIoControl API를 지원합니다. GNSS 드라이버는 SUPL 함수의 중재자/통합자로도 작동합니다.

• GNSS 디바이스/엔진: GNSS 디바이스의 SoC 및 하드웨어 부분을 캡슐화하는 개념적 구성 요소입니다. IHV는 이 구성 요소 내에서 대부분의 GNSS 기능을 구현하도록 선택할 수 있으므로 GNSS 드라이버 계층이 매우 얇아집니다(기본적으로 GNSS 디바이스와 상호 작용하기 위한 어댑터).

레거시 Windows 모델을 따르는 GNSS(전역 탐색 위성 시스템) 디바이스 및 드라이버 지원

Windows 10 위치 플랫폼은 레거시 센서 v1.0 클래스 드라이버를 통해 통합되거나(위치 센서 드라이버 작성 참조) thr GNSS 드라이버 참조에 설명된 새로운 GNSS DDI를 통해 통합된 GNSS 디바이스를 지원합니다.

따라서 Windows 7, Windows 8 및 Windows 8.1 있는 Sensor v1.0 클래스 확장 모델과 통합되는 GNSS 디바이스가 있는 Windows 디바이스는 변경할 필요 없이 Windows 10 계속 작동할 것으로 예상됩니다. 사용자의 업그레이드 프로세스를 개선하기 위해 이러한 드라이버(및 새 드라이버)를 Windows 업데이트 게시하는 것이 좋습니다.

또한 Windows 10 발급된 HLK(하드웨어 랩 키트)에서 GNSS 디바이스에 대한 두 가지 테스트 집합이 있습니다.

• 새 모델을 따르는 드라이버를 인증하기 위한 하나의 새로운 테스트 세트입니다.

• 이전 모델을 따르는 드라이버를 인증하는 또 다른 테스트 집합입니다. 이는 Windows 8.1 WHCK에서 사용할 수 있었던 것과 동일한 테스트 집합입니다.

HLK의 새 Gatherer 구성 요소는 시스템에서 실행해야 하는 두 테스트 집합(있는 경우)을 식별합니다.

GNSS(전역 탐색 위성 시스템) 디바이스의 공존

시스템에서 검색된 여러 GNSS 디바이스의 드문 경우, 위치 플랫폼은 주로 시스템의 전체 전력 소비를 줄이기 위해 하나의 디바이스만 사용합니다. 다음과 같은 가정이 고려되었습니다.

• 새 DDI를 사용하는 디바이스는 최신 버전이 될 수 있으므로 전력 소비가 향상되고 별자리를 더 많이 지원하며 더 나은 지원을 지원할 가능성이 높습니다. 따라서 이전 드라이버 모델을 사용하는 디바이스와 새 드라이버 모델을 사용하는 디바이스가 감지되면 후자가 선택됩니다.

• 내부 GNSS 디바이스가 있을 때 사용자가 외부 GNSS 디바이스를 연결하는 경우 사용자가 이 외부 디바이스를 사용하려고 할 가능성이 높습니다.

이러한 가정을 기반으로 하는 위치 플랫폼의 동작은 다음과 같습니다.

• 두 개의 공존 레거시 드라이버의 경우: 호환성 문제를 다시 방지하기 위해 동작은 두 GNSS 디바이스가 동시에 사용되고 응답 중 하나가 애플리케이션에 스택으로 전달되는 Windows 8.1 동작과 동일합니다.

• 디바이스의 레거시 드라이버 1개와 외부에 연결된 새 드라이버 1개의 경우: 외부에 연결된 GNSS 디바이스가 사용됩니다.

• 디바이스의 새 드라이버 1개와 외부에 연결된 새 드라이버 1개의 경우: 외부에 연결된 GNSS 디바이스가 사용됩니다.

선택한 GNSS 디바이스가 지오펜싱 또는 기타 오프로드된 작업을 지원하는 경우 해당 디바이스를 사용하는 동안 오프로드가 수행됩니다. GNSS 어댑터는 여러 GNSS 디바이스 간에 기능 또는 세션을 분할하지 않습니다.

GNSS(전역 탐색 위성 시스템) 인터페이스 개요

GNSS 어댑터와 GNSS 드라이버 간의 상호 작용은 다음 범주에 속합니다.

기능 정보 교환

Windows 플랫폼에서 GNSS 스택의 확장성 및 적응성을 지원하기 위해 GNSS 어댑터와 GNSS 드라이버는 기본 GNSS 스택의 다양한 잘 정의된 기능과 Windows 플랫폼에서 제공하는 지원에 대한 일반적인 이해를 설정합니다. 기능 측면은 이 GNSS 인터페이스 정의의 일부로 Microsoft에서 잘 정의하고 있으며, GNSS 공간에서 더 많은 혁신이 계속되고 다양한 칩셋/드라이버 세트가 시장에 등장함에 따라 진화할 것입니다. GNSS 어댑터는 초기화 시 또는 필요에 따라 기본 GNSS 드라이버/디바이스의 다양한 기능을 쿼리하고 그에 따라 GNSS 드라이버와의 상호 작용을 최적화합니다.

GNSS 어댑터와 GNSS 드라이버 간의 기능 정보 교환은 IOCTL_GNSS_SEND_PLATFORM_CAPABILITY 및 IOCTL_GNSS_GET_DEVICE_CAPABILITY 제어 코드를 사용하여 수행됩니다.

GNSS(전역 탐색 위성 시스템) 드라이버 명령 및 구성

GNSS 어댑터는 GNSS 드라이버의 일회성 구성 또는 주기적인 다시 구성을 수행할 수 있습니다. 마찬가지로 GNSS 어댑터는 드라이버를 통해 특정 GNSS 관련 명령을 실행할 수 있습니다. 이 작업은 드라이버와 HLOS(상위 수준 운영 체제) 간에 명령 실행 프로토콜을 정의하여 수행됩니다. 특정 명령 유형에 따라 의도한 작업이 즉시 또는 시스템을 다시 시작한 후에 적용될 수 있습니다. GNSS 디바이스 기능 정보와 마찬가지로 GNSS 명령은 이 GNSS 인터페이스 정의의 일부로 Microsoft에 의해 잘 정의되며 향후 GNSS 디바이스/드라이버의 혁신과 다각화로 계속 발전할 것입니다.

디바이스 명령 실행 및 구성은 제어 코드 IOCTL_GNSS_SEND_DRIVERCOMMAND 사용하여 수행됩니다.

위치 정보

이는 기본 GNSS 디바이스의 기본 함수입니다. 가장 기본적인 형태로 GNSS 어댑터는 GNSS 드라이버에서 디바이스의 현재 위치를 요청합니다. 위치 요청의 변형에는 다음과 같은 위치 세션 유형이 포함됩니다(제한되지는 않음).

• 디바이스의 현재 위치(단일 샷 수정)

• 지속적인 주기적 수정 스트림(시간 기반 추적)

• 이동 임계값을 기반으로 하는 연속 수정 스트림(거리 기반 추적)

모든 GNSS 하드웨어 및 GNSS 드라이버에 필요한 유일한 필수 위치 세션 유형은 단일 샷 수정 세션 유형입니다. 네이티브(SOC, GNSS 디바이스에서 구현되고 GNSS 드라이버 또는 애플리케이션 프로세서에서 실행되는 서비스에서 구현됨), 시간 기반 추적 세션 및 거리 기반 추적 세션은 필요에 따라 지원될 수 있습니다. 이러한 두 가지 유형의 네이티브 추적 세션에 대한 기본 이점은 SOC에서 더 많은 처리를 수행하고 필요한 경우에만 변경 내용을 보고하여 AP(애플리케이션 프로세서)를 더 오랫동안 휴면 상태로 유지함으로써 잠재적인 절전 모드입니다. 네이티브 거리 기반 추적에 대한 지원은 더 높은 전력 절감 효과를 가져올 수 있고 애플리케이션에서 더 광범위하게 사용되기 때문에 네이티브 시간 기반 추적 세션보다 더 큰 영향을 줍니다.

GNSS 드라이버에서 위치 정보를 검색하는 작업은 다음 작업으로 구성된 상태 저장 고유 수정 세션을 통해 수행됩니다.

1. 수정 세션 시작: GNSS 어댑터는 LBS 애플리케이션의 요청으로 인해 시작 수정 세션을 시작합니다. GNSS 어댑터는 요청과 특정 요구 사항 및 기본 설정 연결을 설정하고 제어 코드 IOCTL_GNSS_START_FIXSESSION 실행하여 엔진을 시작하도록 GNSS 드라이버를 긴밀하게 연결합니다.

2. 디바이스 위치 가져오기(데이터 수정): 수정 세션이 시작되면 GNSS 어댑터는 드라이버에서 수정을 기다리는 IOCTL_GNSS_GET_FIXDATA 제어 코드를 발급합니다. 엔진에서 새 위치 정보를 사용할 수 있는 경우 GNSS 드라이버는 보류 중인 이 가져오기 수정 요청에 응답합니다.

   수정 세션 유형이 LKG 수정(현재 수정이 아닌)인 경우 위치 정보는 드라이버의 캐시에서 가져옵니다.

   GNSS 어댑터는 GNSS 드라이버가 사용 가능한 경우 수정 데이터를 반환하기 위해 항상 비동기 I/O 요청을 사용할 수 있도록 합니다. 수정의 특성에 따라 더 많은 수정 데이터가 예상되는 경우 GNSS 어댑터는 다른 I/O 요청(동일한 IOCTL 사용)을 실행하며 이 시퀀스는 더 이상 데이터를 사용할 수 없거나 수정 세션이 중지될 때까지 계속됩니다.

3. 수정 세션 수정: GNSS 드라이버가 동일한 유형의 수정 세션 멀티플렉싱을 지원하지 않는 경우 GNSS 어댑터는 해당 수준에서 멀티플렉싱을 수행하는 경우 해당 수정 세션 유형에 대한 IOCTL_GNSS_MODIFY_FIXSESSION 실행할 수 있습니다.

4. 세션 수정 중지: 특정 수정 세션과 관련된 추가 위치 정보가 필요하거나 예상되지 않은 경우 GNSS 어댑터는 중지 수정 세션을 실행합니다.

네이티브 지오펜싱 지원

GNSS DDI는 이 사양에 정의된 IOCTL 집합을 사용하여 지오펜스 오프로드 시나리오를 지원합니다. 드라이버가 이 지원을 나타내기 위해 특수 기능 플래그를 정의합니다. 이 플래그는 GNSS 스택이 기본적으로 지오펜싱을 지원하는 경우에만 설정해야 합니다(즉, 애플리케이션 프로세서가 아닌 GNSS 칩에서 지오펜싱을 구현). 드라이버가 기본적으로 지오펜스를 지원하지 않는 경우 플래그를 설정하지 않습니다. HLOS는 AP(최적이 않은 애플리케이션 프로세서) 기반 지오펜스 추적 엔진을 이미 지원합니다. 이 솔루션은 네이티브 솔루션만큼 전원이 최적화되지는 않지만 잘 테스트되고 최적화되므로 AP에서 구현된 동등한 솔루션으로 대체해서는 안 됩니다.

HLOS에서 지오펜스 추적을 수행하려면 애플리케이션 프로세서가 지오펜스 위반을 감지하기 위해 주기적으로 절전 모드를 해제해야 하므로 펜스가 위반되지 않은 경우에도 전력이 소모됩니다. 따라서 이 구현은 최적이 아닐 것으로 간주됩니다.

또한 HLOS는 기본 지오펜스 추적 솔루션에서 받은 오류 알림 시 기본 드라이버가 낮은 신호 조건 또는 기타 일시적인 오류로 인해 지오펜스를 추적할 수 없는 경우 AP 기반 지오펜스 추적을 장애 조치 메커니즘으로 사용합니다. 네이티브 지오펜싱 지원은 지오펜스 추적이 SoC에 완전히 오프로드되고 애플리케이션 프로세서가 지오펜스 관련 이벤트 처리에 대해서만 해제된 경우에만 유용합니다. 하드웨어가 네이티브 지오펜스 추적을 지원하지 않는 경우 GNSS 드라이버는 드라이버 계층에서 구현을 시도해서는 안 됩니다.

또한 GNSS 엔진은 문서화된 IHV 관련 튜닝 매개 변수를 노출하여 전력 소비와 사용자 환경 간의 적절한 균형을 찾아야 합니다. 또한 지원되는 지오펜스의 수는 헤더 파일에 정의된 MIN_GEOFENCES_REQUIRED 값보다 많아야 합니다. MIN_GEOFENCES_REQUIRED 애플리케이션별로 정의됩니다. 한 애플리케이션은 다른 애플리케이션 또는 통신사에서 사용하는 지오펜스 수를 알지 못했습니다.

지오펜싱 오프로드 지원에는 다음 요구 사항이 포함됩니다.

• HLOS는 DDI를 통해 하나 이상의 지오펜스를 만들 수 있어야 하며 드라이버는 추적을 시작하기 위해 하드웨어로 보냅니다.

• HLOS는 DDI를 통해 이전에 만든 지오펜스를 하나 이상 삭제할 수 있어야 하며, 드라이버는 추적을 중지하기 위해 하드웨어로 보냅니다.

• 이상적으로 GNSS 하드웨어는 각 지오펜스에 대한 초기 지오펜스 추적 상태를 이해하고 이 초기 상태의 변경 내용만 보고하는 데 사용해야 합니다. GNSS 하드웨어가 이 기능을 지원하지 않는 경우 지오펜스를 만들 때마다 초기 상태를 HLOS에 보고합니다.

• GNSS 하드웨어는 전원 효율적인 방식으로 디바이스의 현재 위치를 추적하고 디바이스가 추적된 지오펜스를 입력 및/또는 종료할 때마다 AP를 절전 모드에서 해제합니다. GNSS 드라이버는 지오펜스 경고를 HLOS에 전달합니다.

• 낮은 위성 신호 및 기타 일시적인 오류 조건에서 GNSS 엔진은 기존 지오펜스를 안정적으로 추적하지 못할 수 있습니다. GNSS 엔진은 추적 중단을 감지할 수 있어야 하며 GNSS 드라이버는 추적 상태 오류 경고를 HLOS에 전달해야 합니다. HLOS는 GNSS 하드웨어가 지오펜스를 복구하고 다시 추적할 수 있을 때까지 기본 AP 기반 지오펜스 추적으로 전환됩니다.

• GNSS 엔진이 지오펜스를 추적할 수 없음을 나타내는 알림을 제공해야 하는 정확한 조건은 다양하며 구현은 IHV에 따라 다릅니다. 구현에 대한 몇 가지 지침은 다음과 같습니다.

  • GNSS 엔진이 사용자가 이동하지 않고 25미터 이하의 지오펜스 경계가 없다는 확신을 가지고 감지할 수 있는 경우 GNSS 엔진은 추적 오류를 보낼 필요가 없습니다.

  • GNSS 엔진이 사용자가 이동하지 않고 25미터 이하의 지오펜스 경계가 있다는 확신을 가지고 감지할 수 있는 경우 GNSS 엔진은 1분 이내에 추적 오류를 보내야 합니다.

  • GNSS 엔진에서 사용자가 이동하고 있고 100미터 이내의 지오펜스 경계가 있는 경우 GNSS 엔진은 1분 이내에 추적 오류를 보내야 합니다.

  • GNSS 엔진이 사용자가 이동하고 있는지 확인할 수 없고 100미터 이하의 지오펜스 경계가 있는 경우 GNSS 엔진은 1분 이내에 추적 오류를 보내야 합니다.

  • GNSS 엔진에서 사용자가 이동하는 것을 감지한 경우 GNSS 엔진은 예상 이동 속도와 가장 가까운 지오펜스까지의 거리에 비례하여 추적 오류를 한 번에 보내야 합니다. 권장 사항은 [(Distance-to-close-fence-boundary(m) / estimated speed (m/s)) - 15s] 내에서 오류를 보내는 것입니다. GNSS 엔진은 이동 감지 표시기를 사용하여 추적 오류를 보내야 하는 타이밍을 결정할 수 있습니다.

  • GNSS 엔진이 사용자가 이동하는지 여부를 확인할 수 없는 경우 GNSS 엔진은 빠른 이동 속도와 가장 가까운 지오펜스까지의 거리에 비례하여 추적 오류를 시간에 보내야 합니다. [Distance-to-close-fence-boundary(m) / 343(m/s)] 내에서 오류를 보내는 것이 좋습니다.

• GNSS 엔진이 지오펜스 추적 상태 오류를 보고한 기간 동안 HLOS로 전송된 지오펜스 위반 이벤트가 없어야 합니다.

• HLOS는 단일 명령을 통해 이전에 만든 모든 지오펜스를 삭제하여 지오펜스 추적을 다시 설정할 수 있습니다.

• 모바일에서 시작된 지오펜스는 재부팅 또는 드라이버 다시 시작 시 GNSS 하드웨어 또는 드라이버에 유지되지 않습니다. HLOS는 최종 사용자 애플리케이션을 대신하여 지속성을 처리하고 필요에 따라 지오펜스를 생성/삭제합니다.

고유하게 지오펜싱 오프로드를 지원하는 GNSS 어댑터와 GNSS 엔진 간의 상호 작용 측면에서 지오펜스 추적 실패의 경우 GNSS 어댑터는 다음과 같이 수행합니다.

• GNSS 드라이버가 추적 실패를 반환하면 AP 기반 추적을 사용합니다.

• 현재 OS 수준에서 추적 중인 지오펜스의 모든 업데이트(추가/삭제)를 드라이버에 계속 푸시하여 동기화됩니다. 이렇게 하면 GNSS 엔진이 현재 OS에서 추적 중인 지오펜스를 파악하는 데 도움이 되며, 는 새 데이터를 기반으로 결정을 추적/추적할 수 없음을 만들 수 있습니다.

• GNSS 드라이버가 추적 기능에서 SUCCESS를 다시 보내면 AP 기반 추적기에서 결정한 대로 지오펜스 상태 변경을 푸시합니다.

지원 및 도우미 데이터에 대한 드라이버 알림

때때로 GNSS 드라이버는 GNSS 어댑터의 지원 데이터 또는 도우미 작업이 필요할 수 있습니다. 여기에는 다양한 형태의 AGNSS 데이터(시간 주입, 삭제, 초기 거친 위치), 네트워크 시작 사용자 평면 위치 지원을 위한 사용자 동의 팝업 등이 포함됩니다.

• GNSS 어댑터를 사용하지 않고 GNSS 드라이버에서 GNSS 지원 데이터를 가져올 수 있습니다. 그럼에도 불구하고 다음과 같은 몇 가지 이유로 GNSS 어댑터를 사용하여 Microsoft 포지셔닝 서비스를 활용하는 것이 좋습니다.

  • Microsoft 위치 스택은 데이터 연결을 설정하고 로밍 제약 조건, 데이터 기본 설정, 네트워크 자동 모드 통합 등을 준수합니다.

  • Microsoft 포지셔닝 서비스는 서버 간 백 엔드 연결을 통해 IHV와 관련된 주기적인 지원 데이터를 얻고 필요한 모든 디바이스에 제공할 수 있으므로 IHV는 가용성, 확장성 및 응답성 요구 사항을 충족하는 전 세계 프런트 엔드 지원 서비스를 배포할 필요가 없습니다.

• 받은 편지함 애플리케이션에 대한 개인 정보에 대한 사용자 동의는 운영 체제에서 소유합니다. 따라서 네트워크 시작 위치 요청에 대해 사용자에게 알리는 UI 또는 네트워크 시작 위치 요청에 응답하기 위해 사용자의 동의를 요청하는 UI는 Microsoft에서 소유합니다. GNSS 드라이버는 네트워크 시작 위치 요청이 수신될 때 GNSS 어댑터에 알리고 필요한 경우 요청을 이행하기 전에 사용자의 응답을 기본 시간까지 기다립니다.

GNSS 드라이버는 자체적으로 상위 계층에 대한 요청을 시작할 수 없으므로 GNSS 어댑터가 GNSS 드라이버에서 이러한 요청을 사전에 검색하여 항상 보류 중인 IRP를 하나 이상 유지하여 GNSS 드라이버가 보류 중인 요청에 다시 응답할 수 있도록 이러한 유형의 작업을 수행할 수 있습니다. 지원/도우미 날짜 요청이 수신되면 GNSS 어댑터는 데이터를 가져오거나 GNSS 드라이버를 대신하여 특정 작업을 실행한 후 다른 DeviceIoControl 호출을 통해 필요한 정보를 GNSS 드라이버에 삽입합니다.

드라이버의 알림은 공통 이벤트 모델을 통해 처리됩니다. 예를 들어 GNSS 지원의 경우 GNSS 어댑터는 제어 코드 IOCTL_GNSS_LISTEN_AGNSS 사용하여 GNSS 드라이버에서 AGNSS 요청을 받습니다. 그 후 GNSS 어댑터는 AGNSS 지원 데이터를 가져오고 IOCTL_GNSS_INJECT_AGNSS 문제를 해결하여 데이터를 GNSS 드라이버로 푸시합니다.

이 알림 메커니즘은 지오펜스 관련 경고 데이터를 수신하고 업데이트를 상태 데도 사용됩니다. 어댑터는 개별 지오펜스 경고를 수신하고 지오펜스 추적의 전체 상태 변경 내용을 수신하기 위해 IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS제어 코드 IOCTL_GNSS_LISTEN_GEOFENCE_ALERT 사용합니다.

GNSS(전역 탐색 위성 시스템) 드라이버 로깅

진단을 위해 GNSS 드라이버는 아래 또는 ETW에 설명된 Microsoft 규정 로깅 메커니즘(WPP)을 사용하여 오류 및 기타 진단 정보를 기록해야 합니다. 두 메커니즘이 모두 지원되지만 드라이버는 ETW가 아닌 로깅 목적으로 WPP를 사용하는 것이 좋습니다. WPP가 권장되는 이유 중 하나는 드라이버 디버깅에 도움이 될 수 있는 도구의 가용성입니다.

드라이버는 이 규정된 로깅 기술을 통하지 않고 사람이 읽을 수 있거나 다른 방법으로 정보를 기록해서는 안 됩니다. 자세한 내용은 WPP 소프트웨어 추적을 참조하세요.

WPP 소프트웨어 추적을 사용하여 메시지 로깅은 Windows 이벤트 로깅 서비스를 사용하는 것과 비슷합니다. 드라이버는 로그 파일에 메시지 ID 및 서식이 지정되지 않은 이진 데이터를 기록합니다. 그 후처리기는 로그 파일의 정보를 사람이 읽을 수 있는 형식으로 변환합니다. 그러나 WPP 소프트웨어 추적은 이벤트 로깅 서비스에서 지원하는 것보다 더 유능하고 유연한 메시지 형식을 지원합니다. 예를 들어 WPP 소프트웨어 추적은 IP 주소, GUID, 시스템 ID, 타임스탬프 및 기타 유용한 데이터 형식을 기본적으로 지원합니다. 또한 사용자는 애플리케이션과 관련된 사용자 지정 데이터 형식을 추가할 수 있습니다.

통신사 프로토콜 지원

다양한 통신사 위치 지정 프로토콜(SUPL, UPL, CP 등)을 지원하려면 IHV 제공 GNSS 스택(GNSS 드라이버, GNSS 디바이스/엔진)이 필요합니다. 이렇게 하지 않으면 디바이스가 통신사의 동의를 통과하지 못하며 디바이스를 상용화할 수 있는 위치가 크게 제한됩니다.

특정 통신사를 위한 디바이스를 배송하려면 이러한 프로토콜에 대한 지원과 통신사 요구 사항 준수가 필수입니다. 이동 통신 사업자 프로토콜에 대한 지원은 대부분의 비 전화 플랫폼에 필수적이지 않을 수 있습니다. 특히 플랫폼에 MBB(모바일 광대역) 지원이 포함되어 있지 않은 경우.

모든 구현 조각은 IHV 스택에서 추상화되며 Microsoft HLOS 구성 요소는 다음과 무관합니다.

• 프로토콜의 특정 구현 세부 정보(예: 프로토콜 작동 방법, 프로토콜 메시지 해석 등).

• 구현 스택의 모양입니다(예: 구현은 GNSS 디바이스/엔진 또는 GNSS 드라이버 내에 있거나 별도의 HLOS 서비스가 필요한 경우).

• 프로토콜을 구현하기 위해 IHV 소유 GNSS 스택 내의 다양한 부분 간의 상호 작용. 예를 들어 GNSS 드라이버가 특정 SUPL 프로토콜 메시지에 응답하기 위해 Wi-Fi 검사 결과가 필요한 경우 사용자 모드 확장이 개인 IOCTL 호출을 통해 드라이버에 Wi-Fi 검사 결과를 삽입하거나 UMDF 2.0 드라이버의 이 부분을 만들거나 낮은 수준에서 이 상호 작용을 처리하도록 하면 됩니다. Microsoft GNSS HLOS 구성 요소는 IHV GNSS 스택 구성 요소 간의 이러한 상호 작용을 인식하지 못합니다.

요약하자면, IHV 또는 OEM은 SUPL 클라이언트(그리고 시스템이 중국에 배송될 경우 잠재적으로 UPL 클라이언트)를 제공하고 GNSS 드라이버와/내에서 통합해야 합니다. SUPL 클라이언트와 위치 플랫폼의 모든 상호 작용은 GNSS DDI를 통해 수행됩니다.

통신사 프로토콜의 구현을 용이하게 하고 플랫폼별 기술을 사용하여 소프트웨어 개발의 부담을 줄이기 위해 GNSS 어댑터는 IHV GNSS 스택에 특정 기능을 제공합니다. GNSS 드라이버는 HLOS 구성 요소에서 이러한 기능을 수신하기 위한 중개자로 처리됩니다. 예를 들어 GNSS 어댑터는 IHV GNSS 스택의 다른 부분이 아닌 GNSS 드라이버와만 상호 작용합니다. GNSS 드라이버 IOCTL은 GNSS 드라이버와 GNSS 어댑터 간에 이러한 기능의 구문과 의미 체계를 정의합니다. GNSS 드라이버는 통신사 프로토콜을 구현하는 특정 IHV 구성 요소에 대한 라우팅을 담당합니다. 대체로 GNSS 어댑터는 GNSS 드라이버에 다음과 같은 기능을 제공합니다.

1. 구성: 통신사는 OMA 프로토콜 표준에 의해 적용되는 구성 메커니즘을 사용하여 디바이스를 프로비전하고 구성을 변경합니다. 예를 들어 SUPL 표준은 UICC에 따라 SUPL 구성을 수행하거나 OMA-DM 또는 OMA-CP를 통해 얻은 SUPL OMA 구성 프로필 정보를 사용하여 수행해야 합니다.

   구성 목적으로 휴대폰에서 사용할 수 있는 특정 기능(OMA-DM 및 OMA CP)은 Windows 10 때까지 다른 플랫폼에서 사용할 수 없었습니다. Windows 10 모든 플랫폼은 새 GNSS DDI가 사용되는 한 CSP(SUPL 구성 서비스 공급자)를 통해 SUPL 구성을 지원할 수 있습니다. CSP를 통해 주입된 프로비전은 이미지 자체(provxml 또는 다변량)에서 또는 OMA-DM 또는 OMA-CP를 통해 통신사에서 제공될 수 있습니다. SUPL CSP는 SUPL CSP에 정의되어 있습니다.

   Windows 10 구성 데이터를 해석하고 추출하기 위해 CSP(구성 서비스 공급자)를 사용하는 독점 기술, 디바이스 관리를 정의합니다. Microsoft는 OMA 구성을 사용하고 GNSS 어댑터를 통해 GNSS 드라이버에 구성을 푸시하기 위한 CSP를 제공합니다.

   또는 IHV는 휴대폰 관련 CSP(디바이스 관리 기술)를 사용하여 통신사 구성 사양을 사용하는 사용자 모드 구성 요소를 작성할 수도 있습니다. 그러나 이는 IHV에 추가적인 부담이 되며 권장되지 않습니다.

   이중 SIM 디바이스의 경우를 포함하여 시스템에서 하나의 SUPL 구성만 지원됩니다. Microsoft는 UICC 및 UICC 변경에 따라 SUPL을 다시 구성하는 기능을 제공합니다. 이 외에도 디바이스 로밍의 경우 HLOS는 독립 실행형 모드에서 작동하도록 SUPL 클라이언트를 다시 구성합니다. 이 문서에서는 다양한 모바일 작업 프로토콜(SUPL 1.0 및 2.0, v2UPL 등)에 대해 이러한 구성 데이터를 푸시하기 위한 IOCTL을 정의합니다.

2. NI 요청에 대한 사용자 동의 처리: 개인 정보 요구 사항을 충족하기 위해 특정 네트워크 시작 위치 지정 요청에는 사용자 동의가 필요합니다. IHV는 플랫폼 구성 요소에 대한 UI를 작성할 수 없습니다. 따라서 GNSS 어댑터는 GNSS 드라이버를 대신하여 사용자 동의를 위해 UI를 처리합니다. GNSS 드라이버가 UI 팝업을 요청하는 알림 IOCTL과 이러한 요청에 대한 사용자 응답을 전달하는 GNSS 어댑터에 대한 IOCTL은 GNSS 드라이버 IOCTL에 정의되어 있습니다.

완벽하게 작동하는 SUPL 클라이언트를 구현하기 위해 IHV 스택은 OS 플랫폼을 통해 사용 가능한 인터페이스 또는 일반 기능을 사용해야 합니다. 다음은 IHV가 SUPL 클라이언트를 구현하는 데 활용할 수 있는 Windows 10 사용할 수 있는 기능 목록입니다.

이 기능 중 어느 것도 위치 플랫폼 또는 GNSS DDI의 일부가 아니지만 설명 및 GNSS 드라이버 개발자가 OS에서 SUPL 기능을 구현하기 위해 활용할 수 있는 기능을 이해하는 데 도움이 되도록 여기에 포함되어 있습니다.

• SMS 라우터: SMS 라우터를 사용하면 SUPL 클라이언트가 SUPL NI 요청을 전달하는 SIP 푸시 메시지의 WAP 푸시를 구독할 수 있습니다.

• 이러한 연결을 요청하기 위해 SUPL 및 API에 사용할 연결을 구성하는 연결 관리자 기능: 통신사는 전용 연결 또는 기본 인터넷 연결과 다른 연결에서 SUPL 트래픽을 가져야 할 수 있습니다. 이렇게 하려면 다음을 연결 관리자.

  • OEM 또는 통신사가 SUPL 통신을 위해 사용할 연결을 구성하는 데 사용할 수 있는 구성 서비스 공급자입니다.

  • SUPL 연결의 연결 매개 변수를 쿼리하는 SUPL 클라이언트에 대한 API입니다.

  • 이전 단계에서 가져온 매개 변수를 사용하여 SUPL 연결을 설정하는 API입니다.

• 셀룰러 연결 구성: 다른 셀룰러 연결의 매개 변수(예: SUPL 연결에 대한 매개 변수)를 구성하려면 OEM 또는 통신사에서 사용할 수 있는 구성 서비스 공급자가 있습니다. 그런 다음, 이 연결은 연결 관리자 SUPL 용도로 연결할 수 있습니다.

• SUPL 연결이 진행되는 동안 연결을 활성 상태로 유지하도록 요청합니다. 시스템이 연결된 대기 상태인 동안 SUPL 클라이언트는 HSLP와의 연결을 시작해야 할 수 있습니다. 이는 GNSS 디바이스가 Microsoft 기반 위치 지정을 사용하도록 구성되거나 통신사가 NI 요청을 보냈기 때문에 지원 정보를 가져와야 하기 때문일 수 있습니다. 이 경우 SUPL 클라이언트는 HSLP와의 연결을 시작하고 SUPL 세션이 완료될 때까지 연결이 활성 상태인지 확인해야 합니다.

• MBB(모바일 광대역) 모듈과의 상호 작용: Windows 10 HLOS를 통해 셀룰러 측정값을 검색하고 긴급 통화가 발생한 시점 등을 파악할 수 있는 API가 없습니다. MBB와의 모든 상호 작용은 MBB와의 직접 통합(AT 명령 또는 기타 독점 메서드를 통해)을 통해 수행해야 합니다.

제조 테스트

OEM은 제조 시와 고객 지원 지점에서 GNSS 하드웨어 및 GNSS 스택(GNSS 드라이버 및 GNSS 디바이스/엔진)이 올바르게 작동하고 있는지 확인하는 방법이 있어야 합니다. IHV는 OEM이 이 테스트를 수행할 수 있도록 독점 메커니즘을 제공하거나 필요에 따라 DDI에서 인터페이스를 구현하여 OEM이 제조 테스트를 시작하고 결과를 얻을 수 있도록 할 수 있습니다.

테스트의 큰 초점은 하드웨어 유효성 검사 또는 드라이버 유효성 검사에 있다는 점을 감안할 때 제조 테스트를 수행할 때 위치 프레임워크는 무시됩니다. 일반적으로 디바이스는 최소 구성 요소 및 서비스 집합이 로드되는 특별한 "안전한 운영 체제 모드"에 있습니다. 이 모드에서 OEM은 테스트 사례를 트리거하는 테스트 애플리케이션 집합을 시작할 수 있습니다. 제조 중 효율성과 속도를 위해 다양한 구성 요소 내의 테스트에 대한 동시성 지원이 매우 바람직합니다.

제조 테스트용 인터페이스에는 다음 두 가지 유형의 테스트가 포함됩니다.

1. 캐리어 웨이브 테스트: 이 테스트는 외부 연결/안테나 테스트의 유효성을 검사하는 것입니다. 이 테스트에서 GNSS 엔진은 CW 신호를 검색하고 응답에서 SNR(노이즈 배급에 신호 또는 노이즈 배급에 대한 캐리어) 측정값을 제공해야 합니다. 이상적으로 테스트는 응답을 10Hz로 다시 제공해야 합니다.

2. 자체 테스트: 이 테스트는 GNSS 엔진의 기본 기능의 유효성을 검사하기 위한 것입니다. 자체 테스트는 외부 신호를 주입하지 않고도 엔진의 기본 문제(결함이 있는 하드웨어, GNSS 하드웨어의 잘못된 연결)를 검색할 수 있어야 합니다. 이 유효성 검사의 목표는 디바이스가 더 철저하고 비용이 많이 드는 테스트를 거치기 전에 이 저렴한 테스트를 수행하고 프로덕션 라인에서 게이트로 사용하는 것입니다. 이 테스트에서 GNSS 엔진 및 드라이버는 핀 연결에 대해 자체 유효성 검사를 수행하고 모든 것이 정상이거나 오류가 발생했음을 나타내는 상태 코드를 반환해야 합니다. 오류에 대한 오류 코드는 감지된 오류를 나타내야 합니다. 오류 코드는 IHV에 의해 설정됩니다.

I/O 고려 사항

GNSS 기능은 디바이스 드라이버에 대한 기존 파일 읽기 및 쓰기 요청에 매핑되지 않으므로 ReadFile 및 WriteFile 함수는 GNSS 드라이버 API에 사용되지 않습니다. 모든 GNSS 기능은 IOCTL이라고도 하는 잘 정의된 GNSS 특정 디바이스 I/O 컨트롤(DeviceIoControl) 요청을 사용하여 구현됩니다.

모든 IOCTL은 입력 및 출력 데이터 모두에 대한 데이터 전송 메커니즘으로 METHOD_BUFFERED 사용합니다. GNSS 관련 데이터의 크기가 상대적으로 작기 때문에 추가 버퍼 복사는 시스템 성능에 영향을 주지 않아야 합니다.

CreateFile 함수의 FILE_FLAG_OVERLAPPED 옵션을 사용하여 GNSS 드라이버가 열립니다. 따라서 모든 IOCTL은 암시적으로 비동기적입니다. 그러나 대부분의 GNSS IOCTL은 의미상 비동기적이지만(예: IOCTL이 드라이버 내에서 활동을 트리거하고 결과가 비동기적으로 다시 예상됨) 일부 IOCTL은 이러한 IOCTL과 관련된 논리적 비동기 작업이나 활동이 없다는 점에서 의미상 동기적입니다. 이러한 몇 가지 IOCTL의 동기 동작은 I/O 작업이 완료될 때까지 DeviceIoControl 호출을 실행한 후 GNSS 어댑터 스레드를 차단하여 수행됩니다. 따라서 모든 IOCTL 처리의 일부로 항상 IRP를 완료하는 것은 GNSS 드라이버의 책임입니다. GNSS 어댑터는 동기 호출 계약을 적용해야 하며 오류가 발생할 경우 이러한 명령을 다시 시도하거나 다시 시도하지 않을 수 있습니다. IHV 드라이버는 오류를 반환하기 전에 드라이버 쪽의 모든 논리를 통합했는지 확인해야 합니다.

요청 및 응답 작업의 경우 GNSS 어댑터는 항상 보류 중인 I/O 작업을 사용할 수 있도록 유지하므로 GNSS 드라이버에 이전에 호출된 작업에 대한 응답으로 보낼 데이터가 있는 경우 보류 중인 IRP를 통해 응답을 보낼 수 있습니다.

단일 샷 세션

드라이버에 대한 단일 샷 수정에 대한 시작 수정 요청에는 정확도 및 응답 시간 값이 포함됩니다. GNSS 엔진은 이러한 값을 사용하여 애플리케이션 요청의 의도를 이해하고 지능적인 결정을 내릴 수 있습니다. 드라이버에서 요청을 받으면 엔진에서 생성된 중간 수정 사항을 반환하기 시작해야 합니다. 중간 수정 사항은 정확도 요구 사항을 충족하거나 최종 수정 사항을 계산하는 동안 엔진에서 생성된 수정 사항입니다. 이러한 중간 수정의 빈도는 적용되지 않으며 엔진의 구현 세부 정보입니다. GNSS 어댑터는 몇 초마다 수정 사항이 올 것으로 예상하며 마지막 중간 수정과 달라야 합니다.

GNSS 엔진이 현재 신호 조건에서 더 나은 수정을 얻을 수 없다고 결정하면 최종 수정 사항을 반환하고 추가 계산을 중지해야 합니다. 최종 수정은 정확도 요구 사항을 충족하거나 엔진이 현재 조건에서 제공된 정확도를 향상시킬 수 없다는 것을 나타냅니다.

GNSS 어댑터는 다음 두 경우 중 하나에서 단일 샷 세션에 대한 중지 수정을 발급합니다.

• 드라이버에서 최종 수정 사항을 가져옵니다.

• 요청에 대한 응답 시간에 도달했습니다. 여기서 마지막 중간 수정 사항이 애플리케이션에 전송됩니다.

다음 그림에서는 두 개의 단일 샷 세션을 보여 줍니다.

세션 1: 드라이버에 정확도 및 응답 시간 매개 변수가 주어졌습니다. start fix 명령 후에 드라이버가 중간 수정 사항을 보내기 시작했습니다. 잠시 후 더 정확한 수정 사항을 반환할 수 없다고 판단하여 마지막 수정 사항을 최종 수정으로 표시했습니다. 응답 시간 제한에 도달하기 전에 이 문제가 발생했습니다. 어댑터는 최종 수정 사항을 애플리케이션에 보내고 중지 수정 명령을 실행했습니다.

세션 2: 위의 세션 1과 동일하지만 이 경우 엔진은 정확도 요구 사항을 충족하기 위해 더 나은 수정을 계속 진행했으며 그 사이에 중간 수정 사항을 계속 보냈습니다. 세션 응답 시간 제한에 도달하면 어댑터는 드라이버에서 이 세션을 닫아야 하는 중지 수정을 실행했습니다. 받은 마지막 중간 수정 사항이 애플리케이션에 전송되었습니다.

단일 샷 지원을 구현할 때 고려해야 할 중요한 디자인 측면 중 하나는 거리 기반 추적 세션과 시간 기반 추적 세션이 모두 지원되지 않는 경우 GNSS 엔진은 중지 수정 명령을 받은 후 3~5초 동안 위성을 계속 추적해야 한다는 것입니다. 이는 GNSS 어댑터가 단일 샷 수정 세션을 사용하여 시뮬레이션된 거리 기반 추적 세션 및/또는 시간 기반 추적 세션을 구현해야 하고, GNSS 엔진이 위성 추적을 즉시 중지하는 경우 대부분의 GNSS 디바이스는 획득이 지연되어 탐색 요구 사항을 충족하는 시뮬레이션된 추적 세션을 구현하는 것이 불가능하기 때문입니다. 추적 또는 매핑 애플리케이션을 실행합니다.

시스템이 활성 상태일 때뿐만 아니라 시스템이 연결된 대기 상태인 동안 GNSS 어댑터는 단일 샷 수정에 대한 요청을 시작할 수 있습니다. 이는 애플리케이션 프로세서 또는 기타 사례에서 백그라운드 작업, 시스템 서비스, 지오펜스 추적의 필요성을 충족하기 위해 발생할 수 있습니다. GNSS 드라이버는 이러한 세션 요청을 GNSS 디바이스에 전달하고 요청을 충족하거나 GNSS 어댑터에 오류를 제공할 수 있어야 합니다.

다음 시퀀스 다이어그램은 독립 실행형 GNSS 수정 가져오기와 관련된 상위 수준 작업을 보여 줍니다. 여기에는 지원 데이터 요청이 포함되지 않습니다.

시퀀스 설명은 다음과 같습니다.

1. GNSS 어댑터는 CreateFile API를 사용하여 GNSS 드라이버를 엽니다. WDF/KMDF/UMDF는 GNSS 드라이버에 필요한 선택적 콜백을 만듭니다. 반환된 파일 핸들은 모든 후속 작업에 사용됩니다.

2. GNSS 어댑터는 IOCTL을 실행하여 다양한 플랫폼 기능을 드라이버에 전달합니다. GNSS 드라이버는 I/O 작업을 완료합니다.

3. GNSS 어댑터는 디바이스 기능을 가져오기 위해 IOCTL을 발급합니다. GNSS 드라이버는 디바이스 기능을 반환하고 I/O 작업을 완료합니다.

4. GNSS 어댑터는 드라이버별 구성 또는 명령에 대해 IOCTL을 발급합니다. GNSS 드라이버는 필요한 작업을 수행하고 I/O 작업을 완료합니다.

5. GNSS 어댑터는 수정의 형식 및 기타 측면을 지정하는 매개 변수와 함께 IOCTL_GNSS_START_FIXSESSION 발급합니다. 이 IOCTL을 받으면 GNSS 드라이버는 기본 디바이스와 상호 작용하여 수정 사항을 받기 시작하고 I/O 작업을 완료합니다.

6. GNSS 어댑터는 IOCTL_GNSS_GET_FIXDATA 발급하고 I/O 완료를 기다립니다. GNSS 드라이버에 사용 가능한 중간 수정 사항이 있을 때마다 I/O 작업을 완료하여 데이터를 반환합니다.

7. 6단계는 GNSS 드라이버가 더 이상 수정이 필요하지 않음을 나타내기 전까지 반복됩니다(최종 수정이 수신됨).

8. GNSS 어댑터 문제가 IOCTL_GNSS_STOP_FIXSESSION. GNSS 드라이버는 원래 수정 요청과 관련된 필요한 정리 작업을 수행합니다.

9. GNSS 어댑터는 CloseHandle API를 사용하여 드라이버 파일 핸들을 닫습니다.

GNSS IOCTL 및 관련 데이터 구조는 GNSS 드라이버 참조에 자세히 설명되어 있습니다.

거리 기반 추적 세션

거리 기반 추적 세션은 최종 사용자 애플리케이션에서 자주 사용되며, 지금까지 .NET API에서 사용할 수 있는 유일한 세션 유형이었습니다. 거리 값이 0이면 GNSS 엔진이 가능한 가장 높은 속도로 수정 사항을 제공해야 합니다.

GNSS 어댑터는 후자가 SupportDistanceTracking 기능이 있음을 나타내는 경우에만 GNSS 드라이버로 거리 추적 세션을 시작합니다.

거리 추적 세션에 대한 드라이버에 대한 시작 수정 요청에는 원하는 수평 정확도와 이동 임계값이 포함됩니다. 이 임계값은 GNSS 드라이버가 위치 업데이트를 제공하기 전에 시스템이 커버해야 하는 미터의 하버사인 거리입니다. GNSS 엔진은 이러한 값을 사용하여 애플리케이션 요청의 의도를 이해하고 위치가 검사 빈도를 조정하는 등 지능적인 결정을 내릴 수 있습니다.

드라이버에서 시작 수정 요청을 받으면 최종 수정을 얻을 때까지 엔진에서 생성된 중간 수정 사항을 반환하기 시작해야 합니다. 세션의 첫 번째 위치로 간주됩니다. 이 후 GNSS 엔진은 하버신 거리가 대략적으로 적용되었음을 감지할 때마다 수정 사항을 제공하기 시작합니다.

GNSS 엔진이 디바이스의 위치를 더 이상 추적할 수 없다고 판단하는 경우(예: 위성이 더 이상 표시되지 않는 경우) 위치 플랫폼이 다른 메커니즘으로 대체되어 최종 사용자 애플리케이션에 위치 업데이트를 제공할 수 있도록 GNSS 어댑터에 오류를 반환해야 합니다. GNSS 어댑터는 다음 시간 내에 오류를 제공해야 합니다.

[(Distance-remaining-since-last-known-position (m) / estimated speed (m/s)) – 5 초] 또는 5 초 중 가장 큰 값입니다.

GNSS 엔진이 GNSS 어댑터에 오류를 제공했지만 GNSS 어댑터가 아직 추적 세션을 중지하지 않은 경우 추적 위치를 다시 시작할 수 있는 경우 전원 최적화 방식으로 GNSS 엔진이 계속 검사 합니다. IHV는 최적화를 사용하여 저전력에서 이 검색을 수행할 수 있습니다. 최적화를 위한 일반적인 기술은 다음과 같습니다.

• 프로그레시브 백오프

• 다시 검사할 디바이스 이동을 나타내는 저렴한 신호 대기

• 위성 신호에 대한 저전력 검사

GNSS 엔진이 오류 조건 후에 최종 수정을 다시 제공할 수 있게 되면 추적이 성공적으로 재개되었음을 나타내기 위해 해당 위치를 GNSS 어댑터로 보내야 합니다.

추적 세션을 요청한 하나 이상의 애플리케이션이 요청을 취소했거나 새 애플리케이션이 거리 기반 추적 세션을 요청하는 경우 GNSS 어댑터는 거리 기반 추적 세션에 대한 수정 수정 명령을 실행합니다. 이러한 경우 GNSS 어댑터는 다른 활성 세션을 멀티플렉싱하는 데 필요한 새 집계된 세션 매개 변수를 계산하고 이러한 매개 변수로 GNSS 드라이버를 업데이트합니다.

다음과 같은 경우 GNSS 어댑터는 거리 기반 추적 세션에 대한 중지 수정 명령을 실행합니다.

• 추적 세션은 시스템에서 사용할 수 있는 다른 위치 지정 엔진에 전달되었습니다.

• 추적 세션을 요청한 애플리케이션이 요청을 취소했습니다.

다음 그림에서는 두 개의 거리 기반 추적 세션을 보여 줍니다.

세션 1: 추적 세션을 시작할 때 GNSS 드라이버에 정확도 및 이동 임계값 매개 변수가 주어졌습니다. 시작 수정 명령 후에 드라이버는 최종 수정 또는 정확도 요구 사항을 충족하는 수정 사항을 얻을 때까지 중간 수정을 보내기 시작합니다. 이때 이러한 수정 사항이 GNSS 어댑터에 제공되고 GNSS 엔진이 거리 추적 프로세스를 시작합니다. 세션이 활성화된 동안 GNSS 어댑터는 T1 및 T2 시간에 세션 매개 변수를 수정하라는 요청을 보냅니다. 매개 변수를 수정할 때마다 GNSS 드라이버는 GNSS 어댑터에 수정 업데이트를 보내고 GNSS 어댑터가 중지 수정 명령을 보낼 때까지 새 매개 변수를 사용하여 거리 추적 세션을 다시 시작합니다.

세션 2: 세션 시작 프로세스는 위의 세션 1과 유사하지만 지정된 시점에서 GNSS 엔진이 위치를 추적할 수 없습니다. 거리 및 예상 이동 속도에 따라 달라지는 시간이 지나면 GNSS 드라이버가 오류를 보냅니다. GNSS 엔진은 복구할 수 있을 때 저전력으로 계속 검사, 복구할 때 새 수정 사항을 전송하여 GNSS 어댑터에 이를 나타냅니다. 세션은 GNSS 어댑터가 중지 수정 명령을 보낼 때까지 필요에 따라 새 수정 사항으로 업데이트됩니다.

시스템이 활성 상태일 때뿐만 아니라 시스템이 연결된 대기 상태인 동안 GNSS 어댑터는 활성 상태를 유지하거나 거리 기반 추적 세션을 시작할 수도 있습니다. 이는 애플리케이션 프로세서 또는 기타 사례에서 백그라운드 작업, 시스템 서비스, 지오펜스 추적의 필요성을 충족하는 데 발생할 수 있습니다. GNSS 드라이버는 이러한 세션 요청을 GNSS 디바이스에 전달하고 요청을 충족하거나 GNSS 어댑터에 오류를 제공할 수 있습니다.

시간 기반 추적 세션

시간 기반 추적 세션은 사용자 인터페이스(예: 맵, 탐색 애플리케이션 등)를 새로 고치기 위해 빈번하고 일반적인 위치 업데이트가 필요한 애플리케이션에서 사용할 수 있습니다.

GNSS 어댑터는 나중에 SupportContinuousTracking 기능이 있음을 나타내는 경우에만 GNSS 드라이버로 시간 기반 추적 세션을 시작합니다.

시간 기반 추적 세션에 대한 드라이버에 대한 시작 수정 요청에는 원하는 수평 정확도와 GNSS 드라이버가 위치 업데이트를 제공해야 하는 기본 설정 시간 간격이 포함됩니다. GNSS 엔진은 이러한 값을 사용하여 애플리케이션 요청의 의도를 이해하고 위치를 검사 빈도를 조정하고 간격 몇 초 전에 위성 획득을 시작하여 위치 업데이트를 적시에 제공하는 등 지능적인 결정을 내릴 수 있습니다.

드라이버에서 시작 수정 요청을 받으면 최종 수정을 얻을 때까지 엔진에서 생성된 중간 수정 사항을 반환하기 시작해야 합니다. 이 위치는 세션의 첫 번째 위치로 간주됩니다. 이후 GNSS 엔진은 세션 매개 변수에 필요한 간격으로 수정 사항을 제공하기 시작합니다. GNSS 엔진이 애플리케이션에 필요한 빈도로 위치를 제공할 수 없는 경우 가능한 최대 속도로 수정을 제공해야 합니다.

GNSS 엔진이 디바이스의 위치를 더 이상 추적할 수 없다고 판단하는 경우(예: 위성이 더 이상 표시되지 않는 경우) 위치 플랫폼이 다른 메커니즘으로 대체되어 최종 사용자 애플리케이션에 위치 업데이트를 제공할 수 있도록 GNSS 어댑터에 오류를 반환해야 합니다.

GNSS 엔진이 GNSS 어댑터에 오류를 제공했지만 GNSS 어댑터가 아직 추적 세션을 중지하지 않은 경우 추적 위치를 다시 시작할 수 있는 경우 전원 최적화 방식으로 GNSS 엔진이 계속 검사 합니다.

IHV는 이전 섹션에서 설명한 대로 최적화를 사용하여 저전력에서 이 검색을 수행할 수 있습니다. GNSS 엔진이 오류 조건 후에 최종 수정을 다시 제공할 수 있게 되면 추적이 성공적으로 재개되었음을 나타내기 위해 해당 위치를 GNSS 어댑터로 보내야 합니다.

추적 세션을 요청한 하나 이상의 애플리케이션이 요청을 취소했거나 새 애플리케이션이 시간 기반 추적 세션을 요청하는 경우 GNSS 어댑터는 시간 기반 추적 세션에 대한 수정 수정 명령을 실행합니다. 이러한 경우 GNSS 어댑터는 다른 활성 세션을 멀티플렉싱하는 데 필요한 새 집계된 세션 매개 변수를 계산하고 이러한 매개 변수로 GNSS 드라이버를 업데이트합니다.

GNSS 어댑터는 다음과 같은 경우 시간 기반 추적 세션에 대한 중지 수정 명령을 실행합니다.

• 추적 세션은 시스템에서 사용할 수 있는 다른 위치 지정 엔진에 전달되었습니다.

• 추적 세션을 요청한 애플리케이션이 요청을 취소했습니다.

다음 그림에서는 두 개의 시간 기반 추적 세션을 보여 줍니다.

세션 1: 추적 세션을 시작할 때 GNSS 드라이버에 정확도 및 기본 설정 간격 매개 변수가 주어졌습니다. start fix 명령 후에는 드라이버가 최종 수정 또는 정확도 요구 사항을 충족하는 수정 사항을 얻을 때까지 중간 수정을 보내기 시작합니다. 이때 이러한 수정 사항이 GNSS 어댑터에 제공되고 GNSS 엔진이 시간 기반 추적 프로세스를 시작합니다. 세션이 활성화된 동안 GNSS 어댑터는 T1 및 T2 시간에 세션 매개 변수를 수정하라는 요청을 보냅니다. 매개 변수를 수정할 때마다 GNSS 드라이버는 GNSS 어댑터에 수정 업데이트를 보내고 GNSS 어댑터가 중지 수정 명령을 보낼 때까지 새 매개 변수를 사용하여 시간 기반 추적 세션을 다시 시작합니다.

세션 2: 세션 시작 프로세스는 위의 세션 1과 비슷하지만 지정된 시점에서 GNSS 엔진이 위치를 추적할 수 없게 됩니다. GNSS 엔진이 세션 매개 변수에 필요한 간격의 15초 이내에 수정 사항을 제공할 수 없는 경우 GNSS 드라이버는 오류를 보냅니다. GNSS 엔진은 복구할 수 있을 때 저전력으로 계속 검사, 복구할 때 새 수정 사항을 전송하여 GNSS 어댑터에 이를 나타냅니다. 세션은 GNSS 어댑터가 중지 수정 명령을 보낼 때까지 필요에 따라 새 수정 사항으로 업데이트됩니다.

시스템이 활성 상태일 때뿐만 아니라 시스템이 연결된 대기 상태인 동안 GNSS 어댑터는 활성 상태를 유지하거나 시간 기반 추적 세션을 시작할 수도 있습니다. 이는 백그라운드 작업, 시스템 서비스, 애플리케이션 프로세서의 지오펜스 추적 또는 기타 사례의 필요성을 충족할 수 있습니다. GNSS 드라이버는 이러한 세션 요청을 GNSS 디바이스에 전달하고 요청을 충족하거나 GNSS 어댑터에 오류를 제공할 수 있습니다.

다양한 유형의 수정 세션을 동시에 처리합니다.

일부 고급 GNSS 엔진은 Distance-Based 및/또는 Time-Based 추적 세션을 사용하여 단일 샷 세션을 동시에 처리할 수 있습니다. 이상적으로 독립적인 세션은 서로 영향을 미치지 않아야 하지만, 특히 동시 단일 샷 및 시간 기반 추적 세션의 경우 항상 가능하지는 않을 수 있습니다. 이 섹션에서는 다양한 형식의 동시 세션을 처리하기 위해 손상이 필요한 경우 IHV 구현에 대한 몇 가지 지침을 제공합니다.

이 섹션에서는 다음 약어를 사용합니다.

• Ss: 단일 샷 세션

• Dbt: 거리 기반 추적 세션

• TBT: 시간 기반 추적 세션

• TBF: 수정 간 시간

다음 표에서는 단일 샷 및 시간 기반 추적 세션을 동시에 처리하기 위한 몇 가지 시나리오를 제공합니다.

시간 기반 및 거리 기반 추적 세션이 동시에 있는 경우 GNSS 엔진 정확도 추적을 둘 중 가장 작은 값으로 작동하도록 설정할 수 있습니다. 다음 표에서는 동시 단일 샷 및 추적 세션이 있을 때 필요한 정확도에 대해 서로 다른 값의 경우 몇 가지 지침을 제공합니다.