Пользователь
0,0
рейтинг
16 октября 2013 в 19:44

Администрирование → Что такое MANET или почему WiFi не решение всех телекоммуникационных проблем

Прочитав очередной пост на хабре на тему самоорганизующихся сетей автор понял, что в этой теме до сих пор нет ясности. В большинстве случаев о самоорганизующихся радиосетях говорят «mesh», «ad hoc», «mobile ad hoc» и т.д., подразумевая, что это одно и тоже. И это касается не только простого хабро-обывателя, пусть даже технически подкованного, но и большинства инженеров с PhD. К тому же, зачастую такие сети преподносятся как универсальное средство на все случаи жизни [1] или даже как чуть-ли не единственный вектор развития и эволюции телеком индустрии [2]. Смею уверить, что без четкого понимания места и роли этих сетей, такие утверждения, по крайней мере, преждевременны, хотя и недалеки от реальности.

Итак, начнем с определения, что же такое сети типа Mesh, Ad Hoc, mobile Ad Hoc и в чем разница между ними.

Mesh сети – радиосети ячеистой структуры, состоящие из беспроводных стационарных маршрутизаторов, которые создают беспроводную магистраль и зону обслуживания абонентов) и мобильных/стационарных абонентов, имеющих доступ (в пределах зоны радиосвязности) к одному из маршрутизаторов. Топология – звезда, со случайным соединением опорных узлов.
Ad hoc сети – радиосети со случайными стационарными абонентами, реализующие полностью децентрализованное управление при отсутствии базовых станций или опорных узлов. Топология – фиксированная со случайным соединением узлов.
MANET (Mobile Ad hoc NETworks) сети – радиосети со случайными мобильными абонентами, реализующие полностью децентрализованное управление при отсутствии базовых станций или опорных узлов. Топология – быстро меняющаяся со случайным соединением узлов.
К этому надо добавить WSN (Wireless Sensor Networks) — беспроводные сенсорные (телеметрические) сети, состоящие из малогабаритных сенсорных узлов с интегрированными функциями мониторинга определенных параметров окружающей среды, обработки и передачи данных по радиоканалам. Они могут, в зависимости от задачи, строиться как топологии mesh, ad hoc так и MANET; автомобильные сети VANET (Vehicle Ad hoc NETworks) – сети связи транспортных средств; и всевозможные гибриды вышеизложенного.

Почему именно MANET?

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

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

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

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

О технологиях и стандартах

В большинстве научных работ и коммерческих проектах (прожектах) подразумевается использование стандартов IEEE 802.11, известного в народе как WiFi, IEEE 802.15.4 (ZigBee) или же IEEE 802.15.1 (Bluetooth). На этом практически исчерпываются предлагаемые радио технологии по данной теме. Объясняется такое неразнообразие подходов просто: у нас уже есть WiFi и Bluetooth в каждом смартфоне, так не лучше ли переиспользовать их для задач самоорганизации радиосетей. При этом рисуется красивая картинка, как в [3], и объясняются преимущества от их использования в сценарии ...MANET.

Вот тут и «зарыта собака». Дело в том, что ни IEEE 802.15.4, ни тем более IEEE 802.11 не разрабатывались для сетей типа MANET. Они разрабатывались для mesh-сетей (см. выше определение) и имеют иерархический принцип построения. Тот же стандарт ZigBee подразумевает 3 типа устройств в сети: координатор, маршрутизатор (роутер) и конечное устройство. Ну и что скажете вы? А дело в том, что даже если на столе у вас будут лежать 2 конечных ZigBee-устройства, скажем торшер и чайник, то они никогда не будут «говорить» друг с другом напрямую, а только через роутер. К тому же, новое устройство никогда не войдет в сеть без предварительного «ОК» и кучи других параметров от координатора. На все это надо время, во время которого пользователь просто ждет. Это особенно важно для сетей с быстро меняющейся топологией, например VANET.

