Архитектура драйвера глобальной навигационной спутниковой системы (GNSS)

Общие сведения об архитектуре драйвера UMDF 2.0 глобальной навигационной спутниковой системы (GNSS), рекомендации по вводу-выводу и рассматриваются несколько типов сеансов отслеживания и исправления.

Обзор архитектуры

На следующей высокоуровневой блок-схеме компонентов показано, как драйвер UMDF 2.0 глобальной навигационной спутниковой системы (GNSS) интегрируется с платформой Windows 10.

Компоненты на схеме описаны здесь:

• Приложение LBS: Пользовательское приложение, использующее функции расположения платформы Windows 10

• Тестирование приложения. Приложение для тестирования функциональных возможностей GNSS.

• API GNSS: Интерфейс COM (компонентная объектная модель) IGnssAdapter , который предоставляет функциональные возможности устройства GNSS для внутренних компонентов службы определения местоположения, а также для тестирования приложений. Точная форма этого API находится за пределами область этого документа. Компоненты Windows используют устройство GNSS путем программирования на основе COM-интерфейса IGnssAdapter . Набор API GNSS — это частный API, который предназначен только для компонентов платформы расположения (например, для службы определения местоположения и приложений для тестирования расположения) и недоступен для других приложений сторонних разработчиков или сторонних приложений.

• Адаптер GNSS: Это одноэлементный COM-объект, реализующий com-интерфейс IGnssAdapter . Тестовые приложения и внутренние компоненты службы определения местоположения создают экземпляр этого объекта и используют устройство GNSS через интерфейс IGnssAdapter . Компонент подсистемы позиционирования GNSS службы определения местоположения реализует класс COM, который предоставляет интерфейс IGnssAdapter . Служба расположения предоставляет фабричный механизм для тестирования и других внепроцессных приложений для создания экземпляра одноэлементного COM-объекта адаптера GNSS COM-класса в службе определения местоположения. Внепроцессные приложения используют указатель com-интерфейса для программирования на драйвер GNSS.

  COM обрабатывает указатель интерфейса прокси на внепроцессные приложения, чтобы приложения обрабатывали указатель интерфейса IGnssAdapter как внутрипроцессный COM-объект, но вызовы фактически обрабатываются одноэлементным объектом адаптера GNSS в службе определения местоположения.

  Подсистема позиционирования GNSS использует внутренний объект адаптера GNSS для предоставления службе определения местоположения функциональных возможностей, относящихся к конкретному расположению. Адаптер GNSS открывает дескриптор файла для драйвера GNSS с помощью API CreateFile , а затем заключает вызовы собственных API GNSS в соответствующие вызовы DeviceIoControl , обслуживает конечный автомат с объектом драйвера GNSS и поддерживает состояние различных входящих запросов из верхних слоев. Этот компонент взаимодействует непосредственно с базовым стеком устройств GNSS через общедоступный интерфейс GNSS IOCTL, определенный в этом документе. Устройство GNSS логически рассматривается как эксклюзивный ресурс, и поэтому единый адаптер GNSS управляет всем доступом к устройству GNSS.

  Некоторые тестовые приложения драйвера белого ящика также могут использовать интерфейс IOCTL драйвера GNSS непосредственно в непроизводственной среде вместо использования адаптера GNSS через частные API GNSS. Однако эти тестовые приложения должны будут реализовать собственный конечный автомат и обработку для имитации определенных функций адаптера GNSS.

• Драйвер GNSS: Драйвер, предоставляемый IHV, реализован с помощью UMDF 2.0. Драйвер GNSS поддерживает API-интерфейсы GNSS DeviceIoControl , взаимодействуя с фактическим оборудованием GNSS. Драйвер GNSS также работает в качестве медиатора или интегратора для функций SUPL.

• Устройство или обработчик GNSS: Это концептуальный компонент, который инкапсулирует SoC и аппаратные компоненты устройства GNSS. IHV может реализовать большую часть функций GNSS в этом компоненте, что делает уровень драйвера GNSS очень тонким (по сути, адаптером для взаимодействия с устройством GNSS).

Поддержка устройств и драйверов глобальной навигационной спутниковой системы (GNSS), которые соответствуют устаревшей модели Windows

Платформа определения местоположения в Windows 10 поддерживает устройства GNSS, интегрированные с помощью устаревшего драйвера класса Sensors версии 1.0 (см. статью Написание драйвера датчика местоположения) или интегрированные с помощью нового DDI GNSS, описанного в справочнике по драйверам GNSS.

Поэтому устройства Windows с устройством GNSS, которые интегрируются с моделью расширения класса Sensor версии 1.0, которая существовала в Windows 7, Windows 8 и Windows 8.1, должны продолжать работать в Windows 10 без каких-либо изменений. Настоятельно рекомендуется, чтобы эти драйверы (и любые новые драйверы) были опубликованы в клиентский компонент Центра обновления Windows, чтобы улучшить процесс обновления для наших пользователей.

В комплекте аппаратной лаборатории (HLK), выпущенном с Windows 10, также будут два разных набора тестов для устройств GNSS:

• Один новый набор тестов для сертификации драйверов в соответствии с новой моделью.

• Еще один набор тестов для сертификации драйверов в соответствии со старой моделью. Это будет тот же набор тестов, который был доступен в WHCK в Windows 8.1.

Новый компонент средства сбора данных в HLK определяет, какой из двух наборов тестов должен выполняться в системе, если таковой имеется.

Сосуществование устройств глобальной навигационной спутниковой системы (GNSS)

В редких случаях, когда в системе обнаружено несколько устройств GNSS, платформа определения местоположения будет использовать только одно устройство, главным образом для снижения общего энергопотребления в системе. Были рассмотрены следующие предположения:

• Устройства, использующие новый DDI, скорее всего, будут более новыми, и, следовательно, с большей вероятностью будут иметь лучшее энергопотребление, поддерживать больше созвездий и более эффективную помощь. Поэтому при обнаружении устройства, использующий старую модель драйвера, и устройства, использующий новую модель драйвера, будет выбрано последнее.

• Если пользователь подключает внешнее устройство GNSS при наличии внутреннего устройства GNSS, скорее всего, пользователь хочет использовать это внешнее устройство.

Поведение платформы расположения на основе этих предположений будет следующим:

• Если существуют два сосуществующих устаревших драйвера. Чтобы избежать проблем с обратной совместимостью, поведение будет таким же, как и в Windows 8.1, в котором оба устройства GNSS используются одновременно, а один из ответов передается в стек приложениям.

• Случай одного устаревшего драйвера на устройстве и одного нового драйвера с внешним подключением: используется устройство GNSS с внешним подключением.

• Случай одного нового драйвера на устройстве и одного нового драйвера с внешним подключением. Используется устройство GNSS с внешним подключением.

Если выбранное устройство GNSS поддерживает геозону или другие операции разгрузки, разгрузка будет выполнена во время использования этого устройства. Адаптер GNSS не разделяет функции или сеансы между несколькими устройствами GNSS.

