CC BY
37УДК 004.057.4 DOI:10.31854/1813-324X-2020-6-3-38-46
Разработка протокола взаимодействия меток и считывателей для системы позиционирования на основе измерения времени распространения радиосигнала
A.B. Тарлыков1 ©
1Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича, Санкт-Петербург, 193232, Российская Федерация *Адрес для переписки: atarlykov@gmail.com
Информация о статье
Поступила в редакцию 10.07.2020 Принята к публикации 11.08.2020
Ссылка для цитирования: Тарлыков А.В. Разработка протокола взаимодействия меток и считывателей для системы позиционирования на основе измерения времени распространения радиосигнала // Труды учебных заведений связи. 2020. Т. 6. № 3. С. 38-46. D0I:10.31854/1813-324X-2020-6-3-38-46
Аннотация: В статье рассматривается задача построения протокола взаимодействия подвижных меток и стационарных считывателей для системы позиционирования, основанной на измерении времени распространения радиосигнала. Проанализирован вопрос уменьшения количества передаваемых сообщений. Приводится общее описание предлагаемого протокола, структура сообщений и основные сценарии взаимодействия.
Ключевые слова: позиционирование, метки, протокол, время распространения радиосигнала.
Введение
Системы позиционирования все сильнее проникают в повседневные области деятельности. Это могут быть задачи, связанные с контролем переносного оборудования, оптимизацией деятельности персонала, контролем доступа в опасные и не предусмотренные регламентом зоны, навигация в закрытых пространствах и другие задачи, более комплексные и базирующиеся на выше перечисленных. Для решения подобных задач могут использоваться различные технологии, к примеру, достаточно распространенным подходом является использование RFID-меток [1]. Но подобные метки не рассчитаны на отслеживание точного местоположения объектов и, как правило, применяются для общего контроля, на их основе могут строиться системы учета времени и общий мониторинг. Другим подходом является использование систем RTLS (от англ. Real Time Locating System) [2, 3]. Главное их достоинство - отслеживание координат контролируемого объекта с достаточно высокой (до сантиметров) точностью и достоверностью контроля позволяют RTLS-системам решать гораздо более широкий круг задач в сравнении с другими.
Общая схема рассматриваемых ЯТЬ^-систем
Основной задачей рассматриваемой системы позиционирования является контроль и отслеживание местоположения подвижных объектов. Каждый отслеживаемый объект ассоциируется с аппаратной меткой, местоположение которой отслеживается относительно стационарных считывателей. Объем контролируемой зоны определяется геометрическим расположением считывателей. Таким образом, в состав системы позиционирования входят следующие основные элементы (рисунок 1): стационарные считыватели с фиксированными координатами; подвижные метки; центральная система расчета положения меток на основе координат считывателей и расстояний до части из них.
T2
И'
...... м
Rl2
R,3
T3
R 1
Рис. 1. Общая схема взаимодействия элементов системы
Fig. 1. Interactions of System Elements
На рисунке 1 приведены элементы системы, участвующие в отдельно взятой транзакции по определению местоположения метки, где: С, -считыватели; Mt - метка, инициировавшая транзакцию; Г/ - измеренное в процессе транзакции время распространения сигнала от метки Mt до считывателя С,-; RJi - рассчитанное считывателем Cj расстояние до метки Mt; Р - централизованная система расчета положения меток.
Считыватели и метки характеризуются уникальными идентификаторами, задаваемыми на этапе начальной настройки системы. Метки являются подвижными, основную часть времени находятся в состоянии сна, пробуждаются через определенные промежутки времени и инициируют транзакцию с рядом считывателей для определения расстояний. Набор и количество сообщений в рамках каждой транзакции может варьироваться и определяется протоколом. По окончании транзакции все считыватели, успешно рассчитавшие расстояние до метки, передают информацию в центральную систему для расчета обновленного положения метки. В случае возникновения коллизий транзакция завершается по тайм-ауту.
В процессе работы метка может взаимодействовать с любыми доступными считывателями. В рамках же отдельно взятой транзакции у метки существует возможность исключить ряд считывателей из взаимодействия, что, в ряде случаев, должно позволить разгрузить радиоканал и повысить точность за счет использования различных наборов опорных считывателей.
Необходимо отметить, что в основе функционирования подобных систем лежит механизм доступа к среде ALOHA и условием стабильной работы является минимизация утилизации радиоканала, что, в свою очередь, ведет к необходимости уменьшения количества передаваемых сообщений и их размера. Данную задачу и пытается решить предлагаемый в статье протокол.
Методы позиционирования в RTLS-системах
В рамках RTLS-систем используются различные методы позиционирования, отличающиеся наборами измеряемых параметров. Среди них можно выделить три, используемых наиболее часто [2-6]:
- по уровню принимаемого радиосигнала, RSSI (от англ. Received Signal Strength Indicator) [7, 8];
- по углам относительно известных направлений [9];
- на основе измерения времени распространения радиосигнала.
Технологии позиционирования на основе измерения времени распространения радиосигнала часто объединяются под общим названием ToF (от англ. Time of Flight) [5]. В рамках данного метода существует целый ряд технологий определения
расстояний, различаются они способом получения и обработки данных, на основе которых производится расчет местоположения радиометки. В основном метод базируется на технологиях беспроводной связи, подпадающих под действие группы стандартов IEEE 802.15.4a [10, 11], поддерживающих важную опцию измерения времени распространения сигнала между приемником и передатчиком. Так как измерение времени производится одновременно с пересылкой данных, то поддержка данной функции не требует дополнительных затрат энергии и большей пропускной способности каналов. Кроме того, появляется возможность одновременного решения задач позиционирования и параметрического мониторинга. Приведем основные технологии функционирования подобных систем:
- технология TDoA (от англ. Time Difference of Arrival): определение расстояния производится по разнице во времени распространения радиосигнала от радиометки до группы считывателей, что требует синхронизации часов приемной части системы; радиометка с определенной частотой отсылает сообщения на все «видимые» считыватели, которые определяют моменты времени прихода радиосигнала и передают эту информацию на сервер обработки, где и производятся вычисления местоположения метки как пересечение трех и более гипербол;
- технология ToA (от англ. Time of Arrival): в данном случае используется тактовая синхронизация всей приемо-передающей аппаратуры, точность синхронизации достаточно важна и может доходить до нескольких пикосекунд; радиометка передает радиосигнал в фиксированные моменты времени; считыватели измеряют время между отправкой радиосигнала радиометкой и его приемом считывателем, далее рассчитывается расстояние; высокие требования к синхронизации приводят к сложностям при эксплуатации и росту стоимости решений;
- технология TWR (от англ. Two Way Ranging [12]). В данном случае используется два сообщения: первое - от метки к считывателю, и второе -от считывателя к метке. Время задержки ответа на считывателе фиксируется и отсылается в ответном сообщении метке, таким образом, метка рассчитывает расстояние на основе зафиксированных моментов передачи и приема сообщений, а также -времени задержки на считывателе. Тактовая синхронизация при данной технологии не используется, так как отсылка и прием радиосигнала осуществляются одним и тем же устройством. Данная технология не лишена проблем и основная из них -нестабильность опорных генераторов, участвующих в обмене устройств, что приводит к трудностям измерения положения с точностью более метра [13];
- технология DS-TWR (от англ. Double Sided -Two Way Ranging [12]): в схеме DS-TWR процесс измерения времени производится дважды (рисунок 2): радиометка инициирует процесс измерения и замеряет время Тг между отсылкой и приемом ответного сообщения, затем аналогичную операцию выполняет считыватель, замеряя время Тз. Далее расстояние рассчитывается на основе времен Т1 - Т4, где Т2 и Т4 - времена задержки ответов считывателем и радиометкой, соответственно; как и в варианте TWR, времена Т2 и Т4 пересылаются в ответных сообщениях и доступны для использования в расчетах;
- технология SDS-TWR (от англ. Symmetrical Double Sided - Two Way Ranging [3, 12]): разновидность DS-TWR с равными (фиксированными) временами ответа обоих устройств (Т2 и Т4 на рисунке 2), что упрощает вычисления, но привносит ряд трудностей - поочередный обмен метки со всеми считывателями и увеличение времени итерации для поддержки максимального расстояния.
Время итерации, Ti
Метка
-t
Время задержки ответа, Tt
=Н=
Время
Считыватель
П-Ц
Время задержки ответа, T2
Время итерации, Тз
лем) в ответное сообщение метке. Все расчеты могут производиться считывателем, который запоминает время Т2 на своей стороне и получает в ответном сообщении от метки времена Т1 и Т4. В данном случае автоматически решается и проблема передачи от метки рассчитанного на ее стороне расстояния для первой итерации метка -считыватель - метка. Все расчеты выполняет считыватель, что также снижает и суммарный объем передаваемых через радиоканал данных.
Время
Время задержки .итерации, Tu ответа, Tt
Метка
Ht
Время
Считыватель
Время Время задержки итерации, T3 ответа, T2
Рис. 2. Пример обмена в режиме DS-TWR
Fig. 2. Example of Interactions in DS-TWR Mode
Таким образом, вариантов взаимодействия группы меток и считывателей существует достаточно много. Но необходимо отметить, что приведенные выше варианты рассматривают взаимодействие одной метки и небольшой группы считывателей, достаточной для определения местоположения метки. Непосредственное использование указанных схем является далеким от оптимальности решением для практических сценариев, включающих большое количество меток и считывателей.
Далее, при построении протокола, в качестве базиса будет использоваться технология DS-TWR [14]. Кроме базового варианта с использованием четырех сообщений для определения расстояния, данная технология позволяет использовать несколько оптимизаций. Во-первых, существует возможность использовать не четыре сообщения для определения расстояния метка - считыватель, а три (рисунок 3), что повышает общую эффективность схемы. В данном случае ответное сообщение от считывателя используется для измерения времени сразу двух итераций обмена: метка - считыватель - метка и считыватель - метка - считыватель.
Более того, в данном случае нет необходимости включать время Т2 (задержка ответа считывате-
Рис. 3 Пример обмена с использованием трех сообщений
Fig. 3. Interactions with Three Messages
Второй важной особенностью режима DS-TWR является возможность группировки сообщений, что связано с отсутствием требования синхронности режима SDS-TWR (времена Т2 и Т4 не фиксированы, см. рисунки 2, 3), что, в свою очередь, позволяет в схеме с одной меткой и тремя считывателями уменьшить общее количество сообщений с девяти до пяти - одно инициирующее сообщение ко всем считывателям, три ответных от считывателей и единый ответ метки всем считывателям (рисунок 4).
Считыватель №2
Считыватель №3
' задерж&та, T23 Время ^W, T33 ' Рис. 4. Пример обмена с использованием пяти сообщений
Fig. 4. Interactions with Five Messages
Здесь запись вида Т4 определяет время Т4 (в соответствии с рисунками 2, 3) при взаимодействии метки со считывателем с индексом i.
Протокол взаимодействия меток и считывателей
Рассмотрим вариант построения протокола обмена между совокупностью меток и считывателей на основе технологии DS-TWR с использованием группировки сообщений. Целью будет являться уменьшение общего количества сообщений, необходимых для измерения положения всех меток.
Все сообщения будут содержать в себе стандартный набор полей и иметь следующий вид:
\FC, АРР, FUNC, FDATA\,
где поля определяются следующим образом:
- FC (Frame Control), управляющая информация для сообщения, может задавать битовую размерность адресов устройств, модификаторы протокола и т. п.;
- АРР, уникальный идентификатор системы или приложения;
- FUNC, код прикладного сообщения;
- FDATA, данные текущего сообщения, формат определяется значением поля FUNC.
В дальнейших рассуждениях поля FC и АРР будут опускаться при описании частных сообщений протокола как не относящиеся к логике взаимодействия меток и считывателей.
При реализации протокола будем ссылаться на ряд параметров, значения которых могут варьироваться при необходимости (таблица 1).
ТАБЛИЦА 1. Временные параметры протокола
TABLE 1. Temporal Parameters of the Protocol
Параметр Описание
т* Период запросов со стороны метки, инициирующих процесс измерения расстояния до ряда считывателей, может быть как фиксированным, так и варьироваться в некоторых пределах
Ttps Период запросов со стороны метки, инициирующих процесс измерения расстояния для уточнения положения в случае необходимости, - ^р
Ttcl Длительность временного окна ожидания меткой ответов от считывателей после посылки инициирующего сообщения об измерении положения, вариант повышенной длительности (см. далее)
Ttc Длительность временного окна ожидания меткой ответов от считывателей, вариант обычной длительности (см. далее)
Tapl Длительность временного окна для посылки ответа считывателем после приема инициирующего сообщения от метки (вариант повышенной длительности), Тар1 - Т(с1
т 1 ар Длительность временного окна для посылки ответа считывателем после приема инициирующего сообщения от метки (вариант обычной длительности), Тар - Т1с
Далее рассмотрим общую логику поведения метки и типы сообщений, необходимые для решения задачи позиционирования. В процессе работы метка периодически инициирует транзакции по измерению расстояния до ряда считывателей. В простейшем варианте это могут быть все установленные считыватели или считыватели, принявшие инициирующее сообщение. Каждая транзакция включает в себя инициирующее сообщение метки, ответы от считывателей и результирующее сообщение от метки (технология ЭБ-ТШЯ позволяет осуществлять группировку ответных сообщений). Очевидно, присутствует линейная зависимость об-
щего количества сообщений в рамках транзакции от количества ответивших считывателей, и важным является минимизация подобных сообщений в процессе работы. Варианты минимизации в большей степени определяются логикой построения алгоритма считывателя, но и на уровне протокола должна существовать возможность подобную логику реализовать.
Будем использовать несколько вариантов сообщения для инициирования транзакции. Самым простым вариантом выступает широковещательное сообщение о начале транзакции, участвовать в которой может любой считыватель, принявший запрос. Данный вариант может быть использован в качестве «холодного старта» при включении метки или метка может «откатиться» к его использованию при падении количества отвечающих считывателей в процессе обмена. Транзакция, инициируемая данным типом сообщения, характеризуется использованием временного окна повышенной длительности (см. таблицу 1). Формат сообщения следующий:
\FM1, TID,SEQ\,
где FMI - код сообщения инициации транзакции; TID - идентификатор метки; SEQ - последовательный циклический номер транзакции метки.
Второй вариант сообщения инициирующего транзакцию выглядит полностью аналогично и отличается только кодом сообщения (FM2). Тем не менее, данный вариант является основным и позволяет считывателям использовать различные механизмы для минимизации количества ответов. Также данный тип транзакции характеризуется использованием временного окна уменьшенной длительности для накопления ответов от считывателей.
При использовании сообщений типа FM2 возможен вариант, когда по какой-либо причине метке ответило мало считывателей или неудачно расположенные считыватели. Например, в случае, если метка получила ответ от двух считывателей, чего недостаточно для полноценного позиционирования. В подобных случаях следующая транзакция может быть организована меткой ранее очередного запланированного сеанса.
Также разумной выглядит возможность явного исключения ряда считывателей из участия в очередной транзакции, что может быть использовано как для уточнения положения при недостаточном количестве участников в предыдущей транзакции, так и для разгрузки среды передачи, исключая ответы ряда считывателей. Для поддержки подобной возможности предлагается расширить набор инициирующих сообщений метки дополнительным вариантом, включающим идентификаторы соответствующих считывателей:
\FM3, TID, SEQ, #А, AID[#A}\,
где FM3 - код сообщения инициации транзакции с исключением ряда считывателей; #А - количество считывателей, исключаемых из инициируемого сеанса измерения расстояния; AID - идентификаторы считывателей в количестве, соответствующем значению поля #A.
Подобное расширение набора инициирующих сообщений позволяет явно менять наборы считывателей в последовательных транзакциях (для уточнения положения относительно разных наборов считывателей), что может быть актуально при плотном покрытии территории считывателями и при наличии различных помех в направлении ряда считывателей. Но важно отметить, что подобная поддержка может выходить за возможности конкретной метки, например, метка может быть оборудована малым объемом памяти, не позволяющим вести статистику использования считывателей.
Стоит отдельно упомянуть возможный вариант инициирующего сообщения метки с указанием конкретных целевых считывателей (обратный вариант к FM3). На первый взгляд такой вариант должен выступать простым способом кардинального снижения количества ответных сообщений от считывателей. Но при дальнейшем рассмотрении оказывается, что на метку переходит задача по выбору предпочтительных считывателей, что приводит к повышению нагрузки на метку и росту требований к аппаратному обеспечению, в первую очередь - объему памяти. Также метка ограничена в возможностях построения оптимального набора считывателей для обмена в рамках транзакции, сказывается весьма ограниченный объем доступной ей информации. Возможным вариантом могло бы являться использование набора считывателей из предыдущей транзакции в течение нескольких итераций, что требует минимальных затрат от метки. Но отсутствие гарантий на оптимальность набора считывателей, участвовавших в любой отдельно взятой транзакции, сильно снижает эффективность подобного подхода. Таким образом, возможность всех разом расположенных считывателей на каждом итерации «соревноваться» за участие в транзакции позволяет повысить вероятность построения «удачных» комбинаций считывателей в ходе последовательных транзакций. Также отказ от указания целевых считывателей в сообщении позволяет переложить задачу оптимизации на часть системы (считыватели), обладающую априори большими ресурсами и большей информацией о состоянии всей системы. Все перечисленные выше моменты указывают на нецелесообразность использования варианта инициирующего сообщения с фиксированным набором целевых считывателей.
Следующая стадия обработки транзакции приходится на считыватели. Каждый из них большую часть времени находится в режиме приема сооб-
щений. После приема, инициирующего сообщения от какой-либо метки, считыватель случайным образом выбирает время ответа в пределах длительности окна ответа (соответствующего типу принятого сообщения) и помечает данное событие в своем плане ответов. Наличие плана ответов позволяет реализовать параллельный обмен с несколькими метками и, более того, производить упаковку сообщений в ряде случаев. В случае, когда помещаемый в план ответ пересекается по времени передачи с уже запланированным ответом другой метке, такие ответы могут быть объединены в единое сообщение для нескольких меток. Подобное решение позволяет уменьшить суммарное время передачи и пересечения с другими транзакциями.
Таким образом, ответные сообщения считывателя в рамках транзакций измерения расстояния с метками могут принимать один из двух вариантов. Первый вариант нацелен на общение с одной меткой и выглядит следующим образом:
\FA1, AID, TID, SEQ\
где FA1 - код ответного сообщения для одной метки; AID - идентификатор считывателя; TID -идентификатор метки, которой предназначен ответ; SEQ - текущий номер транзакции, полученный от метки.
Второй вариант реализует возможность ответа нескольким меткам:
\FA2,AID,#T, (TID1, SEQ1 ){#Г}\,
где FA2 - код ответного сообщения для группы меток; #Т - количество целевых меток; (TID1, SEQ1 ) -наборы из номера транзакции и идентификатора соответствующей метки в количестве, указанном в поле #Т.
Рассмотрим дальнейшее функционирование метки. После отсылки инициирующего сообщения какого-либо вида метка переходит в режим приема для обработки ответов от считывателей. На прием отводится окно времени фиксированной длительности (см. таблицу 1). Если инициирующее сообщение позволяло оптимизацию ответов, то в ходе приема ответных сообщений метка может закрыть окно приема после получения определенного количества ответов (например, трех ответов уже может быть достаточно для определения местоположения). В случае отсутствия ответных сообщений в течение открытого окна приема, метка завершает транзакцию и переходит в режим сна до следующей попытки. Кроме ответов на инициирующее сообщение самой метки, метка может принять ответы считывателей другим меткам. В общем случае подобные сообщения могут быть проигнорированы, но в ряде случаев могут быть использованы для определения расстояния в самом простом режиме TWR с использованием всего двух сообщений и
увеличенной погрешности. Данный вариант может быть актуален в случае недостаточного количества ответов самой метке.
Использование ассиметричной схемы DS-TWR позволяет метке «упаковать» ответ всем считывателям в единое сообщение. Закрыв окно приема (заранее или по истечении времени), метка отсылает ответ всем считывателям, сообщения от которых были получены. Общая структура сообщения выглядит следующим образом:
\FM3, TID, SEQ, #AR, (AID1, Т^, T^){#AR}, #AS, (AID1, Ti ) {# AS} |,
где FM3 - код сообщения окончания транзакции; #AR - количество считывателей, сообщения от которых были получены в рамках транзакции и которым предназначено данное финальное сообщение; #AS - количество считывателей, сообщения которых были предназначены другим меткам, были «подслушаны» данной меткой и с которыми метка предлагает измерить расстояние в режиме обмена двумя сообщениями (данный блок может отсутствовать); (AID1, TI, Т1) - наборы, включающие идентификатор считывателя, время обмена сообщениями метка - считыватель - метка и время задержки между приемом ответного сообщения соответствующего считывателя и общим ответом (текущее сообщение), индексы соответствуют рисунку 3, количество наборов соответствует значению поля #AR; (AID1, T4t) - наборы из идентификатора считывателя и времени задержки между приемом ответного сообщения соответствующего считывателя и общим ответом (текущее сообщение), индексы соответствуют рисунку 3, количество наборов соответствует значению поля #AS.
После приема финального сообщения от метки, считывателем производится расчет расстояния и отсылка информации в отслеживающую систему по одному из доступных каналов связи. Возможны следующие состояния транзакции с меткой в момент приема финального сообщения от нее:
- считыватель находится в списке адресатов в принятом сообщении и существует активная транзакция с данной меткой: такое состояние означает, что от метки был принят запрос на измерение расстояния и ей был отослан ответ (индивидуальный или в составе группового ответа) в рамках стандартного процесса обмена;
- считыватель находится в списке адресатов в принятом сообщении, активная транзакция с меткой отсутствует: в данном случае от метки не было запросов на измерение расстояния (или он не был принят), но она приняла ответ данного считывателя некой другой метке и решила использовать его для оценки расстояния в режиме двух сообщений (вариант TWR). Данное решение метки может быть продиктовано, к примеру, недоста-
точным количеством ответов от считывателей на ее начальный запрос измерения расстояний;
- считыватель не находится в списке адресатов сообщения, но транзакция с меткой активна и существует запланированный ответ в плане ответов: данная ситуация может сложиться в случае, когда ответ считывателя запланирован ближе к окончанию временного окна ответа метке, а метка накопила необходимое (или максимальное) количество ответов от других считывателей и приняла решение о досрочном закрытии окна приема ответных сообщений от считывателей. В данном случае считыватель удаляет запланированный ответ метке из плана ответов, что пересекается с общей логикой функционирования считывателя в случае мониторинга сообщений от других считывателей (как было указано выше), в данном случае ответ метке может быть отменен заранее;
- также возможен вариант утери финального сообщения в результате коллизий в радиоканале, в подобном случае транзакция завершается считывателем по истечении времени: при необходимости информация может передаваться в центральную систему для мониторинга количества сбоев и потерь в работе системы.
Как упоминалось выше, основной вклад в минимизацию количества передаваемых сообщений дает уменьшение ответов считывателей на инициирующие запросы меток. Количество сообщений остальных типов уменьшению практически не подлежат, возможна только оптимизация путем их агрегации, поддержка чего была предложена в базовом протоколе.
Рассматривая оптимизацию количества ответов со стороны считывателей, можно предложить следующие варианты. Считыватель должен осуществлять контроль ответных сообщений других считывателей в рамках каждой активной транзакции измерения расстояния и отменять отсылку своего ответа в случае, когда к моменту ответа накоплено определенное количество ответов данной метке от других считывателей (конкретное значение является параметром протокола). Данный вариант оптимизации позволяет отсечь ответные сообщения, размещенные ближе к окончанию временного окна ответа метке (в плане ответов) и согласуется с предварительным закрытием данного окна со стороны метки.
Следующим шагом оптимизации может стать вариант с периодическим пропуском части транзакций на основе информации о расстоянии до метки, предполагая, что с увеличением расстояния возрастает вероятность нахождения метки в окрестности других считывателей. Также возможен контроль служебных сообщений других считывателей (например, с информацией о рассчитанном расстоянии до меток) и на основании этих данных принятие решения об ответе метке на
инициирующее сообщение. Возможен и вариант обмена сообщениями между считывателями, что может быть использовано для взаимной оценки расстояния и использования этих данных для автоматического построения схемы взаимного расположения считывателей. Подобная схема позволяет отслеживать примерное положение меток в окрестности считывателя и принимать решение об участии в транзакции в зависимости от расположения каждой метки относительно совокупности считывателей.
Часть указанных вариантов оптимизации реализуется достаточно просто и полностью основываются на базовом протоколе взаимодействия считывателей и меток. Оставшаяся часть, которая требует использования дополнительного протокола для взаимодействия самих считывателей, реализуется сложнее, но также не требует доработки базового протокола.
Сравним количество сообщений, необходимое для определения положения каждой метки для различных вариантов взаимодействия меток и считывателей (таблица 2). Будем считать достаточным измерение расстояния до трех считывателей для удачного определения местоположения каждой метки. Обозначим количество меток через Т и количество считывателей - через А.
Могут возникнуть опасения, что группировка приводит к сильному увеличению размера сообщений и повышает вероятность коллизий. Детальный анализ загруженности радиоканала и вероятности коллизий выходит за рамки данной статьи, но приведем оценку времени занятости радиоканала для случаев индивидуальных и группового ответа метки четырем считывателям. Обратимся к рекомендациям «ГОСТ Р 58082-2018» [15] на системы позиционирования в реальном времени. Рассмотрим предлагаемые в разделе № 5.2 режимы функционирования метки с длиной преамбулы 256 и 1024 символов при скорости передачи данных - 850 кб/с. Дополнительно проведем анализ для скорости передачи 6,81 Мбит/с, входящей в стандарт и поддерживаемой, например, модулями Эееашауе ЭШ1000 [16]. Будем считать размер блока данных равным 16 байтам для индивидуальных ответов метки одному считывателю и 56 байтам для группового ответа одновременно четырем считывателям. Используя данные из раздела «5.3.4 Временные параметры преамбулы» [15] примерно оценим время, необходимое для пересылки данных считывателям (таблица 3).
На приведенном примере можно видеть, что группировка сообщений существенно сокращает суммарное время передачи и, соответственно, загрузку радиоканала. Основной выигрыш достигается за счет экономии на передаче таких служебных полей сообщений, как преамбулы и блоки синхронизации. Аналогичным образом выигрыш
достигается и для остальных типов сообщений с группировкой передачи. Также поддержка протоколом исключения набора считывателей из транзакции с меткой позволяет снизить конкуренцию считывателей за радиоканал при ответе метке и снижает общее количество коллизий.
ТАБЛИЦА 2. Количество сообщений для различных вариантов взаимодействия
TABLE 2. Number of Messages for Various Modes
Вариант Сообщений, шт. Сообщений (T = 100, A = 20), шт.
Режим четырех сообщений каждой пары метка -считыватель 4АТ 8 000
Режим четырех сообщений, но единым инициирующим сообщением Т* (1 + ЗА) 6 100
Режим четырех сообщений, но единым инициирующим сообщением и группировкой ответов меткой Т* (4 + 2А) 4 400
Режим трех сообщений и единым инициирующим сообщением Т* (4+ А) 2 400
Режим трех сообщений, единым инициирующим сообщение и группировкой ответов меткой Т* (2+ А) 2 200
Рассмотренный протокол без оптимизации со стороны считывателей Т* (2+ А) 2 200
Рассмотренный протокол без оптимизации со стороны считывателей и перекрытием 10 % запросов от меток Т* (2 + 0,9А) 2 000
Рассмотренный протокол с функцией мониторинга со стороны считывателей 5Т 500
Рассмотренный протокол с функцией мониторинга со стороны считывателей и перекрытием 10 % запросов от меток 4,5Т 450
ТАБЛИЦА 3. Оценка времени передачи данных считывателям
TABLE 3. Summarized TX Time to Notify Four Anchors
Размер преамбулы, символов Скорость передачи блока данных Суммарное время индивидуальных ответов, мкс Время группового ответа, мкс
256 850 Кбит/с 1 732 773
6,81 Мбит/с 1 100 349
1024 850 Кбит/с 4 788 1 537
6,81 Мбит/с 4 276 1 113
В рамках дальнейших исследований планируется провести полноценное моделирование системы позиционирования с использованием предлагаемого протокола для более точной оценки загрузки радиоканала и возможных коллизий.
Таким образом, использование протокола и достаточно простых оптимизаций на его основе позволяет принципиально снизить количество необходимых сообщений в процессе определения местоположения меток и снизить суммарное время занятости радиоканала. С увеличением количества участников - меток и считывателей - эффект
увеличивается, что должно снизить количество коллизий передаваемых сообщений по сравнению с простыми вариантами взаимодействия. Что, в общем итоге, должно позволить создавать более сложные и объемные комплексы для измерения местоположения объектов.
Список используемых источников
1. Want R. An introduction to RFID technology // IEEE Pervasive Computing. 2006. Vol. 5. Iss. 1. PP. 25-33. D01:10.1109/ MPRV.2006.2
2. Gaffney B. Considerations and Challenges in Real Time Locating Systems Design // Decawave. URL: https://www.decawave. com/considerations-and-challenges-in-real-time-locating-systems-design (дата обращения 03.03.2020)
3. Real Time Location Systems (RTLS) // Nanotron Technologies GmbH. URL: https://nanotron.com/assets/pdf/whitepapers/ WP_RTLS.pdf (дата обращения 03.03.2020)
4. Кривченко Т. Программно-аппаратные методы измерения расстояния по времени распространения радиосигнала при помощи приемопередатчика nanoLOC // Беспроводные технологии. 2012. № 3(28). С. 48-53.
5. Botta M., Simek M., Krajsa O., Cervenka V., Pal T. On Location Estimation Technique Based of the Time of Flight in Low-power Wireless Systems // Measurement Science Review. 2015. Vol. 15. Iss. 2. PP. 58-63. D0I:10.1515/msr-2015-0009
6. Миниахметов Р.Х., Рогов А.А., Цымблер М.Л. Обзор алгоритмов локального позиционирования для мобильных устройств // Вестник Южно-Уральского государственного университета. Серия: Вычислительная математика и информатика. 2013. T. 2. № 2. С. 83-96.
7. Sauter M. From GSM to LTE-Advanced: An Introduction to Mobile Networks and Mobile Broadband: Second Edition. 2014. D0I:10.1002/9781118861943
8. iBeacon // Apple Developer. URL: https://developer.apple.com/ibeacon (дата обращения 03.03.2020)
9. Dave H. How AoA & AoD Changed the Direction of Bluetooth Location Services // Bluetooth. URL: https://www.bluetooth. com/blog/new-aoa-aod-bluetooth-capabilities (дата обращения 03.03.2020)
10. Karapistoli E., Pavlidou F.-N., Gragopoulos I., Tsetsinas I. An overview of the IEEE 802.15.4a Standard // Communications Magazine. 2010. Vol. 48. Iss. 1. PP. 47-53. D0I:10.1109/MC0M.2010.5394030
11. IEEE Std 802.15.4-2011. IEEE Standard for Local and metropolitan area networks. Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs). D0I:10.1109/IEEESTD.2011.6012487
12. Sang C.L., Adams M., Hormann T., Hesse M., Porrmann M., ROckert U. Numerical and Experimental Evaluation of Error Estimation for Two-Way Ranging Methods // Sensors. 2019. Vol. 19. Iss. 3. D0I:10.3390/s19030616
13. Decawave. Sources of error in DW1000 based two-way ranging (twr) schemes // APS011 application note. URL: https://www.decawave.com/wp-content/uploads/2018/08/aps011_sources_of_error_in_twr.pdf (дата обращения 03.03.2020)
14. Decawave. The implementation of two-way ranging with the dw1000 // APS013 application note. URL: https://www.decawave.com/wp-content/uploads/2018/08/aps013_dw1000_and_two_way_ranging_v2.2.pdf (дата обращения 03.03.2020)
15. ГОСТ Р 58082-2018 (ИСО/МЭК 24730-62: 2013). Системы позиционирования в реальном времени (RTLS). Часть 62. Сверхширокополосный радиоинтерфейс с высокой частотой повторения импульсов. М.: Стандартинформ, 2018. 64 с.
16. Decawave. DW1000 User Manual. How to use, configure and program the dw1000 uwb transceiver. URL:
https://www.decawave.com/sites/default/files/resources/dw1000_user_manual_2.11.pdf (дата обращения 03.03.2020)
* * *
Developing Anchor-Tag Communication Protocol for
Positioning System Based on Time of Flight Measurement
A. Tarlykov1
1rrhe Bonch-Bruevich Saint-Petersburg State University of Telecommunications, St. Petersburg, 193232, Russian Federation
Article info
D0I:10.31854/1813-324X-2020-6-3-38-46 Received 10 th July 2020 Accepted 11th August 2020
For citation: Tarlykov A. Developing Anchor-Tag Communication Protocol for Positioning System Based on Time of Flight Measurement. Proc. of Telecom. Universities. 2020;6(3):38-46. (in Russ.) D0I:10.31854/1813-324X-2020-6-3-38-46
Abstract: The article deals with the problem of designing a protocol for the interaction of movable tags and stationary readers based on measuring the spreading time of a radio signal. The issue of reducing the number of transmitted messages is analyzed. Common description of the proposed protocol, the messages and main interaction scenarios structure are provided.
Keywords: positioning, tags, anchors, protocol, time of flight. References
1. Want R. An introduction to RFID technology. IEEE Pervasive Computing. 2006;5(1):25-33. D01:10.1109/MPRV.2006.2
2. Decawave. Gaffney B. Considerations and Challenges in Real Time Locating Systems Design. Available from: https://www.decawave.com/considerations-and-challenges-in-real-time-locating-systems-design [Accessed 3rd March 2020]
3. Real Time Location Systems (RTLS). Nanotron Technologies GmbH. Available from: https://nanotron.com/assets/pdf/ whitepapers/WP_RTLS.pdf [Accessed 3rd March 2020]
4. Krivchenko T. Software and Hardware Methods for Measuring the Distance in Terms of the Propagation Time of a Radio Signal Using the nanoLOC Transceiver. Wireless technologies. 2012;3(28):48-53. (in Russ.)
5. Botta M., Simek M., Krajsa 0., Cervenka V., Pal T. On Location Estimation Technique Based of the Time of Flight in Low-power Wireless Systems. Measurement Science Review. 2015;15(2):58-63. D0I:10.1515/msr-2015-0009
6. Miniakhmetov R.M., Rogov A.A., Zymbler M.L. The Survey of Indoor Positioning Algorithms for Mobile Devices. Bulletin of the South Ural State University. Series "Computational Mathematics and Software Engineering". 2013;2(2):83-96. (in Russ.)
7. Sauter M. From GSM to LTE-Advanced: An Introduction to Mobile Networks and Mobile Broadband: Second Edition. 2014. D0I:10.1002/9781118861943
8. Apple Developer. iBeacon. Available from: https://developer.apple.com/ibeacon [Accessed 3rd March 2020]
9. Bluetooth. Dave H. How AoA & AoD Changed the Direction of Bluetooth Location Services. Available from: https://www.bluetooth.com/blog/new-aoa-aod-bluetooth-capabilities [Accessed 3rd March 2020]
10. Karapistoli E., Pavlidou F.-N., Gragopoulos I., Tsetsinas I. An overview of the IEEE 802.15.4a Standard. Communications Magazine. 2010;48(1):47-53. D0I:10.1109/MC0M.2010.5394030
11. IEEE Std 802.15.4-2011. IEEE Standard for Local and metropolitan area networks. Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs). D0I:10.1109/IEEESTD.2011.6012487
12. Sang C.L., Adams M., Hormann T., Hesse M., Porrmann M., Ruckert U. Numerical and Experimental Evaluation of Error Estimation for Two-Way Ranging Methods. Sensors. 2019;19(3). D0I:10.3390/s19030616
13. Decawave. Sources of error in DW1000 based two-way ranging (twr) schemes. APS011 application note. Available from: https://www.decawave.com/wp-content/uploads/2018/08/aps011_sources_of_error_in_twr.pdf [Accessed 3rd March 2020]
14. Decawave. The implementation of two-way ranging with the dw1000. APS013 application note. Available from: https://www.decawave.com/wp-content/uploads/2018/08/aps013_dw1000_and_two_way_ranging_v2.2.pdf [Accessed 3rd March 2020]
15. G0ST P 58082-2018 Information technology. Real time locating systems (RTLS). Part 62. High rate pulse repetition frequency Ultra Wide Band (UWB) air interface. Moscow: Standartinform Publ.; 2020. (in Russ.)
16. Decawave. DW1000 User Manual. How to use, configure and program the dw1000 uwb transceiver. URL: https://www.decawave.com/sites/default/files/resources/dw1000_user_manual_2.11.pdf [Accessed 3rd March 2020]
Сведения об авторе:
ТАРЛЫКОВ Алексей Владимирович
начальник НОЦ «Лаборатория программирования» Санкт-Петербургского государственного университета телекоммуникаций им. проф. М.А. Бонч-Бруевича, atarlykov@gmail.com © https://orcid.org/QQQQ-Q0Q2-57Q7-24Q6