То же касается технологии Bluetooth, где всегда есть один координатор, который раздает тайм-слоты и управляет доступом в канал. Абоненты, как и в ZigBee, всегда общаются через координатора. Координаторы могут образовывать между собой scatternet, но реально это не работает (см. дальше почему). Bluetooth 4.0, известный как Bluetooth Low Energy, и вовсе предназначен для передачи «раз в час» пакетов длины не более 20 байт прикладных данных [4]. Так что он физически не подходит для высокоскоростных сервисов.

О проблемах

А теперь представьте себе машину, которая мчится по магистрали и ей необходимо обменяться информацией со светофором и проезжающей машиной и сравните это со временем, которое вы тратите на вход в обычную WiFi сеть или подсоединяетесь по Bluetooth к новому устройству. Сравнили? Плюс ко всему, соединение должно быть надежным (с подтверждением доставки), защищенным (шифрование + аутентификация) и быстрым (пропускная способность желательно > 1 Мбит/с).

Или другой пример – MANET. Представьте солдата на поле боя, где ситуация меняется ежесекундно, а ему надо в реальном времени доложить обстановку командованию, получить приказ, загрузить тактическую карту и тд. Такое соединение помимо надежности и безопасности должно быть еще и устойчивым к изменениям топологии, маршрутизация должна обладать быстрой сходимостью, т.е. гарантировать нахождение маршрута заданного качества за разумное время, гарантировать отсутствие зацикливаний, обеспечивать многоадресатную рассылку. А если таких солдат много. Скажем, рота или батальон?

Вот теперь можно представить, какого рода проблемы стоят перед этими сетями.

Так все-таки, почему же, при всех вышеупомянутых требованиях, нельзя создать гибридную или полностью распределенную радиосеть типа MANET на стандарте IEEE 802.11 или ZigBee или Bluetooth? Можно! Но давайте скажем честно, что это будет за сеть.

1. МАС уровень
Наиболее важным для эффективной работы радиосетей с коммутацией пакетов является канальный уровень, точнее его МАС-подуровень из-за его концептуальной сложности и глобального сетевого влияния, т.к. нерациональная организация коллективного доступа к радиоканалу может значительно снизить скорость передачи пакетов по сети или даже совсем заблокировать ее работу вне зависимости от качества функционирования других уровней эталонной модели OSI.

В WiFi, как и в ZigBee, используется протокол множественного доступа с контролем несущей и предотвращением коллизий — CSMA/CA. Он предполагает, что «один говорит-остальные молчат». При этом производится обмен управляющими фреймами RTS/CTS для решения проблемы скрытого абонента и среда передачи резервируется для передающей станцией. Не буду утомлять техническими подробностями как это делается – кто захочет узнать, в Интернете тонны информации на эту тему. Скажу лишь, что резервирование среды по методу CSMA/CA требует строгой симметричности линий и определенных элементов координированного управления, что для MANET – невозможно/нежелательно.

Итого, имеем деградацию параметров производительности протокола множественного доступа при высокой динамике изменения топологии и интенсивном трафике.


2. Адресация
Сейчас только ленивый не знает о том, что адресное пространство IPv4 исчерпано.
Понятно, что поднимать DHCP и раздавать адреса внутри сети MANET – идея нежизнеспособная хотя бы потому, что это потребует времени на поиск маршрута к серверу, да и как маршрутизировать изначальный адрес типа 0.0.0.0 при многоскачковой ретрансляции пакета?

Принято считать, что IPv6 является тем протоколом, который ляжет в основу сетей будущего. Согласимся с этим. Но тогда возникает некоторое недоумение по поводу неповсеместной поддержки нового протокола разработчиками маршрутизации. Даже такие основополагающие ad hoc документы IETF, как RFC 3561, RFC 4728, не предлагают конкретных механизмов поддержки IPv6. Таким образом, эта проблема отдается на откуп вендорам железа, а те в свою очередь решают задачу как могут.

