УПРАВЛЕНИЕ ПОТОКОМ ПЕРИОДИЧЕСКИХ ВСПОМОГАТЕЛЬНЫХ ДАННЫХ
CONTROLLING STREAM OF PERIODIC AUXILIARY DATA

Область техники
[0001] Различные формы осуществления изобретения в целом относятся к области технологий позиционирования (определения местоположения). Более конкретно различные формы осуществления изобретения касаются смены опорных приемников для задач позиционирования.
Предпосылки создания изобретения
[0002] Этот раздел предназначен для представления предпосылок создания изобретения или контекста изобретения, которое изложено в формуле изобретения. Описанное здесь может включать идеи, которые могли быть предложены, но не обязательно были ранее предложены. Поэтому если иное не указано, описанное в этом разделе не является известным уровнем техники для описания и формулы изобретения в данной заявке.
[0003] Навигационные системы, которые позволяют электронным устройствам определять местоположение, становятся все более широко распространенными. В настоящее время имеется ряд таких навигационных систем, включая глобальные навигационные спутниковые системы (Global Navigation Satellite Systems GNSS), такие как глобальная система определения местоположения (Global Positioning System, GPS), российская Глобальная навигационная спутниковая система (GLObal NAvigation Satellite System, GLONASS), Спутниковая система дифференциальной коррекции (Satellite-Based Augmentation System, SBAS), Вспомогательная система с локальной зоной действия (Local Area Augmentation System, LAAS), "Квазизенитная спутниковая система" (Quasi-Zenith Satellite Systems, QZSS) и будущая европейская система Galileo. Приводимая в качестве примера система GNSS может включать сеть спутников, которая передает навигационные сигналы, включая данные времени и расстояния. Приемники системы GNSS принимают эти передаваемые по радио навигационные сигналы и вычисляют на их основе точное глобальное местоположение.
[0004] Один аспект GNSS включает относительное позиционирование. Относительное позиционирование - технология позиционирования, в которой устройство позиционируется относительно другого устройства. Цель этой технологии позиционирования состоит в том, чтобы точно определить относительное положение (не обязательно абсолютное положение) или базисную линию (вектор перемещения и направление между устройствами относительно друг друга) между этими двумя устройствами. Относительное позиционирование может выполняться между двумя терминалами или между терминалом и опорной станцией. Кроме того, относительное позиционирование может выполняться в среде с несколькими базисными линиями, где базисные линии определяются между многочисленными устройствами.
[0005] Самая простая форма относительного позиционирования включает определение разности позиций между двумя устройствами. Однако в основном относительное позиционирование включает высокоточные методы, которые, как правило, достигают субдециметрового уровня точности. Одним таким коммерчески используемым высокоточным методом является кинематическая съемка в режиме реального времени (Real-Time Kinematic, RTK). Метод RTK основан на получении измерений фазы непрерывной периодической несущей и/или кода от двух приемников системы GNSS, которые могут быть терминалами, виртуальными опорными приемниками (virtual reference receiver, VRR) и/или физическими опорными приемниками, и линейного комбинирования измерений от приемников таким образом, что синфазные погрешности компенсируются. Например, когда базисная линия является короткой, атмосферные погрешности (из-за тропосферы, ионосферы) исключаются почти полностью.
[0006] При профессиональном использовании для относительного позиционирования обычно используются двухчастотные приемники GPS. Двухчастотная возможность позволяет, например, осуществить компенсацию остаточных погрешностей ионосферы. Альтернативно и в случаях, когда базисная линия короткая и синфазные погрешности могут считаться компенсированными, могут использоваться одночастотные приемники.
Соответственно, чем короче базисная линия, тем более прямым и более простым получается точное решение базисной линии.
[0007] Как упомянуто, измерения позиционирования могут выполняться между терминалами и приемниками VRR. Приемники VRR являются расчетными опорными приемниками, которые создаются в желаемом месте и предоставляются запрашивающему посредством службы VRR. В некоторых случаях служба VRR создает единственный VRR по запросу для желаемого местоположения. В других случаях служба VRR обеспечивает большое количество приемников VRR в статической сетке. Таким образом, когда терминал должен быть позиционирован относительно приемника VRR, из статической сетки выбирается наиболее близкий к терминалу приемник VRR. Следует отметить, что приемники VRR требуют знания грубого местоположения устройства, которое необходимо позиционировать. Это грубое местоположение может быть получено с помощью обычной системы GNSS с использованием вспомогательных данных (Assisted GNSS, AGNSS).
[0008] В одной обычной опции развертывания провайдер службы VRR может использовать сеть физических приемников GNSS для получения опорных измерений. Эти опорные измерения могут использоваться для того, чтобы дать возможность провайдеру службы VRR создать приемник VRR в любом заданном месте в пределах области, охваченной сетью GNSS. Преимущество этого подхода заключается в том, что VRR может создаваться в местоположении терминала, который должен позиционироваться относительно приемника VRR. Следовательно, базисная линия будет очень короткой, и вследствие ее вычислительной природы местоположение VRR известно очень точно. Таким образом, расчет базисной линии между приемником VRR и терминалом позволяет определять абсолютное местоположение терминала с очень высоким уровнем точности.
[0009] В контексте долгосрочной эволюции сетей связи (Long Term Evolution, LTE), технологии подвижной радиосвязи 4-го поколения, позиционирование на основе GNSS включает протокол позиционирования LTE (LTE Positioning Protocol, LPP). Говоря с точки зрения архитектуры, LPP является протоколом между "целевым устройством" (target) и "сервером". Целевое устройство обычно является оборудованием пользователя (User Equipment, UE), которое необходимо позиционировать, а сервер обычно является узлом, который предоставляет команды позиционирования и вспомогательные данные для целевого устройства. Следует понимать, что используемое здесь оборудование UE является примером целевого устройства. Кроме того, должно быть понятно, что UE с точки зрения протокола LPP могут служить и целевыми устройствами, и серверами. Например, при относительном позиционировании между двумя UE одно UE можно считать сервером, а другое UE можно считать целевым устройством. В этой схеме оборудование UE, функционирующее как сервер, может запрашивать измерения фазы кода/несущей от другого оборудования UE, функционирующего как целевое устройство. Оборудование UE, функционирующее как сервер, может таким образом определить базисную линию между двумя UE с высокой точностью на основании измерений фазы кода/несущей от другого оборудования UE, функционирующего как целевое устройство.
[0010] Чтобы происходило позиционирование с высокой точностью, постоянный поток вспомогательных данных опорного измерения должен течь от сервера к целевому устройству. В спецификации LPP (описанной в документе 3GPP TS 36.355 Stage 3, находящейся на веб-сайте организации "Проект сотрудничества по созданию системы третьего поколения" (3-rd Generation Partnership Project, 3GPP) это происходит посредством того, что целевое устройство посылает серверу запрос, называемый сообщением запроса вспомогательных данных (Request Assistance Data) LPP. Сервер принимает это сообщение и отвечает сообщением предоставления вспомогательных данных (Provide Assistance Data) LPP. Хотя спецификация LPP разрешает многочисленные последовательные сообщения предоставления вспомогательных данных LPP, целевое устройство в настоящее время не может запрашивать такие непрерывные периодические вспомогательные данные.
[0011] В дополнение к типичному взаимодействию "запрос"-"предоставление", спецификация LPP допускает также незапрашиваемое предоставление вспомогательных данных, при этом сервер принудительно посылает вспомогательные данные целевому устройству без предварительного запроса их целевым устройством. Это полезно, когда сервер знает, что целевое устройство, вероятно, запросит некоторые вспомогательные данные, например, в таком сеансе системы GNSS на основе оборудования UE, в котором сервер может быть уверен, что после подачи команды на позиционирование таким способом целевое устройство запросит эфемериды. Таким образом, сервер может действовать упреждающе и принудительно посылать вспомогательные данные в терминал без явного запроса.
[0012] В спецификации LPP обмен сообщениями основан на транзакциях в сеансе LPP. Сеанс LPP используется для поддержки одного запроса местоположения и состоит из транзакций каждая из которых выполняет единственную операцию. Например, в случае инициируемой оборудованием UE доставки вспомогательных данных, транзакция LPP состоит из сообщения LPP Request Assistance Data (от целевого устройства к серверу) и одного или нескольких сообщений LPP Provide Assistance Data (от сервера к целевому устройству). То есть транзакция LPP состоит из одного сообщения запроса и одного или нескольких сообщений предоставления (или, в случае без запроса, одного или нескольких сообщений предоставления).
[0013] В случаях, когда целевое устройство должно быть точно позиционировано относительно конкретного приемника VRR (то есть относительного позиционирования на основе VRR), имеются по меньшей мере две альтернативные опции применения. В первой опции применения служба VRR обеспечивает платформу определения местоположения защищенной пользовательской плоскости (Secure User Plane Location Protocol Location Platform, SLP) со статической сеткой приемников VRR. Например, служба VRR может обеспечить платформу SLP приемниками VRR в 10-километровой сетке для некоторой географической области. Когда целевое устройство затем должно быть позиционировано, сервер выбирает приемник VRR, наиболее близкий к целевому устройству, и начинает предоставление данных опорных измерений от этого приемника VRR целевому устройству. Во второй опции применения приемник VRR динамически создается на основании запроса от целевого устройства, и данные измерения предоставляются относительно этого приемника VRR.
[0014] Принимая во внимание подвижную природу различных узлов, включенных в протокол LPP, имеются ситуации, в которых является необходимым и/или выгодным сменить приемник VRR, связанный с целевым устройством. Например, приемник VRR, возможно, должен быть сменен, когда расстояние между ним и целевым устройством слишком велико, например, из-за перемещения целевого устройства. Это особенно верно в случаях, где целевое устройство является одночастотным приемником и поэтому требует короткой базисной линии, чтобы сохранить хорошее качество (как упомянуто выше). Другой пример того, когда приемник VRR, возможно должен быть сменен, имеет место, когда линия прямой видимости между спутником и целевым устройством нарушается. Например, когда видимость между спутником и целевым устройством низка или когда выгодно иметь ориентацию базисной линии в определенном направлении, целевое устройство может решить сменить приемник VRR, чтобы получить более стабильную базисную линию.
Сущность различных форм осуществления изобретения
[0015] Различные формы осуществления изобретения направлены на процессы для оперативной и эффективной смены приемника VRR, связанного с конкретным целевым устройством. В первом сценарии целевое устройство знает о находящихся поблизости приемниках VRR (с помощью списка соседей) и запрашивает новую транзакцию для переключения на "новый" приемник VRR. Во втором сценарии целевое устройство запрашивает новую транзакцию для переключения на "новый" приемник VRR, но не знает о находящихся поблизости приемниках VRR. В третьем сценарии целевое устройство знает о находящихся поблизости приемниках VRR (с помощью списка соседей) и изменяет происходящую транзакцию для перехода на "новый" приемник VRR. В четвертом сценарии целевое устройство также изменяет происходящую транзакцию для перехода на "новый" приемник VRR, но не знает о находящихся поблизости приемниках VRR. Таким образом, различные формы осуществления изобретения сменяют приемник VRR в пределах того же самого сеанса передачи вспомогательных данных, и непрерывность опорных измерений гарантируется с помощью выполнения "мягкого хэндовера" при переключении со "старого" приемника VRR на "новый" приемник VRR. В первом и втором сценариях это включает запуск новой транзакции дополнения для "нового" приемника VRR, а в третьем и четвертом сценариях это включает использование элемента модификации в сигнализации о переключениях.
[0016] Различные формы осуществления изобретения предлагают способ, устройство и программное изделие для компьютера, предназначенные для определения того, что вспомогательные данные, принимаемые относительно первого опорного приемника, должны быть заменены вспомогательными данными относительно второго опорного приемника. Сообщение запроса передается на сервер, запрашивающий вспомогательные данные относительно второго опорного приемника. Вспомогательные данные для первого опорного приемника и второго опорного приемника принимают с сервера. Тогда определяется измерение относительно второго опорного приемника, и сервер запрашивают прекращение передачи вспомогательных данных для первого опорного приемника.
[0017] Различные формы осуществления изобретения предлагают также способ, устройство и программное изделие для компьютера для приема на сервере сообщения запроса, запрашивающего вспомогательные данные относительно второго опорного приемника. Определяется, могут ли быть предоставлены запрашиваемые вспомогательные данные относительно второго опорного приемника. Если запрашиваемые вспомогательные данные могут быть предоставлены, вспомогательные данные относительно второго опорного приемника передают в дополнение к вспомогательным данным относительно первого опорного приемника. Дополнительно в ответ на прием запроса на прекращение передачи вспомогательных данных относительно первого опорного приемника прекращается передача таких вспомогательных данных.
[0018] Хотя следующее описание различных форм осуществления изобретения сосредоточено на смене приемников VRR в контексте протокола LPP, должно быть понятно, что он приводится просто в качестве примера и общие принципы применимы к любому протоколу позиционирования.
[0019] Эти и другие преимущества и особенности изобретения вместе со структурой и способом его работы станут более очевидными из следующего подробного описания, приводимого вместе с прилагаемыми чертежами, на которых подобные элементы имеют подобные номера позиций всюду на нескольких чертежах, описанных ниже.
Краткое описание чертежей
[0020] Различные формы осуществления изобретения описаны со ссылкой на прилагаемые чертежи, на которых:
[0021] Фиг.1 - общая схема системы, в которой могут быть реализованы различные формы осуществления изобретения.
[0022] Фиг.2 - перспективное изображение электронного устройства, которое может использоваться совместно с реализацией различных форм осуществления.
[0023] Фиг.3 - схематическое представление электрической схемы, которая может быть включена в состав электронного устройства фиг.2.
[0024] Фиг.4 поясняет пример аспекта протокола LPP системы 10, показанной на фиг.1.
[0025] Фиг.5 поясняет пример реализации различных форм осуществления изобретения.
[0026] Фиг.6 - блок-схема, иллюстрирующая пример реализации различных форм осуществления, в которых целевое устройство имеет список соседей.
[0027] Фиг.7 - блок-схема, показывающая пример реализации различных форм осуществления, в которых целевое устройство не имеет списка соседей.
[0028] Фиг.8 - блок-схема, показывающая пример реализации различных форм осуществления, в которых целевое устройство имеет список соседей.
[0029] Фиг.9 - блок-схема, показывающая пример реализации различных форм осуществления, в которых целевое устройство не имеет списка соседей.
Подробное описание различных форм осуществления изобретения [0030]. На фиг.1 показана система 10, в которой могут использоваться различные формы осуществления изобретения, содержащая многочисленные устройства связи, которые могут осуществлять связь с помощью одной или нескольких сетей. Система 10 может содержать любую комбинацию проводных или беспроводных сетей, включая, но не ограничиваясь этим, сеть подвижной телефонной связи (например, глобальную систему мобильной связи (Global System for Mobile Communications, GSM), систему на основе широкополосного множественного доступа с кодовым разделением (Wideband Code Division Multiple Access, W-CDMA), систему на основе множественного доступа с кодовым разделением (Code Division Multiple Access, CDMA), систему на основе стандарта долгосрочной эволюции сетей связи (LTE), систему по технологии сверхширокополосной подвижной связи (Ultra Mobile Broadband, UMB), систему высокоскоростной пакетной передачи данных (High Rate Packet Data, HRPD) и систему по технологии глобальной совместимости для микроволнового доступа (Worldwide Interoperability for Microwave Access, WiMax), беспроводную локальную сеть (Local Area Network, LAN), персональную локальную сеть Bluetooth, локальную сеть Ethernet, локальную сеть кольцевой структуры с передачей маркера (token ring LAN), территориально распределенную сеть, Интернет и т.д. Система 10 может содержать устройства как проводной, так и беспроводной связи.
[0031] Например, показанная на фиг.1 система 10 включает сеть 11 подвижной телефонной связи и Интернет 28. Способность подключения к сети 28 Интернет может включать, но не ограничивается этим, беспроводные соединения большой дальности, беспроводные соединения малой дальности и различные проводные соединения, включая, но не ограничиваясь этим, телефонные линии, кабельные линии, силовые линии и т.п.
[0032] Приводимые в качестве примера устройства связи или оборудование UE системы 10 могут включать, но не ограничиваются этим, электронное устройство 12, комбинацию персонального цифрового помощника (Personal Digital Assistant, PDA) и мобильного телефона 14, PDA 16, устройство интегрированного обмена сообщениями (Integrated Messaging Device, IMD) 18, настольный компьютер 20, портативный компьютер 22 типа ноутбук и т.д. Устройства связи могут быть как фиксированными, так и мобильными, например переносимыми передвигающимся человеком. Устройства связи могут быть установлены также в каком-либо виде транспорта, включая, но не ограничиваясь этим, в автомобиле, грузовике, такси, автобусе, в поезде, на судне, в самолете, велосипеде, мотоцикле и т.п. Некоторые или все устройства связи могут посылать и принимать вызовы и сообщения и обмениваться информацией с провайдерами услуг через беспроводное соединение 25 с базовой станцией 24. Базовая станция 24 может быть соединена с сетевым сервером 26, обеспечивающим связь между мобильной телефонной сетью 11 и Интернетом 28. Система 10 может включать дополнительные устройства связи и устройства связи различных типов.
[0033] Устройства связи могут обмениваться информацией с помощью различных технологий, включая, но не ограничиваясь этим, такие как CDMA, GSM, универсальная система мобильных телекоммуникаций (Universal Mobile Telecommunications System, UMTS), множественный доступ с временным разделением каналов (Time Division Multiple Access, TDMA), множественный доступ с частотным разделением каналов (Frequency Division Multiple Access, FDMA), WiMax, протокол управления передачей/протокол Интернет) (Transmission Control Protocol/Internet Protocol, TCP/IP), служба обмена короткими сообщениями (Short Messaging Service, SMS), служба обмена мультимедийными сообщениями (Multimedia Messaging Service, MMS), электронная почта, служба обмена мгновенными сообщениями (Instant Messaging Service, IMS), Bluetooth, IEEE 802.11 и т.п. Устройство связи, применяемое при реализации различных форм осуществления данного изобретения, может обмениваться информацией с использованием различных сред включая, но не ограничиваясь этим, радио, инфракрасные, лазерные, кабельные соединения и т.п.
[0034] На фиг.2 и 3 показано одно типичное электронное устройство или оборудование UE 12, в котором различные формы осуществления изобретения могут быть реализованы и/или использованы совместно с реализацией различных форм осуществления. Однако следует понимать, что различные формы осуществления изобретения не обязательно ограничены одним конкретным типом устройства. Электронное устройство или оборудование UE 12, показанное на фиг.2 и 3, содержит корпус 30, дисплей 32 в виде дисплея на жидких кристаллах, клавиатуру 34, микрофон 36, динамик 38, батарею 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде универсальной карты на интегральных микросхемах (Universal Integrated Circuit Card, UICC) согласно одной форме осуществления изобретения, устройство 48 считывания карт, электронные схемы 52 радиоинтерфейса, электронные схемы 54 кодека, контроллер 56 и запоминающее устройство 58. Используются отдельные схемы и элементы, хорошо известные в данной области техники.
[0035] Фиг.4 поясняет аспект протокола LPP показанной на фиг.1 системы 10, включающей целевое устройство 410, первый приемник VRR 420 (то есть расчетный опорный приемник в противоположность физическому опорному приемнику), второй приемник VRR 430, сервер 440, службу VRR 450, сеть GNSS 460 (например, содержащую физические приемники GNSS) и различные космические аппараты (space vehicles, SV) GNSS 470. Система может использоваться для высокоточного позиционирования целевого устройства 410. Более точно, система может использоваться для высокоточного позиционирования целевого устройства 410 относительно приемника VRR 420, 430. Как указано выше, эти приемники VRR 420, 430 могут динамически создаваться по запросу или могут предоставляться как часть сетки приемников VRR, которую служба VRR производит для использования платформы SLP 450 (то есть платформы определения местоположения с использованием протокола определения местоположения защищенной пользовательской плоскости (Secure User Plane for Location, SUPL). Платформа SLP является платформой определения местоположения, которая функционирует как оконечная точка и для протокола определения местоположения плоскости пользователя (User Plane Location Protocol, ULP), который является протоколом определения местоположения SUPL организации Открытый мобильный альянс (Open Mobile Alliance, ОМА), и для LPP. Протокол SUPL является протоколом определения местоположения, стандартизированным организацией ОМА, который предоставляет те же самые функциональные возможности в плоскости пользователей в такой сети на основе протокола Интернет (Internet Protocol, IP), которые протоколы позиционирования плоскости управления предоставляют в плоскости управления. В дополнение к позиционированию протокол SUPL также обеспечивает, среди других функциональных возможностей, функциональные возможности аутентификации, защиты и начисления платы. С точки зрения стека протоколов протокол LPP инкапсулируется в ULP, то есть протокол ULP является протоколом переноса информации для LPP.
[0036] Фиг.5 поясняет пример процесса переключения с первого приемника VRR 520 на второй приемник VRR 530. Целевое устройство 510 начинает с первой фиксированной базисной линии 540 относительно первого приемника VRR 520. Используемый здесь термин "фиксированная базисная линия" означает, что неоднозначности целого числа фазовых циклов разрешаются и фиксируются на их целых значениях. Это позволяет решение базисной линии с высокой точностью. В случаях, когда неоднозначности не могут быть фиксированы, может использоваться также плавающее решение базисной линии. Хотя и не столь точная как фиксированная базисная линия, плавающая базисная линия может быть решена в большинстве обстоятельств, тогда как фиксированная базисная линия требует условий хорошего сигнала GNSS. Когда плавающая базисная линия решается относительно близлежащего приемника VRR, это производит более точное решение позиции, чем обычная технология AGNSS. Целевое устройство 510 затем определяет потребность в смене приемника VRR. Целевое устройство 510 запрашивает измерения у сервера 550 для второго приемника VRR 530, то есть, например, более близкого к целевому устройству 510, чем первый приемник VRR 520. Целевое устройство 510 затем начинает принимать опорные измерения и для первого приемника VRR 520 и для второго приемника VRR 530. Эта ситуация позволяет непосредственно определить вторую базисную линию 560, потому что местоположения первого приемника VRR 520, второго приемника VRR 530 и первой базисной линии 540 известны: (вторая базисная линия 560)=(первая базисная линия 540)+((второй VRR 530)-(первый VRR 520)). Это знание второй базисной линии 560 делает возможным легкое разрешение новых неоднозначностей целого числа. Как только целевое устройство 510 уверено, что оно захватило новую базисную линию (то есть вторую базисную линию 560) и связанные с ней неоднозначности целого числа, целевое устройство 510 запрашивает сервер 550 остановить предоставление измерений для первого приемника VRR 520. Таким образом, в общем, при смене приемника VRR измерения базисной линии для "старого" и "нового" приемника VRR принимают в течение короткого времени, давая время для определения необходимых параметров (неоднозначности целого числа и базисной линии) относительно "нового" приемника VRR до завершения измерений для "старого" приемника VRR.
[0037] Есть по меньшей мере четыре сценария выполнения смены приемника VRR, каждый из которых подробно рассматривается ниже. Следует понимать, что эти четыре сценария - не единственные сценарии и что большее число сценариев предполагается в соответствии с различными формами осуществления. Первые два сценария включают запуск "новой" транзакции, чтобы совершить смену приемника VRR, и все вместе упоминаются в дальнейшем как "Вариант 1". Другие два сценария включают передачу информационного элемента Modify ("Модифицировать") в вышеупомянутом сообщении LPP Request Assistance Data для выполнения смены приемника VRR, и все вместе упоминаются в дальнейшем как "Вариант 2". В некоторых случаях элемент IE Modify инкапсулируется в сообщения запроса, тогда как в других случаях элемент IE Modify находится в сообщении нового типа. С Вариантом 1 фактическая смена приемника VRR выполняется целевым устройством, запрашивающим поддержку опорного измерения для "нового" приемника VRR (то есть новой транзакции) и останавливающим поддержку измерения для "старого" приемника VRR, когда хэндовер заканчивается. С Вариантом 2 параметры текущего сеанса модифицируются, и нет никакой потребности запускать другую транзакцию.
[0038] В поддерживаемой оборудованием UE простой ситуации, в которой вычисление позиции выполняется на сервере и оборудование UE только предоставляет запрашиваемые измерения серверу, платформа SLP имеет информацию о базисной линии и может предпринять необходимые шаги внутренне, без взаимодействия с оборудованием UE. Таким образом, нет никакой разницы между Вариантом 1 и Вариантом 2 для ситуаций, поддерживаемых оборудованием UE. Однако в ситуации на основе оборудования UE вычисление позиции выполняется в оборудовании UE и поэтому должна рассматриваться архитектура развертывания приемника VRR, показанная на фиг.4. Как объяснено выше, одной опцией является динамическое создание приемников VRR по запросу, а другой является наличие службы VRR, создающей сетку приемников VRR для использования платформой SLP. Поскольку динамическое создание приемника VRR по запросу и создание сетки VRR для использования платформы SLP различаются, обе опции исследуются ниже перед подробным обсуждением сигнализации, используемой при смене приемника VRR в контексте Варианта 1 и Варианта 2.
[0039] Что касается опции сетки, то если платформа SLP имеет сетку приемников VRR, из которой можно выбирать, сервер может предоставлять целевому устройству самый близкий приемник VRR, когда целевое устройство запрашивает поддержку опорного измерения сообщением LPP Request Assistance Data. Следует отметить, что в этом случае местоположение целевого устройства предполагается известным с некоторой точностью, например, на основании обычной коррекции AGNSS. Когда сервер отвечает поддержкой опорных измерений в сообщении LPP Provide Assistance Data, сервер может предоставлять также список соседей, "находящихся рядом" приемников VRR, таким образом позволяя целевому устройству принять решение относительно того, на какой приемник VRR переключиться в случае необходимости. Заметим, что приемники VRR в списке соседей связаны с идентификаторами или уникальными номерами так, что целевое устройство может указать на конкретный приемник VRR при запросе на смену приемника VRR. В дополнение к вышеописанному, сервер мог бы снабжать целевое устройство списком соседей в случаях, когда сервер не имеет сетки приемников VRR, но обеспечивает приемник VRR для другого целевого устройства поблизости. В таком случае в предоставляемом списке соседей может быть также индикация срока службы или продолжительности, связанная с приемником VRR.
[0040] Таким образом, и с учетом Варианта 1 (то есть когда смена приемника VRR запускает "новую" транзакцию), список соседей работает как руководящая информация для целевого устройства относительно того, когда выгодно сменить приемник VRR. В Варианте 2 (то есть когда смена приемника VRR выполняется передачей информационного элемента Modify в сообщении LPP Request Assistance Data) включение списка соседей указывает целевому устройству, что сервер способен к смене приемника VRR и что сервер способен предоставлять опорные измерения для двух приемников VRR одновременно. Заметим, что эта возможность не имеет значения в варианте 1, так как две транзакции (старая и новая) более или менее независимы друг от друга.
[0041] Переходя к опции динамического создания (то есть опции динамического создания приемников VRR по запросу) применительно к Варианту 1, целевое устройство запрашивает другой приемник VRR в новой позиции. В этом случае для целевого устройства полезно сообщить серверу идентификатор ID (identifier, ID) транзакции выполняемого потока VRR. Эта информация уведомляет сервер о том, что целевое устройство выполняет хэндовер, и поэтому сервер не должен случайно закончить текущий поток VRR, запустив предоставление нового потока VRR. Кроме того, при обращении к идентификатору ID транзакции текущего сеанса VRR сервер может непосредственно взять некоторые подготовленные параметры (например, для каких систем GNSS и сигналов предоставлять поддержку) из текущего сеанса для нового сеанса. В Варианте 2 опция для выполнения опции динамического создания должна включать в сообщение LPP Provide Assistance Data от сервера к целевому устройству индикацию того, что целевое устройство может запросить смену приемника VRR, то есть что сервер способен предоставить опорные измерения для двух приемников VRR одновременно.
[0042] Следует отметить, что современная спецификация протокола LPP (Релиз 9) допускает только одно сообщение Assistance Data Request LPP на транзакцию. Таким образом, и как было упомянуто, транзакция в настоящее время состоит из одного сообщения запроса и одного или нескольких сообщений предоставления (или, в случаях без запроса, одного или нескольких сообщений предоставления). Соответственно, в Варианте 1 обязательно будет новая транзакция, потому что передается новое сообщение запроса. Наоборот, в Варианте 2 не будет никакой новой транзакции, а будет модификация текущей транзакции. Независимо от варианта сообщение запроса может содержать идентификатор ID соты / позицию, чтобы приемник VRR мог быть назначен оборудованию UE. Когда в запросе нет информации о позиции, сервер может начинать сеанс позиционирования с целевым устройством так, чтобы сервер получил, например, грубую позицию целевого устройства. В сообщении LPP Assistance Data Request оборудование UE может определить желаемое максимальное расстояние до приемника VRR (то есть "Качество Опоры" (Quality of Reference)). Это расстояние до приемника VRR может оказывать прямое влияние на качество высокоточного определения позиции.
[0043] В свете вышеизложенного сообщение LPP Provide Assistance Data от сервера для поддержки опорного измерения VRR в дополнение к другой возможной информации применительно к Варианту 1 может включать следующее:
[0044] (i) поддержку опорного измерения для текущего приемника VRR;
[0045] (ii) список соседей, то есть координаты ближайших приемников VRR; и
[0046] (iii) команду хэндовера для принудительного хэндовера (рассматриваемого ниже).
[0047] Применительно к Варианту 2 сообщение LPP Provide Assistance Data от сервера для поддержки опорного измерения VRR может включать следующее:
[0048] (i) поддержку опорного измерения для текущего приемника VRR;
[0049] (ii) поддержку опорного измерения для приемника VRR, на который переключается "целевое устройство";
[0050] (iii) список соседей, то есть координаты ближайших приемников VRR; и
[0051] (iv) индикацию того, что "целевое устройство" может запросить смену приемника VRR.
[0052] Теперь обратимся к действительной сигнализации для смены приемника VRR, ниже приводится подробное рассмотрение в отношении сигнализации для Варианта 1 и Варианта 2. Каждый вариант разделяется на два сценария исходя из того, имеет ли целевое устройство список соседей.
Вариант 1, Сценарий 1
[0053] Как упомянуто выше, в Варианте 1 фактическая смена приемника VRR выполняется посредством запроса поддержки опорного измерения для "нового" приемника VRR и затем остановки доставки поддержки измерения для "старого" приемника VRR, когда хэндовер закончен. В случаях, когда целевое устройство решило, что требуется сменить приемник VRR, и оно имеет список соседей, включающий координаты возможных приемников VRR, целевое устройство инициирует новую транзакцию, посылая серверу сообщение LPP Request Assistance Data. В сообщение запроса целевое устройство включает элемент 1Е (information element, IE) RefStationChangeRequest. Элемент 1Е RefStationChangeRequest включает TransactionID (идентификатор транзакции) текущего потока вспомогательных данных приемника VRR. Причиной для включения TransactionID текущего потока вспомогательных данных приемника VRR была объяснена выше, то есть - не позволять серверу остановить поток для "старого" или текущего приемника VRR немедленно после начала предоставления "нового потока". Дополнительно в элемент IЕ RefStationChangeRequest включается newRefStationReqWithID, который обеспечивает целевое устройство идентификатором ID "нового" приемника VRR, на который целевое устройство желает переключиться. Целевое устройство получает эту информацию идентификатора ID из списка соседей, которым оно обладает. Затем сервер принимает сообщение и в случае, когда сервер может предоставить данные для "нового" приемника VRR, сервер начинает предоставление целевому устройству поддержки опорного измерения приемника VRR согласно запросу. Когда целевое устройство завершило смену приемника VRR, целевое устройство прерывает транзакцию опорной поддержки "старого" приемника VRR путем запроса серверу на прерывание передачи опорных вспомогательных данных для "старого" приемника VRR (например, посредством сообщения LPP Abort (на прекращение выполнения LPP), содержащего соответствующий идентификатор ID транзакции). С другой стороны, когда сервер принимает сообщение и решает, что он не может предоставить данные для нового приемника VRR, сервер прерывает новую транзакцию.
[0054] Фиг.6 - блок-схема, иллюстрирующая процессы, связанные с этой формой осуществления. На шаге 600 целевое устройство со списком соседей решает, что смена необходима или была бы полезна. На шаге 610 целевое устройство посылает серверу сообщение LPP Request Assistance Data, содержащее RefStationChangeRequest, который включает TransactionID потока вспомогательных данных текущего приемника VRR. Дополнительно в поле newRefStationReqWithID, связанное с элементом IE RefStationChangeRequest, целевое устройство включает идентификатор приемника VRR из списка соседей, на который целевое устройство хотело бы переключиться. На шаге 620 сервер принимает сообщение LPP Request Assistance Data и определяет, может ли он предоставить запрашиваемую поддержку опорного измерения. Если сервер не может предоставить запрашиваемую поддержку опорного измерения, то он прерывает новую транзакцию на шаге 630. Однако если сервер может предоставить запрашиваемую поддержку опорного измерения, сервер начинает на шаге 640 предоставление запрашиваемой поддержки опорного измерения для "нового" приемника VRR в новой транзакции в дополнение к поддержке опорного измерения, уже предоставляемой для "старого" приемника VRR в текущей транзакции. На шаге 650, как только целевое устройство успешно переключилось на "новый" приемник VRR, оно прерывает транзакцию опорной поддержки "старого" приемника VRR. Как упомянуто выше, это может быть достигнуто посылкой сообщения LPP Abort с идентификатором ID транзакции, которую необходимо прервать.
Вариант 1, Сценарий 2
[0055] Далее в соответствии с различными формами осуществления изобретения описываются случаи, когда целевое устройство не имеет списка соседей. Отсутствие списка соседей может быть следствием множества причин, включая архитектуру, имеющую динамические приемники VRR, или потому что сервер просто не включил список соседей в сообщение. Хотя описанное ниже относится к случаям, когда список соседей отсутствует, должно быть понятно, что нижеописанный процесс может произойти, даже когда целевое устройство имеет список соседей.
[0056] В этом варианте целевое устройство функционирует способом, аналогичным описанному выше, отличие заключается в том, что элемент IE RefStationChangeRequest вместо упомянутого выше newRefStationReqWithID включает элемент IE newRefStationReqWithCoords, который указывает позицию для нового приемника VRR в значениях координат. Одной причиной для использования/предоставления координат вместо конкретного идентификатора является то, что целевое устройство в этом сценарии не обладает списком соседей и поэтому не знает идентификаторы ID соседних приемников VRR.
[0057] Следует отметить, что в некоторых сценариях целевое устройство может запрашивать новый приемник VRR в месте, которое отличается от текущего местоположения целевого устройства. Например, целевое устройство может запрашивать местоположение на основании планируемого перемещения целевого устройства.
[0058] Фиг.7 - блок-схема, иллюстрирующая процессы, связанные с этой формой осуществления изобретения. На шаге 700 целевое устройство решает, что смена необходима и/или была бы полезна. Как упомянуто выше, целевое устройство может обладать или не обладать списком соседей. На шаге 710 целевое устройство посылает серверу сообщение LPP Request Assistance Data (запрос вспомогательных данных LPP). Сообщение LPP Request Assistance Data содержит TransactionID и newRefStationReqWithCoords. TransactionID включает идентификатор ID потока вспомогательных данных текущего приемника VRR. А элемент IE newRefStationReqWithCoords включает желаемые координаты для "нового" приемника VRR. На шаге 720 сервер принимает сообщение LPP Request Assistance Data и определяет, может ли он предоставить запрашиваемую поддержку опорного измерения. Если сервер не может предоставить запрашиваемую поддержку опорного измерения, он прерывает новую транзакцию на шаге 730. Однако если сервер может предоставить запрашиваемую поддержку опорного измерения, сервер начинает на шаге 740 предоставление запрашиваемой поддержки опорного измерения в новой транзакции для "нового" приемника VRR в запрашиваемом местоположении в дополнение к поддержке опорного измерения, уже предоставляемой в текущей транзакции для "старого" приемника VRR. На шаге 750, как только целевое устройство успешно переключилось на "новый" приемник VRR, оно прерывает транзакцию опорной поддержки "старого" приемника VRR.
[0059] Ниже приводится листинг примера информационных элементов для Варианта 1. Этот приводимый в качестве примера код на формальном языке абстрактного описания синтаксиса версии 1 (Abstract Syntax Notation One, ASN. I) поясняет пример реализации различных форм осуществления изобретения. Следует отметить, что приводимый ниже код ASN.I поясняет пример нотации, которая описывает структуру данных, например, для представления кодирования/декодирования и передачи данных в соответствии с различными формами осуществления. Также должно быть понятно, что представленный ниже пример кода ASN.1 может определять сообщения для использования в соответствующем протоколе связи, давая в результате двоичное кодирование путем использования некоторого числа правил кодирования, например, ASN.1.
Пример информационных элементов. Вариант 1
Request:: = SEQUENCE {
transactionID
TransactionID,
requestOfHaAssistance
RequestOfHaAssistance,
}
RequestOfHaAssistance:: = SEQUENCE {
refStationReq
RefStationReq OPTIONAL,
refStationChangeRequest
RefStationChangeRequest
OPTIONAL,
}
RefStationReq:: = SEQUENCE {
coordinates Coordinates,--Местоположение, для которого запрашивается опорная станция
measurementsRequested MeasurementsRequested,--Определяет запрашиваемые системы GNSSs и сигналы
qualityOfRefStation QoR OPTIONAL,--Максимальное расстояние до опорной станции
}
RefStationChangeRequest:: = SEQUENCE {
CurrentTransaction TransactionID,
newRefStationReqWithCoords RefStationReq OPTIONAL,--3anpoc с координатами
newRefStationReqWithId RefStationID OPTIONAL,--3anpoc с ID
Provide:: = SEQUENCE {
transactionID TransactionID,
provideHaAsssistance ProvideHaAsssistance,
}
ProvideHaAsssistance:: = SEQUENCE {
measurements
Measurements,
neighborlist
Neighborlist OPTIONAL,
handOverCommand
TransactionID OPTIONAL,
}
Measurements:: = SEQUENCE {
gNSSMeasurements GNSSMeasurements,--Содержит измерения фазы несущей/фазы кода для запрашиваемых GNSS и сигналов, которые "сервер" мог вывести, чтобы послать на основании, скажем, возможностей "целевого устройства", предоставляемых "серверу" в LPP Provide Capabilities или на основании параметров в запросе
coordinates
Coordinates,"Координаты VRR
}
NeighborList:: = SEQUENCE(1..16) OF Neighbor-ЗАМЕЧАНИЕ: "16" соседей приведено в качестве примера
Neighbor:: = SEQUENCE {
Coordinates
Coordinates,
refStationId
RefStationID,
}
RefStationID:: = INТЕОЕР(0…65535)--Замечание: "65535" идентификаторов ID - это приводимый в качестве примера диапазон
TransactionID:: = IМТЕСЕR(0…255)--Замечание:: "255" идентификаторов ID транзакций приведены в качестве примера.
Вариант 2. Форма осуществления 3
[0060] Как рассмотрено ранее, Вариант 2 отличается от Варианта 1 тем, что фактическая смена приемника VRR выполняется информационным элементом Modify в сообщении LPP Request Assistance Data. Задачей элемента IE Modify является смена параметров (то есть используемого приемника VRR) текущего сеанса. В этом случае предполагается, что транзакция LPP может фактически включать многочисленные сообщения LPP Request Assistance Data, то есть новое сообщение запроса не запускает новую транзакцию. Таким образом, элемент IE Modify может быть встроен в сообщение LPP Request Assistance Data. Поэтому когда целевое устройство желает модифицировать параметры, оно может просто послать сообщение LPP Request Assistance Data серверу и не запускать новую транзакцию. Это сообщение запроса с элементом IE Modify имеет тот же самый идентификатор ID транзакции, что и текущая транзакция, и, следовательно, сервер может связать запрос модификации с правильной транзакцией.
[0061] Следует понимать, что этот элемент IE Modify может быть также сообщением своего собственного типа, таким как LPP Modify Assistance Data. Это сообщение тогда используется аналогично элементу IE Modify, подробно описываемому ниже. Естественно LPP Modify Assistance Data тогда имеет тот же самый идентификатор транзакций, что и текущая транзакция вспомогательных данных, позволяя серверу связать запрос модификации с правильной транзакцией.
[0062] В случаях, когда целевое устройство имеет список соседей (включая координаты возможных приемников VRR поблизости), целевое устройство знает, по меньшей мере, неявно, что сервер способен осуществлять сигнализацию, необходимую для смены приемника VRR. Таким образом, целевое устройство посылает первое сообщение LPP Request Assistance Data с элементом IE Modify, запрашивающим смену приемника VRR и включающим идентификатор одного из приемников VRR из списка соседей в элементе IE changeTo. В ответ сервер, в дополнение к уже предоставляемой поддержке опорного измерения, начинает предоставлять поддержку опорного измерения для приемника VRR, указанного в элементе IE Modify. Целевое устройство затем выполняет необходимые шаги для смены приемника VRR. Сделав это, целевое устройство посылает серверу второе сообщение LPP Request Assistance Data с элементом IE Modify, в котором целевое устройство командует серверу с помощью элемента IЕ остановки остановить передачи измерений для "старого" приемника VRR. Таким образом, в дополнение к приемникам VRR в списке соседей, требующих уникальных идентификаторов ID, активный или "старый" приемник VRR также требует идентификатора ID, чтобы целевое устройство могло назвать VRR при запросе для сервера остановить предоставление измерений. Альтернативно можно заканчивать передачу измерений для "старого" приемника VRR, указывая координаты того приемника VRR, который целевое устройство желает остановить. Использование идентификаторов, однако, более эффективно и однозначно.
[0063] Следует отметить, что могут быть ситуации, в которых сервер может быть не способен предоставлять измерения для второго приемника VRR. В таких ситуациях сервер может сигнализировать об этой неспособности целевого устройства с помощью кода ошибки. Альтернативно сервер может просто не предоставлять данные, запрашиваемые для второго приемника VRR. Таким образом, целевое устройство не должно предполагать, что оно будет способно сменить приемник VRR.
[0064] Фиг.8 - блок-схема, иллюстрирующая процессы, связанные с этой формой осуществления изобретения. На шаге 800 целевое устройство со списком соседей решает, что смена приемника VRR необходима и/или была бы полезна. Как упомянуто выше, включение списка соседей является индикацией того, что сервер способен к обработке для смены приемника VRR. На шаге 810 целевое устройство посылает серверу первое сообщение LPP Request Assistance Data с элементом IE Modify, указывающим идентификатор ID "нового" целевого устройства, в отношении которого целевое устройство хотело бы принять вспомогательные данные. На шаге 820 сервер определяет, могут ли быть предоставлены такие вспомогательные данные. Если сервер не может предоставить такие вспомогательные данные, на шаге 830 сервер посылает целевому устройству код ошибки. Альтернативно и как упомянуто выше, сервер может не посылать код ошибки, а может просто не предоставлять вспомогательные данные, которые запрашиваются. Если, однако, сервер может предоставить вспомогательные данные, на шаге 840, сервер предоставляет запрашиваемые вспомогательные данные для "нового" приемника VRR, а также вспомогательные данные для "старого" или текущего приемника VRR. Целевое устройство принимает эту информацию и продолжает переключаться со "старого" приемника VRR на "новый" приемник VRR. Как только этот процесс полностью завершен, на шаге 850 целевое устройство посылает серверу второе сообщение LPP Request Assistance Data с элементом IE Modify и элементом IE остановки, указывающим идентификатор ID "старого" или "активного" приемника VRR, чтобы остановить для него передачу вспомогательных данных.
Вариант 2, Форма осуществления 4
[0065] Для ситуаций, когда целевое устройство решает, что смена приемника VRR необходима и целевое устройство не имеет списка соседей, целевое устройство посылает серверу первое сообщение LPP Request Assistance Data с элементом IE Modify. В отличие от предыдущей ситуации, однако, где в него включен идентификатор ID соседнего приемника VRR, в этой ситуации посылается информация, выраженная в координатах, (текущая или желаемая). То есть вместо того, чтобы давать идентификатор ID приемника VRR как параметр в информационном элементе Modify, при запросе на смену приемника VRR целевое устройство предоставляет координаты. Кроме того, целевое устройство может послать элемент 1Е qualityOfRefStation, определяющий, например, максимально разрешенное расстояние до приемника VRR. Остальные сигналы GNSS могут оставаться одинаковыми с упомянутыми выше. Сервер принимает эту информацию и начинает предоставлять поддержку опорного измерения для двух приемников VRR. Целевое устройство затем выполняет смену приемника VRR и завершает поток поддержки опорного измерения от старого приемника VRR посредством предоставления второго сообщения LPP Request Assistance Data с элементом IE Modify и элементом IE остановки, указывающим идентификатор ID приемника VRR, использование которого должно быть прекращено.
[0066] Следует отметить, что, даже если нет индикации того, что смена приемника VRR возможна, целевое устройство может оставить запрос на смену. Если сервер не может предоставить поддержку для двух приемников VRR одновременно с целью смены, целевое устройство, как рассмотрено выше, примет код ошибки или просто обнаружит отсутствие запрашиваемых вспомогательных данных.
[0067] Также следует отметить, что это является возможным механизмом, даже если имеется фоновое развертывание VRR на основе сетки. Сервер просто сообщит целевому устройству, что смена приемника VRR является возможной (в сообщении LPP Provide Assistance Data) с помощью refStationChangeOk, и целевое устройство тогда запросит новый приемник VRR в желаемом местоположении. Использование refStationChangeOk в сообщении LPP Provide Assistance Data выгодно потому, что текущая реализация протокола LPP (Релиз 9) не имеет определенного сообщения для сервера, чтобы предоставлять его возможности целевому устройству. То есть в протоколе LPP Релиз 9 целевое устройство не может запрашивать возможности сервера, и поэтому посылка refStationChangeOk с сообщением LPP Provide Assistance Data удобна, чтобы сообщить целевому устройству, что сервер способен к поддержке смены приемника VRR.
[0068] Должно быть понятно, однако, что предоставление информации о возможности сервера (например, что сервер способен поддерживать смену приемника VRR) в отдельном сообщении о возможности от сервера к целевому устройству является альтернативной опцией для вышеописанного. То есть альтернативой для предоставления сообщения refStationChangeOk в сообщении LPP Provide Assistance Data является посылка сообщения о возможности сервера от сервера к целевому устройству.
[0069] Фиг.9 - блок-схема, иллюстрирующая процессы, связанные с этой формой осуществления изобретения. На шаге 900 целевое устройство решает, что смена приемника VRR необходима или была бы полезна. На шаге 910 целевое устройство посылает серверу первое сообщение LPP Request Assistance Data с элементом IE Modify, указывающим конкретные координаты и, опционально, информацию о качестве. На шаге 920 сервер определяет, могут ли быть предоставлены такие вспомогательные данные.
Если сервер не может предоставить такие вспомогательные данные, то на шаге 930 сервер посылает целевому устройству код ошибки. Если, однако, сервер может предоставить вспомогательные данные, то на шаге 940 сервер предоставляет запрашиваемые вспомогательные данные для "нового" приемника VRR, а также вспомогательные данные для "старого" или текущего приемника VRR. Целевое устройство принимает эту информацию и продолжает переключение со "старого" приемника VRR на "новый" приемник VRR. Как только этот процесс полностью закончен, на шаге 950 целевое устройство посылает серверу второе сообщение LPP Request Assistance Data с элементом IE Modify и элементом IE остановки, указывающим идентификатор ID того приемника VRR, использование которого необходимо прекратить.
[0070] Ниже приводится листинг примера информационных элементов для Варианта 2. Этот приводимый в качестве примера код на формальном языке абстрактного описания синтаксиса версии 1 (ASN.I) поясняет пример реализации различных форм осуществления изобретения. Следует отметить, что приводимый ниже код ASN.I поясняет пример нотации, которая описывает структуру данных, например, для представления кодирования/декодирования и передачи данных в соответствии с различными формами осуществления. Должно быть понятно, что представленный ниже пример кода ASN.1 может определять сообщения для использования в соответствующем протоколе связи, давая в результате двоичное кодирование путем использования некоторого числа правил кодирования, например, ASN.1.
Пример информационных элементов. Вариант 2
Request:: = SEQUENCE {
transactionID TransactionID,
requestOfHaAssistance RequestOfHaAssistance,
}
RequestOfHaAssistance:: = SEQUENCE {
refStationReq RefStationReq OPTIONAL,
modify Modify OPTIONAL,
}
RefStationReq:: = SEQUENCE {
coordinates Coordinates,--Местоположение, для которого запрашивается опорная станция
measurementsRequested MeasurementsRequested OPTIONAL,--Определяет запрашиваемые системы GNSS и сигналы, сервер может вывести эту информацию также исходя из возможностей целевого устройства
qualityOfRefStation QoR OPTIONAL,--Максимальное расстояние до опорной станции
}
Modify:: = SEQUENCE {
changeTo
ChangeTo OPTIONAL,
stop
RefStationID OPTIONAL,
}
ChangeTo:: = SEQUENCE {
newRefStation
RefStationReq OPTIONAL,
newRefStationId
RefStationID OPTIONAL,
}
Provide:: = SEQUENCE {
transactionID
TransactionID,
provideHaAsssistance ProvideHaAsssistance,
}
ProvideHaAsssistance:: = SEQUENCE {
measurementsList
MeasurementsList,
neighborlist
Neighborlist OPTIONAL,
refStationChangeOk BOOLEAN,
}
MeasurementsList:: = SEQUENCE (1…2) OF Measurements
Measurements:: = SEQUENCE {
gNSSMeasurements GNSSMeasurements,--Содержит измерения фазы несущей/фазы кода для запрашиваемых GNSS и сигналов, которые "сервер" мог вывести на основании, скажем, возможностей "целевого устройства", предоставляемых "серверу" в LPP Provide Capabilities, или на основании параметров в запросе
coordinates
Coordinates,--Координаты VRR
refStationID RefStationID,
}
NeighborList:: = SEQUENCE(1…16) OF Neighbor-ЗАМЕЧАНИЕ: "16"
соседей приведено в качестве примера
Neighbor:: = SEQUENCE {
Coordinates
Coordinates,
refStationId
RefStationID,
}
RefStationID:: = INТЕОЕР(0…65535)--Замечание: "65535" идентификаторов ID - приводимый в качестве примера диапазон
TransactionID:: = INТЕОЕР(0…255)--Замечание: "255" идентификаторов ID транзакций приведены в качестве примера.
[0071] Протокол LPP (Релиз 9) обеспечивает потенциал для переноса возможностей от целевого устройства к серверу. Эти возможности целевого устройства переносятся к серверу в сообщении LPP Provide Capabilities. Сообщение LPP Provide Capabilities может предоставляться в ответ на запрос или без явного запроса от сервера (то есть без запроса). Эти возможности выгодны, потому что, например, они могут помочь определить, какие измерения следует предоставлять целевому устройству. Например, в вышеупомянутых сообщениях запроса вспомогательное поле может использоваться целевым устройством, чтобы указать, какую GNSS и какие сигналы GNSS оно желает принять в поддержке опорного измерения. Таким образом, как указывается в коде ASN.1, если нет никакого measurementsRequested, то сервер определяет, какие измерения предоставлять, на основании обмена сообщениями о возможностях, которые, вероятно, придется запрашивать от целевого устройства. Подводя итоги, можно сказать, что сервер знает, какие измерения предоставлять целевому устройству, или на основании обмена сообщениями запроса/обеспечения возможности, или на основании явного запроса в measurementsReq uested в RefStationReq.
[0072] А именно, при обмене LPP Request/Provide Capabilities (Запроса/Предоставления возможностей LPP) сервер может определить, способно ли целевое устройство к выполнению хэндовера. Как рассмотрено ниже, это знание о хэндовере полезно, например, в случаях принудительного хэндовера. Другим известным элементом, который можно переносить при обмене LPP Request/Provide Capabilities, является возможность целевого устройства к решению со многими базисными линиями, то есть способно ли целевое устройство к приему поддержки опорного измерения для множества приемников и решению базисной линии в отношении всех опорных приемников. Заметьте, что это отличается от смены приемника VRR, но также может использоваться с этой целью.
[0073] Принудительный хэндовер включает решение сервером от имени целевого устройства начать принимать опорные измерения для второго приемника VRR. В ответ на инициирование такого принудительного хэндовера, целевое устройство, как предполагается, переключается на "новый" приемник VRR и прекращает использование "старого" приемника VRR. Принудительный хэндовер может произойти в ситуациях, когда сервер знает базисную линию, то есть когда целевое устройство сообщает базисную линию серверу. На основании этого знания сервер может дать команду на выполнение принудительного хэндовера на новый приемник VRR вследствие проблем ресурсов, производительности, эффективности и т.д.
Вариант 1, Принудительный хэндовер
[0074] В Варианте 1 сервер может дать целевому устройству команду на хэндовер в элементе IE ProvideHaAssistance. Эта команда хэндовера несет с собой идентификатор ID новой транзакции, в которой сервер начинает принудительно предавать целевому устройству информацию поддержки опорного измерения для нового приемника VRR. Как только целевое устройство выполняет смену приемника VRR, целевое устройство может остановить транзакцию старого приемника VRR посылкой команды на прекращение работы для этой транзакции. В случае если целевое устройство не способно выполнить смену VRR, целевое устройство просто прерывает новую транзакцию и предоставляет, например, серверу возможности целевого устройства, указывающие, что целевое устройство не способно к смене приемника VRR. Очевидно, если сервер знает возможности целевого устройства и знает, что целевое устройство не может выполнить смену приемника VRR, сервер не должен делать попытку принудительного хэндовера.
Вариант 2, Принудительный хэндовер
[0075] В Варианте 2, если сервер знает, что целевое устройство способно к выполнению смены, то тогда сервер может просто запустить предоставление поддержки опорного измерения для двух приемников VRR (старого и нового). Сервер может знать это, например, на основании упомянутых выше возможностей.
[0076] В приведенном выше коде ANS.1 элемент MeasurementList может нести измерения для двух приемников VRR. Можно указать, что в случаях, где есть измерение для двух приемников VRR, целевое устройство должно переключиться на тот приемник, который оно в настоящее время не использует. Другой пример способа сообщения команды на хэндовер может включать использование явного поля Boolean, которое говорит целевому устройству, что оно должно переключиться на конкретный приемник VRR.
[0077] Если платформа SLP не знает, способно ли целевое устройство к такому хэндоверу, то необходимо другое решение. Одно такое решение заключается в определении, что целевое устройство должно немедленно остановить поток поддержки опорного измерения для нового приемника VRR, с помощью посылки серверу сообщения LPP Request Assistance Data с элементом IE Modify, несущим команду элемента IE на остановку с идентификатором ID нового приемника VRR.
[0078] В случаях, если сервер знает, что оборудование UE способно к выполнению смены, но по некоторым причинам это оборудование UE желает отклонить команду смены, оборудование UE может сделать это, остановив поток поддержки опорного измерения для нового приемника VRR. Альтернативно оборудование UE может отвечать на запрос хэндовера сообщением hand-over proceed ("хэндовер выполняется") или hand-over reject ("хэндовер отклоняется"). Если hand-over proceed посылается от оборудования UE, хэндовер выполняется известным образом, после чего оборудование UE может ответить hand-over complete ("хэндовер завершен") и сервер может остановить предоставление поддержки опорного измерения для старого приемника VRR. Следует отметить, что такая сигнализация не показана в вышеописанных примерах.
Вариант 3
[0079] В дополнение к вышеописанному имеется еще Вариант 3, который не зависит от идентификаторов ID транзакций LPP или управления сеансом LPP высокого уровня, то есть не зависит от того, запускает ли запрос новую транзакцию или нет. В этом варианте управление потоками информации периодического сеанса поддержки производится с использованием Periodic Session ID ("Идентификатора ID Периодического Сеанса"). Он может назначаться сервером, когда запускается периодический сеанс передачи вспомогательных данных. Как показано ниже в примере информационных элементов для Варианта 3, каждое периодическое предоставление вспомогательных данных включает идентификатор ID, чтобы связанные сообщения в пределах периодической доставки вспомогательных данных могли быть связаны на приемном конце. Далее любые модификации сеанса (смена приемника VRR) выполняются посредством PerSessionID так, чтобы изменения в доставке вспомогательных данных могли указывать на правильный сеанс. Этот вариант возможен также для элемента IE Modify, который должен переноситься в отдельном назначенном сообщении LPP, таком как сообщение LPP Modify Assistance Data, которое, однако, не существует в современном LPP (Релиз 9).
[0080] Приводимый в качестве примера хэндовер или смена приемника VRR в Варианте 3 может выполняться следующим образом. Оборудование UE первоначально принимает поддержку опорного измерения для первого приемника VRR. После определения оборудованием UE, что переключение на второй приемник VRR может быть полезным (например, на основании списка соседей), оборудование UE может послать элемент IE Modify, содержащий идентификатор ID второго приемника VRR в элементе 1Е changeTo. Сервер принимает это сообщение и может начать предоставление поддержки опорного измерения для второго приемника VRR в дополнение к первому приемнику VRR. Оборудование UE затем выполняет смену приемников VRR. По ее завершении оборудование UE останавливает поток измерений для первого приемника VRR путем посылки элемента IE Modify, включающего поле остановки.
[0081] Ниже приводится листинг примера информационных элементов для Варианта 3. Этот приводимый в качестве примера код на формальном языке абстрактного описания синтаксиса версии 1 (ASN.I) поясняет пример реализации различных форм осуществления изобретения. Следует отметить, что приводимый ниже код ASN.I поясняет пример нотации, которая описывает структуру данных, например, для представления кодирования/декодирования и передачи данных в соответствии с различными формами осуществления. Должно быть понятно, что представленный ниже пример кода ASN.1 может определять сообщения для использования в соответствующем протоколе связи, давая в результате двоичное кодирование путем использования некоторого числа правил кодирования, например, ASN.1.
Request:: = SEQUENCE {
transactionID
TransactionID,
requestOfHaAssistance
RequestOfHaAssistance,
}
RequestOfHaAssistance:: = SEQUENCE {
refStationReq
RefStationReq OPTIONAL,
modify
Modify OPTIONAL,
}
RefStationReq:: = SEQUENCE {
coordinates Coordinates,--Местоположение, для которого запрашивается опорная станция
measurementsRequested MeasurementsRequested OPTIONAL,-Определяет запрашиваемые системы GNSS и сигналы, альтернативно сервер может знать, какие измерения надо представлять, на основании деталей выполняемого периодического сеанса или на основании возможностей терминала
qualityOfRefStation QoR ОРТЮМАЦ--Максимальное расстояние до опорной станции
}
Modify:: = SEQUENCE {
PeriodicSessionToModify PerSessionID,
changeTo
ChangeTo OPTIONAL,
stop
RefStationID OPTIONAL,
}
ChangeTo:: = SEQUENCE {
newRefStation
RefStationReq OPTIONAL,
newRefStationId
RefStationID OPTIONAL,
}
Provide:: = SEQUENCE {
transactionID
TransactionID,
provideHaAsssistance ProvideHaAsssistance,
}
ProvideHaAsssistance:: = SEQUENCE {
PeriodicSessionID
PerSessionID,
measurementsList
MeasurementsList,
neighborlist
Neighborlist OPTIONAL,
refStationChangeOk BOOLEAN OPTIONAL,--Замечание: будет включен в случае, если сервер поддерживает смену VRR, но не обеспечивает список соседей
}
MeasurementsList:: = SEQUENCE (1…2) OF Measurements
Measurements:: = SEQUENCE {
gNSSMeasurements GNSSMeasurements,--Содержит измерения фазы несущей/фазы кода для запрашиваемых GNSS и сигналов, которые "сервер" мог вывести на основании, скажем, возможностей "целевого устройства", предоставляемых "серверу" в LPP Provide Capabilities или на основании параметров в запросе
coordinates
Coordinates,-KoopnnHaTbi VRR
refStationID RefStationID,
}
NeighborList:: = SEQUENCE(1…16) OF Neighbor--Замечание: "16" соседей приведено в качестве примера
Neighbor:: = SEQUENCE {
Coordinates
Coordinates,
refStationId
RefStationID,
}
RefStationID:: = INТЕОЕР(0…65535)--Замечание: "65535"
идентификаторов ID - приводимый в качестве примера диапазон
PerSessionID:: = INTEGER(0…255)--Замечание: "255" идентификаторов ID сеанса приведены в качестве примера
TransactionID:: = INTEGER(0…255)--Замечание:: "255" идентификаторов ID транзакций приведены в качестве примера.
[0082] Различные формы осуществления изобретения, описанные здесь, приведены в общем контексте шагов способа или процессов, которые могут быть реализованы в одной форме осуществления программным изделием для компьютера, воплощенном на машиночитаемом носителе, содержащем выполняемые компьютером команды, такие как программный код, выполняемый компьютерами в сетевой среде. Машиночитаемый носитель может включать съемные и несъемные запоминающие устройства, включая, но не ограничиваясь этим, постоянное запоминающее устройство (Read Only Memory, ROM), оперативное запоминающее устройство (Random Access Memory, RAM), компакт-диски (compact discs, CD), цифровые универсальные диски (digital versatile discs, DVD) и т.д. Вообще программные модули могут включать стандартные подпрограммы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют конкретные абстрактные типы данных. Выполняемые компьютером команды, связанные структуры данных и программные модули представляют примеры программного кода для выполнения шагов раскрытых здесь способов. Конкретная последовательность таких выполняемых команд или связанных структур данных представляет примеры соответствующих действий для осуществления функций, описанных в такие шагах или процессах.
[0083] Кроме того, различные формы осуществления изобретения могут быть реализованы в виде программного обеспечения, аппаратных средств, прикладной логики или комбинации программного обеспечения, аппаратных средств и прикладной логики. Программное обеспечение, прикладная логика и/или аппаратные средства могут находиться, например, в наборе микросхем, мобильном устройстве, настольном компьютере, портативном компьютере или сервере. Программное обеспечение и Web-реализации различных форм осуществления изобретения могут быть достигнуты стандартными методами программирования с логикой на основе системы правил и другой логики для выполнения различных шагов или процессов поиска в базе данных, шагов или процессов корреляции, шагов или процессов сравнения и шагов или процессов решения. Различные формы осуществления изобретения могут также быть полностью или частично реализованы в сетевых элементах или модулях. Следует отметить, что используемые здесь и в приводимой ниже формуле изобретения слова "компонент" и "модуль" предназначены для охвата реализации с использованием одной или более строк программного кода и/или реализации аппаратными средствами, и/или оборудования приема входных данных, вводимых вручную.
[0084] Отдельные и специфические структуры, описанные в предыдущих примерах, должны пониматься как образующие типичную структуру или средства для выполнения конкретных функций, описанных в нижеследующей формуле изобретения, хотя ограничения в формуле изобретения не должны интерпретироваться как образующие ограничения "средство плюс функция", когда термин "средство" там не используется. Кроме того, использование термина "шаг" в предыдущем описании не должно использоваться для истолкования какого-либо конкретного ограничения в формуле изобретения как образующего ограничение "шаг плюс функция". В той степени, в которой отдельные ссылочные материалы, включая выданные патенты, заявки на патент и публикации, не являющиеся патентами, описаны или иначе упомянуты здесь, такие ссылочные материалы не предназначены и не должны интерпретироваться как ограничивающие объем нижеследующей формулы изобретения.
[0085] Предыдущее описание форм осуществления изобретения было представлено с целью иллюстрации и описания. Предыдущее описание не предназначено быть исчерпывающим или ограничивающим формы осуществления данного изобретения точной раскрытой формой, и модификации и разновидности возможны в свете вышеизложенных идей или могут быть получены из применения на практике различных форм осуществления изобретения. Формы осуществления, рассмотренные здесь, были выбраны и описаны, чтобы объяснить правила и природу различных форм осуществления изобретения и его практического применения и дать возможность специалистам в данной области техники использовать данное изобретение в различных формах осуществления и с различными модификациями, которые подходят для предполагаемого конкретного использования. Особенности форм осуществления изобретения, описанных здесь, могут быть объединены во все возможные комбинации способов, устройств, модулей, систем и программных изделий для компьютера.
Способ, включающий:
определение в целевом устройстве, что первые принимаемые вспомогательные данные должны быть заменены вторыми вспомогательными данными;
передачу сообщения запроса, запрашивающего вторые вспомогательные данные;
прием первых вспомогательных данных и вторых вспомогательных данных;
определение измерения с учетом вторых вспомогательных данных; и
запрос прекращения передачи первых вспомогательных данных.
Способ, отличающийся тем, что первые вспомогательные данные связаны с первым опорным приемником, и вторые вспомогательные данные связаны со вторым опорным приемником.
Способ, отличающийся тем, что первый и второй опорные приемники являются виртуальными опорными приемниками.
Способ, отличающийся тем, что измерение включает базисную линию относительно второго опорного приемника.
Способ, отличающийся тем, что сообщение запроса включает идентификатор ID второго опорного приемника.
Способ, отличающийся тем, что идентификатор ID второго опорного приемника определяется из списка, включающего соседние опорные приемники.
Способ, отличающийся тем, что сообщение запроса включает идентификатор ID транзакции между целевым устройством и первым опорным приемником.
Способ, отличающийся тем, что сообщение запроса включает координаты второго опорного приемника.
Способ, отличающийся тем, что сообщение запроса включает требование качества, которому должны удовлетворять параметры, связанные со вторым опорным приемником.
Способ, отличающийся тем, что первые вспомогательные данные связаны с первой транзакцией, а вторые вспомогательные данные связаны со второй транзакцией.
Способ, отличающийся тем, что первые вспомогательные данные и вторые вспомогательные данные связаны с одной и той же транзакцией.
Способ, отличающийся тем, что информационный элемент modify посылают с сообщением запроса и новая транзакция не запускается для вторых вспомогательных данных.
Программное изделие для компьютера, воплощенное на машиночитаемом носителе, содержащем машинный код, включающий выполняемые компьютером команды, которые заставляют процессор выполнять вышеупомянутые процессы.
Устройство, содержащее:
процессор; и
блок памяти, соединенный с процессором с возможностью взаимодействия и включающий машинный код, сконфигурированный так, что при работе с процессором он заставляет устройство:
определять, что первые получаемые вспомогательные данные должны быть заменены вторыми вспомогательными данными;
передавать сообщение запроса, запрашивающее вторые вспомогательные данные;
принимать первые вспомогательные данные и вторые вспомогательные данные;
определять измерение с учетом вторых вспомогательных данных; и
запрашивать прекращение передачи первых вспомогательных данных.
Устройство, отличающееся тем, что первые вспомогательные данные связаны с первым опорным приемником, и вторые вспомогательные данные связаны со вторым опорным приемником.
Устройство, отличающееся тем, что первый и второй опорные приемники являются виртуальными опорными приемниками.
Устройство, отличающееся тем, что измерение включает базисную линию относительно второго опорного приемника.
Устройство, отличающееся тем, что сообщение запроса включает идентификатор второго опорного приемника.
Устройство, отличающееся тем, что идентификатор второго опорного приемника определяется списком, включающим соседние опорные приемники.
Устройство, отличающееся тем, что сообщение запроса включает идентификатор транзакции между устройством и первым опорным приемником.
Устройство, отличающееся тем, что сообщение запроса включает координаты второго опорного приемника.
Устройство, отличающееся тем, что сообщение запроса включает требование качества, чтобы параметры, связанные со вторым опорным приемником, удовлетворяли этому требованию качества.
Устройство, отличающееся тем, что первые вспомогательные данные связаны с первой транзакцией, а вторые вспомогательные данные связаны со второй транзакцией.
Устройство, отличающееся тем, что первые вспомогательные данные и вторые вспомогательные данные связаны с одной и той же транзакцией.
Устройство, отличающееся тем, что информационный элемент modify посылают с сообщением запроса и новая транзакция не запускается для вторых вспомогательных данных.
Способ, включающий:
прием на сервере сообщения запроса, запрашивающего вторые вспомогательные данные;
определение, могут ли быть предоставлены запрашиваемые вторые вспомогательные данные;
передачу вторых вспомогательных данных и первых вспомогательных данных, если запрашиваемые вторые вспомогательные данные могут быть предоставлены;
прием запроса на прекращение передачи первых вспомогательных данных; и
прекращение передачи первых вспомогательных данных.
Способ, отличающийся тем, что первые вспомогательные данные связаны с первым опорным приемником, а вторые вспомогательные данные связаны со вторым опорным приемником.
Способ, отличающееся тем, что первый и второй опорные приемники являются виртуальными опорными приемниками.
Способ, отличающийся тем, что сообщение запроса включает идентификатор второго опорного приемника.
Способ, отличающийся тем, что сообщение запроса включает идентификатор транзакции между целевым устройством и первым опорным приемником.
Способ, отличающийся тем, что сообщение запроса включает координаты второго опорного приемника.
Способ, отличающийся тем, что сообщение запроса включает требование качества, чтобы параметры, связанные со вторым опорным приемником, удовлетворяли этому требованию качества.
Способ, отличающийся тем, что первые вспомогательные данные связаны с первой транзакцией, а вторые вспомогательные данные связаны со второй транзакцией.
Способ, отличающийся тем, что первые вспомогательные данные и вторые вспомогательные данные связаны с одной и той же транзакцией.
Способ, отличающийся тем, что информационный элемент modify посылают с сообщением запроса и новая транзакция не запускается для вторых вспомогательных данных.
Программное изделие для компьютера, воплощенное на машиночитаемом носителе, содержащем машинный код, включающий выполняемые компьютером команды, которые заставляют процессор выполнять вышеупомянутые процессы.
Устройство, содержащее:
процессор; и
блок памяти, соединенный с процессором с возможностью взаимодействия и включающий машинный код, сконфигурированный так, что при работе с процессором он заставляет устройство:
принимать сообщение запроса, запрашивающее вторые вспомогательные данные;
определять, могут ли быть предоставлены запрашиваемые вторые вспомогательные данные;
передавать вторые вспомогательные данные и первые вспомогательные данные, если запрашиваемые вторые вспомогательные данные могут быть предоставлены;
принимать запрос на прекращение передачи первых вспомогательных данных; и
прекращать передачу первых вспомогательных данных.
Устройство, отличающееся тем, что первые вспомогательные данные связаны с первым опорным приемником, а вторые вспомогательные данные связаны со вторым опорным приемником.
Устройство, отличающееся тем, что первый и второй опорные приемники являются виртуальными опорными приемниками.
Устройство, отличающееся тем, что сообщение запроса включает идентификатор второго опорного приемника.
Устройство, отличающееся тем, что идентификатор второго опорного приемника определяется из списка, включающего соседние опорные приемники.
Устройство, отличающееся тем, что сообщение запроса включает идентификатор транзакции между целевым устройством и первым опорным приемником.
Устройство, отличающееся тем, что сообщение запроса включает координаты второго опорного приемника.
Устройство, отличающееся тем, что сообщение запроса включает требование качества, чтобы параметры, связанные со вторым опорным приемником, удовлетворяли этому требованию качества.
Устройство, отличающееся тем, что первые вспомогательные данные связаны с первой транзакцией, а вторые вспомогательные данные связаны со второй транзакцией.
Устройство, отличающееся тем, что первые вспомогательные данные и вторые вспомогательные данные связаны с одной и той же транзакцией.
Устройство, отличающееся тем, что информационный элемент modify посылается с сообщением запроса, и новая транзакция не запускается для вторых вспомогательных данных.