А чем не устраивает что-то типа тварей от boston dynamics? И догнать преступника может (если у того вообще от страха ноги не подкосятся), и повалить на землю по команде оператора способен. А чтобы не пугал обычных граждан, можно одеть в дружелюбный пластиковый чехол, сбрасываемый в случае опасности.
Вы забыли ещё про поляризационно-модовую дисперсию, ибо одномодовое волокно не одномодовое, так как свет имеет 2 поляризации.
Хроматическую дисперсию компенсировать проблем нет, причём не обязательно использовать специальные волокна, а зачастую достаточно поставить компенсатор дисперсии (который представляет из себя просто кусок волокна, имеющего «обратный» профиль коэффициента преломления по отношению к стандартному волокну). Причём все параметры относительно легко рассчитываются на этапе проектирования линии.
А вот ПМД невозможно ни рассчитать, ни компенсировать.
Также стоит написать что волноводная дисперсия есть и в многомодовом волокне, но ей просто пренебрегают на фоне межмодовой.
Очень сильно не хватает графика с окнами прозрачности кварцевого волокна. На мой взгляд, только он наглядно может показать причину использования на дальней связи 1550нм.
Если честно, то не очень понимаю что вы предлагаете. Вернее догадываюсь, но не представляю как это сделать — абонентских устройств, понимающих gtp-u нет, а тестировать просто передачу UDP трафика неинтересно — результат заранее известен. Или я неправильно вас понял?
Тут самый сок как раз в инкапсуляци клиентского трафика с TCP в пакеты с UDP и проблемами как раз на уровне клиент-сервер из-за протокола L4 (TCP например) того самого инкапсулируемого пакета.
Могу ошибаться, прошу поправить если где накосячил…
Я соврал по второй части. Трафик от EPC до eNodeB передается в gtp-u, который использует UDP. Там получается инкапсуляция исходного абонентского пакета (у которого в протоколе транспортного уровня может быть что угодно) в тот самый gtp-u, использующий UDP.
Похоже что крутить настройки EPC/eNodeB бесполезно — нужно менять настройки TCP (или что там используется если у этого есть параметры) сессий между источником и получателем трафика (контактик-абонент например).
Спрос будет рождать предложение. Пока такого спроса нет и основные трафик-генераторы всем известны. Есть большие сомнения что они так легко сдадутся. Хотя конечно если они возглавят этот процесс, то ещё как взлетит. Но архитектура сложна, от операторов всё равно никуда не деться (как минимум между океанами сигнал не передать. Тут даже океаны не нужны — тупо между городами связности таким образом не всегда можно обеспечить)
На самом деле здесь мэш мне кажется для другого:
Обеспечить минимальную задержку, например в играх, если два игрока рядом
Позволить телефонам быть ретрансмиттором в экстренных случаях. Например, абонент А вне зоны покрытия, но в зоне абонента Б, который уже имеет сигнал от оператора. Тогда экстренный вызов пройдёт.
Так вы хотите сделать локальную рацию или всё-таки полноценную глобальную мэш сеть? Если второе, то ваш телефон должен быть активной частью сети, даже когда вы им не пользуетесь.
И повторюсь — 5G для передачи данных. Тут пока мэш не работает по озвученным мной выше причинам.
А за что я буду платить оператору, если я не занимаю его каналы? Не проще ли целиком переключиться на меш-сети тогда?:)
Увы, но нет.
Во-первых, представляете энергопотребление устройства, работающего постоянно?
Во-вторых, 5G — это передача данных, голос только бонус. В изолированной меш сети для большинства потребителей просто не будет источника трафика, так что без оператора в том или ином виде не обойтись пока.
И да, голос и так сейчас стремится быть бесплатным довеском к тарифам с передачей данных.
По дропам — есть малозаметная ссылка в тексте на traffic contol. Но чуть более детально всё-таки здесь: Netem.
tc qdisc add dev eth0 root netem loss 0.1% delay 100mc
обеспечит 0,1% потерь и 100 мс задержки.
По второй части вопроса — тут уже сложнее. Конечно очевидно что дело в протоколе транспортного уровня. Для исправления ситуации нужно менять алгоритмы/параметры на оборудовании (EPC, eNodeB), а это уже больше зависит от производителя. Пока никаких изменений в этом направлении не было.
1. Да, правильно. Графики подписаны в процентах, т.е. 1 — это 1%, или 10-2.
2. Приказ 113 требует (переведу на язык своих графиков) 0,1% потерь. Что обеспечит максимальные абонентские скорости 40 Мбит/с. Маловато. А вот следующий шаг в виде 0,01% потерь уже обеспечит почти максимальные скорости для реальных абонентов. Достичь же следующей ступени в 0,001% потерь не всегда возможно в условиях большой территории.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Хроматическую дисперсию компенсировать проблем нет, причём не обязательно использовать специальные волокна, а зачастую достаточно поставить компенсатор дисперсии (который представляет из себя просто кусок волокна, имеющего «обратный» профиль коэффициента преломления по отношению к стандартному волокну). Причём все параметры относительно легко рассчитываются на этапе проектирования линии.
А вот ПМД невозможно ни рассчитать, ни компенсировать.
Также стоит написать что волноводная дисперсия есть и в многомодовом волокне, но ей просто пренебрегают на фоне межмодовой.
Тут самый сок как раз в инкапсуляци клиентского трафика с TCP в пакеты с UDP и проблемами как раз на уровне клиент-сервер из-за протокола L4 (TCP например) того самого инкапсулируемого пакета.
Могу ошибаться, прошу поправить если где накосячил…
Похоже что крутить настройки EPC/eNodeB бесполезно — нужно менять настройки TCP (или что там используется если у этого есть параметры) сессий между источником и получателем трафика (контактик-абонент например).
Подробности тут.
На самом деле здесь мэш мне кажется для другого:
Данная технология пригодится если источником контента будет не какой-либо ресурс, а напрямую человек.
И повторюсь — 5G для передачи данных. Тут пока мэш не работает по озвученным мной выше причинам.
Во-первых, представляете энергопотребление устройства, работающего постоянно?
Во-вторых, 5G — это передача данных, голос только бонус. В изолированной меш сети для большинства потребителей просто не будет источника трафика, так что без оператора в том или ином виде не обойтись пока.
И да, голос и так сейчас стремится быть бесплатным довеском к тарифам с передачей данных.
обеспечит 0,1% потерь и 100 мс задержки.
По второй части вопроса — тут уже сложнее. Конечно очевидно что дело в протоколе транспортного уровня. Для исправления ситуации нужно менять алгоритмы/параметры на оборудовании (EPC, eNodeB), а это уже больше зависит от производителя. Пока никаких изменений в этом направлении не было.
2. Приказ 113 требует (переведу на язык своих графиков) 0,1% потерь. Что обеспечит максимальные абонентские скорости 40 Мбит/с. Маловато. А вот следующий шаг в виде 0,01% потерь уже обеспечит почти максимальные скорости для реальных абонентов. Достичь же следующей ступени в 0,001% потерь не всегда возможно в условиях большой территории.