Общие сведения об интерфейсе глобальной навигационной спутниковой системы (GNSS)

Взаимодействие между адаптером GNSS и драйвером GNSS относится к следующим категориям:

Обмен информацией о возможностях

Для поддержки расширяемости и адаптируемости стека GNSS на платформах Windows адаптер GNSS и драйвер GNSS позволяют получить общее представление о различных четко определенных возможностях базового стека GNSS, а также о поддержке, предоставляемой платформой Windows. Аспекты возможностей хорошо определены корпорацией Майкрософт в рамках этого определения интерфейса GNSS и будут развиваться по мере того, как новые инновации в пространстве 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 и будут продолжать развиваться с будущими инновациями и диверсификацией устройств и драйверов GNSS.

Выполнение и настройка команды устройства выполняется с помощью кода элемента управления IOCTL_GNSS_SEND_DRIVERCOMMAND.

Сведения о положении

Это основная функция базового устройства GNSS. В самой базовой форме адаптер GNSS запрашивает текущее положение устройства из драйвера GNSS. Варианты запроса позиции включают (но не ограничиваются ими) следующие типы сеансов позиции:

• Текущее положение устройства (исправление с одним выстрелом)

• Непрерывный периодический поток исправлений (отслеживание на основе времени)

• Непрерывный поток исправлений на основе порогового значения перемещения (отслеживание на основе расстояния)

Единственным обязательным типом сеанса позиции, требуемым для каждого оборудования GNSS и драйвера GNSS, является тип сеанса однократного исправления. При необходимости можно поддерживать собственные (реализованные в SOC, на устройстве GNSS, а не в драйвере GNSS или в службе, работающей в обработчике приложения), сеансы отслеживания на основе времени и сеансы отслеживания на основе расстояния. Преимуществом main для этих двух типов собственных сеансов отслеживания является потенциальная экономия энергии, так как обработчик приложений (AP) неактивным в течение более длительного времени выполняет большую обработку в SOC и сообщает об изменениях только при необходимости. Поддержка собственного отслеживания на основе расстояния более эффективна, чем собственные сеансы отслеживания на основе времени, так как она может обеспечить более высокую экономию энергии и более широко используется приложениями.

Процесс получения сведений о положении из драйвера GNSS происходит через уникальный сеанс исправления с отслеживанием состояния, состоящий из следующих действий:

1. Запуск сеанса исправления: Адаптер GNSS инициирует сеанс запуска исправления (в результате запроса от приложения LBS). Адаптер GNSS устанавливает конкретные требования и предпочтения, связанные с запросом, и предоставляет драйверу GNSS, чтобы запустить подсистему, чтобы получить исправление путем выдачи кода управления IOCTL_GNSS_START_FIXSESSION.

2. Получение положения устройства (исправление данных): После запуска сеанса исправления адаптер GNSS выдает код управления IOCTL_GNSS_GET_FIXDATA , чтобы начать ждать исправления от драйвера. Когда из подсистемы доступны сведения о новом положении, драйвер GNSS отвечает на этот ожидающий запрос на получение исправления.

   Если тип сеанса исправления — исправление LKG (а не текущее исправление), сведения о положении поступают из кэша драйвера.

   Адаптер GNSS гарантирует, что асинхронный запрос ввода-вывода всегда доступен для драйвера GNSS для возврата данных исправления, если они доступны. В зависимости от характера исправления, если ожидается больше данных исправления, адаптер GNSS отправляет другой запрос ввода-вывода (с использованием того же IOCTL), и эта последовательность продолжается, пока больше не будут доступны данные или сеанс исправления не будет остановлен.

3. Изменение сеанса исправления: Если драйвер GNSS не поддерживает мультиплексирование сеансов исправления того же типа, адаптер GNSS может выдать IOCTL_GNSS_MODIFY_FIXSESSION для этого типа сеанса исправления, когда выполняет мультиплексирование на своем уровне.

4. Остановить сеанс исправления: Адаптер GNSS выдает сеанс исправления остановки, если не требуется или не требуется никаких дополнительных сведений о положении, относящихся к конкретному сеансу исправления.

Поддержка собственных геозон

DDI GNSS поддерживает сценарии разгрузки геозон, используя набор 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 переключается на отслеживание геозоны на основе AP по умолчанию, пока оборудование GNSS не сможет восстановить и отслеживать геозоны снова.

• Точные условия, в которых подсистема GNSS должна предоставлять уведомление о том, что геозоны не могут отслеживаться, будут отличаться, и реализация будет зависеть от IHV. Ниже приведены некоторые рекомендации по реализации.

  • Если подсистема GNSS может с высокой уверенностью обнаружить, что пользователь не перемещается и границы геозоны в 25 метров или меньше, подсистеме GNSS не нужно отправлять ошибку отслеживания.

  • Если подсистема GNSS может с высокой уверенностью обнаружить, что пользователь не перемещается, но есть граница геозоны в 25 метров или меньше, подсистеме GNSS необходимо отправить ошибку отслеживания в течение минуты.

  • Если подсистема GNSS обнаружила, что пользователь перемещается, и граница геозон находится в пределах 100 метров или меньше, подсистеме GNSS необходимо отправить ошибку отслеживания в течение минуты или меньше.

  • Если подсистеме GNSS не удается определить, перемещается ли пользователь и имеется граница геозоны в пределах 100 метров или менее, подсистеме GNSS необходимо отправить ошибку отслеживания в течение минуты или меньше.

  • Если подсистема GNSS обнаружила, что пользователь перемещается, подсистема GNSS должна отправить ошибку отслеживания за время, пропорциональное предполагаемой скорости перемещения и расстоянию до ближайшей геозоны. Рекомендуется отправлять ошибки в пределах [(Расстояние до ближайшей границы забора(м) / предполагаемая скорость (м/с)) - 15 с]. Подсистема GNSS может использовать индикаторы обнаружения движения для определения времени отправки ошибки отслеживания.

  • Если подсистеме GNSS не удается определить, перемещается ли пользователь, подсистеме GNSS необходимо отправить ошибку отслеживания за время, пропорциональное высокой скорости перемещения и расстоянию до ближайшей геозоны. Рекомендуется отправить ошибку в пределах [расстояние до ближайшей границы забора(м) / 343(м/с)].

• В течение периода, когда подсистема GNSS сообщала об ошибке состояния отслеживания геозоны, в HLOS не должно отправляться никаких событий нарушения геозоны.

• HLOS может сбросить отслеживание геозоны, удалив все ранее созданные геозоны с помощью одной команды.

• Геозоны, возникшие на мобильных устройствах, не сохраняются в оборудовании или драйвере GNSS при перезагрузке или перезапуске драйвера. HLOS обрабатывает сохраняемость от имени приложений конечных пользователей и создает или удаляет геозоны по мере необходимости.