Еще одним неприятным фактом для WiFi, в контексте самоорганизующихся сетей, является обязательная адресация на канальном уровне. Это кажется мелочью, но как показывает практика – эта мелочь способна положить всю сеть. Поясняю. Если мы работаем в сети IPv4, то заголовок канального фрейма формируется с помощью протокола ARP, который определяет МАС адрес вызываемого абонента по его IP путем периодического опроса. В протоколе IP версии 6, протокола ARP нет. Он заменен протоколом ICMP версии 6, который предполагает обмен специальными сообщениями ”Neighbor solicitation” – ”Neighbor Advertisement” для привязки МАС адреса к IPv6. Естественно, что в классическом LAN эти запросы не идут далее 1 маршрутизатора, т.к. там все пользователи предполагается сидят на одной общей шине. В радиосетях, в силу их беспроводной природы, все абоненты физически не могут «сидеть» на общем канале и слышать всех остальных, тем более в MANET. А заполнение сети ARP или ICMPv6 запросами ведет к увеличению неинформативного обмена между абонентами и, как следствие, к снижению реальной пропускной способности.

Как видим, на пустом месте получили необходимость в обмене канальными фреймами между соседними абонентами сети.

3. Маршрутизация
Принято делить протоколы маршрутизации на проактивные (табличные), реактивные (зондовые) и их гибриды (есть еще волновые, но о них в другой раз). На заре развития mesh-сетей пытались использовать стандартный протокол маршрутизации OSPF. Из этого ничего не вышло, естественно, т.к. он разрабатывался для совсем иных условий эксплуатации. В результате появилась масса работ, как научных так и не очень, где предлагаются десятки протоколов маршрутизации для самоорганизующихся радиосетей. Кому интересна эта тема, советую сайт www.ieee.org, раздел publications. Проблема, однако, заключается в том, что реально разработанные протоколы маршрутизации сетей MANET либо не реализованы физически в языке С, либо ориентированы на достижение оптимального использования сетевых ресурсов при квазистатичных условиях работы сети, т.е. когда топология меняется медленно или вообще не меняется. Последнее актуально для таблично-ориентированных протоколов типа OLSR, DSDV, WRP, BATMAN, Babel и т.п.

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

Зондовые протоколы, как напр. AODV, DSR, SSR, TORA, предполагают маршрутизацию по запросу, но не до конца стандартизированы (см.выше проблему адресации). К тому же из-за несимметричных каналов маршрутизация должна поддерживать режим построения множества маршрутов как от адресата-к получателю, так и в обратном направлении. А это поддерживают только протоколы DSR и TORA. Поэтому тут пока свободное поле для вольной мысли девелопера. А девелопер бывает разный…

4. Транспортный уровень
Автору по роду научной деятельности довелось работать над адаптацией ТСР и реализацией нового транспортного протокола для MANET. Можно писать на эту тему очень долго и нудно. Поэтому приведу лишь основные выводы из своего опыта. Стандартный протокол TCP, в реализации RFC 793 и RFC 5681 работает плохо при многоскачковой ретрансляции и случайном доступе. Сеть или недогружена или перегружена, связано это не с отсутствием собственно пропускной полосы, а с большими флуктуациями в параметрах соединения между абонентами: задержка, джиттер, процент потерь пакетов; и особенно частым изменением собственно маршрута передачи. К тому же, оказалось, что ТСР должен иметь доступ к нижестоящим уровням – сетевому и канальному для более адекватного реагирования на изменения в такой сети. А концепция cross-layer существует только в статьях разных умных людей и ее практической реализацией никто не занимался. Почти никто. Что делать с этим? Другого ответа кроме как RnD – нет.

Теперь, с учетом всего вышесказанного, какие радиотехнологии «с полки» могут сразу удовлетворить всем требованиям и справиться с вышеописанными проблемами? Ответ очевиден – никакие. Вывод: создать реальную самоорганизующуюся сеть типа MANET можно и на WiFi, но она будет, мягко говоря, не очень хорошо работать. Ровно поэтому мы и не наблюдаем такого бума в беспроводном p2p, как в проводном Интернете, где есть Skype, TOR, торренты и много другого интересного.

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

О перспективах

