В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Традиционно телевизионная инфраструктура была медная, хорошая, надежная, кем-то любимая, кем-то не очень, но чрезвычайно пугающая. Потому что нет ничего более страшного, чем кабельный журнал, особенно если он оформлялся плохо. В журнал заносятся сотни источников и сотни получателей, связанные между собой, и если в этом “закопаться”, будешь напоминать Лаокоона, опутанного змеями. Эта инфраструктура требует постоянной поэтапной модернизации. Хотя чаще всего есть носитель сакрального знания, условный “Васильич”, который по цвету проводов, их засиженности мухами и кабельному журналу с отпечатками его пальцев способен разобраться, что и где работает не так.
Ядром и сердцем инфраструктуры всегда была матрица, вернее, матричный коммутатор. Если посмотреть на его схематичную структуру, то это набор входов и выходов, пересечение которых образует коммутационную точку, то есть направление, по которому сигнал со входа попадает на один или несколько выходов.
Надо сказать, что производство матричных коммутаторов – одна из самых сложных и высокотехнологичных задач с точки зрения проектирования и производства печатных плат. Я лично видел 72-слойную печатную плату матричного коммутатора одной крупной американской фирмы. Плата осуществляла коммутацию поля размером 1024х1024.
Коммутация бывает нескольких видов: видео, звуковая. С появлением сигналов, в которые звук вложен, то есть имбедирован, коммутаторы стали универсальными, они позволяют одновременно коммутировать и видео, и звук. Наиболее “продвинутые” коммутаторы позволяют коммутировать видео и звук отдельно, но в одну и ту же точку выхода. Это серьезная система, которая включает в себя довольно сложную не только электротехническую, но и программную часть. Каждый сигнал на входе сейчас может быть уже и до 12 Гбит/с, если мы говорим о 4К-сигнале, а ранее был до 3 Гбит/с, то есть получаются уже какие-то фантастические терабиты, если не петабиты информации, которые каждую секунду гуляют через эту самую матрицу.
Тем не менее, несмотря на всю эту кажущуюся фантастичность и запредельность, технология, с моей скромной точки зрения, стала подходить к подобию тупика. Во-первых, у подобного рода электромеханических, точнее, электронных систем, есть существенная особенность – коммутация там производится на уровне фактического сигнала, это последовательность битов, нулей и единичек. И для того чтобы эту коммутацию делать мягко, ее надо настраивать в очень плотной жесткой синхронизации со всем остальным студийным оборудованием. Если этого не сделать, в момент коммутации будут наблюдаться микроподрывы, а они да еще микропланы – самый большой бич всех коммутационных проблем. Продвинутые специалисты умеют настраивать матрицы так, чтобы задержка в получении сигнала и задержка в коммутации были выстроены таким образом, чтобы на выходе все было хорошо. И это даже не наука, это искусство – на уровне того, как правильно отстроить звук в огромном сложном помещении. И пусть существуют четкие математические модели, но все равно нужен уже не “Васильич”, а “Петрович”, который своим ухом послушал, подвигал два рычажка – и все стало идеально.
Вторая проблема. Если оборудование работает с электрическими сигналами, то оно, несомненно, их искажает и задерживает. Чтобы с этой ситуацией бороться, придумана масса способов. Например, реклокинг – восстановление сигнала в тактовой синхронизации и формы импульса. Однако и тут крылась проблема, потому что рек-локинг предполагает определенную задержку. К сожалению, эта задержка становится критичной, когда коммутация начинается на уровне сопряжения звука и видео. Любые действия, связанные с коммутацией видео, требуют накопления полного кадра, а это довольно больший объем информации, в то время как звуковые отсчеты совершенно не требуют подобного рода вещей. И одному полному кадру соответствует от 20 до 40 мс этих звуковых записей, и там может быть тысячи этих отсчетов.
Чтобы бороться с последствиями удобства коммутации соединения, потребовалась целая линейка оборудования синхронизации, компенсации, линий задержки и т.д. И технология передачи не стояла на месте. Современный весьма дорогостоящий коаксиальный кабель, хорошо обжатый, который позволяет доставлять цифровой сигнал стандарта, например 3G-SDI, показывает себя на расстояниях до 300 м, а скорее и меньше. Потом требуется устанавливать оборудование, которое будет выполнять тот самый реклокинг, или синхронизацию. Кабель этот очень дорогой и довольно хрупкий. И естественным решением стал переход на оптику.
С оптикой ситуация улучшилась: расстояния стали измеряться уже не сотнями метров, а километрами и даже, если необходимо, их десятками. Но у оптики есть свои проблемы. Обязательным условием становится сначала модуляция – преобразование электрического сигнала в оптический, потом демодуляция, которая, естественно, требует задержки, коммутация электрического сигнала внутри матрицы и дальнейшие действия (потоки света внутри коммутатора, конечно, никто не переключает).
К тому же оптика обладает целым рядом особенностей, которые делают ее неудобной в эксплуатации: коаксиальный кабель мягкий, его можно сгибать, а вот с оптикой такие штуки не проходят. Если ты согнул оптику по радиусу, который не рекомендован, можешь ее вообще сломать либо внести существенное затухание плюс приобрести отраженный сигнал, что приведет к определенным проблемам. Проще говоря, немножечко согнув кабель, можно либо потерять связь, либо внести помехи в передачу данных. И оптика, решив проблему расстояния, добавила новой головной боли.
Я как апологет современных технологий, конечно, очень люблю IP. Эти технологии обладают целым рядом преимуществ по сравнению с передачей данных проводным способами.
Когда я учился по специальности “Системы массового обслуживания”, мы изучали коммутацию каналов и коммутацию пакетов. То, что мы наблюдаем на примере матричных коммутаторов, это классическая коммутация каналов: у тебя есть линия, которая переключается на другую линию. Коммутация пакетов позволяет перебрасывать не всю линию, а только отдельные объекты из любого входа в любой другой вход маленькими долями – вот этими самыми пакетиками. Там, где требуются сверхвысокие скорости и сверхвысокая достоверность, какое-то время коммутаторы были недоступны.
Следующим этапом развития стало появление высоконадежных высокоскоростных технологий доставки, то есть 10-, 20-, 40-, а сейчас уже и 100-гигабитный канал связи пакетной передачи данных, который работает в высокоскоростных и высоконадежных коммутаторах, обеспечивающих минимальные потери. Но даже и этих минимальных потерь удается избежать за счет использования соответствующих протоколов помехоустойчивой доставки SMPTE 2022-6,7 и нового протокола ST2110. Эти два немного конкурирующих семейства протоколов позволяют решать одну и ту же задачу – доставлять сжатый или несжатый сигнал поверх коммутируемых каналов связи и в точке приема корректно восстанавливать его, собирать, решать проблемы синхронизации видео и звука, добавлять метаданные и т.д.
Для того чтобы успешно справиться с этой задачей, потребовалось не только сменить технологию доставки и перейти на протоколы, которые позволяют решить сразу две проблемы. Сначала – проблему синхронизации, потому что протоколы, которые проектировались 2022 и 2110, в них изначально закладывалось, что линии связи могут вносить задержки, они могут перемежать пакеты, они могут идти по разным путям и там, где они встречаются в точке потребления, они собираются в один правильный хороший поток, который дальше можно потреблять.
Второй задачей была задача синхронизации аудио и видео, потому что сигнал видео мы хотим брать из одной точки, а звук из другой. Например, при спортивной трансляции видео идет с площадки, а звук из комментаторской кабины. Если раньше для этого требовалась масса ухищрений, то сейчас –минимальные усилия. И за счет механизма синхронизации умная логика сама соберет правильный звук с правильным видео, выстроит их правильный видеозвукоряд с правильными задержками, чтобы “Гоооол!” комментатор закричал именно тогда, когда мяч закатился в ворота, а не на пять секунд раньше или полминутой позже.
Итак, первый шажок: приготовиться к тому, что инфраструктура будет другая и в голове кое-что придется поменять. Вторым шажком станет то, что ты должен будешь правильно подобрать стэк технологий, на котором придется работать, – хотя бы потому, что технологических протоколов два и надо выбрать какой-то один. Они еще очень молодые, эти протоколы, и совместимости между ними недостаточно. И третий шаг – правильно спроектировать свою сеть.
Классическая иерархическая сеть была рассчитана на то, что нет масштабного управления ее ресурсами. Ее ресурсы распределены так, как была нарисована ее архитектура. И если вдруг в какой-то момент окажется, что потоки данных пойдут не вдоль, а поперек или, того хуже, по диагонали, то сеть будет решать задачу ровно в том объеме, в каком была заложена начальная архитектура. Иерархическая сеть – очень надежная, предсказуемая, но не гибкая. С другой стороны, в инфраструктуре, связанной с телевидением, где может произойти все что угодно, хотелось добиться чего-то другого. И от телекома появились SDN (Software-Defined Networking) – сети, структура которых определяется программным образом. Изначальная топология таких сетей определена, но внутри нее все (иерархия, направление потоков, приоритеты, скорость коммутации) может динамично управляться. В результате получается некий конструктор, из которого ты в нужный момент времени можешь слепить себе именно то, что нужно. Таким образом, существует платформа, в рамках которой ты сам решаешь, куда, как, какие потоки ты хочешь направить, где хочешь, чтоб они собирались, кому отдашь приоритет, как между собой разведешь, как они будут ходить – вертикально, горизонтально, диагонально, как угодно. Эта стэк-технология требует совершенно другого уровня понимания принципов и способов построения сетей и управления ими. Здесь маловато знаний обычного системного администратора, здесь требуется классный специалист, который не просто знает, как работают сети, но и понимает, как работают надстройки над сетями, которые реализуют всю эту гибкость. Эта гибкость, с одной стороны, дает динамичность, а с другой – накладывает определенный отпечаток и создает определенный Overhead, объем служебных данных, которые надо гонять.
В подобного рода сетях не могли не появиться специфические, адаптированные для этой технологии коммутаторы, так называемые SDNS (Software-Defined Networks Switch), которые призваны решать эту проблему. Они являются неким гибридом классического коммутатора сетевого уровня, к которому все привыкли, и при этом обладают достаточным запасом ума и логики, чтобы воспринимать команды. Процессорами их нельзя назвать, скорее, это модули динамической обработки и управления пакетами, которые через них бегают. И отдавая команды SDNS, можно рассчитывать, что он какое-то, возможно, продолжительное время будет их исполнять в соответствии с поставленными задачами.
Это сейчас превалирующий тренд в части изменения модели классической коммутации классического распределения сигналов внутри инфраструктуры телевизионной студии, а также и у операторов связи. Потому что если у телевизионщиков была задача решить ряд проблем – синхронизацию, подмешивание проблемы с коммутацией, отсутствие задержек, резкое изменение направления движения сигналов, но при условии, что количество точек потребления сигнала все же ограниченное, хотя сигналы очень высокоскоростные, то у операторов связи ситуация оказалась еще хуже. Вся эта концепция родилась из того, что телекомы не могут больше обслуживать своих клиентов с помощью иерархических сетей, как бы того ни хотелось.
Как я уже говорил, иерархическая сеть хорошо решает некую среднюю задачу некоего среднего клиента. А мы все давно уже не средние клиенты. У нас задачи становятся уникальными. Кто-то проводит огромное количество времени, пользуясь видеоконференциями. Кто-то играет в онлайн-игры, и у него совершенно другие потребности. Кто-то смотрит тонны 4К-контента в определенные промежутки времени, качественно и хорошо. Все эти потребности одновременно удовлетворить в иерархической системе невозможно. Зато эта задача вполне решаема в рамках управляемой гибкой сети SDN-класса. В этом направлении проведено большое количество научных исследований. Операторы связи сейчас анализируют типы трафика, который потребляют их клиенты. Системы DPI (Deep Packet Inspection) способны на лету анализировать, какие сервисы клиент потребляет, управлять ими, стараясь понять, что и в какое время нужно, как можно адаптировать свою сеть, причем под каждого клиента.
Чтобы учесть разнообразные запросы, оператору требуются так называемые дирижеры (в английском их называют оркестраторами). Это системы управления большими распределенными сетями связи, которые могут динамически перестраиваться. Если коммутаторы – это сердце и кровеносные сосуды, то эти “дирижеры” – мозг, который управляет тем, куда, как, какие потоки пойдут и почему их нужно перераспределить прямо сейчас. Человек в ручном режиме управлять такой системой не может. Эти системы чрезвычайно автоматизированы, с большой долей машинного обучения, с элементами искусственного интеллекта, потому что это система поддержки и принятия решений, это анализ и то, что называется Pattern Recognition, то есть определение моделей и шаблонов поведения, типовых реакций на них. Это то, к чему в конечном итоге придет коммутация.
Как в телефонии IP “убило” все коммутируемые линии (хотя именно они проработают не менее 48 часов, если накроется вся остальная связь), так и в телекоммуникациях произошло то же самое. IP де-факто и де-юре стало стандартом передачи информации, “убив” остальные способы связи, и это же произойдет в телекоме на стыке с телевидением. Просто потому, что строить жестко специализированные системы уже невозможно – заказчик-потребитель не готов потреблять услуги в рамках усредненного абонента, он хочет здесь и сейчас и то, что ему нужно, с гарантированным качеством. Тренд разворачивается от централизованного обслуживания к взгляду от заказчика, его желаний и потребностей. А когда заказчиков, подписчиков, абонентов у тебя миллионы и даже десятки миллионов, то никто не в состоянии сделать это в ручном режиме – требуется гибкая инфраструктура, способная управляться, требуется программное обеспечение и все вышеперечисленное плюс аналитика больших данных. Все это будет помогать “дирижеру” принимать правильное решение, как максимально удовлетворить все потребности, используя ограниченные возможности нашей сети.
Опубликовано: Журнал "Broadcasting. Телевидение и радиовещание" #8+1, 2018
Посещений: 2904
Автор
| |||
В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