С точки зрения взаимодействия между адаптером GNSS и подсистемой GNSS, которая поддерживает разгрузку геозон, в случае сбоя отслеживания геозон адаптер GNSS будет выполнять следующие действия:

• Он будет использовать отслеживание на основе AP, как только драйвер GNSS вернет ошибку для отслеживания.

• Он будет продолжать отправлять все обновления (добавление и удаление) в геозонах, которые в настоящее время отслеживаются на уровне ОС, в драйвер, чтобы они были синхронизированы. Это поможет подсистеме GNSS узнать, какие геозоны в настоящее время отслеживаются ОПЕРАЦИОННОй системой, и она может отслеживать или не может отслеживать определение на основе свежих данных.

• Он будет отправлять изменения состояния геозоны, как определено средство отслеживания на основе AP, как только драйвер GNSS отправит результаты SUCCESS в своей способности отслеживать.

Уведомления водителей о помощи и вспомогательных данных

Время от времени драйверу GNSS могут потребоваться вспомогательные данные или вспомогательные действия от адаптера GNSS. Сюда входят различные формы данных AGNSS (внедрение времени, эфемерии, начальное грубое положение), всплывающее окно согласия пользователя для поддержки сетевого позиционирования плоскости пользователя и т. д.

• Драйвер GNSS может получить данные помощи GNSS без использования адаптера GNSS. Тем не менее рекомендуется получать данные помощи с помощью адаптера GNSS и использования службы позиционирования Майкрософт по нескольким причинам:

  • Стек расположений Майкрософт позаботится о создании подключений к данным и соблюдении ограничений роуминга, настроек данных, интеграции в сетевом режиме и т. д.

  • Служба позиционирования Майкрософт может периодически получать данные о помощи, относящиеся к IHV, через серверное подключение и предоставлять их всем нуждающимся устройствам, сохраняя потребность в развертывании службы поддержки внешнего интерфейса по всему миру, удовлетворяющей требованиям к доступности, масштабируемости и скорости реагирования.

• Согласие пользователей на конфиденциальность для приложений для папки "Входящие" принадлежит операционной системе. Таким образом, любой пользовательский интерфейс, уведомляющий пользователя о запросе расположения, инициированном сетью, или любой пользовательский интерфейс для запроса согласия пользователя на ответ на инициированный сетью запрос о расположении будет принадлежать корпорации Майкрософт. Драйвер GNSS уведомляет адаптер GNSS о получении запроса расположения, инициированного сетью, и при необходимости ожидает ответа от пользователя до времени по умолчанию, прежде чем продолжить выполнение запроса.

Так как драйвер GNSS не может инициировать запрос к верхнему уровню самостоятельно, этот тип операций может выполняться адаптером GNSS, упреждающим поиском такого запроса от драйвера GNSS и тем самым всегда сохраняя один или несколько ожидающих irPs, чтобы драйвер GNSS мог ответить на такие ожидающие запросы. При получении запроса на получение даты помощи или вспомогательного помощника адаптер GNSS получает данные (или выполняет определенное действие от имени драйвера GNSS), а затем внедряет необходимые сведения в драйвер GNSS с помощью другого вызова DeviceIoControl .

Уведомление от драйвера обрабатывается с помощью общей модели событий. Например, для поддержки GNSS адаптер GNSS использует код управления IOCTL_GNSS_LISTEN_AGNSS для получения запроса AGNSS от драйвера GNSS. Впоследствии адаптер GNSS получает данные помощи AGNSS и проблемы , IOCTL_GNSS_INJECT_AGNSS для отправки данных в драйвер GNSS.

Этот механизм уведомлений также используется для получения данных оповещений и обновлений состояния, связанных с геозонами. Адаптер использует код управления IOCTL_GNSS_LISTEN_GEOFENCE_ALERT для получения оповещений об отдельных геозонах и IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS для получения изменений общего состояния отслеживания геозоны.

Ведение журнала драйвера глобальной навигационной спутниковой системы (GNSS)

В целях диагностики драйвер GNSS должен регистрировать ошибки и другие диагностические сведения с помощью механизма ведения журнала, предписанного Майкрософт (WPP), описанного ниже, или трассировки событий Windows. Драйверам рекомендуется использовать WPP для ведения журнала, а не трассировки событий Windows, хотя поддерживаются оба этих механизма. Среди причин, по которым рекомендуется использовать WPP, — доступность средств, которые могут помочь в отладке драйверов.

Драйвер не должен записывать в журнал какую-либо информацию, читаемую человеком или иную, кроме как с помощью этого предписанного метода ведения журнала. Дополнительные сведения см. в разделе Трассировка программного обеспечения WPP.

Ведение журнала сообщений с помощью трассировки программного обеспечения WPP аналогично использованию служб ведения журнала событий Windows. Драйвер регистрирует идентификатор сообщения и неформатированные двоичные данные в файле журнала. Затем постпроцессор преобразует сведения в файле журнала в удобочитаемую форму. Однако трассировка программного обеспечения WPP поддерживает форматы сообщений, которые являются более гибкими и гибкими, чем поддерживаемые службами ведения журнала событий. Например, трассировка программного обеспечения WPP имеет встроенную поддержку IP-адресов, GUID, системных идентификаторов, меток времени и других полезных типов данных. Кроме того, пользователи могут добавлять пользовательские типы данных, относящиеся к их приложению.

Поддержка протокола оператора мобильной связи

Стек GNSS, предоставляемый IHV (драйвер GNSS, устройство или подсистема GNSS), необходим для поддержки различных протоколов позиционирования операторов мобильной связи (SUPL, UPL, CP и т. д.). В противном случае это означает, что устройство не будет проходить приемку от мобильных операторов и значительно ограничивает возможности коммерческого использования устройства.

Поддержка этих протоколов и соответствие требованиям операторов мобильной связи являются обязательными для отправки устройств для определенных операторов мобильной связи. Поддержка протоколов операторов мобильной связи не может быть важной для большинства платформ, не относящихся к телефону, особенно если платформа не включает поддержку мобильной широкополосной связи (MBB).

Все элементы реализации абстрагируются в стеке IHV, а компоненты Microsoft HLOS не зависят от:

• Сведения о конкретной реализации протоколов (например, принцип работы протоколов, интерпретация сообщений протокола и т. д.).

• Форма стека реализации (например, реализация может находиться в пределах устройства или подсистемы GNSS, драйвера GNSS или при необходимости отдельной службы HLOS).

• Взаимодействие между различными элементами в стеке GNSS, принадлежащей IHV, для реализации протоколов. Например, если драйвер GNSS требует Wi-Fi результатов сканирования для ответа на определенное сообщение протокола SUPL, он может сделать это путем внедрения расширения пользовательского режима Wi-Fi результатов сканирования в драйвер через частный вызов IOCTL или сделать эту часть драйвера UMDF 2.0 или обработать это взаимодействие на более низком уровне. Компоненты Microsoft GNSS HLOS не заметив такого взаимодействия между компонентами стека GNSS IHV.