Но не будем сгущать краски, кое-что сделано и для настоящих сетей MANET. Не будем также заниматься рекламой, тем более что это запрещено правилами хабра-сообщества. Просто скажем, что неким коллективом разработано программно-аппаратное решение для встраиваемых систем в виде радиомодуля, которое позволяет организовывать доступ на скоростях до 2 Мбит/с (около 700 кбит/с в приложении) в полностью децентрализованных мобильных радиосетях, с поддержкой реактивной маршрутизации и протокола IPv6. Сейчас заканчивается разработка комплекта разработчика, куда входят от 3-х радиомодулей с платами сопряжения, к которым могут быть подключены различные сенсоры и другие источники информации, отладочная плата, шлюз MANET-Ethernet и пользовательское ПО управления и конфигурирования сети. На базе этого решения возможна также реализация пользовательского терминала в формате защищенного смартфона или модема с USB.

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

Спасибо за внимание и буду признателен за обратную связь!

[1] — www.russianelectronics.ru/leader-r/review/doc/59295
[2] — habrahabr.ru/company/infomania/blog/102814
[3] — habrahabr.ru/post/79360
[4] — e2e.ti.com/support/low_power_rf/f/538/t/71381.aspx
Какой сервис был бы наиболее интересен и полезен юзерам в самоорганизующихся радиосетях:

Проголосовало 339 человек. Воздержалось 59 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

