Всем добрый день, хабровчане!

В предыдущей статье про QoS я рассказал о том, что такое политика приоритезации трафика и что это крайне полезная вещь при ограниченном емкостном ресурсе в телеком сетях операторов связи. Сегодня я хочу более детально рассказать с примерами, на что влияет корректная настройка QoS.

QoS занятный предмет - вроде он есть и вроде его нет. Обычно в сетях телеком операторов все сводится к шаблонным настройкам на том или ином сегменте сети, и если все настроено по шаблону, то приоритезация настроена - считается так. На самом деле это далеко не так. И как раз в момент созревания сомнений рождается вопрос - а как измерить то чего не видно? На помощь приходят измерительные комплексы и визуализация потока данных. В своем примере я покажу два инструмента - всем привычный Zabbix для визуализации очередей и измерительный комплекс IPProbe (ныне SkyLight) компании Accedian, который с помощью протокола TWAMP может создавать измерительные сессии в той или иной очереди и с высокой точность показывать ключевые показатели транспортной сети, такие как delay, jitter, packet loss, variance delay/jitter в направлении UL/DL по отдельности.

Итак начнем с проблемы. В одном из филиалов одного оператора связи пожаловались мобильщики на "транспорт". У них как только просаживаются KPI по радио, то во всем виноваты транспортники, корщики, но только не они. Жаловались на то, что страдает "голос". Т.е. недозвоны, колл-дропы, неразборчивая речь и прочие прелести жизни. После недолгого анализа и разворачивания систем визуализации, предположения подтвердились - не настроен QoS. При этом нужно сразу уточнить, что проблемы на транспортной сети действительно были в виде потерь пакетов (discards). Эти потери были связаны с не оптимально настроенными размерами буферов для той или иной очереди. Плюс к этому некорректная маркировка могла ремапить высокоприоритетный голосовой трафик CP/UP в более низкую очередь - отсюда и проблемы с соединениями, неразборчивой речью и т.д.

Всем здравствуйте, уважаемые хабровчане. Продолжаю перевод статей про 5G и практическую реализацию демо для изучения возможностей и архитектуры 5G. В предыдущей статье мы ознакомились с архитектурой 5G и созданием базовой сети 5G с Open5GS и UERANSIM.

Добрый день, уважаемые хабровчане!

Сегодня и в последующие дни я сделаю перевод статей о развертывании архитектуры сетей 5G для дальнейшего ее изучения. Цель этой статьи - показать, что самые передовые технологии доступны всем и каждому, и что будущее можно создавать своими руками и не ждать. Я верю, что инженерный состав в нашей стране, это талантливые люди, которые могут нивелировать технологическое отставание, которое мы упустили за прошедшие 30 лет.

И снова здравствуйте, господа и дамы!

Сегодня я расскажу об очень ресурсоемкой теме. Тема с названием - внедрение QoS и политики приоритезации трафика в сетях Telco.

С чего все началось? Дело в том, что примерно до 2010 года все телеком операторы жили припеваючи, не зная проблем с технологией Ethernet, и строили свои сети по технологии SDH/Sonet. Суть этой технологии проста как две копейки - с помощью мультиплексирования потоков E1, которые в свою очередь, состоят из 32 таймслотов, создается канал связи с временным разделением фрэймов. Т.е. есть стандартная величина потока Е1 - 2.048 мб/с, который содержит 32 таймслота по 64 кб/с. Далее некоторое количество потоков Е1 мультиплексируется в базовые уровни информационных структур STM-1, STM-16, STM-64 STM-256, что соответствует скоростям 155 мб/с, 2.5 Гб/с, 10 Гб/с, 40 Гб/с. Это значит, что на клиентском интерфейсе мультиплексора под одно клиентское включение выделили 3 таймслота (192 кб/с), и этот клиент не сможет отобрать емкость в основном канале свыше, чем 192 кб/с. Но в этой технологии есть ряд проблем, которые не дали ей развиться после 2010 года - дороговизна оборудования, худшая масштабируемость по сравнению с Ethernet сетями, невозможность развить свыше 40G в выделенном канале (Ethernet за 100G перешагнули в 2015 году в коммерческом использовании). Относительно текущей статьи, я выделю основной плюс сетей SDH - прописал для клиента конкретное количество ресурса, и клиент не сможет забрать из магистрального потока бОльшее количество ресурса, сервис клиента с точки зрения качества будет ровно таким, какой прописали в SLA контракта, исходя из параметров технологии, посредством чего этот канал и был предоставлен. То же самое касается и базовых станций - прописали 8 Е1 на базовую станцию, БС ограничена во всех ее трех (реже 4, 5, 6) секторах 16-ю мб/с. Подключили две БС каскадом на тех же 8 Е1, значит две БС будут делить между собой все те же 16 мб/с - все просто.

Всем добрый день.

В своей предыдущей статье я уже упомянул о разрабатываемой нами системе, которая решает, казалось бы, не решаемую задачу - а именно автодискавери сетевых элементов в сетях телеком операторов, построение топологий, поиск путей прохождения трафика на основе информации, полученной из самих сетевых элементов. При этом стоит уточнить, что система не нуждается в интеграции со сторонними системами управления, такими как NCE (бывший Huawei u2000 TN), SoEM (СУ Ericsson), Aviat Provision, NFM-P (Nokia), и любыми другими. Т.е. система самодостаточна и способна работать в полностью автономном режиме.

Начну с той проблемы, которая возникла много десятилетий тому назад - и название этой проблемы - актуальная информация о состоянии сетей в режиме он-лайн. Дело в том, что мультисервисные сети давно стали мультивендорными - т.е. в каком-то филиале N любого провайдера связи, с течением времени скопилось множество разновендорного оборудования - сети MEN построены на Cisco, Huawei, Nokia. РРЛ - NEC, Huawei, Nokia и т.д. до бесконечности и в разных последовательностях. И т.к. каждый вендор не стремится создать универсальную СУ, которая могла хотя бы нарисовать топологию мультивендорной сети, приходится изобретать велосипед раз за разом.

Чаще всего велосипеды получались не далеко едущими, одноколесными, неудобными, без сидения или колес. Даже в системах управления крупных вендоров, функциональность не блистала. Более менее вменяемое я увидел в СУ Huawei - NCE. Но опять таки - каждый домен типов оборудования на своих вкладках, и единую топологию не получить - т.е. нельзя отобразить единовременно и на одной подложке сеть MBH (MEN+RRL). Не говоря уже о единовременном отображении специфических проблем, за которыми следят операторы связи - высокая утилизация интерфейсов, BBE/ES/SES/UAS, FCS, RSL Low, QoS Drop по очередям и пр.

Всем здравствуйте, уважаемые Хабровчане!

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

Начну с небольшого знакомства и расскажу о своем опыте работы. Без малого 13 лет я являюсь исследователем транспортных сетей в телеком индустрии. Работал в одном из крупнейших операторов связи, был экспертом, менеджером, обычным инженером. Строил и свопировал региональные транспортные сети, развернул с коллегами систему мониторинга сетей MBH от Москвы до Владикавказа, крайние два года отдал изучению графовых баз данных, которые позволили решить не решаемую проблему - автодискавери и построение топологии сетей с путями прохождения трафика сервисов мобильной сети и B2B клиентов. Если забежать немного вперед, то данная система осталась не нужна главному заказчику, и мы благополучно выкинули ее на помойку истории. К сожалению, так бывает, но сейчас не об этом.

Итак, статья будет посвящена графовой БД Neo4j, методам работы с ней, софту по визуализации данных, прикладным задачам.

Немного тезисов - что нужно понять.