Таким образом, IHV или OEM необходимо предоставить клиент SUPL (и, возможно, клиент UPL, если система будет поставляться в Китае) и интегрировать его с драйвером GNSS или внутри него. Все взаимодействия платформы расположения с клиентом SUPL будут выполняться через DDI GNSS.

Чтобы упростить реализацию протоколов оператора мобильной связи и снизить нагрузку на разработку программного обеспечения с использованием технологий, зависящих от платформы, адаптер GNSS предоставляет определенные функции стеку GNSS IHV. Драйвер GNSS рассматривается как посредник для получения таких функций от компонентов HLOS, например адаптер GNSS взаимодействует только с драйвером GNSS, а не с какой-либо другой частью стека GNSS IHV. Списки IOCTL драйвера GNSS определяют синтаксис и семантику таких функций между драйвером GNSS и адаптером GNSS. Драйвер GNSS отвечает за маршрутизацию к конкретному компоненту IHV, реализующего протокол оператора мобильной связи. В целом адаптер GNSS предоставляет следующие функции для драйвера GNSS:

1. Конфигурации: Мобильные операторы подготавливают устройство и изменяют конфигурацию с помощью механизма конфигурации, навязанного стандартами протокола OMA. Например, стандарт SUPL требует, чтобы конфигурация SUPL выполнялись на основе UICC и (или) выполнялись с использованием сведений профиля конфигурации SUPL OMA, полученных через OMA-DM или OMA-CP.

   Некоторые функции, доступные в телефоне для настройки (OMA-DM и OMA CP), были недоступны на других платформах до Windows 10. Начиная с Windows 10 все платформы могут поддерживать конфигурацию SUPL через поставщика служб конфигурации SUPL (CSP), так как используется новый DDI GNSS. Подготовка, внедренная через CSP, может поступать из самого образа (через provxml или multivariant) или от оператора мобильной связи через OMA-DM или OMA-CP. Поставщик служб конфигурации SUPL определяется в SUPL CSP.

   Windows 10 определяет собственную технологию управления устройствами с помощью поставщика служб конфигурации (CSP) для интерпретации и извлечения данных конфигурации. Корпорация Майкрософт предоставляет поставщик служб конфигурации для использования конфигурации OMA и отправки конфигурации в драйвер GNSS через адаптер GNSS.

   Кроме того, IHV может также написать компонент пользовательского режима для использования спецификации конфигурации оператора мобильной связи с использованием технологии управления устройствами (CSP) для телефона. Однако это будет дополнительным бременем для IHV и не рекомендуется.

   В системе поддерживается только одна конфигурация SUPL, включая устройства с двумя SIM-картами. Корпорация Майкрософт предоставляет функциональные возможности для перенастройки SUPL на основе UICC и изменений UICC. Кроме того, в случае перемещения устройства HLOS повторно настраивает клиент SUPL для работы в автономном режиме. В этом документе определяются ioCTL для отправки таких данных конфигурации для различных протоколов мобильных операций (SUPL 1.0 и 2.0, v2UPL и т. д.).

2. Обработка согласия пользователя для запросов NI: Для соблюдения требований к конфиденциальности некоторые запросы на позиционирование, инициированные сетью, требуют согласия пользователя. IHV не могут создавать пользовательский интерфейс для компонентов платформы. Поэтому адаптер GNSS обрабатывает пользовательский интерфейс для предоставления согласия пользователя от имени драйвера GNSS. Списки IOCTL уведомлений для драйвера GNSS для запроса всплывающего окна пользовательского интерфейса и списки IOCTL для адаптера GNSS для передачи ответа пользователя на такой запрос определяются в списках IOCTL драйвера GNSS.

Чтобы реализовать полнофункциональный клиент SUPL, стек IHV должен использовать интерфейсы или общие функциональные возможности, доступные на платформе ОС. Ниже приведен список функций, доступных в Windows 10, которые IHV могут использовать для реализации своего клиента SUPL:

Ни одна из этих функций не является частью платформы расположения или GNSS DDI, но она включена здесь для уточнения и для того, чтобы помочь разработчикам драйверов GNSS понять, что можно использовать из ОС для реализации функций SUPL.

• Маршрутизатор SMS: Маршрутизатор SMS позволяет клиенту SUPL подписаться на wap push-сообщения SIP Push, которые содержат запросы SUPL NI.

• диспетчер подключений возможность настроить подключение, которое будет использоваться для SUPL и API для запроса такого подключения: операторам мобильной связи может потребоваться использовать трафик SUPL в выделенном подключении или просто в подключении, отличном от подключения к Интернету по умолчанию. Для этого диспетчер подключений предлагает:

  • Поставщик службы конфигурации, который изготовитель оборудования или оператор мобильной связи может использовать для настройки подключения, используемого для обмена данными SUPL.

  • API для запроса параметров соединения SUPL клиента SUPL.

  • API для установки соединения SUPL с параметрами, полученными на предыдущем шаге.

• Конфигурация сотового подключения: Чтобы настроить параметры различных сотовых подключений, например параметры подключения SUPL, есть поставщик услуг конфигурации, который может использовать изготовитель оборудования или оператор мобильной связи. Затем это подключение можно связать в диспетчер подключений с назначением SUPL.

• Запрос на сохранение подключений в активном режиме во время подключения SUPL: Клиенту SUPL может потребоваться инициировать подключения с HSLP, пока система находится в режиме ожидания подключения. Это может произойти из-за того, что устройству GNSS необходимо получить сведения о помощи при настройке для использования позиционирования на основе Майкрософт или из-за того, что оператор мобильной связи отправил запрос NI. В этом случае клиенту SUPL потребуется инициировать подключение к HSLP и убедиться, что подключение активно до завершения сеанса SUPL.

• Взаимодействие с модулем мобильной широкополосной связи (MBB): В Windows 10 отсутствуют API, доступные через HLOS для получения измерений сотовой сети, получения сведений о том, когда был сделан экстренный вызов и т. д. Любое взаимодействие с MBB должно осуществляться через прямую интеграцию с MBB (с помощью команд AT или другого защищаемого метода).

Производственное тестирование

Изготовители оборудования должны иметь способ проверки во время производства, а также в точках поддержки клиентов, что оборудование GNSS и стек GNSS (драйвер GNSS и устройство или подсистема GNSS) работают правильно. IHV может предоставлять собственные механизмы, позволяющие изготовителям оборудования выполнять это тестирование, или может при необходимости реализовать интерфейс в DDI, чтобы позволить изготовителю инициировать производственные испытания и получать результаты.

При выполнении производственного тестирования платформа расположения будет обходить стороной, учитывая, что основное внимание уделяется проверке оборудования или драйверу. Как правило, устройство будет находиться в специальном "безопасном режиме операционной системы", где будет загружен минимальный набор компонентов и служб. В этом режиме изготовитель оборудования может инициировать набор тестовых приложений, которые будут запускать тестовые случаи. Для эффективности и скорости во время производства очень желательно иметь поддержку параллелизма для тестов в разных компонентах.

