IrcDDB
Введение
Селективные вызовы в D-STAR - это и преимущество и недостаток.
Преимущество в том, что они есть, ровно как и в профессиональных технологиях транкинговой связи (например: TETRA) и телефонной связи.
Недостаток - на репитерах D-STAR нет возможности разделять частоты (FDMA), а в рамках несущей - время (TDMA). Иными словами, при селективной передаче ресурс репитера монополизируется одним пользователем. Это, кстати, одна из причин, по которой крейне рекомендуется call-routing реализовывать на дуплексных репитерах.
Идея call-routing проста - ровно как в сотовой сети вы не знаете, к какому репитеру подключен ваш корреспондент, знаете лишь позывной ближайшего репитера. В новой станции ICOM ID-31 такая функциональность доведена до блеска - на флеш-карте станции хранится файл со списком репитеров, репитер выбирается по геопозиции, полученой со встроенного GPS-приёмника станции.
При смене позиции ваша станция инициирует передачу на репитер (ну или вы сами нажимаете PTT), таким образом она регистрируется на репитере.
Я точно не знаю, как изначально появился call-routing на ID-RP1C, но эта функция реализована в ПО RS-RP2C и ПО pdplus. В настоящий момент времени вся информация о регистрациях (в инфраструктуре ICOM) передается на Trust Server, доступ к которому жёстко модерируется.
В ранних версиях ПО (generation 1 - G1) была реализована множественная репликация данных между узлами и это приводило к тому, что информация о регистрации узлов могла реплицироваться вплоть до пары часов.
Первый и основной Trust Server был создан командой K5TIT и, как ясно из позывного, находится в штате Техас, США.
Многим радиолюбителям за пределами США не нравилось, что информация о их местоположении "сливается" в США, что привело к организации X-Trust / Multi-Trust. На самом деле краеугольным камнем тут является не то, что техническая площадка находится в Техасе, а что она удалена и при её недоступности (авария на площадке, проблемы на каналах связи) страдают все узлы D-STAR, на которых предоставляется call-routing.
В общем, в Европе появился свой независимый X-Trust, "общения" с которым у US-Trust не было.
ircDDB
Для решения вновь появившейся проблемы немцы из Georg Simon Ohm University of Applied Sciences (DB0FHN) предложили свою разработку - ircDDB.
Своей идеей реализации ircDDB обязан ботнетам - для передачи команд используется старая, как весь Интернет, технология IRC.
IRC - это не что иное, как чат-сервер с функцией релея, благодаря которой сервера можно масштабировать горизонтально, разнеся их географически. Одна группа серверов в США, другая в Европе - все они объеденены группой чатов. Каждый репитер/шлюз является ботом в чате dstar. Практически при каждой новой передаче шлюз передает информацию о маршруте другим ботам через сервера IRC. Информация передается внутри географических регионов и реплицируется на уровне опорных узлов ircDDB. Таким образом обеспечивается высокая производительность и надёжность решения. Хранение операционных данных о маршрутах производится локально на узлах. Теперь становится понятна вторая часть названия системы DDB - distributed database (распределенная база данных).
Я умеренно употребил слово "боты", потому как получателем сообщения о факте передачи (heard) является не весь чат-канал, а боты-серверы ircDDB (ircddbd).
Задачами ircddbd являются:
- кэширование таблиц маршрутизации позывных и видимости;
- обработка входящих сообщений heard;
- подготовка статистики для чат-канала статистики;
- нотификация всех узлов в канале об изменении таблиц маршрутизации и видимости.
При регистрации станций ircddbd сразу сообщает всем узлам, на каком репитере зарегистрирована станция. А при изменениях таблицы репитеров - нотифицирует все узлы о её изменении. Задача управления и раздачи списка узлов решается штатным функционалом серверов IRC - все узлы являются пользователями IRC.
Теперь о связи Trust и ircDDB. Всем узлам, базирующимся на ПО RS-RP2C предлагается установить ircDDB Add-on, подключающий эти узлаы к ircDDB. Таким образом ircDDB покрывает маршрутные таблицы всех Trust-сетей.
Как это работает на практике?
Вы нажимаете PTT на вашей станции. Она отправляет заголовок передачи на репитер. В свою очередь ПО репитера/узла информирует серверных ботов ircDDB о регистрации вашей станции на узле. Таким образом все репитеры, подключённые к ircDDB узнают, с каким репитером вы работаете. Далее, вы делаете селективный вызов через репитер. ПО шлюза по локальной копии маршрутных таблиц определяет, на каком репитере зарегистрирован ваш корреспондент, позывной и IP-адрес шлюза и отправляет VoIP-поток на этот узел.
Вот так вот происходит QSO.