Комментарии 14
Александр, все описанное выше - теория? Или реальный кейс внедрения?
Пока теория. Хотелось бы перейти к практике, но для этого нужно ее популяризировать. А что нужно иметь, чтобы считать это кейсом внедрения? Расчет технико-экономической эффективности? Для внедрения необходимо внести изменения в ПО на сетевом оборудовании и в телефонах. С телефонами проще - можно выложить системное обновление и скачивайте, кто хочет (но лучше, конечно, это делать в процессе производства). С сетевым оборудованием - это может сделать только производитель. К кому обращаться? Остается надеяться, что капля камень точит...
Занимался раньше и теоретическим моделированием каналов пакетной связи с помехами и практической проверкой на реальных радио каналах. Если погружаться, то тема реально сложная. В данном случае предлагаю сначала проверить правильность гипотезы о повторной передаче на уровне TCP. Можно снять дамп на интерфейсе, где все повторы будут видны. Или использовать UDP для оценки. Ну и модель сети мобильного оператора в изложении слишком упрощенная - если копнуть чуть глубже, то обнаружится, что абонентский трафик передается в GTP туннеле. Чтобы получить реально полезные результаты, скорее всего не обойтись без развертывания собственной тестовой сети и анализа ситуации по всему стеку протоколов.
Сейчас и занимаемся исследованием зависимости скорости передачи от вероятности ошибки и от длины пакета. Ошибку вводим путем искажения заданного числа пакетов. Реальный трафик, конечно, гораздо сложнее, но главное - как бы не строилась гарантированная доставка, это всегда повторение передачи, и в этом случае всегда предлагаемое кодирование даст выигрыш. Если использовать UDP, выигрыш будет существенно меньше и только в самых плохих каналах. Развернуть тестовую сеть для нас не реально. Если только не заинтересуется кто-нибудь, кто может.
Если в сети 4G вместо 300 Мбит/с абонент получает реальную скорость 3 Мбит/с, это значит, что в среднем каждый IP-пакет повторяется 100 раз, т.е. вводится 100-кратная избыточность
На практике это не так, снижение скорости (пропускной способности) происходит, главным образом, за счет перехода к более "медленным" модуляциям (скажем QAM16 вместо QAM256), и повышения избыточности помехоустойчивого кодирования (т.е. за счет снижения скорости кодирования). Повторные передачи посылок имеют место, но все-таки далеко не доходят до 100-кратного повтора.
Я в саду имею скорость 100 кбит/с круглые сутки (правильное время измерения скорости - 4 утра.) Это точно не за счет изменения вида модуляции. Но даже там, где это происходит, если использовать кодирование, не придется переключать модуляцию.
Конечно же я в точности не могу знать, что у вас происходит в саду. Однако, могу разумно предположить, что такая низкая скорость, скорее всего, следствие работы механизмов TCP congestion control, которые ошибочно интерпретируют потери сегментов (из-за битовых ошибок на низлежащей сети и как раз отсутствия в реальности того, что в ней "каждый IP-пакет повторяется 100 раз") как следствие перегруженности среды передачи. Поэтому TCP снижает скорость несмотря на фактическое наличие значительно более высокой пропускной способности в сети. Т.е. мы имеем не стократный "объем бесплатного трафика в сети", как вы пишите, а совершенно противоположное - значительная (несмотря на снижение скорости модуляции и кодирования) доля пропускной способности сети, не востребована абонентом, потребляющим мизерные 100кбит/с.
Если с канального уровня OSI на транспортный пакеты будут передаваться без ошибок (исправленных или заменой типа модуляции, или кодированием), работы механизмов TCP congestion control не понадобится. Каждый пакет на уровне TCP будет приниматься с первого раза и без задержек. Соответственно, не будет многократной повторной передачи, которая и образует бесплатный трафик (оператор берет деньги с абонента только за успешно доставленные пакеты). Да, передача каждого пакета займет в 10 раз больше канальных ресурсов, но повторная передача занимает гораздо больше. Для получения конкретных данных нужен эксперимент с реальной базовой станцией и реальным телефоном, в которых прописано кодирование. Как это сделать?
Оператор берет деньги (в смысле учитывает в составе потребленного им объема трафика, если это им тарифицируется) все пакеты (IP), включая и повторно переданные (например, посредством TCP). Повторно переданные фреймы на канальном уровне - да, не учитывает, как не учитывает и то, с какой скоростью кодирования и каким видом модуляции они передавались, что гораздо более критично (т.е. не учитывается то, какие издержки в плане использования частотного ресурса оператором были фактически понесены).
Касательно экспериментов - существуют opensource имплементации 3G и 2G-стеков, однако, я не вижу принципиальности для рассматриваемого вопроса в использовании именно сетей сотовой связи, те же принципы применимы, например, к wifi с гораздо более низким порогом входа.
Можно посмотреть на среду моделирования NS3 (www.nsnam.org) - в свое время использовал ее для диссера - там поле для экспериментов подобного рода (потребуются навыки программирования).
С wifi конечно проще, но это имеет смысл только как модель. Для повышения скорости wifi гораздо дешевле поставить еще один роутер, чем внедрять кодирование. За рекомендацию ns-3 спасибо. Математическое моделирование у меня пока только в матлабе, а для физического эксперимента мы организовываем радиоканал между двумя компьютерами и задаем уровень ошибок
Тема адаптивного кодирования (разными кодами с обнаружением и исправлением ошибок) в мобильной связи была особо актуальна этак в средине-конце 80-х годов. В результате и появились новые схемы не только кодирования, но и (совместно) модуляции и автоматического запроса повторения (HARQ). Которые успешно работают уже более 15 лет в сетях LTE.
Не было только голографического кодирования. Очевидно, это изюминка авторов, опоздавших на сорок лет. Или не опоздавших, если это голографическое кодирование сильно лучше уже известных. Вот на доказательстве последнего можно было бы посоветовать авторам сконцентрироваться. Т.к. как и куда новый код "пристегнуть" в желающих и в возможностях проблемы не будет.
А так, да, популяризация - хорошее дело. Успехов авторам упомянутой статьи!
Спасибо за пожелание. Голографический код требует большой избыточности, но обеспечивает уникальную помехоустойчивость. Например, число случайных ошибок может достигать 40% длины кодового слова, число пакетных ошибок - 100% (все биты инвертированы). Другие коды в таких условиях не работают
Варианты использования - от радиолокации до помехоустойчивой памяти для космоса
Повышение скорости передачи данных в мобильных сетях