Интерфейс для производственных тестов включает два типа тестов:

1. Тест несущей волны: Этот тест предназначен для проверки внешнего подключения или теста антенны. В этом тесте система GNSS должна искать сигнал CW и предоставлять в ответе измерения SNR (сигнал для шумовых норм или носитель для коэффициента шума). В идеале тесты должны предоставлять ответы с частотой 10 Гц.

2. Самостоятельное тестирование: Этот тест предназначен для проверки основных функциональных возможностей подсистемы GNSS. Самотестировать должен быть в состоянии обнаружить основные проблемы в движке (неисправное оборудование, плохие подключения на оборудовании GNSS без необходимости внедрения внешнего сигнала). Цель этой проверки заключается в том, чтобы сделать этот дешевый тест и использовать его в качестве шлюза в производственной линии, прежде чем устройство пройдет более исчерпывающее и дорогостоящее тестирование. В этом тесте подсистема GNSS и драйвер должны выполнить самостоятельную проверку на наличие подключений с закреплением и вернуть код состояния, указывающий, что все в порядке или что произошел сбой. Код ошибки для сбоев должен указывать на обнаруженную ошибку. Коды ошибок задаются IHV.

Рекомендации по вводу-выводу

Так как функции GNSS не сопоставляются с традиционными запросами на чтение и запись файлов к драйверам устройств, функции ReadFile и WriteFile не будут использоваться для API-интерфейсов драйверов GNSS. Все функции GNSS будут реализованы с помощью четко определенных запросов управления вводом-выводом устройств (DeviceIoControl), также известных как ioCTLs.

Все ioCTL будут использовать METHOD_BUFFERED в качестве механизма передачи данных как для входных, так и для выходных данных. Так как размер данных, связанных с GNSS, относительно мал, дополнительная копия буфера не должна влиять на производительность системы.

Драйвер GNSS будет открыт с помощью параметра FILE_FLAG_OVERLAPPED в функции CreateFile . Следовательно, все ioCTL неявно асинхронны. Однако в то время как большинство ioCTL GNSS являются семантически асинхронными (например, IOCTL запускает действие в драйвере и результаты ожидаются асинхронно), некоторые ioCTL семантически синхронны в том смысле, что с такими ICTL не связаны логические асинхронные действия или действия. Синхронное поведение этих нескольких списков IOCTL будет достигнуто путем блокировки потока адаптера GNSS после выполнения вызова DeviceIoControl до завершения операции ввода-вывода. Следовательно, драйвер GNSS отвечает за то, чтобы всегда выполнять IRP в рамках обработки всех ioCTL. Адаптер GNSS должен соблюдать контракт синхронного вызова и в случае ошибок может повторить или не повторить эти команды. Драйвер IHV должен убедиться, что он включил все логики на стороне драйвера, прежде чем возвращать ошибку.

Для операций запроса и ответа адаптер GNSS всегда будет поддерживать отложенную операцию ввода-вывода, чтобы, когда драйвер GNSS имеет данные для отправки в качестве ответа на ранее вызванную операцию, ответ можно было отправить через ожидающий IRP.

Сеанс с одним выстрелом

Запрос на запуск исправления для одного выстрела для драйвера включает значения точности и времени отклика. Подсистема GNSS может использовать эти значения для понимания цели запроса приложения и принятия интеллектуальных решений. После получения запроса драйвером он должен начать возвращать все промежуточные исправления, созданные подсистемой. Промежуточные исправления — это исправления, создаваемые подсистемой при вычислении исправления, которое соответствует требованиям к точности или является окончательным. Частота этих промежуточных исправлений не применяется и является подробным описанием реализации подсистемы. Адаптер GNSS ожидает, что исправления будут поступать каждые несколько секунд, и они должны отличаться от последнего промежуточного исправления.

После того как подсистема GNSS определит, что она не может получить лучшее исправление в текущих условиях сигнала, она должна вернуть окончательное исправление и прекратить дальнейшие вычисления. Окончательное исправление либо соответствует требованиям к точности, либо указывает, что двигатель не может повысить точность, предоставляемую в текущих условиях.

Адаптер GNSS выдает исправление остановки для одного сеанса в любом из двух случаев:

• Он получает окончательное исправление от драйвера.

• Достигнуто время отклика для запроса. Здесь в приложение будет отправлено последнее промежуточное исправление.

На следующем рисунке показаны два сеанса с одним выстрелом:

Сеанс 1. Драйверу были предоставлены параметры Точность и Время отклика. После выполнения команды start fix драйвер начал отправлять промежуточные исправления. Через некоторое время он определил, что не может вернуть более точное исправление, поэтому он указал последнее исправление как окончательное. Это произошло до достижения предельного времени отклика. Адаптер отправил окончательное исправление в приложение и выдал команду stop fix.

Сеанс 2. Как и в сеансе 1 выше, но в этом случае подсистема продолжала идти на лучшее исправление, чтобы соответствовать требованиям к точности, и продолжал отправлять промежуточные исправления между ними. После достижения предельного времени отклика сеанса адаптер выпустил исправление остановки, которое должно закрыть этот сеанс в драйвере. Последнее полученное промежуточное исправление было отправлено приложению.

Один важный аспект проектирования, который следует учитывать при реализации поддержки единого выстрела, заключается в том, что если сеансы отслеживания на основе расстояния и сеансы отслеживания на основе времени не поддерживаются, подсистема GNSS должна продолжать отслеживать спутники в течение 3–5 секунд после получения команды stop fix. Это связано с тем, что адаптерУ GNSS потребуется реализовать имитированные сеансы отслеживания на основе расстояния и (или) сеансы отслеживания на основе времени с помощью сеансов исправления одного выстрела, и если подсистема GNSS немедленно останавливает отслеживание спутников, большинство устройств GNSS будет иметь задержку при приобретении, что делает невозможным реализацию имитированного сеанса отслеживания, удовлетворяющего потребностям навигации. запуск приложений отслеживания или сопоставления.

Адаптер GNSS может инициировать запросы на однократные исправления, когда система находится в режиме ожидания с подключением, а не только при активной системе. Это может произойти для удовлетворения потребностей фоновых задач, системных служб, отслеживания геозон в обработчике приложения или других случаях. Драйвер GNSS должен быть в состоянии передать эти запросы сеанса устройству GNSS и либо выполнить запрос, либо предоставить ошибку адаптеру GNSS.

На следующей схеме последовательностей показаны высокоуровневые действия, связанные с получением автономного исправления GNSS. Сюда не входят запросы на получение данных о помощи.

Описание последовательности выглядит следующим образом:

