CC BY
41
О программировании для сервисов на основе
близости
Д.Е. Намиот
Аннотация— В настоящей статье речь идет о прикладном программировании для сервисов на основе близости. В работе употребляется аббревиатура ProSe (Proximity Services), введенная в спецификациях 3GPP. Согласно спецификациям 3GPP, сервисы на основе близости предназначены для поиска устройств, подходящих для организации непосредственного взаимодействия между устройствами (D2D - Device to Device). В данном случае в работе рассматривается другой подход, в котором именно определение близко расположенных устройств и является конечной целью процесса. Прямое соединение устройств не рассматривается совсем, и основной причиной для этого являются проблемы, связанные с безопасностью. В работе рассматривается подход (модель), при котором определение близости к некоторому устройству (устройствам) является основанием (триггером) для представления данных (сервисов, услуг). Такое основание во многих случаях заменяет или даже дополняет (расширяет) работу с гео-координатами. Соответственно, подход, предложенный в данной работе, состоит в том, что компоненты ProSe (D2D) могут быть основой публичных телекоммуникационных сервисов, которые расширяют (заменяют) сервисы, использующие информацию о местоположении, и не требуют организации непосредственного соединения между устройствами.
Ключевые слова—3GPP, D2D, сетевая близость.
I. Введение
Термин 'сервисы близости' появился в спецификации 3GPP версия 12 в 2015 [1]. В этой реализации было добавлено соединение устройства LTE с другим устройством - device to device communication или D2D. В этой связи и появился термин "сервис близости" (Proximity Services - ProSe). Согласно спецификации, ProSe - это часть технологии D2D. Это важное для нашего дальнейшего рассмотрения замечание, которое фиксирует тот факт, что в целом - это часть процесса для обеспечения прямого взаимодействия устройств между собой. Это операторская технология (процесс управляется оператором), которая основана на целом ряде изменений в стандартах LTE, среди которых основным для D2D является появления так называемого 'sidelink' - радио-интерфейса для прямого взаимодействия устройств между собой (рис. 1). ProSe призвана обеспечить нахождение близкорасположенных устройств. Именно для таких устройств
Статья получена 10 декабря 2019. Д.Е. Намиот - МГУ имени М.В. Ломоносова (e-mail: dnamiot@gmail.com)
введена возможность прямого соединения (sidelink).
I ProSe
2
В
Рис. 1. D2D модель.
На этом рисунке:
1 - каналы управления
2 - sidelink (прямой канал между устройствами A и B) ProSe - сервис определения близости на стороне оператора
Целью такого прямого взаимодействия может быть снижение нагрузки на сеть, увеличение пропускной способности имеющейся полосы пропускания. Другая опция, которая рассматривалась изначально - это обеспечение связи в зонах, где отсутствует покрытие сети. В более общем виде означенные цели могут быть представлены (описаны) как делегирование телекоммуникационным провайдером своих функций [2, 3].
Классически D2D определяется как взаимодействие между двумя устройствами без участия опорной сети (базовых станций) в маршрутизации [4]. D2D взаимодействие - это P2P сеть. В соответствии с этим, предполагается, что эта технология позволит взаимодействующим устройствам делиться контентом, просматривать потоковое видео и т.д. [5]. В качестве основного преимущества для потенциальных D2D сервисов в LTE и 5G обычно заявляется высокая скорость передачи данных с низкой задержкой.
На уровне приложение в литературе обычно обсуждаются такие задачи, как игры, мультимедийные
сервисы, социальные сети, реклама [6,7,8]. Все исследования, которые есть в литературе, сосредоточены на доставке контента с помощью Б2Б соединений. Типичная модель (архитектура) системы представлена на рисунке 2.
Local advertisement
Рис. 2. D2D network [9].
Технически, архитектура системы определения близко расположенных устройств проиллюстрирована на рисунке 3, где изображены основные компоненты и интерфейсы между ними. На этом рисунке представлены:
• Мобильные устройства (UE-A, UE-B)
• сеть радиодоступа (Evolved Universal Terrestrial
Radio Access Network, E-UTRAN) и усовершенствованное пакетное ядро (Evolved Packet Core, EPC)
• Радио-интерфейсы PC1 - PC5
• сервер приложений ProseApp
ProSe Application Server
Рис. 3. Архитектура ProSe [10].
Технически, спецификация определяет следующий алгоритм работы. Мобильное устройство (например, UE-A на рисунке 3) уведомляет окружающие устройства о своем присутствии рассылкой некоторого кода (ProSe Application Code). Этот код выделяется устройству в рамках обращения к некоторой функции (по факту -описанной услуге) - ProSe Application. Все такие функции имеют собственный идентификатор - ProSe
Application ID. Соответственно, ProSe Application Code -это код, связанный с идентификатором приложения и используемый в процессе ProSe Discovery (процесс поиска/представления сервисов). Полученный код рассылается мобильным устройством (спецификация говорит об области до 500 м). При этом рассылаемый код может быть доступен всем (все могут определять наличие сервиса) или же только какой-то ограниченной группе устройств. Отсюда появляется ProSe Restricted Code - код, который делает информацию о сервисе (данных) доступной только некоторой ограниченной группе пользователей. Это связано с поиском сервисов поблизости при наложенных ограничениях - только некоторая выделенная группа пользователей должна иметь доступ к данным.
Discovery Filter: комбинация Application Code/Restricted code и маски (можно считать -регулярного выражения) для отслеживания получения данных по заданному условию
ProSe Function - элемент, который отвечает за предоставление устройствам (UE) доступа к сервисам ProSe, а также за поддержку работы с ProSe Application ID и ProSe Application Code. Спецификация говорит о логической функции. Технически - это веб-сервер (ProSe function будет обрабатывать HTTP запросы от устройств).
ProSe application server - сущность для сохранения информации о пользователях, идентификаторах функций, метаданных и т.д.
Услуги, основанные на принципе близости расположения, включают в себя, согласно спецификации:
• ProSe Direct Discovery: процесс, при котором
устройство (UE) обнаруживает и идентифицирует другое (другие) устройства поблизости
• ProSe Direct Communication: задействование
ресурсов LTE из сотовой сети для передачи сообщений
• Prose Discovery на уровне сети (EPC level ProSe
Discovery) и уровне беспроводных сетей (WLAN)
Очевидно, что для задач, рассматриваемых в данной работе интересен именно (и только) ProSe Direct Discovery элемент. Сетевая близость в таком случае будет определяться относительно некоторого выделенного устройства и обеспечиваться получением некоторого ProSe Application Code от этого устройства.
Спецификация определяет два режима для работы Prose Direct Discovery: открытый и ограниченный. Режим определяет, кто может обнаруживать близкое нахождение конкретного устройства. В рамках Direct Discovery устройство рассылает некоторую идентификационную информацию, которую и могут получать другие устройства поблизости. Факт получения такой идентификационной информации и есть подтверждение того, что отправитель и получатель находятся рядом.
Режим, как было указано выше, определяется для устройства, рассылающего информацию (то есть, устройства, которое используется как опорное для определения близости). В случае открытого режима его рассылка может быть получена любым другим устройством и, соответственно, любое устройство может участвовать в процедуре определения близости. Наоборот, в ограниченном режиме источник рассылки будет определять, какие другие устройства могут получать его рассылку (смогут участвовать в процедуре определения близости). Публичным сервисам должен соответствовать открытый режим. Технически, исходя из предложенной далее модели, вид режима не будет играть никакой роли, модель будет применима в обоих режимах.
Необходимо отметить, что операционная модель и какое-либо описание программных интерфейсов на сегодняшний день отсутствует. Описываемые в литературе сценарии ограничиваются утверждениями о том, что пользователь может найти других пользователей поблизости для того, чтобы поделиться с ними данными. Общее мнение (утверждение) состоит в том, что D2D станет основой многих сервисов, основанных на "местном" (по месту текущего расположения) предоставлении услуг. Но услуги эти если и кратко описываются, то сводятся, фактически к передаче данных между устройствами под контролем оператора связи. Типичный пример - обзор [11], где, фактически, описываются различные вариации соединений устройств между собой. Признавая именно местный (локальный, работающий в пространственно ограниченной области) характер услуг, мы хотели бы остановиться в данной на работе на том, что же они могут из себя предоставлять, и какова может быть программная архитектура для их реализации.
Оставшаяся часть статьи структурирована следующим образом. В разделе II рассматриваются вопросы сетевой близости. В разделе III речь идет о PAS (Proximity Application Server). В разделе IV рассматривается использование модели PAS для беспроводных сетей Wi-Fi и Bluetooth.
II. О МЕСТНЫХ УСЛУГАХ
В нашем представлении публичные сервисы не будут и не могут в современных условиях базироваться на прямом соединении устройств. Причина одна -безопасность. Сервисы D2D описываются как масштабируемое решение для именно
непосредственного соединения между устройствами. Масштабируемость здесь обеспечивается оператором связи, который обеспечивает централизованное управление занятием и освобождением частотных ресурсов. Но это управление никак не отменяет того, что устройство будет устанавливать соединение с другим неизвестным устройством. Устройство для прямого соединения с точки зрения безопасности должно трактоваться именно как неизвестное устройство. Соответственно, прямое соединение - это действие того
же порядка, что и установление соединения по Bluetooth с неизвестным устройством для загрузки какого-то медиа-файла, установка приложений на Android из произвольного источника и т.д. Это действия, которые большинство мобильных пользователей избегает прямо сейчас, и нет никаких оснований полагать, что увеличение скорости обмена данными изменит отношение к таким операциям. Все прямые соединения несут очевидные риски с точки зрения безопасности.
Как нам представляется, прямые соединения (D2D) будут иметь ограниченное применение. Во-первых, здесь можно назвать какую-то выделенную среду (корпоративную подсистему). Можно считать, что все абоненты в такой сети пользуются взаимным доверием. Другой аргумент в пользу использования прямых соединений в таких сетях - отсутствие личных (персональных) данных и наличие какой-то корпоративной сервисной службы (ИТ поддержки), которая и будет решать возможные проблемы с устройствами. Другая опция - это какой-то сервис, который неявно использует в своих алгоритмах прямые обмены. В этом случае речь идет о доверии к самому сервису, мобильный абонент может и не знать о таковых обменах. В качестве примера можно привести сервисы, которые используют P2P обмен в своих алгоритмах. Классический пример - Skype P2P protocol [12]. Использование самим оператором клиентских устройств для выполнения своих задач (offloading) остается прозрачным для абонента и также попадает в эту категорию [13].
Нам представляется, что сервисы на основе близости должны рассматриваться как контекстно-зависимые сервисы. Информация о близости - это часть определения контекста. Соответственно, главное, что должно делать определение (детектирование) близости -это определения условий для представления или обработки данных.
Сами же публичные сервисы должны работать, по нашему мнению, без установления соединения (или, по крайней мере, без обязательного требования установления соединения). Фактически, безопасным для пользователей на сегодняшний день является установление внешнего соединения по веб-протоколам с доверенными хостами. С точки зрения кибербезопасности и анализа возможных связанных проблем - это просмотр (не несущий проблем) без обязательств дополнительной загрузки данных и явное принятие решения пользователем о загрузке данных (именно это есть аналог прямого соединения) на свое устройство.
При таком подходе от сервиса D2D, фактически, остается только одна составляющая - Direct Discovery (DD). Возвращаясь к модели, представленной на рисунке 3 и описанной выше, получение устройством ProSe Application Code является окончанием процесса определения близости (поиска и раскрытия близлежащих узлов). Контекстно-зависимое приложение (а таковыми, по факту, являются все мобильные приложения), получив такой код, может использовать
эту информацию (факт близости к отправителю) при обработке данных. Каждый такой полученный код теперь является частью контекста [14, 15].
Как типы возможных действий (операций) с контентом мы можем указать следующее:
• Попадание устройства в зону доступности
(рассылки) конкретного кода (кодов) или выход из такой зоны вызывает изменение статуса (состояния) в приложении
• Попадание устройства в зону доступности
(рассылки) конкретного кода (кодов) или выход из такой зоны вызывает запрос информации (какое-то обращение к хранилищу данных) для последующей обработки
• Пребывание в зоне рассылки кода (кодов)
вызывает изменение статуса или запрос информации при наступлении каких-то иных условий (например, по превышению времени пребывания)
• Запись событий (вход/выход из зоны рассылки и
пребывание в зоне рассылки) для использования в последующей обработке
Примеры приложений:
• Уведомление о пересечении (на вход или выход) некоторого виртуального периметра (аналог гео-решетки)
• Отправка уведомления с купоном / специальным предложением в случае повторного присутствия в некоторой области
• Выключение звонка на мобильном телефоне при попадании в некоторую область
• Уведомление при изменении набора получаемых (доступных) кодов и т.д.
Ограниченная зона распространения (рассылки) ProSe Application Code всегда будет определять пространственно ограниченную область для возможных реакций (для представления данных, например). С точностью до размеров этой области, ProSe Application Code может заменять гео-позиционирование. Определение гео-координат будет заменяться на определение близости к некоторому отправителю. Если распространяемый код (функция) привязана к какому-то местоположению, то получение кода - это подтверждение близости к указанному месту. Отметим, что само понятие близости является естественным применением для сервисов, учитывающих местоположение. Онтологический анализ сервисов, связанных с определением местоположения проводится во многих работах. В качестве примеров можно привести работы [16, 17].
Использование ProSe Application Code в контекстно-зависимых приложениях может быть объяснено следующим образом. Контекст (так, как это понимается для мобильных вычислений) - это произвольные измеряемые характеристики, которые могут быть добавлены к местоположению. Полученный ProSe
Application Code - это есть (семантически) данные некоторого сенсора (proximity sensor), которые должны быть поставлены в приложение, для использования в его алгоритмах. Простой пример для веб-приложения. Фрагмент кода на JavaScript, который получает текущие координаты пользователя:
<script>
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition (showPosition); } else {
x.innerHTML = "Geolocation is not
supported by this browser."; }
function showPosition(position) {
//Latitude: position.coords.latitude
//Longitude:position.coords.longitude
отображение контента в зависимости от
координат
}
</script>
После получения координат вызывается callback-функция showPosition(position)в которую передаются полученные координаты. Здесь можно организовать отображения данных на вебстранице для заданных координат. Например, управляя видимостью блоков текста с помощью CSS, динамически создавая такие блоки и т.д. Именно так это работает на тысячах веб-страниц, настраивая их контент по местоположению пользователя. Это типичное использование контекста (местоположение - это всегда часть контекста). Это использование основано на том, что приложение (в данном случае - веб-приложение) имеет доступ к контексту (может прочесть эти данные). В данном случае этот доступ обеспечивается поддержкой в браузере объекта navigator.geolocation. Поддержка ProSe должна будет означать наличие семантически эквивалентного объекта (например, navigator.prose), который позволит также в заданной callback-функции получить значение ProSe Application Code, и, в зависимости от этого, динамически модифицировать страницу. Например, у нас есть некоторый бизнес-центр (веб-сайт) и код, доступный устройствам внутри этого центра. Тогда указанным выше способом можно добавить на веб-страницу фрагмент, который распознает, находится ли в данный момент времени посетитель сайта физически внутри бизнес центра (в этом случае на странице сайта будет доступен соответствующий код). Соответственно, вебстраницу можно будет модифицировать с учетом того, что посетитель находится внутри (показать специальные предложения, акции с ограниченным временем и т.п.).
В данном случае, мы не останавливаемся на возможных технических деталях такой реализации для веб-браузеров. Это может быть и стандарт a-la W3C Geo, кастомизированные версии браузеров, плагин для
Chrome, прокси-приложение для веб-страниц, которая добавляет нужные объекты и т.д. Методы реализации могут быть темой отдельных работ.
III. О СЕРВЕРЕ ПРИЛОЖЕНИЙ
Как следует из описанного выше, в предлагаемом подходе из спецификации D2D мы останавливаемся исключительно на одной ее компоненте - Direct Discovery (DD). Соответственно, мобильное устройство, которое рассылает код, семантически, представляется (трактуется) как тег. Рассылка Pro Se Application Code рассматривается, например, также как рассылка тегом Bluetooth Low Energy (BLE) пары своих идентифицирующих значений (minor, major) [18]. Отличия состоят в организации этого процесса и наличии (отсутствии в случае BLE) управления.
Получение сторонним устройством такого распространяемого кода есть фиксация факта близости по отношению к отправителю и, одновременно, уточнение информации о контексте (устройство-получатель находится или нет в зоне получения конкретного тега). Разные теги (получение различных кодов) просто соответствуют разным характеристикам контента. Иными словами - мы следуем предложенной ранее концепции сетевой близости. Обычно такой термин использовался с ориентацией на слово "сетевая". Это метрика, которая оценивала количество промежуточных узлов. Иными словами - сколько узлов сети необходимо преодолевать пакету данных или задержка в передаче данных [19]. Мы же в своих работах ориентировались именно на пространственную близость, которая оценивалась с помощью сетевых технологий [20]. В основе такой оценки и лежало простое ограничение распространения сигнала в случае беспроводных сетей [21].
Определив отправителя ProSe Application Code как "тег", мы можем следовать общей архитектурной модели работы с тегами. Данные, которые рассылает тег, служат, в общем случае, ключом для поиска информации, ассоциированной с данной рассылкой (или с тегом, если данные не меняются). Это отображено на рисунке 4. В случае контекстно-ориентированных систем, информация, ассоциированная с рассылкой -это то, что и описывает дополнения к контексту. Для ProSe, в нашем понимании, должно быть то же самое, просто с заменой тегов на устройство-вещатель.
Следующий момент, который необходимо отметить -это расположение доступного контента. На рисунке 4 для получения контента необходимо обращаться к внешнему источнику (сервер, облако). Это объясняется абсолютно просто - те же самые BLE теги просто не имеют возможности хранить какой-то контент. Вопрос с соединениями отпадает еще и по такой причине. В целом, если мы рассмотрим сервисы, которые учитывают местоположение, то, очевидно, что, определив близко-расположенные объекты, сервис, в большинстве случаев, вообще не может с ними
"соединяться". Поиск, в большинстве случаев, реально сосредоточен на "местных" объектах (по отношению либо к текущему местоположению, либо к некоторому
воображаемому).
Scanned Beacon ' _ i
Beacon A
Beacon В
ô"
«0»
Beacon А «в»
- _ - Scanned Beacon
Beacon A
Beacon В
Mobile А 4 ЧШ ' Mobile В
\ Beacon В
Ш Conti
Ш
съ
Beacon Content
Beacon A Content A
Beacon В Content В
Server
Рис. 4. Запрос контента по ID тега [22]
Но этот поиск практически никогда не предполагает соединения, поскольку ищутся объекты, которые просто не имеют таких функций. Спецификация 3GPP в части ProSe говорит только о мобильных устройствах (UE на рисунке 3), но это именно из-за того, что изначальная цель состояла в обеспечении прямого соединения. Ничто не мешает прямо сейчас обобщить этот подход и рассматривать одно из конечных устройств на рисунке 3 как тег, который, например, будет представлять какой-то физический объект. На самом деле, предполагая соединение мы, фактически, останавливаемся просто на одном возможном типе сервисов, который имеет естественные ограничения. На самом деле, именно контекстная модель описывает все множество сервисов.
В базовой архитектуре ProSe, на рисунке 3 есть упоминание о ProSe Application Server. Но все, что пока говорится - это только то, что это структура для хранения информации о возможных функциях, т.е. сервисах, для которых и выдается ProSe Application Code. Ниже мы представляем наше видение того, как это могло бы выглядеть.
Наличие уникальных идентификаторов для всех типов контента приводит нас к тому, что в основе системы лежит база данных с моделью ключ-значение. Выбор решений здесь огромный, в наших экспериментах мы использовали Redis [23]. Соответственно, запись - это код сервиса и соответствующий контент. В качестве такого контента мы предлагаем использовать описания на Hypercat [24]. Hypercat представляет собой открытую спецификацию, которая предназначена для описания ресурсов в IoT проектах. Любое описание на HyperCat представляет собой некоторый JSON фрагмент. Основной элемент описания - URI с сопутствующим набором RDF-подобных триплетов, которые определяют свойства объекта, описываемого этим URI. Система используется в British Telecom и была предложена BSI в качестве стандарта для поиска в системах IoT.
IV. Модель сервера приложений для беспроводных
СЕТЕЙ
В этом разделе мы хотели бы остановиться на том, как смоделировать предложенный подход уже сейчас, без доступных API для ProSe. Здесь мы воспользуемся давно разрабатываемым нами подходом, связанным с использованием произвольных узлов беспроводных сетей в качестве тегов и построения на такой базе информационных систем, основанных на модели сетевой близости. Для передачи значений используется идентификация беспроводного узла. Например, программно задаваемое имя точки Bluetooth или точки доступа Wi-Fi. Значения могут передаваться в представлении (рекламе) беспроводного узла. Во всех этих случаях беспроводной узел осуществляет рассылку информации, прием которой не требует организации соединений (то есть, является безопасным). Этот подход работает без управления со стороны оператора. Более того, это будет работать совсем без телекоммуникационного оператора. Использование Bluetooth Low Energy позволяет сделать области распространения достаточно малыми (1 метр и меньше), такие рассылки можно создавать динамически, программно создавая узлы беспроводных сетей. Платой за это является отсутствие масштабируемости, которую обещает спецификация 3GPP.
В силу того, что области распространения такого кода могут быть небольшими (например, при использовании Bluetooth это распространение будет в области прямой видимости), есть простая интерпретация для контента в таком сервере приложений. Систему можно описывать как сетевой эквивалент QR-кода. Пользователь фотографирует с помощью камеры телефона QR-код и получает контент, на который этот код ссылается. В сетевом варианте телефон сканирует (автоматически или после явного указания) доступные сетевые коды и получает контент, на который эти коды ссылаются. Все формы контента, которые есть в стандарте QR-кодов, могут быть описаны с помощью Hypercat. Можно добавить любой другой контент для распознавания. Например, лента в Twitter или Телеграмм-канал, которые имеют отношение к местным проблемам. Все это легко описывается с помощью URI в Hypercat.
V. Заключение
В настоящей статье речь идет о разработке публичных сервисов на базе 3GPP D2D. Предложена модель, которая использует только часть этой спецификации -DD (Direct discovery). Другая составляющая (непосредственное взаимодействие устройств) оставлена за рассмотрением по причине проблем с безопасностью. В работе рассматривается архитектурная модель, при котором определение близости к некоторому устройству (устройствам) является основанием (триггером) для представления данных (сервисов, услуг). При таком рассмотрении определение близости устройств может заменять (а также расширять или дополнять) работу с гео-координатами, а также являться элементом
определения контекста в контекстно-ориентированных системах. В работе предложенная операционная модель, включающая в себя базу данных с моделью ключ-значение и фрагменты JSON из системы с открытым кодом Hypercat для непосредственного представления контента.
Библиография
[1] 3GPP TS 24.334 V12.1.1, December 2014; Technical Specification Group Core Network and Terminals, Proximity-services (ProSe) User Equipment (UE) to ProSe function protocols; Stage 3; Release 12.
[2] Rebecchi, Filippo, et al. "Data offloading techniques in cellular networks: A survey." IEEE Communications Surveys & Tutorials 17.2 (2014): 580-603.
[3] Malandrino, Francesco, Claudio Casetti, and Carla-Fabiana Chiasserini. "LTE offloading: When 3GPP policies are just enough." 2014 11th Annual Conference on Wireless On-demand Network Systems and Services (WONS). IEEE, 2014.
[4] Militano, Leonardo, et al. "Device-to-device communications for 5G internet of things." EAI Endorsed Trans. Internet Things 1.1 (2015): 1-15.
[5] Sneps-Sneppe M., Namiot D. (2020) Digital Railway and How to Move from GSM-R to LTE-R and 5G. In: Sukhomlin V., Zubareva E. (eds) Convergent Cognitive Information Technologies. Convergent 2018. Communications in Computer and Information Science, vol 1140. Springer, Cham.
[6] Vo, Nguyen-Son, et al. "Optimal video streaming in dense 5G networks with D2D communications." IEEE Access 6 (2017): 209223.
[7] Pu, Lingjun, et al. "sNDN: a social-aware named data framework for cooperative content retrieval via D2D communications." Proceedings of the 10th International Workshop on Mobility in the Evolving Internet Architecture. ACM, 2015.
[8] Mumtaz, Shahid, Kazi Mohammed Saidul Huq, and Jonathan Rodriguez. "Direct mobile-to-mobile communication: Paradigm for 5G." IEEE Wireless Communications 21.5 (2014): 14-23.
[9] Goian, Huda S., et al. "Popularity-based video caching techniques for cache-enabled networks: a survey." IEEE Access 7 (2019): 2769927719.
[10] LTE Direct http://www.3glteinfo.com/lte-direct/ Retrieved: Jan, 2020
[11] Farzamiyan, Amir Hossein. "A Survey on Device-to-Device Communication in 5G Wireless Networks." 14th International Conference on Software Technologies. 2019.
[12] Wang, Hao. "Skype VoIP service-architecture and comparison." INFOTECH Seminar Advanced Communication Services (ASC). 2005.
[13] Andreev, Sergey, et al. "Cellular traffic offloading onto networkassisted device-to-device connections." IEEE Communications Magazine 52.4 (2014): 20-31.
[14] Namiot, Dmitry, and Manfred Sneps-Sneppe. "Context-aware data discovery." 2012 16th International Conference on Intelligence in Next Generation Networks. IEEE, 2012.
[15] Namiot, Dmitry. "Context-Aware Browsing--A Practical Approach." 2012 Sixth International Conference on Next Generation Mobile Applications, Services and Technologies. IEEE, 2012.
[16] Couclelis, Helen. "Ontologies of geographic information." International Journal of Geographical Information Science 24.12 (2010): 1785-1809.
[17] Lutz, Michael, and Dave Kolas. "Rule-Based Discovery in Spatial Data Infrastructure." Transactions in GIS 11.3 (2007): 317-336.
[18] Namiot, Dmitry, and Manfred Sneps-Sneppe. "The physical web in smart cities." 2015 Advances in Wireless and Optical Communications (RTUWO). IEEE, 2015.
[19] Sharma, Puneet, et al. "Estimating network proximity and latency." ACM SIGCOMM Computer Communication Review 36.3 (2006): 39-50.
[20] Namiot, Dmitry, and Manfred Sneps-Sneppe. "On Proximity-Based Information Delivery." International Conference on Distributed Computer and Communication Networks. Springer, Cham, 2018.
[21] Namiot, Dmitry, and Manfred Sneps-Sneppe. "Geofence and network proximity." Internet of Things, Smart Spaces, and Next Generation Networking. Springer, Berlin, Heidelberg, 2013. 117-127.
[22] Zaim, Dalal, and Mostafa Bellafkih. "Bluetooth Low Energy (BLE) based geomarketing system." 2016 11th International Conference on Intelligent Systems: Theories and Applications (SITA). IEEE, 2016.
[23] Macedo, Tiago, and Fred Oliveira. Redis Cookbook: Practical Techniques for Fast Data Manipulation. " O'Reilly Media, Inc.", 2011.
[24] Duke, Alistair, and Sandra Stincic Clarke. "Hypercat RDF: Semantic Enrichment for IoT." Semantic Technology: 6th Joint International Conference, JIST 2016, Singapore, Singapore, November 2-4, 2016, Revised Selected Papers. Vol. 10055. Springer, 2016.
On proximity services programming
Dmitry Namiot
Abstract— This article deals with applied programming for services based on proximity. The paper describes ProSe (Proximity Services) introduced in 3GPP specifications. According to the 3GPP specifications, Proximity Services is designed to find devices suitable for direct communication between devices (D2D - Device to Device). In this case, the paper deals with another approach where the definition of close devices is the ultimate goal of the process. Direct connection of devices is not considered at all, and the main reason for this is security related problems. The paper deals with a model where definition of proximity to some device (devices) is the basis (trigger) for presenting data (services). Such a basis in many cases replaces or even complements (expands) the work with geo-referenced coordinates. Accordingly, the approach proposed in this paper is that the ProSe (D2D) components may be the basis for public telecommunication services that extend (replace) services that use location information and do not require direct connection between devices.
Keywords— 3GPP, D2D, network proximity.
REFERENCES
[1] 3GPP TS 24.334 V12.1.1, December 2014; Technical Specification Group Core Network and Terminals, Proximity-services (ProSe) User Equipment (UE) to ProSe function protocols; Stage 3; Release 12.
[2] Rebecchi, Filippo, et al. "Data offloading techniques in cellular networks: A survey." IEEE Communications Surveys & Tutorials 17.2 (2014): 580-603.
[3] Malandrino, Francesco, Claudio Casetti, and Carla-Fabiana Chiasserini. "LTE offloading: When 3GPP policies are just enough." 2014 11th Annual Conference on Wireless On-demand Network Systems and Services (WONS). IEEE, 2014.
[4] Militano, Leonardo, et al. "Device-to-device communications for 5G internet of things." EAI Endorsed Trans. Internet Things 1.1 (2015): 1-15.
[5] Sneps-Sneppe M., Namiot D. (2020) Digital Railway and How to Move from GSM-R to LTE-R and 5G. In: Sukhomlin V., Zubareva E. (eds) Convergent Cognitive Information Technologies. Convergent 2018. Communications in Computer and Information Science, vol 1140. Springer, Cham.
[6] Vo, Nguyen-Son, et al. "Optimal video streaming in dense 5G networks with D2D communications." IEEE Access 6 (2017): 209-223.
[7] Pu, Lingjun, et al. "sNDN: a social-aware named data framework for cooperative content retrieval via D2D communications." Proceedings of the 10th International Workshop on Mobility in the Evolving Internet Architecture. ACM, 2015.
[8] Mumtaz, Shahid, Kazi Mohammed Saidul Huq, and Jonathan Rodriguez. "Direct mobile-to-mobile communication: Paradigm for 5G." IEEE Wireless Communications 21.5 (2014): 14-23.
[9] Goian, Huda S., et al. "Popularity-based video caching techniques for cache-enabled networks: a survey." IEEE Access 7 (2019): 27699-27719.
[10] LTE Direct http://www.3glteinfo.com/lte-direct/ Retrieved: Jan, 2020
[11] Farzamiyan, Amir Hossein. "A Survey on Device-to-Device Communication in 5G Wireless Networks." 14th International Conference on Software Technologies. 2019.
[12] Wang, Hao. "Skype VoIP service-architecture and comparison." INFOTECH Seminar Advanced Communication Services (ASC). 2005.
[13] Andreev, Sergey, et al. "Cellular traffic offloading onto network-assisted device-to-device connections." IEEE Communications Magazine 52.4 (2014): 20-31.
[14] Namiot, Dmitry, and Manfred Sneps-Sneppe. "Context-aware data discovery." 2012 16th International Conference on Intelligence in Next Generation Networks. IEEE, 2012.
[15] Namiot, Dmitry. "Context-Aware Browsing--A Practical Approach." 2012 Sixth International Conference on Next Generation Mobile Applications, Services and Technologies. IEEE, 2012.
[16] Couclelis, Helen. "Ontologies of geographic information." International Journal of Geographical Information Science 24.12 (2010): 1785-1809.
[17] Lutz, Michael, and Dave Kolas. "Rule-Based Discovery in Spatial Data Infrastructure." Transactions in GIS 11.3 (2007): 317336.
[18] Namiot, Dmitry, and Manfred Sneps-Sneppe. "The physical web in smart cities." 2015 Advances in Wireless and Optical Communications (RTUWO). IEEE, 2015.
[19] Sharma, Puneet, et al. "Estimating network proximity and latency." ACM SIGCOMM Computer Communication Review 36.3 (2006): 39-50.
[20] Namiot, Dmitry, and Manfred Sneps-Sneppe. "On Proximity-Based Information Delivery." International Conference on Distributed Computer and Communication Networks. Springer, Cham, 2018.
[21] Namiot, Dmitry, and Manfred Sneps-Sneppe. "Geofence and network proximity." Internet of Things, Smart Spaces, and Next Generation Networking. Springer, Berlin, Heidelberg, 2013. 117127.
[22] Zaim, Dalal, and Mostafa Bellafkih. "Bluetooth Low Energy (BLE) based geomarketing system." 2016 11th International Conference on Intelligent Systems: Theories and Applications (SITA). IEEE, 2016.
[23] Macedo, Tiago, and Fred Oliveira. Redis Cookbook: Practical Techniques for Fast Data Manipulation. " O'Reilly Media, Inc.", 2011.
[24] Duke, Alistair, and Sandra Stincic Clarke. "Hypercat RDF: Semantic Enrichment for IoT." Semantic Technology: 6th Joint International Conference, JIST 2016, Singapore, Singapore, November 2-4, 2016, Revised Selected Papers. Vol. 10055. Springer, 2016