@YuriiVoitenko
карма
30,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (37)

  • +1
    Раз вы ссылаетесь на мою статью, то в описании протоколов могли и про cjdns написать.
    В wi-fi ad-hoc сетях коллизии также решаются с помощью CSMA/CA?
    • +2
      cjdns — это из другой оперы совсем. Здесь рассматривались протоколы маршрутизации именно беспроводных сетей, а не Интернета и тем более не p2p сервисов, вроде Skype. Так называемый режим ad hoc в wifi имеет тот же самый канальный уровень, что и режим «точки доступа», следовательно и CSMA/CA тоже. Хотя на самом деле ничего общего с определением «ad hoc» этот режим не имеет. Просто была точка доступа в виде роутера на полу, а стала в виде лэптопа на столе. Но суть та же, остальные подключаются именно к этой новой «точке», а не к друг-другу.
      • 0
        Ну атак у cjdns маршрутизация децентрализованная в добавок, и работает он именно в сетях а не в интернете т.е L2
        • +1
          Под него есть RFC?
          Если нет, тогда вот ссылка launchpad.net/cjdns, где сказано что это отголосок славно-известной Kademlia DHT.
          И это работает, простите, не на L2, a L3 поверх маршрутизации Интернета.
          Я ни в коей мере не пытаюсь Вас обидеть, просто это реально другая штука. Серьезно.
          • 0
            Так. Я не его разработчик, просто интересуюсь этим, на l2 работает, в топике на который вы ссылаетесь спорами мы это доказали :)
            • 0
              Бесспорно, работает. В Интернете. Я сам большой любитель p2p и DHT. В свое время в kazaa, прородителе skype, сидел и выкачивал всякие раритеты. Но только вот жаль, что эта штука не сможет работать в радиосетях с переменной топологией. Ключевая причина этого тут, раздел ## The Router, абзац 5. А в целом, нормальная вещь )
              • 0
                А из-за чего? я не говорю что вы не правы — а мне правдо интересно, просто мы тут планируем в компании энтузиастов построить Mesh В России
                • 0
                  Ну например из-за того, что роутеры обновляют маршруты по UDP/IPv6 с TTL=0. Но не это главное, конечно. Понимаете, Mesh и MANET — 2 большие разницы. В первом случае, вы просто ставите точки и прописываете маршруты между ними (или они сами их ищут), а абененты всегда соединяются с точкой. В MANET нет точек доступа, а все абоненты — роутеры. Поэтому маршруты должны строиться по другим принципам.
                  Не спорю, mesh и wifi очень перспективные технологии. Но они созданы для других сценариев эксплуатации.
                  А вашему проекту «Mesh В России» искренне желаю удачи! )
  • 0
    А где нибудь уже есть устройства в полной мере реализующие MANET? Или пока только драфты и те на бумаге?
    • 0
      Есть. Я ж говорю, разработали программно-аппаратный комплекс, размером 28х45 мм. Если интересно могу дать ссылку, где можно ознакомиться с деталями и заказать.
      • +2
        Конечно, давайте ссылку!
        • 0
          Я бы купил несколько на пробу, если они конечно стоят, не как крыло от чугунного боинга.
          • 0
            Смотря что за устройства, если это девелоперские модули, я бы тоже посмотрел.
        • +1
          wp2p.org/index.php?q=en/ad-hocmanet-communication-kit
          Это eval. kit.
          Dev. kit со звуком на подходе.
          Встраиваемые модули уже есть, но пока не вывешены на сайт полностью. Но в принципе уже можно их заказать тоже.
          В общем, «stay tuned to know more»…
          • 0
            Вынесите ссылку в статью.
            • 0
              Нельзя, так как это будет считаться рекламой. Или можно?
              • +1
                habrahabr.ru/company/tm/blog/197634/
                На ваш «некий коллектив» эта штука не распрстраняется? А то могли бы бложик завести, там точно будет можно…
      • +1
        Я думаю тут всем интересно, поэтому дай ссылку в комментах. Не думаю что это будет такая уж прям реклама.
    • 0
      В полной или нет — судите сами, но суть та же: MotoMesh SOLO

      Если верить рассказам сейлов, изначально разрабатывалось для связи между танками на поле боя. Используется проприетарный протокол MEA. Точки доступа нужны только для соединения с проводными сетями — всё остальное на клиентах. В результате — зверски надежная система: децентрализованная, самоорганизуюшаяся, самовосстанавливающаяся, сверхнадежный радиотракт (который, работая в 2.4ГГц убивает всё остальное во всем диапазоне :) ), скорости (перемещения клиентов) > 100км/ч, но медленная. 2Mbps для нее — очень крутой показатель. Ессно, никакого IPv6 — чистый L2. Ну, и цена :)
      В итоге используется в шахтах, карьерах, сложных участках аэропортов, узловых и сортировочных ж/д станций, портов и т.д. — там, где ничего другое не работает в принципе.
  • +2
    2 года назад очень интересовался этой темой, даже подписался на обновления от IETF datatracker.ietf.org/wg/manet/charter/

    Молодцы что двигаете эту тему, за ней будущее!!!
  • 0
    Не очень понятны следующие вопросы:
    1. Находится ли радиочастота вашего решения в диапазоне не требующем лицензирования в России.
    2. Мощность передатчика (чтобы соответственно тоже не требовалось лицензирование).
    3. Дальность связи при этом (в идеале график зависимости скорости от дальности).

    А так в принципе ваше решение конечно весьма интересует. Хотя скорость 2 Мбит/с — это конечно всё же маловато пока… Если хотя бы 10, то уже совсем другой расклад был. Но для начала и это не плохо.
    • +1
      1. Полосы частот 2,4 ГГц — 2,483 ГГц не требуют лицензирования в России при выходной мощности не более 100 мВт.
      2. Выходная мощность в варианте модуля без усилителя 0 dBm (1 mW), с усилителем 18 dBm (63 mW) — см. п.1
      3. Дальность связи определяется условиями распространения и чувствительностью приемника: -85 dBm без усилителя и -90 dBm с усилом. Бюджет канала, соответственно, дает ответ по макс. дальности.

      Если интересны детали PHY, то модуляция — GFSK, ширина канала — 2,54 МГц, общее число доступных каналов — 17.

      Скорость, конечно, не супер какая, но для большинства сервисов хватает.
      • 0
        Ммм ну всё же, как вы оцениваете максимальную дальность без снижения скорости в условиях прямой видимости и варианте 63 mW?

        Да, для обычных вещей вполне достаточная скорость. Просто нам актуально ещё и видео в реальном времени…
      • 0
        Вот почему, никто не делает такие решения под 902-928 Мгц, которые кстати тоже везде нелицензируются…
        • +1
          Там скорости не те. Плюс к этому, относительно узкий диапазон частот. Хотя если Вам очень надо, можно кастомизировать наше решение.
          • 0
            ну 2 мегабита прокачать можно, убикути 54 запросто прокачивает, древние арланы 630ые 875 кб, на 30 км держат.
            • 0
              Честно говоря, ничего не понял ))))).
              Как это «прокачать», если там аппаратно сделана модуляция, полосы частот, ВЧ тракт?
              Поднять уровень сигнала что-ли усилителем? Ну так от этого только сигнал/шум увеличится, а скорости будут те же.
              А вообще интересно, то что Вы написали. Можно по подробнее?
  • +2
    С усилителем по free space модели около 1,5 км будет. Точка-точка, разумеется. С ретрансляцией — много больше.
    Видео реального времени тоже можно, но качество будет зависеть от полосы кодека и устойчивости к джиттеру. Словом, надо пробовать ).
    • +1
      Очень позитивно. А тогда ещё несколько вопросов:
      1. Планируете ли в дальнейшем увеличение скорости или нет? Т.е. стоит ли такой вектор в разработке?
      2. Я там глянул у вас в контактах Швеция стоит… Это вы реально там или же только формальности для бизнеса, а сами здесь где-то? Это может иметь значения при некоторых применениях…
      3. У вас указано, что есть вариант подключение по ethernet и плюс ещё другие (usb?). Так вот как дела с драйверами (linux, windows) во втором случае?
      4. А можно какие-то приблизительные цены на конкретные платы уже сейчас назвать или пока нет?
      • 0
        1. Все зависит от элементной базы. Мы пользуемся готовыми трансиверами от ведущих мировых производителей.
        3. Опробовали библиотеку libUSB для Windows — работает в bulk mode. Возможно предоставить в коплекте. Но USB пока только предзаказ — плата, на этапе производства.
        2 — 4. Все, что так или иначе касается коммерции, пожалуйста, в личку. Не будем нарушать хабра-правила! )
  • 0
    Мне кажется удобный сервис может выглядеть так.

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

    После этого, находясь в другой части города используя публичный идентификатор отправляю в сеть сообщение вида: «Нужно доставить сообщение… пиру… за… BTC». Узел, который берет на себя доставку сообщения (и её верификацию) через любые доступные каналы получает заслуженную копеечку.

    Одним из каналов в таком случае вполне может быть MANET.
    • 0
      Ну первое, т.е. про шифрование и аутентификацию, у нас реализовано, причем в децентрализанном виде.
      А вот что значит «заслуженную копеечку» во втором случае, не понял...)) Поясните?
      • 0
        Представьте доп. сервис: участник сети Х видит, что А хочет передать В сообщение, при этом В нет в сети, но к нему есть другой канал (прямой вайфай, выделенный канал в инете и т.п.), он предлагает А передать своё сообщение каким-то другим способом, за это и запрашивает вознаграждение. Тогда у участников появляется стимул иметь высокую связность с другими узлами сети и служить ретрансляторами.
        • 0
          Оригинально, но коммерчески нереализуемо… Кто кому будет платить и сколько и вообще как знать, что это за участник сети, если все закрыто на сетевом уровне? Кроме как IPv6 получателя он ничего больше не знает.
          Я бы предложил немного другую модель: участник сети имеющий шлюз MANET, который виден из Интернета, при каждом каждом пробросе трафика по линии «радио-Ethernet» и наоборот считает этот трафик. Потом на этот объем данных он сможет говорить из радиосети с PSTN или хранить распределенно в MANET облаке свои данные. Как Вам такой вариант?
          • 0
            Вполне реализуемо, если брать Bitcoin, его транзакции проводить через публичную сеть (интернет), а оплачиваемые сообщения — на уровне шифрованной mesh-сети.

            Про PSTN не очень понял, если честно.
            • 0
              Про PSTN — все просто. Если есть статический IPv6, то весь трафик из/в PSTN от/к этому адресу можно посчитать, и следовательно перевести в минуты VoIP. Естественно, что наш кодек будет не variable bitrate, a constant bitrrate. Не настаиваю на этом решении, но по крайней мере знаю как его реализовать. А как идентифицировать тип сообщения в зашифрованном трафике на L3 не представляю себе? Интересно было бы развить вашу мысль…
  • 0
    Жаль, что реальное устройство пока не взлетело.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.