1. Адаптер GNSS открывает драйвер GNSS с помощью API CreateFile . WDF/KMDF/UMDF делает необходимые необязательные обратные вызовы драйверу GNSS. Возвращенный дескриптор файла используется для всех последующих операций.

2. Адаптер GNSS выдает IOCTL для передачи различных возможностей платформы драйверу. Драйвер GNSS завершает операцию ввода-вывода.

3. Адаптер GNSS выдает IOCTL для получения возможностей устройства. Драйвер GNSS возвращает возможности устройства и завершает операцию ввода-вывода.

4. Адаптер GNSS выдает ioCTL для любой конфигурации или команд, относящихся к конкретному драйверу. Драйвер GNSS выполняет необходимое действие и завершает операцию ввода-вывода.

5. Адаптер GNSS выдает IOCTL_GNSS_START_FIXSESSION вместе с параметрами, определяющими тип и другие аспекты исправления. После получения этого IOCTL драйвер GNSS взаимодействует с базовым устройством, чтобы начать получать исправления, а затем завершает операцию ввода-вывода.

6. Адаптер GNSS выдает IOCTL_GNSS_GET_FIXDATA и ожидает завершения ввода-вывода. Всякий раз, когда драйвер GNSS имеет доступное промежуточное исправление, он возвращает данные путем завершения операции ввода-вывода.

7. Шаг 6 повторяется, пока драйвер GNSS не укажет, что больше исправлений не ожидается (окончательное исправление получено).

8. Проблемы с адаптером GNSS IOCTL_GNSS_STOP_FIXSESSION. Драйвер GNSS выполняет необходимую операцию очистки, связанную с исходным запросом на исправление.

9. Адаптер GNSS закрывает дескриптор файла драйвера с помощью API CloseHandle .

Списки IOCTL GNSS и связанные структуры данных подробно описаны в справочнике по драйверу GNSS.

Сеанс отслеживания на основе расстояния

Сеансы отслеживания на основе расстояния часто используются приложениями конечных пользователей, так как исторически это был единственный тип сеанса, доступный в API .NET. Значение расстояния 0 указывает, что подсистема GNSS должна предоставлять исправления с максимально возможной скоростью.

Адаптер GNSS будет запускать сеансы отслеживания расстояния с драйвером GNSS, только если последний указывает, что у него есть возможность SupportDistanceTracking.

Запрос на исправление начала к водителю для сеанса отслеживания расстояния будет включать в себя горизонтальную точность и порог движения, который представляет собой расстояние хеверсинуса в метрах, которое система должна покрыть до того, как драйвер GNSS выполнит обновление положения. Подсистема GNSS может использовать эти значения, чтобы понять назначение запроса приложения и принимать интеллектуальные решения, например адаптировать частоту проверка для определения местоположения.

После получения драйвером запроса на запуск исправления он должен начать возвращать все промежуточные исправления, созданные подсистемой, пока не получит окончательное исправление. Это будет считаться первой позицией сеанса. После этого подсистема GNSS должна начать предоставлять исправления всякий раз, когда обнаруживает, что расстояние хэверсина было приблизительно покрыто.

Если подсистема GNSS определяет, что она больше не может отслеживать расположение устройства (например, если спутники больше не видны), он должен вернуть ошибку адаптеру GNSS, чтобы платформа расположения вернется к другим механизмам для предоставления обновлений положения в приложении конечного пользователя. Адаптер GNSS должен предоставить ошибку в течение следующего времени:

[(Расстояние, оставшееся с момента последней известной позиции (м) / предполагаемая скорость (м/с)) – 5 секунд] или 5 секунд, в зависимости от того, какой из них является наибольшим.

Если подсистема GNSS предоставила адаптеру GNSS сообщение об ошибке, но адаптер GNSS еще не остановил сеанс отслеживания, подсистема GNSS должна продолжать проверка в оптимизированном для питания способе, если он может возобновить отслеживание расположения. IHV может использовать оптимизации, чтобы сделать это обнаружение с низким энергопотреблением. Ниже перечислены распространенные методы оптимизации.

• Прогрессивная отката

• Ожидание недорогих сигналов, которые свидетельствуют о перемещении устройств для повторной проверки

• Проверка низкого энергопотребления для спутникового сигнала

Когда подсистема GNSS снова сможет предоставить окончательное исправление после возникновения ошибки, она должна отправить эту позицию адаптеру GNSS в качестве признака успешного возобновления отслеживания.

Адаптер GNSS выдает команду изменить исправление для удаленного сеанса отслеживания, если одно или несколько приложений, запросив сеанс отслеживания, отменили запрос или если новые приложения запрашивают сеанс отслеживания на основе расстояния. В этом случае адаптер GNSS вычисляет новые агрегированные параметры сеанса, необходимые для мультиплексирования различных активных сеансов, и обновляет драйвер GNSS этими параметрами.

Адаптер GNSS выдает команду stop fix для сеанса отслеживания на основе расстояния, если:

• Сеанс отслеживания был передан другому механизму позиционирования, доступному в системе.

• Приложения, запрашивающие сеанс отслеживания, отменили запрос.

На следующем рисунке показаны два сеанса отслеживания на основе расстояния.

Сеанс 1. Драйверу GNSS были предоставлены параметры точности и порога перемещения при инициации сеанса отслеживания. После выполнения команды start fix драйвер начинает отправлять промежуточные исправления, пока не получит окончательное исправление или исправление, соответствующее требованиям к точности, когда такое исправление будет предоставлено адаптеру GNSS, а подсистема GNSS запустит процесс отслеживания расстояния. Пока сеанс активен, адаптер GNSS отправляет запрос на изменение параметров сеанса время от времени T1 и T2. После каждого изменения параметров драйвер GNSS отправляет исправление адаптеру GNSS и возобновляет сеанс отслеживания расстояния с новыми параметрами, пока адаптер GNSS не отправит команду stop fix.

Сеанс 2. Процесс запуска сеанса аналогичен описанному выше сеансу 1, но в данный момент подсистеме GNSS не удается отслеживать позицию. Через время, зависящее от расстояния и предполагаемой скорости движения, водитель GNSS отправляет ошибку. Подсистема GNSS продолжает проверка с меньшей мощностью, когда она может восстановиться, и когда она восстанавливается, указывает на это для адаптера GNSS, отправляя новое исправление. При необходимости в сеансе будут добавлены новые исправления, пока адаптер GNSS не отправит команду stop fix.

Адаптер GNSS может сохранять активность или даже инициировать сеансы отслеживания на основе расстояния, пока система находится в режиме ожидания подключения, а не только при активной системе. Это может произойти для удовлетворения потребностей фоновых задач, системных служб, отслеживания геозон в обработчике приложения или других случаях. Драйвер GNSS должен быть в состоянии передать эти запросы сеанса устройству GNSS и либо выполнить запрос, либо предоставить ошибку адаптеру GNSS.

Сеанс отслеживания на основе времени

