ИИ разве что с широком смысле. Многослойные нейросети со сложной архитектурой требующие обучения на больших данных тут вряд ли пригодятся, а вот много if-ов и хитрых формул описывающих системы с обратной связью вполне применимы. И скорее всего придется построить и обсчитывать математическую модель этих фильтров
действительно, основным тормозом развития 5G относится отсутствие его потребителей, поэтому он внедряется сильно медленнее чем планировалось. На улицах не видно автономных автомобилей, народ массово не ходит в VR очках и т.д. А с задачей скоростной передачи данных неплохо справляется и LTE. Тут именно "не угадали" рынок, а точнее слишком оптимистично его оценили. И теперь (инсайт) разработчики основных вендоров сидят (какое-то время сидели?) без годовых бонусов
SGSN и GGSN даже не разрабатываются, так как это узлы опорной сети 2G/3G. сейчас такое разве что по старой памяти кто-то эксплуатирует, новое разрабатывать даже смысла нет.
остальное же это части 4G коры, где я не копенгаген и не знаю что NDA а что нет. не судите строго (:
Вряд-ли получится создать систему связи в которой будет реализовано все и сразу
Вы не поверите, можно. только TTM (time to market) у такой системы будет мягко говоря очень большим. Сейчас конъюнктура рынка такова, что операторы готовы получать базовые станции по частям: сначала железо с софтом для устранения цифрового неравенства (так называется БС которая не потянет высокую нагрузку, т.е. можно поставить только в каком-нибудь селе Кукуево где еще проводные телефоны в ходу), потом получать все более и более проработанные прошивки поддерживающие большую нагрузку, потом железо следующего поколения, потом лучшие прошивки... и на этом круг сансары замыкается. иногда правда разрывается и замыкается вновь на стандартах нового поколения. В случае 5G же свет клином на скорости передачи и емкости по абонентам не сходится, дописываются еще части стандарта посвященные всяким разным uRLLC (Ultra-Reliable Low-Latency Communications) и mMTC (massive Machine-Type Communications).
а какие проблемы с Mission-Critical Push-to-Talk? это один из многих узкоспециализированных режимов работы целлы. По сути своей не более чем набор фич которые нужно поддержать, причем только на уровне софта. И да, это не бесплатно как с точки зрения разработки (программисты есть всегда хотят, а нейросети не работают без серверов и электричества), так и с точки зрения эксплуатационных характеристик: общая скорость передачи данных в целе падает чем больше используется MCPTT. Скажу даже больше: MCPTT абстракция уровня L2 (наверное самый большой удар приходится на планировщик MACPS) и выше, вплоть до того что определяющим становится время задержки получения данных в ядре сети. PHY-ю без разницы что переносят в себе пакеты данных и какой у них приоритет. В PHY просто приходят другие настройки, например MCS поменьше MCS — Modulation and Coding Scheme, отвечает за скорость корректирующего кода и размер QAM‑созвездия. чем меньше MCS тем более консервативно ведет себя планировщик: меньше скорость передачи данных, но больше помехоустойчивость
А сидели бы на старом добром (M)FSK или PSK - горя бы не знали
Знали бы, еще и рукавом бы слезы горючие утирали только так. Здесь идет размен более полного использования возможностей радиоканала на аппаратную сложность. Сравните (простите (М)ЧМ я цинично проигнорирую, там ничего принципиально не поменяется) PSK16 vs. QAM16 на картинке ниже: метрикой качества для созвездия является расстояние между соседними точками (именно они будут с большей вероятностью перепутаны из-за шумов). При прочих равных у QAM16 это расстояние сильно больше, а значит перепутываний меньше и в конечном итоге можно больше информации загнать в тот же самый канал с тем же самым шумом.
При этом да, у QAM пик-фактор получается сильно больше 1, и это начинает требовать линейности усилителя. При этом сам усилитель действительно хочется запускать с углом отсечки меньше 90° (или как вы правильно сказали в классе С), потому что боремся за КПД и рассеиваемую тепловую мощность.
И да, без DPD с его математикой и дополнительными АЦП это не поженить.
для выпуска разработанного нами оборудования у ядра есть все что необходимо. если не лень, то можно сходить посмотреть например на сайт и прочитать про ФАБ Дубна
разработчиком RU является одно из подразделений ядра. Ждите следующие статьи цикла, там расскажут более подробно и в красках. Про схемотехнику и конструктив BBU тоже планируем писать
15 лет назад был 2010-й, и по моей памяти мобильного интернета хватало разве что в ICQ початиться да в гугле пошариться. Первый смартфон у меня появился в 2012-м году, брал еще на юноне (рынок такой), ютуб и прочее я на нем не смотрел. Дело было в СПб, а у вас это где?
У нас ведется разработка собственного ядра сети, равно как и GSM контроллера. Но этот цикл статей именно про базовую станцию и ее железо, поэтому весь остальной телеком остается за скобками. Цикл статей про ядро сети (я слышал) на стадии планирования, так что ждите будет
Есть мнение что предложенное решение в статье далеко от оптимального.
функции osMessageQueuePut и osMessageQueueGet копируют данные из очереди в локальную память, а это копирование явно лишнее и очень расточительно по отношению к памяти. на вашем месте я бы воспользовался Memory Pool и передавал между тасками через очереди только указатели на области памяти, избегая копирования всего сообщения.
посмотрел краем глаза. Впечатления остались самые положительные, книга подкупает строгостью рассуждений и выводом всего и вся. Да, в ней есть все и даже больше чем в этой статье. но там формат 100 страниц + приложения
тут я похоже мало что могу сделать. на версии для пк (где это все и писалось) формулы видны. как только заметил что на мобильной версии вместо формул разметка написал в тех поддержку, сейчас жду ответа. Если кому-то известно решение этой проблемы просьба отписаться.
А пока что читайте с пк
пока что не очень похоже на рабочую технологию, слишком много будет ложных срабатываний. Как например робот-кресло из первого видео мог спокойно проехать перед машущим руками человеком.
P.S. А почему тесла от медведей задним ходом отъехала? автопилотам же вроде страх неведом
Хотелось бы дополнительно попросить ссылки на англо- и русскоязычные научные статьи по теме навигации в облаке дронов. вы как человек занимающийся этой темой скорее всего должны знать кто что пишет. спасибо!
ИИ разве что с широком смысле. Многослойные нейросети со сложной архитектурой требующие обучения на больших данных тут вряд ли пригодятся, а вот много if-ов и хитрых формул описывающих системы с обратной связью вполне применимы. И скорее всего придется построить и обсчитывать математическую модель этих фильтров
действительно, основным тормозом развития 5G относится отсутствие его потребителей, поэтому он внедряется сильно медленнее чем планировалось. На улицах не видно автономных автомобилей, народ массово не ходит в VR очках и т.д. А с задачей скоростной передачи данных неплохо справляется и LTE. Тут именно "не угадали" рынок, а точнее слишком оптимистично его оценили. И теперь (инсайт) разработчики основных вендоров сидят (какое-то время сидели?) без годовых бонусов
попробую ответить на ваш вопрос.
SGSN и GGSN даже не разрабатываются, так как это узлы опорной сети 2G/3G. сейчас такое разве что по старой памяти кто-то эксплуатирует, новое разрабатывать даже смысла нет.
остальное же это части 4G коры, где я не копенгаген и не знаю что NDA а что нет. не судите строго (:
Вы не поверите, можно. только TTM (time to market) у такой системы будет мягко говоря очень большим. Сейчас конъюнктура рынка такова, что операторы готовы получать базовые станции по частям: сначала железо с софтом для устранения цифрового неравенства (так называется БС которая не потянет высокую нагрузку, т.е. можно поставить только в каком-нибудь селе Кукуево где еще проводные телефоны в ходу), потом получать все более и более проработанные прошивки поддерживающие большую нагрузку, потом железо следующего поколения, потом лучшие прошивки... и на этом круг сансары замыкается. иногда правда разрывается и замыкается вновь на стандартах нового поколения. В случае 5G же свет клином на скорости передачи и емкости по абонентам не сходится, дописываются еще части стандарта посвященные всяким разным uRLLC (Ultra-Reliable Low-Latency Communications) и mMTC (massive Machine-Type Communications).
а какие проблемы с Mission-Critical Push-to-Talk? это один из многих узкоспециализированных режимов работы целлы. По сути своей не более чем набор фич которые нужно поддержать, причем только на уровне софта. И да, это не бесплатно как с точки зрения разработки (программисты есть всегда хотят, а нейросети не работают без серверов и электричества), так и с точки зрения эксплуатационных характеристик: общая скорость передачи данных в целе падает чем больше используется MCPTT.
Скажу даже больше: MCPTT абстракция уровня L2 (наверное самый большой удар приходится на планировщик MACPS) и выше, вплоть до того что определяющим становится время задержки получения данных в ядре сети. PHY-ю без разницы что переносят в себе пакеты данных и какой у них приоритет. В PHY просто приходят другие настройки, например MCS поменьше MCS — Modulation and Coding Scheme, отвечает за скорость корректирующего кода и размер QAM‑созвездия. чем меньше MCS тем более консервативно ведет себя планировщик: меньше скорость передачи данных, но больше помехоустойчивость
Знали бы, еще и рукавом бы слезы горючие утирали только так. Здесь идет размен более полного использования возможностей радиоканала на аппаратную сложность. Сравните (простите (М)ЧМ я цинично проигнорирую, там ничего принципиально не поменяется) PSK16 vs. QAM16 на картинке ниже: метрикой качества для созвездия является расстояние между соседними точками (именно они будут с большей вероятностью перепутаны из-за шумов). При прочих равных у QAM16 это расстояние сильно больше, а значит перепутываний меньше и в конечном итоге можно больше информации загнать в тот же самый канал с тем же самым шумом.
При этом да, у QAM пик-фактор получается сильно больше 1, и это начинает требовать линейности усилителя. При этом сам усилитель действительно хочется запускать с углом отсечки меньше 90° (или как вы правильно сказали в классе С), потому что боремся за КПД и рассеиваемую тепловую мощность.
И да, без DPD с его математикой и дополнительными АЦП это не поженить.
для выпуска разработанного нами оборудования у ядра есть все что необходимо. если не лень, то можно сходить посмотреть например на сайт и прочитать про ФАБ Дубна
да
разработчиком RU является одно из подразделений ядра. Ждите следующие статьи цикла, там расскажут более подробно и в красках. Про схемотехнику и конструктив BBU тоже планируем писать
15 лет назад был 2010-й, и по моей памяти мобильного интернета хватало разве что в ICQ початиться да в гугле пошариться. Первый смартфон у меня появился в 2012-м году, брал еще на юноне (рынок такой), ютуб и прочее я на нем не смотрел. Дело было в СПб, а у вас это где?
У нас ведется разработка собственного ядра сети, равно как и GSM контроллера. Но этот цикл статей именно про базовую станцию и ее железо, поэтому весь остальной телеком остается за скобками. Цикл статей про ядро сети (я слышал) на стадии планирования, так что ждите будет
В ETSI EN 302 307-2 V1.4.1 есть Part 2: DVB-S2 Extensions (DVB-S2X). Ваша надстройка часть того же открытого стандарта
Зачем делать реверсить открытый протокол? ищите документ ETSI EN 302 307-2 V1.4.1
есть YOCTO Project -- специальная штука для построения дистрибутивов под любые нужны.
Есть мнение что предложенное решение в статье далеко от оптимального.
функции
osMessageQueuePutиosMessageQueueGetкопируют данные из очереди в локальную память, а это копирование явно лишнее и очень расточительно по отношению к памяти. на вашем месте я бы воспользовался Memory Pool и передавал между тасками через очереди только указатели на области памяти, избегая копирования всего сообщения.Насчет [1] книги сейчас под рукой нет, но вроде бы там это было
А пока что читайте с пк
P.S. А почему тесла от медведей задним ходом отъехала? автопилотам же вроде страх неведом