Сеансы отслеживания на основе времени могут использоваться приложениями, которым требуется частое и регулярное обновление позиции для обновления пользовательского интерфейса (например, карты, приложения навигации и т. д.).

Адаптер GNSS будет запускать сеансы отслеживания на основе времени с драйвером GNSS, только если более поздняя указывает, что у него есть возможность SupportContinuousTracking.

Запрос на начало исправления к драйверу для сеанса отслеживания на основе времени будет включать в себя желаемую горизонтальную точность и интервал времени, с которым драйвер GNSS должен обеспечить обновление позиции. Подсистема GNSS может использовать эти значения для понимания намерения запроса приложения и принятия интеллектуальных решений, таких как адаптация частоты проверка для определения местоположения, начало получения спутников за несколько секунд до интервала, чтобы обеспечить своевременное обновление позиции и т. д.

После получения драйвером запроса на запуск исправления он должен начать возвращать все промежуточные исправления, созданные подсистемой, пока не получит окончательное исправление. Это будет считаться первой позицией сеанса. После этого подсистема GNSS должна начать предоставлять исправления с интервалом, требуемым параметрами сеанса. Если подсистеме GNSS не удается предоставить позиции с частотой, требуемой приложением, она должна предоставлять исправления с максимальной скоростью.

Если подсистема GNSS определяет, что она больше не может отслеживать расположение устройства (например, если спутники больше не видны), он должен вернуть ошибку адаптеру GNSS, чтобы платформа расположения вернется к другим механизмам для предоставления обновлений положения в приложении конечного пользователя.

Если подсистема GNSS предоставила адаптеру GNSS сообщение об ошибке, но адаптер GNSS еще не остановил сеанс отслеживания, подсистема GNSS должна продолжать проверка в оптимизированном для питания способе, если он может возобновить отслеживание расположения.

IHV может использовать оптимизации, чтобы сделать это обнаружение с низким энергопотреблением, как описано в предыдущем разделе. Когда подсистема GNSS снова сможет предоставить окончательное исправление после возникновения ошибки, она должна отправить эту позицию адаптеру GNSS в качестве признака успешного возобновления отслеживания.

Адаптер GNSS выдает команду изменить исправление для сеанса отслеживания на основе времени, если одно или несколько приложений, запрашивающих сеанс отслеживания, отменили запрос или если новые приложения запрашивают сеанс отслеживания на основе времени. В этом случае адаптер GNSS вычисляет новые агрегированные параметры сеанса, необходимые для мультиплексирования различных активных сеансов, и обновляет драйвер GNSS этими параметрами.

Адаптер GNSS выдает команду stop fix для сеанса отслеживания на основе времени, если:

• Сеанс отслеживания был передан другому механизму позиционирования, доступному в системе.

• Приложения, запрашивающие сеанс отслеживания, отменили запрос.

На следующем рисунке показаны два сеанса отслеживания на основе времени.

Сеанс 1. Драйверу GNSS была предоставлена точность и предпочтительный параметр интервала при инициации сеанса отслеживания. После выполнения команды start fix драйвер должен начать отправку промежуточных исправлений, пока не получит окончательное исправление или исправление, соответствующее требованиям к точности, после чего такое исправление будет предоставлено адаптеру GNSS, а подсистема GNSS запустит процесс отслеживания на основе времени. Пока сеанс активен, адаптер GNSS отправляет запрос на изменение параметров сеанса время от времени T1 и T2. После каждого изменения параметров драйвер GNSS отправляет исправление адаптеру GNSS и возобновляет сеанс отслеживания на основе времени с новыми параметрами, пока адаптер GNSS не отправит команду stop fix.

Сеанс 2. Процесс запуска сеанса аналогичен описанному выше в сеансе 1, но в определенный момент подсистема GNSS перестает отслеживать позицию. Если подсистеме GNSS не удается предоставить исправление в течение 15 секунд после интервала, необходимого для параметров сеанса, драйвер GNSS отправляет ошибку. Подсистема GNSS продолжает проверка с меньшей мощностью, когда она может восстановиться, и когда она восстанавливается, указывает на это для адаптера GNSS, отправляя новое исправление. При необходимости в сеансе будут добавлены новые исправления, пока адаптер GNSS не отправит команду stop fix.

Адаптер GNSS может оставать активным или даже инициировать сеансы отслеживания на основе времени, когда система находится в режиме ожидания подключения, а не только при активной системе. Это может произойти для удовлетворения потребностей фоновых задач, системных служб, отслеживания геозоны в обработчике приложения или других случаях. Драйвер GNSS должен быть в состоянии передать эти запросы сеанса устройству GNSS и либо выполнить запрос, либо предоставить ошибку адаптеру GNSS.

Одновременное управление различными типами сеансов исправления

Некоторые расширенные подсистемы GNSS могут обрабатывать одновременно сеанс single shot с Distance-Based и (или) сеансом отслеживания Time-Based. В идеале независимые сеансы не должны влиять друг на друга, но это не всегда возможно, особенно в случае одновременных сеансов отслеживания одиночного выстрела и отслеживания на основе времени. В этом разделе приведены некоторые рекомендации по реализации IHV на случай, если необходимо выполнить компрометацию для обработки одновременных сеансов различных типов.

В этом разделе используются следующие акронимы:

• SS: Сеанс с одним выстрелом

• DBT: Сеанс отслеживания на основе расстояния

• TBT: сеанс отслеживания на основе времени

• TBF: Время между исправлениями

В следующей таблице приведены некоторые сценарии одновременной обработки однократных сеансов отслеживания и сеансов отслеживания на основе времени.

Случай	SS active?	ТБT активен?	Сведения об обращениях	Допустимый интервал исправлений	Комментарии
1	X	X	Сеанс SS, текущий во время запуска периодического сеанса TBT с оставшимся тайм-аутом >= интервал	То же, что и интервал TBT	Поведение сеанса SS: Промежуточные и окончательные исправления отправляются до истечения времени ожидания. Сеанс закрыт сразу после получения остановки. Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления. Исправления, полученные приблизительно в рамках интервала. Сеанс закрыт сразу после получения остановки.
2	X	X	Сеанс SS, выполняемый во время запуска периодического сеанса TBT с оставшимся интервалом времени ожидания <	Интервал остается таким же, как и время ожидания службы SS, пока не будет выполнен сеанс SS. Затем интервал можно обновить так, чтобы он совпадал с интервалом ТБТ.	Поведение сеанса SS: Промежуточные и окончательные исправления отправляются до истечения времени ожидания. Сеанс закрыт сразу после получения остановки. Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления Исправления получены приблизительно в течение интервала, но могут быть более частыми во время сеанса SS. Сеанс закрыт сразу после получения остановки.
3	X	X	Сеанс SS запущен, пока продолжается периодический сеанс TBT, запущенный с тайм-аутом >= интервал	То же, что и интервал TBT	Поведение сеанса SS: Промежуточные и окончательные исправления отправляются до истечения времени ожидания. Сеанс закрыт сразу после получения остановки. Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления Исправления, полученные приблизительно в рамках интервала. Сеанс закрыт сразу после получения остановки.
4	X	X	Сеанс службы SS запущен, когда продолжается периодический сеанс TBT, запущенный с интервалом времени ожидания <	Интервал изменяется так же, как и время ожидания службы SS, пока сеанс SS не будет удовлетворен. Затем интервал можно обновить так, чтобы он совпадал с интервалом ТБТ.	Поведение сеанса SS: Промежуточные и окончательные исправления отправляются до истечения времени ожидания. Сеанс закрыт сразу после получения остановки. Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления. Исправления получены приблизительно в течение интервала, но могут быть более частыми во время сеанса SS. Сеанс закрыт сразу после получения остановки.
5		X	Периодический сеанс TBT, запущенный с изменением интервала	Сеанс с модемом обновляется до нового интервала, чтобы он совпадал с интервалом TBT. При необходимости сеанс модема будет перезапущен.	Поведение сеанса SS: Неприменимо Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления. Исправления, полученные приблизительно в рамках интервала. Сеанс закрыт сразу после получения остановки.
6	X	X	Сеанс SS, текущий в момент, когда текущий периодический сеанс TBT получает изменение интервала, с оставшимся тайм-аутом >= интервал	То же, что и интервал TBT	Поведение сеанса SS: Промежуточные и окончательные исправления отправляются до истечения времени ожидания. Сеанс закрыт сразу после получения остановки. Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления Исправления, полученные приблизительно в рамках интервала. Сеанс закрыт сразу после получения остановки.
7	X	X	Сеанс SS, текущий в момент, когда текущий периодический сеанс ТБТ получает изменение интервала с оставшимся интервалом времени ожидания <	Интервал изменится так же, как и оставшееся время ожидания SS до тех пор, пока сеанс SS не будет удовлетворен. Затем интервал можно обновить так, чтобы он совпадал с интервалом ТБТ.	Поведение сеанса SS: Промежуточные и окончательные исправления отправляются до истечения времени ожидания. Сеанс закрыт сразу после получения остановки./li> Поведение сеанса TBT: Отправляются промежуточные и окончательные исправления Исправления получены приблизительно в течение интервала, но могут быть более частыми во время сеанса SS. Сеанс закрыт сразу после получения остановки.

При наличии одновременного сеанса отслеживания на основе времени и расстояния можно настроить отслеживание точности подсистемы GNSS для работы с наименьшими из двух. В следующей таблице также приведены некоторые рекомендации для разрозненных значений точности, необходимых при одновременном одиночном снимке и сеансах отслеживания.

Случай	Точность SS	Точность DBT или TBT	Общая точность подсистемы GNSS	Комментарии
1	Средний/низкий —> высокий	Неприменимо	Средний/низкий —> высокий	Поведение сеанса SS: Сеанс с устройством GNSS обновляется или перезапускается для получения результата высокой точности. Промежуточные исправления предоставляются для HLOS по мере их доступности.
2	Высокий —> средний/низкий	Неприменимо	Высокий —> средний/низкий	Поведение сеанса SS: Сеанс с устройством GNSS обновляется или перезапускается для получения результата средней или низкой точности. Если исправление, удовлетворяющее требованиям, уже доступно, оно возвращается в качестве окончательного исправления. В противном случае промежуточные исправления предоставляются HLOS по мере их доступности.
3	Средний/низкий —> высокий	Высокий	Высокий	Поведение сеанса SS: Учитывая, что для сеанса DBT или TBT уже существует сеанс высокой точности, сеанс SS просто предоставляет промежуточные дополнительные исправления для HLOS, пока не будет получена окончательная требуемая точность или окончательное исправление.
4	Высокий —> средний/низкий	Высокий	Высокий	Поведение сеанса SS: Учитывая, что для сеанса DBT или TBT уже существует сеанс высокой точности, сеанс SS просто предоставляет промежуточные дополнительные исправления для HLOS, пока не будет получена окончательная требуемая точность или окончательное исправление.
5	Средний/низкий —> высокий	Средний/низкий	Средний/низкий —> высокий, а затем обратно на средний/низкий после завершения сеанса SS	Поведение сеанса SS: Сеанс с устройством GNSS обновляется или перезапускается для получения результата высокой точности. Промежуточные исправления предоставляются для HLOS по мере их доступности. Поведение сеанса DBT или TBT: Это нормально для этого сеанса, чтобы временно получать результаты высокой точности. Однако после передачи сеанса SS точность этого сеанса должна вернуться к средней или низкой.
6	Высокий --> средний/низкий	Средний/низкий	Высокий --> средний/низкий	Поведение сеанса SS: Сеанс с устройством GNSS обновляется или перезапускается для получения результата средней или низкой точности. Если исправление, удовлетворяющее требованиям, уже доступно, оно возвращается в качестве окончательного исправления. В противном случае промежуточные исправления предоставляются для HLOS по мере их доступности.
7	Неприменимо	Средний/низкий --> Высокий	Средний/низкий --> Высокий	b>Поведение сеанса DBT или TBT:** Сеанс с устройством GNSS обновляется или перезапускается для получения результатов высокой точности. Промежуточные исправления предоставляются для HLOS по мере их доступности.
8	Неприменимо	Высокий --> средний/низкий	Высокий --> средний/низкий	Поведение сеанса DBT или TBT: Сеанс с устройством GNSS обновляется или перезапускается для получения результата средней или низкой точности. Если исправление, удовлетворяющее требованиям, уже доступно, оно возвращается в качестве окончательного исправления. В противном случае промежуточные исправления предоставляются для HLOS по мере их доступности.
9	Высокий	Средний/низкий --> Высокий	Высокий	Поведение сеанса DBT или TBT: Сеанс уже получал исправления с высокой точностью или промежуточные исправления, поэтому никаких изменений не было.
10	Высокий	Высокий --> средний/низкий	После завершения сеанса службы SS изменится на "Высокий", а затем изменится на "Средний/Низкий".	Поведение сеанса DBT или TBT: Сеанс может продолжать получать исправления высокой точности или промежуточные исправления до завершения сеанса SS. Затем он должен измениться на исправления средней или низкой точности.
11	Средний/низкий<	Средний/низкий --> Высокий	Средний/низкий --> Высокий	Поведение сеанса DBT или TBT: Сеанс с устройством GNSS обновляется или перезапускается для получения результатов высокой точности. Промежуточные исправления предоставляются для HLOS по мере их доступности.
12	Средний/низкий	Высокий --> средний/низкий	Высокий --> средний/низкий	Поведение сеанса DBT или TBT: Сеанс с устройством GNSS обновляется или перезапускается для получения результата средней или низкой точности. Если исправление, удовлетворяющее требованиям, уже доступно, оно возвращается в качестве окончательного исправления. В противном случае промежуточные исправления предоставляются для HLOS по мере их доступности.