eng
Справиться со взрывным ростом трафика традиционными методами развития телекоммуникационных сетей можно только благодаря высоким затратам на повышение их пропускной способности. Требуются новые подходы к развитию бизнеса операторов.
DOI: 10.22184/2070-8963.2017.64.3.58.66
УДК 621.391.1
DOI: 10.22184/2070-8963.2017.64.3.58.66
УДК 621.391.1
Теги: ecomp architecture etsi nfv standard standardization of sdn/nfv архитектура ecomp стандарт etsi nfv стандартизация sdn/nfv
Новый подход и его технология
Один из новых подходов – цифровая трансформация с простыми и насущными целями, такими как снижение затрат на развитие и техническую эксплуатацию сети; стандартизация и унификация сетевого оборудования; расширение спектра услуг сети; снижение времени разработки и вывода новых услуг на рынок. Этим целям полностью отвечает технология виртуализации сетевых функций NFV (Network Function Virtualization), тесно связанная с технологией программно конфигурируемых (определяемых) сетей SDN (Software Defined Network). В сетевой модели операторов связи NFV означает фундаментальный сдвиг, при котором сетевые функции, ранее выполнявшиеся на выделенном специализированном оборудовании, перемещаются в виртуальную (программную) инфраструктуру из общих стандартных серверов.
На практике это означает: миграцию сетевых функций со специализированного оборудования на стандартные серверы COTS (Commercial-off-the-shelf) на базе процессоров Ч86; абстрагирование функций управления сетью в среде виртуальных машин с поддержкой многих операционных систем на множестве физических серверов; гибкое перераспределение функционала между требуемыми местоположениями на сети – дата-центрами (ЦОД), узлами коммутации, оборудованием на стороне пользователя, с целью максимизации эффективности операций и производительности сетевых элементов; создание сети, ориентированной на приложения, а не только на перенос трафика.
Виртуализация сетевых функций может охватывать практически все области сети: коммутацию, маршрутизацию, серверы широкополосного доступа (BRAS), шлюзы и узлы доступа, брандмауэры (firewall), узлы глубокого анализа пакетов DPI (Deep Packet Inspection), межсетевые контроллеры сессий SBC (Session Border Controller), балансировщики нагрузки (LB) и другие сетевые элементы. В мобильных сетях NFV может затрагивать подсистему услуг IP-мультимедиа IMS (IP-Multimedia Subsystem), образуя виртуальную vIMS и усовершенствованную пакетную сеть ЕРС (Evolved Packet Core) – vEPC, и даже сети радиодоступа RAN.
NFV – технология будущих операторских сетей. Это не рекламный "хайпинг" вендоров с целью роста продаж нового оборудования. Напротив, технологический переворот в отрасли поставит в затруднительное положение также и телеком-вендоров. Их продуктовые линейки издавна представляли собой "аппаратный телеком" – и в процессе цифровой трансформации они вынуждены переоснащать производственные мощности и переориентировать R & D-центры, испытывая к тому же прессинг со стороны ИТ-вендоров как новых конкурентов.
Цифровая трансформация на базе NFV – разворачивающаяся на наших глазах революция в отрасли связи, которую можно сравнить лишь с заменой аналоговых АТС цифровыми, происходившую 40–50 лет назад и занявшую не один десяток лет. Как и "цифровизация" полвека назад, "NFV-зация", вероятно, займет достаточно продолжительное время.
Стандартизация
Сейчас это главный камень преткновения на пути развития NFV. Пока нельзя сказать, что стандартизация технологий SDN / NFV полностью завершена. Более или менее выстроен основной каркас (Framework), внутри которого проводится работа по детализации интерфейсов и протоколов, описание функционала и расширение номенклатуры виртуальных сетевых функций VNF (Virtual Network Functions).
Сегодня можно выделить два главных источника стандартизации NFV. Это рабочая группа по NFV в европейском институте стандартизации ETSI ISG NFV, созданная в 2013 году, а также созданная AT & T (крупнейшим оператором США и мира по капитализации) группа из более чем 2 000 сотрудников по разработке собственной архитектуры ECOMP (Enhanced Control, Orchestration, Management and Policy). ECOMP во многом сходна с архитектурой ETSI и является частью концепции цифровой трансформации AT & T под названием Domain 2.0.
По словам старшего вице-президента AT & T Д.Донована, когда компания приступала к цифровой трансформации, еще не было никаких руководств и стандартов, которым можно было бы последовать (темп работы ETSI ISG NFV, членом которой являлась и AT & T, видимо, их не устраивал). Поэтому AT & T стала создавать руководство для себя. Однако в AT & T считают важным совместимость стандартов ETSI и Domain 2.0 / ECOMP, а также обеспечение возможности взаимодействия обеих платформ.
Хотя в стандартах ETSI пока имеются некоторые "пробелы", они быстро заполняются по мере появления имплементаций в виде пилотных, а затем коммерческих проектов. Кроме того, ETSI ISG NFV является базисом для проекта OPNFV (Open Platform for NFV), в котором создаются средства открытой разработки (opensource) приложений NFV. Это открывает массу возможностей для софтверных стартапов, которые создают приложения для сетевой инфраструктуры операторов, тем самым расширяя их возможности и участвуя в разделении доходов (Revenue Sharing). Это могут быть нейронные сети, которые еще называют "искусственным интеллектом" AI (Artificial Intelligence), различные приложения с использованием анализа "больших данных" (Big Data), приложения Интернета вещей и Индустриального интернета (IoT / IIoT) и многое другое.
Стандарт ECOMP сейчас гораздо более детализирован и ориентирован на систему поддержки операций. Столь крупный оператор, как AT & T, вряд ли может позволить себе тратить годы на обсуждения и проработку деталей интерфейсов и протоколов, и техническое перевооружение такой компании походит на замену винтовых двигателей на реактивные в полете на высоте 10 тыс. м (что, как увидим далее, у AT & T неплохо получается). С другой стороны, не так много компаний, которые практически используют именно стандарт ЕСОМР. На конец 2016 года было известно, что его приняли в качестве базовой платформы операторы Bell Canada и Orange. Рассмотрим оба стандарта и сравним их. Это даст некоторое понимание, какие пробелы имеются в ETSI NFV и как их можно ликвидировать.
Ведущим в отрасли связи (в мире) в данный момент является стандарт ETSI NFV. Практически все вендоры разрабатывают свои решения NFV на его основе. Большинство операторов также используют этот стандарт для развертывания NFV на своих сетях. Основная структура (framework) стандарта ETSI NFV показана на рис.1.
Структура имеет четыре главные области: инфраструктура NFVI (NFV Infrastructure), подсистема управления и оркестрации MANO (Management and Orchestration), виртуальные сетевые функции VNF и соответствующие им системы управления сетевыми элементами EMS (Element Management System), а также средства интеграции существующей системы поддержки операций OSS (Operations Support System) с MANO. Заметим, что это самая непроработанная часть "фреймворка": референсные точки Os-Ma и Se-Ma пока детально не определены.
Модули EMS являются "рудиментом" былой реализации, где сетевые функции были встроены в аппаратное оборудование и управлялись от аппаратной EMS. В процессе эволюции VNF, когда они будут разрабатываться специально "под облако" (cloud native), надобность в использовании таких EMS постепенно отпадет, и их функции уйдут в MANO. Забегая вперед, заметим, что в ECOMP именно так и сделано.
Очень важная часть – подсистема MANO, которая состоит из оркестратора NFV (NFVO), менеджера VNF – VNFM (VNF Manager), и менеджера виртуальной инфраструктуры VNFI – VIM (Virtual Infrastructure Manager). Виртуальная инфраструктура VNFI также очень важна – именно здесь происходит то, что называется виртуализацией.
Чтобы образно представить себе, как сделать виртуальным (или программным) то, что раньше было "железным" (например, маршрутизатор или "файерволл"), можно провести аналогию различий между театром и кино. В театре зрители видят "аппаратную реализацию" пьесы: игру живых актеров, реальные декорации и "живой оркестр". А в кино они видят "виртуализацию" пьесы на кинопленке, или в мультимедийном цифровом файле. Суть пьесы при этом не меняется, и, в общем, можно сказать, что абоненты (зрители) получают ту же услугу (переживают за героев пьесы), что и в театре.
Таким образом, аппаратные сетевые платформы – "театр", а NFV – "кино". Если не вдаваться в эстетические различия разных видов искусства, то экономические преимущества кино перед театром очевидны – билет в кино стоит дешевле чем в театр, и затраты на организацию киносеанса также гораздо меньше, чем спектакля в театре. И это притом, что в кино можно показать гораздо больше, чем в театре (предоставить более широкий набор "сервисов").
В VNFI используются только три вида стандартного "железа": серверы (Ч86), хранилища (HDD / SSD) и сетевое оборудование коммутации и маршрутизации. Сверху находится уровень виртуализации, который превращает эти три вида оборудования в их виртуальные образы: машины, контейнеры, области хранения. Виртуальные сети создаются с использованием технологии SDN, которая здесь не рассматривается, однако она синергетически связана с NFV (хотя, теоретически, NFV может обходиться и без SDN). В этой виртуальной среде работают VNF, которые эмулируют работу сетевых элементов. А также в ней создаются новые сетевые функции и сервисы, которые раньше были либо невозможны в принципе, либо создание их было слишком сложным или очень дорогим.
Теперь обратимся к архитектуре ЕСОМР (рис.2). Несмотря на сложный вид, разобраться в ней связисту, умеющему читать по-английски, несложно. Здесь мы также упомянем лишь основные области этой архитектуры.
Это портал для проектирования и операционных функций (ECOMP Portal), куда входят компоненты: проектирования и создания услуг (Service Design&Creation), создания политик (Policy Creation), проектирования приложений аналитики (Analytic Application Design). Кроме того, под управлением ECOMP-портала находятся компонент реестра активных и доступных элементов A & AI (Active and Available Inventory), компонент сбора данных, аналитик и событий DCAE (Data Collection Analytics and Events), главный оркестратор услуг MSO (Master Service Orchestrator), а также контроллеры для различных сетей и приложений в них. Голубым цветом на схеме выделена среда для проектирования и создания (design / creation) сервисов, политик и бизнес-правил. Желтым цветом показана среда исполнения (execution).
Порталы обеспечивают интерфейс пользователя для проектирования, установки политик и выполнения операций. Компонент A & AI обеспечивает обзор предоставленных сервисов, а также доступных ресурсов. Он работает по заданной информационной модели и может динамически добавлять, а также модифицировать сервисы. Компонент DCAE обеспечивает функционал FCAPS (управление отказами, конфигурацией, учетом, производительностью и безопасностью) при управлении сервисами и задействованными устройствами. Компонент MSO обеспечивает полную оркестрацию всей активности в архитектуре ЕСОМР.
Хотя архитектуры ETSI и AT & T выглядят очень по-разному, их принципы работы, в целом, очень близки. Идея разработки ЕСОМР была в том, чтобы расширить и детализировать идеи ETSI, особенно в части контроллеров и установки политик. По сравнению с ETSI NFV в ЕСОМР также расширены возможности по учету (inventory) ресурсов и сервисов. На рис.3 показано сравнение функционала архитектур, выполненное самой AT & T в исходной статье о ЕСОМР.
Основное различие в том, что EMS в архитектуре ECOMP отсутствуют, зато функционал FCAPS добавлен в область ECOMP Execution. По мере развития ETSI NFV она будет все больше походить на ECOMP AT & T. По мере того, как все больше операторов будут реализовывать решения на базе этих двух архитектур, они будут совершенствоваться, и без уроков реального мира здесь не обойтись. Модель ETSI, скорее всего, будет дополнена полнофункциональным оркестратором по примеру AT & T. OPNFV будет расширять границы использования, от VIM / NFVI к MANO, что сейчас лишь только намечается.
Скорее всего, в ближайшем будущем мы увидим существенные перемены в обеих архитектурах. Однако не стоит ожидать появления новых стандартов. Не будет ошибкой выбор любой из двух архитектур, поскольку развиваться они будут в сторону сближения.
Реализация
Технологии SDN / NFV еще нельзя назвать полностью зрелыми и детально проработанными, однако в отрасли уже сформировалась устойчивая тенденция виртуализации сетевой инфраструктуры. На этот путь уже встали многие операторы мира, среди которых можно назвать американские компании AT & T, Comcast и Verizon, международный оператор Telefуnica, германский Deutsche Telekom, британский Vodafone, японский NTT, китайские China Telecom и China Mobile. В России вопросы цифровой трансформации активно прорабатывает "Ростелеком", который даже создал соответствующее подразделение. Интересный проект разворачивается в Белоруссии – полная виртуализация опорной сети (vEPC) сотового оператора Velcom на базе решений одного из китайских вендоров.
Рассмотрим два крупнейших проекта цифровой трансформации: Domain 2.0 в AT & T и UNICA / L + D в Telefуnica. Один из них является примером проактивного подхода к цифровой трансформации и может служить образцом; другой, хотя тоже достаточно масштабный, служит примером того, как недостаток общности видения и рассогласованности работы подразделений может привести если не к провалу проекта в целом, то к достаточно низким результатам.
AT&T Domain 2.0
Основы проекта трансформации Domain 2.0 ("полное переосмысление концепции построения сети") были провозглашены руководителем компании Д.Донованом на Всемирном мобильном конгрессе MWC 2015 в Барселоне в феврале 2015 года: за последние восемь лет общий трафик в сети AT & T вырос в 10 раз за счет широкого распространения смартфонов и планшетов; с 2007 по 2015 год рост мобильного трафика данных в сети AT & T составил 150 000%, причем более половины этого трафика составляют услуги видео; ежедневный объем трафика AT & T превышает 110 ПБ, или примерно 130 млн ч HD-видео. Справиться с таким трафиком можно двумя способами: либо увеличить число аппаратных сетевых узлов и их пропускную способность (но это приведет к драматическому росту расходов и все равно не даст нужного эффекта), либо трансформировать архитектуру сети. AT & T видит трансформацию в программно конфигурируемой сети SDN и виртуализации сетевых функций NFV.
AT & T уже апробировало эти технологии в своих многочисленных дата-центрах и теперь хочет распространить этот опыт на всю сеть. Однако полная трансформация сети оператора требует не только виртуализации, но и полного переосмысления и реорганизации всего бизнеса, вплоть до работы "полевых" инженеров, а также "сдвига квалификации" технического персонала с оборудования на программное обеспечение. AT & T поставила целью стать "софтверной компанией" (software company) и уверена в том, что если что-то работает в ИТ, то это будет работать и в более широкой телекоммуникационной отрасли. У AT & T теперь нет отдельных департаментов ИТ и телекоммуникаций. Глава компании говорит, что половина всех усилий по цифровой трансформации – это внутренние организационные преобразования, в то время как другая половина активности направлена на внешние факторы (качество услуг, ARPU, экономические показатели).
К 2020 году AT & T планирует виртуализировать не менее 75% сетевых функций. Остальные 25% функций либо не подлежат виртуализации, либо решение об этом будет определяться их необходимостью в 2020 году. К началу 2016 года 14 млн абонентов AT & T обслуживались на базе виртуализированного ядра сети vCPE, была создана 21 VNF, а к концу 2016-го число VNF превысило 85. В 2016 году оператор запустил услугу NumberSync, привязывающую все мобильные устройства пользователя к его мобильному номеру.
Переход от инфраструктуры традиционного оператора к распределенной программной архитектуре, по словам главы AT & T, это настоящий культурный сдвиг, "разворот на 180 градусов". Поэтому компания активно работает с ведущими университетами США, которые участвуют в переобучении персонала AT & T и заранее готовят из студентов будущих сотрудников с новым мышлением. Большое значение придается подходу DevOps (разработка новых продуктов при участии сотрудников операционных подразделений, которые затем будут работать с этими продуктами).
Интегрированное облако AIC (AT & T Integrated Cloud), построенное на принципах OpenStack, поддерживает все приложения – как корпоративные, так и публичные. В целевой архитектуре AIC планируется создать более 150 VNF. К концу 2015 года было создано 74 интегрированные облачные зоны (узла) AIC для размещения VNF (планировалось – 69); к концу 2016 года – 205 зон. Большинство оборудования в AIC – так называемые "белые ящики" (White Box), в которых уровень управления вынесен на верхний уровень (в облако AIC). По мнению Д.Донована, если операторы хотят выжить, они должны переходить на модель White Box / COTS. AT & T не только использует "коммерческие" White Box, но также сотрудничает с производителями компонентов, чтобы получить именно те характеристики, которые нужны пользователям.
В процессе сотрудничества с ON Lab (Open Networking Laboratory) по проекту CORD (Central Office Rearchitected as Datacenter, "узел связи, выполненный как дата-центр") AT & T виртуализовала такие сетевые элементы как GPON, OLT, шлюз ШПД, коммутатор агрегации Ethernet. Они были дисагрегированы по функциям, затем эти функции были реализованы программно, что позволило снизить общую стоимость владения и энергопотребление узлов связи. В марте 2016 года состоялись испытания проекта CORD, показавшие эффективность этой модели.
В AT & T также была создана платформа ECOMP (Enhanced Control, Orchestration, Management & Policy) – усовершенствованная платформа для управления, оркестрации, администрирования и установки политик как основа для всей текущей активности оператора на базе виртуализации NFV (см. рис.2). Она автоматизирует много задач: доставку услуг, их обеспечение (provisioning), управление производительностью, управление при отказах, программную конфигурацию сети (SDN). ECOMP спроектирована для работы с OpenStack, но может также работать и с другими вычислительными и программными средами. ECOMP – самый большой и сложный программный проект, который когда-либо выполняла AT & T. Предыдущие программные проекты AT & T могли содержать десятки миллионов строк кода, созданного тысячами программистов, и иногда проходили десятилетия до полной зрелости продукта. Такой подход был неприемлем для проекта цифровой трансформации. Требовались большая быстрота и гибкость (agile), а также открытость. Код проекта ECOMP, с 8 млн строк, был написан всего трехстами разработчиками. Основа ECOMP была создана за 1,5 года и будет развиваться дальше. AT & T создала шесть "творческих лабораторий" (AT & T Foundry) – в Кремниевой Долине, Хьюстоне, Атланте, Далласе и в Израиле. Для тысяч сотрудников AT & T проводится программа переобучения Reskilling. Многие сотрудники, начинавшие 10–20 лет назад как сервис-инженеры ТфОП, сейчас успешно осваивают новые перспективные профессии, например, аналитик данных (data analyst).
AT & T активно работает со стандартизирующими и научными организациями, такими как IETF, ETSI, IEEE и др., а также с организациями, разрабатывающими основы открытого ПО (open-source): Open Daylight, ONOS, ONF и другими в разработке стандартов SDN / NFV. Внедрение SDN / NFV привело к сокращению внутренних затрат AT & T. Как заявил президент подразделения AT & T Labs К.Прабху в марте 2016 года, компания ожидает экономию ОРЕХ в размере 40–50% за счет замены множества ручных операций автоматизированными скриптами и процедурами.
Telefуnica
В 2014 году технический директор компании Telefуnica Э.Бланко провозгласил программу трансформации в "цифрового оператора" (Digital Telco), предусматривающую миграцию критически важных сетевых функций с аппаратной платформы на программную, на основе открытого ПО и на стандартном ИТ-оборудовании COTS (Commercial Off The Shelf). Программа получила название UNICA и предусматривала виртуализацию 30% всего сетевого телекоммуникационного оборудования к концу 2016 года. Основной целью программы было сокращение ОРЕХ на 30% и внедрение концепции Agility (быстрота ввода и расширение диапазона функций и услуг). Кроме того, практически независимо от UNICA, в подразделении исследований и разработок Telefуnica (I + D) была инициирована еще одна программа Lean + Digital, где Digital – рост доходов от цифровых услуг, а Lean – снижение CAPEX и OPEX примерно на 1,5 млрд евро к концу 2016 года.
Таким образом, в компании Telefуnica фактически были запущены две программы виртуализации NFV при очень слабом взаимодействии, а иногда и откровенном противостоянии друг с другом. Не было также и единства в понимании NFV-трансформации. С одной стороны, проект UNICA, поддерживаемый Э.Бланко, был нацелен на максимальную унификацию операций (как видно из названия) на основе облачной архитектуры и был "вендоро-ориентированным". С другой стороны, проект L + D был нацелен на сотрудничество с организациями открытых стандартов, прежде всего ETSI, где Telefуnica стала одним из основателей рабочей группы по NFV.
Разногласия в выборе курса трансформации проявились, например, в том, что в марте 2015 года компания HP (сейчас HPE – Hewlett Packard Enterprise) была назначена основным поставщиком инфраструктуры NFV согласно стратегии UNICA. Однако лишь днем ранее Telefуnica провела презентацию, в которой был представлен мультивендорный подход к реализации NFV в соответствии с ETSI. И уже в декабре 2015 года HPE была смещена со своего "пьедестала" ведущего поставщика инфраструктуры NFV. Истинные причины этого шага так и остались неясными. Затем в феврале на конгрессе MWC 2016 основным поставщиком оборудования NFV для Telefуnica объявляется компания Ericsson. И на том же MWC 2016 подразделение I + D объявило о создании сообщества OSM (Open Source Mano Community), в которое вошли 22 вендора и оператора под эгидой ETSI.
Такое "двоевластие" и неопределенность курса привели к тому, что, хотя в целом обе программы трансформации в Telefуnica достигли определенных результатов, они были далеко не столь впечатляющими, как у их американских коллег в AT & T, где единая стратегия трансформации имела полную и публичную поддержку со стороны совета директоров. Что касается высшего руководства Telefуnica, которое должно было бы служить арбитром в разногласиях между подразделениями огромной мультинациональной компании (что, в общем, неизбежно в инновационных проектах такого масштаба), то нет никаких свидетельств того, чтобы члены совета директоров делали какие-либо публичные заявления по данному поводу. Процесс реализации проекта цифровой трансформации в Telefуnica напоминал маятник, раскачивающийся между двумя стратегиями: UNICA и L + D. В целом, они не были взаимоисключающими, но первая программа была более эффективна при моновендорной, а вторая – при мультивендорной реализации.
Возможными причинами недостаточной эффективности проекта было явное нежелание отдельных вендоров, в особенности имеющих большой установленный парк оборудования в Telefуnica, воспринимать дух мультивендорного сотрудничества, который активно проводился ее исследовательским подразделением. Например, оператор прилагал много усилий к тому, чтобы конкурирующие вендоры, такие как Cisco и Ericsson, взаимодействовали между собой, как это требуется для экосистемы NFV. Компания HPE в бытность ведущим вендором проекта должна была активно взаимодействовать с оборудованием компании ALU (Alcatel-Lucent, сейчас – Nokia), но и эти компании так и не нашли путей продуктивного сотрудничества.
Что касается достижений проекта, Telefуnica внесла большой вклад в разработку открытых стандартов ETSI, а также была инициатором создания сообщества OSM по разработке услуг на базе ПО с открытыми исходными кодами (open source). Основным достижением проекта стала разработка информационной модели на базе ПО open source, независимой от вендорной реализации, которая дает возможность разворачивать VNF с использованием менеджеров виртуальной инфраструктуры VIM, оркестраторов, SDN и физических инфраструктур от разных производителей. Требования к ресурсам и цепочному составлению услуг (chaining) были детально описаны и стандартизованы.
Кроме Telefуnica, большой вклад в OSM внесли операторы British Telecom, Telenor и Telecom Austria Group, а также вендоры облачного ПО для NFV: Intel, Canonical, RIFT.io и Mirantis и др. Эта модель закладывает основы для взаимодействия с различными рабочими группами в США, поддерживаемыми Linux Foundation и AT & T, для международного взаимодействия операторов и вендоров, а также для разработки глобальных стандартов.
Однако в части финансовых показателей ни проект UNICA, ни научный вклад в ETSI и OSM не привели к заметному росту доходов Telefуnica. Изменение затрат ОРЕХ / САРЕХ пока сложно оценить из-за отсутствия опубликованных данных. До конца 2016 года не было поставлено ни одной коммерческой VNF. Видимыми результатами проекта до недавнего времени были вклады в разработку стандартов. А для клиентов оператора результаты проекта пока остаются практически нулевыми.
Мы рассмотрели лишь два самых показательных проекта цифровой трансформации операторского бизнеса на базе технологий виртуализации сетевых функций, хотя есть и другие, не менее интересные, проекты. В частности, мы будем следить за разворачивающимся в Беларуси проектом vCPE, поскольку это первый проект в мире по виртуализации сразу всей опорной сети оператора. О других проектах, вероятно, будет рассказано в последующих статьях, если тема цифровой трансформации операторского бизнеса вызовет интерес читателей.
Перспективы
В целом, из анализа текущей ситуации по проектам цифровой трансформации телекоммуникационных сетей (как двух вышеописанных проектов, так и других) можно сделать следующие выводы.
Во-первых, нет никакой "универсальной кальки", никакой "дорожной карты", применив которую можно с легкостью реализовать проект цифровой трансформации. Бизнес каждого оператора, как и ситуация на сети, сугубо индивидуальны, что хорошо видно на сравнении двух проектов. Конечно, необходимо изучать опыт первопроходцев и перенимать удачные идеи, однако, слепое копирование может только навредить.
Во-вторых, проект цифровой трансформации необходимо начинать с тщательного анализа текущей ситуации на сети и состояния бизнеса оператора. Параллельно с этим анализом можно и нужно сформулировать цель (или цели) цифровой трансформации, к которой нужно идти, ставя по пути промежуточные цели и корректируя этапы и временные отрезки их достижения.
В-третьих, в проекте цифровой трансформации должна быть задействована вся организационная структура оператора. Необходима широкая пропаганда целей трансформации среди всего персонала оператора, чтобы этот проект не рассматривался как "блажь" его руководства или как некая кампанейщина. Такое наблюдалось в структуре Telefуnica, когда инициативы офиса технического директора и исследовательского подразделения были замкнуты, фактически, внутри этих структурных единиц, а исполнители в других подразделениях часто не понимали конечных целей процесса.
В-четвертых, можно выделить два основных подхода к реализации проекта трансформации: закрытый (моновендорный, или с главным вендором-интегратором) и открытый (мультивендорный). Однако не следует думать, что в AT & T культивировался только один из этих подходов, раз там был единый проект. Подход AT & T можно характеризовать как "закрытый & открытый", поскольку там в качестве вендора-интегратора выступил сам оператор, определяя стратегию и характеристики оборудования, заказываемого у разных вендоров. Подход Telefуnica можно назвать "закрытый VS открытый", поскольку между двумя группами адептов существовала неявная, а часто и явная, конфронтация. Какой подход более выгоден оператору, следует решать на этапе разработки стратегии проекта.
В-пятых, руководство оператора не должно занимать выжидательную отстраненную позицию, пока его активисты трансформации будут стараться получить какие-то результаты в своей "песочнице". Конечно, определенный период на выработку стратегии, тактических подходов и их апробацию необходим. Однако после определения стратегии необходим момент, когда руководство оператора должно открыто выразить свою поддержку проекту трансформации и активно следить за его реализацией, выступая арбитром в случаях противоречий между исполнительными подразделениями.
Самое плохое, что может сделать руководство оператора, переходя от выработки стратегии к практической реализации – назначить "ответственное подразделение" и никак не задействовать остальную структуру. Более того, оставить другие подразделения в неведении о проводимой в этом направлении работе. Это неизбежно приведет к скепсису незадействованных сотрудников, поскольку "аппаратное мышление" (т.е. "сетевая функция – это устройство, а не программа") еще чрезвычайно сильно среди технического персонала, как "связистов", так и "айтишников". Крах проекта в таком случае более чем вероятен.
Нельзя сводить проект цифровой трансформации только к техническим мероприятиям (например, виртуализации сети). Необходим комплекс мероприятий, в том числе чрезвычайно важна программа переобучения персонала, как, например, Reskilling в AT & T.
Наконец, поскольку проект цифровой трансформации предусматривает тесное взаимодействие между оператором и вендором(ами), нужно сделать несколько замечаний о политике вендоров в этом вопросе.
Вендоры, участвующие в проекте трансформации, должны стремиться к сотрудничеству в рамках проекта, проводя политику "кооперенции" (кооперация + конкуренция). Отсутствие такого подхода ярко проявилось в проекте Telefуnica, напоминавшем временами "крутящуюся дверь" в супермаркете, с назначением одних вендоров и смещением других. В конечном счете отсутствие "кооперенции" между вендорами ударит "бумерангом" по ним же самим в случае провала проекта.
Большой ошибкой вендоров, которая может привести к неуспеху проекта, является диктат своей экспертизы и компетенции и неуемная "сверхпродажа" (overselling) своих решений, маркетинговая политика: "выбери меня – птицу счастья завтрашнего дня". Опыт и компетенция оператора ничуть не меньше, а иногда и больше вендорского. Например, на форуме SDN World Forum в октябре 2016 года в Гааге (Нидерланды) многим из вендоров решений SDN и NFV пришлось выслушать немало упреков со стороны операторов, в частности Verizon, British Telecom и Orange. Вице-президент по инновациям Verizon Ш.Хакл в своем докладе указал, что его компанию не интересуют вертикально-интегрированные решения, где "все работает" только в рамках этой вертикали. По его мнению, вендоры должны делать больший упор на совместимость и взаимо-операбельность своих решений и выходить к заказчикам с такими продуктами SDN / NFV, функции которых оттестированы в мультивендорной среде. Обращаясь к поставщикам программных сетевых функций (VNF), он сказал: "Не заставляйте меня писать адаптеры для того, чтобы задействовать ваши VNF на моей сети. Это ваша работа, а не моя".
Часто вендоры делают большую ошибку при разработке решений для оператора, завышая потенциально достижимые финансовые результаты трансформации или предсказывая слишком короткие сроки их достижения. Как и в предыдущем пункте, это часто является маркетинговым "атавизмом", стремлением убрать конкурентов с "поляны". Такая политика очень недальновидна и для самих вендоров. Например, на конгрессе по SDN в Дюссельдорфе в октябре 2015 года вице-президент французского оператора Orange Н.Форэ говорил, что завышение финансовых оценок (overselling) SDN и NFV – контрпродуктивно. Это может привести к сокращению инвестиционных программ на следующий период планирования из-за завышенных объемов экономии как планируемого результата. Кроме того, это может вызывать у заказчика раздражение и разочарование в возможностях вендора.
Можно сделать общий вывод о том, что цифровая трансформация стала сложившимся трендом развития отрасли телекоммуникаций, однако она требует полного переосмысления бизнес-моделей, маркетинговой и технической политики, а также глобальных организационных преобразований как в среде операторов, так в среде вендоров. Немаловажную роль играет также переосмысление модели сотрудничества операторов и вендоров.
Один из новых подходов – цифровая трансформация с простыми и насущными целями, такими как снижение затрат на развитие и техническую эксплуатацию сети; стандартизация и унификация сетевого оборудования; расширение спектра услуг сети; снижение времени разработки и вывода новых услуг на рынок. Этим целям полностью отвечает технология виртуализации сетевых функций NFV (Network Function Virtualization), тесно связанная с технологией программно конфигурируемых (определяемых) сетей SDN (Software Defined Network). В сетевой модели операторов связи NFV означает фундаментальный сдвиг, при котором сетевые функции, ранее выполнявшиеся на выделенном специализированном оборудовании, перемещаются в виртуальную (программную) инфраструктуру из общих стандартных серверов.
На практике это означает: миграцию сетевых функций со специализированного оборудования на стандартные серверы COTS (Commercial-off-the-shelf) на базе процессоров Ч86; абстрагирование функций управления сетью в среде виртуальных машин с поддержкой многих операционных систем на множестве физических серверов; гибкое перераспределение функционала между требуемыми местоположениями на сети – дата-центрами (ЦОД), узлами коммутации, оборудованием на стороне пользователя, с целью максимизации эффективности операций и производительности сетевых элементов; создание сети, ориентированной на приложения, а не только на перенос трафика.
Виртуализация сетевых функций может охватывать практически все области сети: коммутацию, маршрутизацию, серверы широкополосного доступа (BRAS), шлюзы и узлы доступа, брандмауэры (firewall), узлы глубокого анализа пакетов DPI (Deep Packet Inspection), межсетевые контроллеры сессий SBC (Session Border Controller), балансировщики нагрузки (LB) и другие сетевые элементы. В мобильных сетях NFV может затрагивать подсистему услуг IP-мультимедиа IMS (IP-Multimedia Subsystem), образуя виртуальную vIMS и усовершенствованную пакетную сеть ЕРС (Evolved Packet Core) – vEPC, и даже сети радиодоступа RAN.
NFV – технология будущих операторских сетей. Это не рекламный "хайпинг" вендоров с целью роста продаж нового оборудования. Напротив, технологический переворот в отрасли поставит в затруднительное положение также и телеком-вендоров. Их продуктовые линейки издавна представляли собой "аппаратный телеком" – и в процессе цифровой трансформации они вынуждены переоснащать производственные мощности и переориентировать R & D-центры, испытывая к тому же прессинг со стороны ИТ-вендоров как новых конкурентов.
Цифровая трансформация на базе NFV – разворачивающаяся на наших глазах революция в отрасли связи, которую можно сравнить лишь с заменой аналоговых АТС цифровыми, происходившую 40–50 лет назад и занявшую не один десяток лет. Как и "цифровизация" полвека назад, "NFV-зация", вероятно, займет достаточно продолжительное время.
Стандартизация
Сейчас это главный камень преткновения на пути развития NFV. Пока нельзя сказать, что стандартизация технологий SDN / NFV полностью завершена. Более или менее выстроен основной каркас (Framework), внутри которого проводится работа по детализации интерфейсов и протоколов, описание функционала и расширение номенклатуры виртуальных сетевых функций VNF (Virtual Network Functions).
Сегодня можно выделить два главных источника стандартизации NFV. Это рабочая группа по NFV в европейском институте стандартизации ETSI ISG NFV, созданная в 2013 году, а также созданная AT & T (крупнейшим оператором США и мира по капитализации) группа из более чем 2 000 сотрудников по разработке собственной архитектуры ECOMP (Enhanced Control, Orchestration, Management and Policy). ECOMP во многом сходна с архитектурой ETSI и является частью концепции цифровой трансформации AT & T под названием Domain 2.0.
По словам старшего вице-президента AT & T Д.Донована, когда компания приступала к цифровой трансформации, еще не было никаких руководств и стандартов, которым можно было бы последовать (темп работы ETSI ISG NFV, членом которой являлась и AT & T, видимо, их не устраивал). Поэтому AT & T стала создавать руководство для себя. Однако в AT & T считают важным совместимость стандартов ETSI и Domain 2.0 / ECOMP, а также обеспечение возможности взаимодействия обеих платформ.
Хотя в стандартах ETSI пока имеются некоторые "пробелы", они быстро заполняются по мере появления имплементаций в виде пилотных, а затем коммерческих проектов. Кроме того, ETSI ISG NFV является базисом для проекта OPNFV (Open Platform for NFV), в котором создаются средства открытой разработки (opensource) приложений NFV. Это открывает массу возможностей для софтверных стартапов, которые создают приложения для сетевой инфраструктуры операторов, тем самым расширяя их возможности и участвуя в разделении доходов (Revenue Sharing). Это могут быть нейронные сети, которые еще называют "искусственным интеллектом" AI (Artificial Intelligence), различные приложения с использованием анализа "больших данных" (Big Data), приложения Интернета вещей и Индустриального интернета (IoT / IIoT) и многое другое.
Стандарт ECOMP сейчас гораздо более детализирован и ориентирован на систему поддержки операций. Столь крупный оператор, как AT & T, вряд ли может позволить себе тратить годы на обсуждения и проработку деталей интерфейсов и протоколов, и техническое перевооружение такой компании походит на замену винтовых двигателей на реактивные в полете на высоте 10 тыс. м (что, как увидим далее, у AT & T неплохо получается). С другой стороны, не так много компаний, которые практически используют именно стандарт ЕСОМР. На конец 2016 года было известно, что его приняли в качестве базовой платформы операторы Bell Canada и Orange. Рассмотрим оба стандарта и сравним их. Это даст некоторое понимание, какие пробелы имеются в ETSI NFV и как их можно ликвидировать.
Ведущим в отрасли связи (в мире) в данный момент является стандарт ETSI NFV. Практически все вендоры разрабатывают свои решения NFV на его основе. Большинство операторов также используют этот стандарт для развертывания NFV на своих сетях. Основная структура (framework) стандарта ETSI NFV показана на рис.1.
Структура имеет четыре главные области: инфраструктура NFVI (NFV Infrastructure), подсистема управления и оркестрации MANO (Management and Orchestration), виртуальные сетевые функции VNF и соответствующие им системы управления сетевыми элементами EMS (Element Management System), а также средства интеграции существующей системы поддержки операций OSS (Operations Support System) с MANO. Заметим, что это самая непроработанная часть "фреймворка": референсные точки Os-Ma и Se-Ma пока детально не определены.
Модули EMS являются "рудиментом" былой реализации, где сетевые функции были встроены в аппаратное оборудование и управлялись от аппаратной EMS. В процессе эволюции VNF, когда они будут разрабатываться специально "под облако" (cloud native), надобность в использовании таких EMS постепенно отпадет, и их функции уйдут в MANO. Забегая вперед, заметим, что в ECOMP именно так и сделано.
Очень важная часть – подсистема MANO, которая состоит из оркестратора NFV (NFVO), менеджера VNF – VNFM (VNF Manager), и менеджера виртуальной инфраструктуры VNFI – VIM (Virtual Infrastructure Manager). Виртуальная инфраструктура VNFI также очень важна – именно здесь происходит то, что называется виртуализацией.
Чтобы образно представить себе, как сделать виртуальным (или программным) то, что раньше было "железным" (например, маршрутизатор или "файерволл"), можно провести аналогию различий между театром и кино. В театре зрители видят "аппаратную реализацию" пьесы: игру живых актеров, реальные декорации и "живой оркестр". А в кино они видят "виртуализацию" пьесы на кинопленке, или в мультимедийном цифровом файле. Суть пьесы при этом не меняется, и, в общем, можно сказать, что абоненты (зрители) получают ту же услугу (переживают за героев пьесы), что и в театре.
Таким образом, аппаратные сетевые платформы – "театр", а NFV – "кино". Если не вдаваться в эстетические различия разных видов искусства, то экономические преимущества кино перед театром очевидны – билет в кино стоит дешевле чем в театр, и затраты на организацию киносеанса также гораздо меньше, чем спектакля в театре. И это притом, что в кино можно показать гораздо больше, чем в театре (предоставить более широкий набор "сервисов").
В VNFI используются только три вида стандартного "железа": серверы (Ч86), хранилища (HDD / SSD) и сетевое оборудование коммутации и маршрутизации. Сверху находится уровень виртуализации, который превращает эти три вида оборудования в их виртуальные образы: машины, контейнеры, области хранения. Виртуальные сети создаются с использованием технологии SDN, которая здесь не рассматривается, однако она синергетически связана с NFV (хотя, теоретически, NFV может обходиться и без SDN). В этой виртуальной среде работают VNF, которые эмулируют работу сетевых элементов. А также в ней создаются новые сетевые функции и сервисы, которые раньше были либо невозможны в принципе, либо создание их было слишком сложным или очень дорогим.
Теперь обратимся к архитектуре ЕСОМР (рис.2). Несмотря на сложный вид, разобраться в ней связисту, умеющему читать по-английски, несложно. Здесь мы также упомянем лишь основные области этой архитектуры.
Это портал для проектирования и операционных функций (ECOMP Portal), куда входят компоненты: проектирования и создания услуг (Service Design&Creation), создания политик (Policy Creation), проектирования приложений аналитики (Analytic Application Design). Кроме того, под управлением ECOMP-портала находятся компонент реестра активных и доступных элементов A & AI (Active and Available Inventory), компонент сбора данных, аналитик и событий DCAE (Data Collection Analytics and Events), главный оркестратор услуг MSO (Master Service Orchestrator), а также контроллеры для различных сетей и приложений в них. Голубым цветом на схеме выделена среда для проектирования и создания (design / creation) сервисов, политик и бизнес-правил. Желтым цветом показана среда исполнения (execution).
Порталы обеспечивают интерфейс пользователя для проектирования, установки политик и выполнения операций. Компонент A & AI обеспечивает обзор предоставленных сервисов, а также доступных ресурсов. Он работает по заданной информационной модели и может динамически добавлять, а также модифицировать сервисы. Компонент DCAE обеспечивает функционал FCAPS (управление отказами, конфигурацией, учетом, производительностью и безопасностью) при управлении сервисами и задействованными устройствами. Компонент MSO обеспечивает полную оркестрацию всей активности в архитектуре ЕСОМР.
Хотя архитектуры ETSI и AT & T выглядят очень по-разному, их принципы работы, в целом, очень близки. Идея разработки ЕСОМР была в том, чтобы расширить и детализировать идеи ETSI, особенно в части контроллеров и установки политик. По сравнению с ETSI NFV в ЕСОМР также расширены возможности по учету (inventory) ресурсов и сервисов. На рис.3 показано сравнение функционала архитектур, выполненное самой AT & T в исходной статье о ЕСОМР.
Основное различие в том, что EMS в архитектуре ECOMP отсутствуют, зато функционал FCAPS добавлен в область ECOMP Execution. По мере развития ETSI NFV она будет все больше походить на ECOMP AT & T. По мере того, как все больше операторов будут реализовывать решения на базе этих двух архитектур, они будут совершенствоваться, и без уроков реального мира здесь не обойтись. Модель ETSI, скорее всего, будет дополнена полнофункциональным оркестратором по примеру AT & T. OPNFV будет расширять границы использования, от VIM / NFVI к MANO, что сейчас лишь только намечается.
Скорее всего, в ближайшем будущем мы увидим существенные перемены в обеих архитектурах. Однако не стоит ожидать появления новых стандартов. Не будет ошибкой выбор любой из двух архитектур, поскольку развиваться они будут в сторону сближения.
Реализация
Технологии SDN / NFV еще нельзя назвать полностью зрелыми и детально проработанными, однако в отрасли уже сформировалась устойчивая тенденция виртуализации сетевой инфраструктуры. На этот путь уже встали многие операторы мира, среди которых можно назвать американские компании AT & T, Comcast и Verizon, международный оператор Telefуnica, германский Deutsche Telekom, британский Vodafone, японский NTT, китайские China Telecom и China Mobile. В России вопросы цифровой трансформации активно прорабатывает "Ростелеком", который даже создал соответствующее подразделение. Интересный проект разворачивается в Белоруссии – полная виртуализация опорной сети (vEPC) сотового оператора Velcom на базе решений одного из китайских вендоров.
Рассмотрим два крупнейших проекта цифровой трансформации: Domain 2.0 в AT & T и UNICA / L + D в Telefуnica. Один из них является примером проактивного подхода к цифровой трансформации и может служить образцом; другой, хотя тоже достаточно масштабный, служит примером того, как недостаток общности видения и рассогласованности работы подразделений может привести если не к провалу проекта в целом, то к достаточно низким результатам.
AT&T Domain 2.0
Основы проекта трансформации Domain 2.0 ("полное переосмысление концепции построения сети") были провозглашены руководителем компании Д.Донованом на Всемирном мобильном конгрессе MWC 2015 в Барселоне в феврале 2015 года: за последние восемь лет общий трафик в сети AT & T вырос в 10 раз за счет широкого распространения смартфонов и планшетов; с 2007 по 2015 год рост мобильного трафика данных в сети AT & T составил 150 000%, причем более половины этого трафика составляют услуги видео; ежедневный объем трафика AT & T превышает 110 ПБ, или примерно 130 млн ч HD-видео. Справиться с таким трафиком можно двумя способами: либо увеличить число аппаратных сетевых узлов и их пропускную способность (но это приведет к драматическому росту расходов и все равно не даст нужного эффекта), либо трансформировать архитектуру сети. AT & T видит трансформацию в программно конфигурируемой сети SDN и виртуализации сетевых функций NFV.
AT & T уже апробировало эти технологии в своих многочисленных дата-центрах и теперь хочет распространить этот опыт на всю сеть. Однако полная трансформация сети оператора требует не только виртуализации, но и полного переосмысления и реорганизации всего бизнеса, вплоть до работы "полевых" инженеров, а также "сдвига квалификации" технического персонала с оборудования на программное обеспечение. AT & T поставила целью стать "софтверной компанией" (software company) и уверена в том, что если что-то работает в ИТ, то это будет работать и в более широкой телекоммуникационной отрасли. У AT & T теперь нет отдельных департаментов ИТ и телекоммуникаций. Глава компании говорит, что половина всех усилий по цифровой трансформации – это внутренние организационные преобразования, в то время как другая половина активности направлена на внешние факторы (качество услуг, ARPU, экономические показатели).
К 2020 году AT & T планирует виртуализировать не менее 75% сетевых функций. Остальные 25% функций либо не подлежат виртуализации, либо решение об этом будет определяться их необходимостью в 2020 году. К началу 2016 года 14 млн абонентов AT & T обслуживались на базе виртуализированного ядра сети vCPE, была создана 21 VNF, а к концу 2016-го число VNF превысило 85. В 2016 году оператор запустил услугу NumberSync, привязывающую все мобильные устройства пользователя к его мобильному номеру.
Переход от инфраструктуры традиционного оператора к распределенной программной архитектуре, по словам главы AT & T, это настоящий культурный сдвиг, "разворот на 180 градусов". Поэтому компания активно работает с ведущими университетами США, которые участвуют в переобучении персонала AT & T и заранее готовят из студентов будущих сотрудников с новым мышлением. Большое значение придается подходу DevOps (разработка новых продуктов при участии сотрудников операционных подразделений, которые затем будут работать с этими продуктами).
Интегрированное облако AIC (AT & T Integrated Cloud), построенное на принципах OpenStack, поддерживает все приложения – как корпоративные, так и публичные. В целевой архитектуре AIC планируется создать более 150 VNF. К концу 2015 года было создано 74 интегрированные облачные зоны (узла) AIC для размещения VNF (планировалось – 69); к концу 2016 года – 205 зон. Большинство оборудования в AIC – так называемые "белые ящики" (White Box), в которых уровень управления вынесен на верхний уровень (в облако AIC). По мнению Д.Донована, если операторы хотят выжить, они должны переходить на модель White Box / COTS. AT & T не только использует "коммерческие" White Box, но также сотрудничает с производителями компонентов, чтобы получить именно те характеристики, которые нужны пользователям.
В процессе сотрудничества с ON Lab (Open Networking Laboratory) по проекту CORD (Central Office Rearchitected as Datacenter, "узел связи, выполненный как дата-центр") AT & T виртуализовала такие сетевые элементы как GPON, OLT, шлюз ШПД, коммутатор агрегации Ethernet. Они были дисагрегированы по функциям, затем эти функции были реализованы программно, что позволило снизить общую стоимость владения и энергопотребление узлов связи. В марте 2016 года состоялись испытания проекта CORD, показавшие эффективность этой модели.
В AT & T также была создана платформа ECOMP (Enhanced Control, Orchestration, Management & Policy) – усовершенствованная платформа для управления, оркестрации, администрирования и установки политик как основа для всей текущей активности оператора на базе виртуализации NFV (см. рис.2). Она автоматизирует много задач: доставку услуг, их обеспечение (provisioning), управление производительностью, управление при отказах, программную конфигурацию сети (SDN). ECOMP спроектирована для работы с OpenStack, но может также работать и с другими вычислительными и программными средами. ECOMP – самый большой и сложный программный проект, который когда-либо выполняла AT & T. Предыдущие программные проекты AT & T могли содержать десятки миллионов строк кода, созданного тысячами программистов, и иногда проходили десятилетия до полной зрелости продукта. Такой подход был неприемлем для проекта цифровой трансформации. Требовались большая быстрота и гибкость (agile), а также открытость. Код проекта ECOMP, с 8 млн строк, был написан всего трехстами разработчиками. Основа ECOMP была создана за 1,5 года и будет развиваться дальше. AT & T создала шесть "творческих лабораторий" (AT & T Foundry) – в Кремниевой Долине, Хьюстоне, Атланте, Далласе и в Израиле. Для тысяч сотрудников AT & T проводится программа переобучения Reskilling. Многие сотрудники, начинавшие 10–20 лет назад как сервис-инженеры ТфОП, сейчас успешно осваивают новые перспективные профессии, например, аналитик данных (data analyst).
AT & T активно работает со стандартизирующими и научными организациями, такими как IETF, ETSI, IEEE и др., а также с организациями, разрабатывающими основы открытого ПО (open-source): Open Daylight, ONOS, ONF и другими в разработке стандартов SDN / NFV. Внедрение SDN / NFV привело к сокращению внутренних затрат AT & T. Как заявил президент подразделения AT & T Labs К.Прабху в марте 2016 года, компания ожидает экономию ОРЕХ в размере 40–50% за счет замены множества ручных операций автоматизированными скриптами и процедурами.
Telefуnica
В 2014 году технический директор компании Telefуnica Э.Бланко провозгласил программу трансформации в "цифрового оператора" (Digital Telco), предусматривающую миграцию критически важных сетевых функций с аппаратной платформы на программную, на основе открытого ПО и на стандартном ИТ-оборудовании COTS (Commercial Off The Shelf). Программа получила название UNICA и предусматривала виртуализацию 30% всего сетевого телекоммуникационного оборудования к концу 2016 года. Основной целью программы было сокращение ОРЕХ на 30% и внедрение концепции Agility (быстрота ввода и расширение диапазона функций и услуг). Кроме того, практически независимо от UNICA, в подразделении исследований и разработок Telefуnica (I + D) была инициирована еще одна программа Lean + Digital, где Digital – рост доходов от цифровых услуг, а Lean – снижение CAPEX и OPEX примерно на 1,5 млрд евро к концу 2016 года.
Таким образом, в компании Telefуnica фактически были запущены две программы виртуализации NFV при очень слабом взаимодействии, а иногда и откровенном противостоянии друг с другом. Не было также и единства в понимании NFV-трансформации. С одной стороны, проект UNICA, поддерживаемый Э.Бланко, был нацелен на максимальную унификацию операций (как видно из названия) на основе облачной архитектуры и был "вендоро-ориентированным". С другой стороны, проект L + D был нацелен на сотрудничество с организациями открытых стандартов, прежде всего ETSI, где Telefуnica стала одним из основателей рабочей группы по NFV.
Разногласия в выборе курса трансформации проявились, например, в том, что в марте 2015 года компания HP (сейчас HPE – Hewlett Packard Enterprise) была назначена основным поставщиком инфраструктуры NFV согласно стратегии UNICA. Однако лишь днем ранее Telefуnica провела презентацию, в которой был представлен мультивендорный подход к реализации NFV в соответствии с ETSI. И уже в декабре 2015 года HPE была смещена со своего "пьедестала" ведущего поставщика инфраструктуры NFV. Истинные причины этого шага так и остались неясными. Затем в феврале на конгрессе MWC 2016 основным поставщиком оборудования NFV для Telefуnica объявляется компания Ericsson. И на том же MWC 2016 подразделение I + D объявило о создании сообщества OSM (Open Source Mano Community), в которое вошли 22 вендора и оператора под эгидой ETSI.
Такое "двоевластие" и неопределенность курса привели к тому, что, хотя в целом обе программы трансформации в Telefуnica достигли определенных результатов, они были далеко не столь впечатляющими, как у их американских коллег в AT & T, где единая стратегия трансформации имела полную и публичную поддержку со стороны совета директоров. Что касается высшего руководства Telefуnica, которое должно было бы служить арбитром в разногласиях между подразделениями огромной мультинациональной компании (что, в общем, неизбежно в инновационных проектах такого масштаба), то нет никаких свидетельств того, чтобы члены совета директоров делали какие-либо публичные заявления по данному поводу. Процесс реализации проекта цифровой трансформации в Telefуnica напоминал маятник, раскачивающийся между двумя стратегиями: UNICA и L + D. В целом, они не были взаимоисключающими, но первая программа была более эффективна при моновендорной, а вторая – при мультивендорной реализации.
Возможными причинами недостаточной эффективности проекта было явное нежелание отдельных вендоров, в особенности имеющих большой установленный парк оборудования в Telefуnica, воспринимать дух мультивендорного сотрудничества, который активно проводился ее исследовательским подразделением. Например, оператор прилагал много усилий к тому, чтобы конкурирующие вендоры, такие как Cisco и Ericsson, взаимодействовали между собой, как это требуется для экосистемы NFV. Компания HPE в бытность ведущим вендором проекта должна была активно взаимодействовать с оборудованием компании ALU (Alcatel-Lucent, сейчас – Nokia), но и эти компании так и не нашли путей продуктивного сотрудничества.
Что касается достижений проекта, Telefуnica внесла большой вклад в разработку открытых стандартов ETSI, а также была инициатором создания сообщества OSM по разработке услуг на базе ПО с открытыми исходными кодами (open source). Основным достижением проекта стала разработка информационной модели на базе ПО open source, независимой от вендорной реализации, которая дает возможность разворачивать VNF с использованием менеджеров виртуальной инфраструктуры VIM, оркестраторов, SDN и физических инфраструктур от разных производителей. Требования к ресурсам и цепочному составлению услуг (chaining) были детально описаны и стандартизованы.
Кроме Telefуnica, большой вклад в OSM внесли операторы British Telecom, Telenor и Telecom Austria Group, а также вендоры облачного ПО для NFV: Intel, Canonical, RIFT.io и Mirantis и др. Эта модель закладывает основы для взаимодействия с различными рабочими группами в США, поддерживаемыми Linux Foundation и AT & T, для международного взаимодействия операторов и вендоров, а также для разработки глобальных стандартов.
Однако в части финансовых показателей ни проект UNICA, ни научный вклад в ETSI и OSM не привели к заметному росту доходов Telefуnica. Изменение затрат ОРЕХ / САРЕХ пока сложно оценить из-за отсутствия опубликованных данных. До конца 2016 года не было поставлено ни одной коммерческой VNF. Видимыми результатами проекта до недавнего времени были вклады в разработку стандартов. А для клиентов оператора результаты проекта пока остаются практически нулевыми.
Мы рассмотрели лишь два самых показательных проекта цифровой трансформации операторского бизнеса на базе технологий виртуализации сетевых функций, хотя есть и другие, не менее интересные, проекты. В частности, мы будем следить за разворачивающимся в Беларуси проектом vCPE, поскольку это первый проект в мире по виртуализации сразу всей опорной сети оператора. О других проектах, вероятно, будет рассказано в последующих статьях, если тема цифровой трансформации операторского бизнеса вызовет интерес читателей.
Перспективы
В целом, из анализа текущей ситуации по проектам цифровой трансформации телекоммуникационных сетей (как двух вышеописанных проектов, так и других) можно сделать следующие выводы.
Во-первых, нет никакой "универсальной кальки", никакой "дорожной карты", применив которую можно с легкостью реализовать проект цифровой трансформации. Бизнес каждого оператора, как и ситуация на сети, сугубо индивидуальны, что хорошо видно на сравнении двух проектов. Конечно, необходимо изучать опыт первопроходцев и перенимать удачные идеи, однако, слепое копирование может только навредить.
Во-вторых, проект цифровой трансформации необходимо начинать с тщательного анализа текущей ситуации на сети и состояния бизнеса оператора. Параллельно с этим анализом можно и нужно сформулировать цель (или цели) цифровой трансформации, к которой нужно идти, ставя по пути промежуточные цели и корректируя этапы и временные отрезки их достижения.
В-третьих, в проекте цифровой трансформации должна быть задействована вся организационная структура оператора. Необходима широкая пропаганда целей трансформации среди всего персонала оператора, чтобы этот проект не рассматривался как "блажь" его руководства или как некая кампанейщина. Такое наблюдалось в структуре Telefуnica, когда инициативы офиса технического директора и исследовательского подразделения были замкнуты, фактически, внутри этих структурных единиц, а исполнители в других подразделениях часто не понимали конечных целей процесса.
В-четвертых, можно выделить два основных подхода к реализации проекта трансформации: закрытый (моновендорный, или с главным вендором-интегратором) и открытый (мультивендорный). Однако не следует думать, что в AT & T культивировался только один из этих подходов, раз там был единый проект. Подход AT & T можно характеризовать как "закрытый & открытый", поскольку там в качестве вендора-интегратора выступил сам оператор, определяя стратегию и характеристики оборудования, заказываемого у разных вендоров. Подход Telefуnica можно назвать "закрытый VS открытый", поскольку между двумя группами адептов существовала неявная, а часто и явная, конфронтация. Какой подход более выгоден оператору, следует решать на этапе разработки стратегии проекта.
В-пятых, руководство оператора не должно занимать выжидательную отстраненную позицию, пока его активисты трансформации будут стараться получить какие-то результаты в своей "песочнице". Конечно, определенный период на выработку стратегии, тактических подходов и их апробацию необходим. Однако после определения стратегии необходим момент, когда руководство оператора должно открыто выразить свою поддержку проекту трансформации и активно следить за его реализацией, выступая арбитром в случаях противоречий между исполнительными подразделениями.
Самое плохое, что может сделать руководство оператора, переходя от выработки стратегии к практической реализации – назначить "ответственное подразделение" и никак не задействовать остальную структуру. Более того, оставить другие подразделения в неведении о проводимой в этом направлении работе. Это неизбежно приведет к скепсису незадействованных сотрудников, поскольку "аппаратное мышление" (т.е. "сетевая функция – это устройство, а не программа") еще чрезвычайно сильно среди технического персонала, как "связистов", так и "айтишников". Крах проекта в таком случае более чем вероятен.
Нельзя сводить проект цифровой трансформации только к техническим мероприятиям (например, виртуализации сети). Необходим комплекс мероприятий, в том числе чрезвычайно важна программа переобучения персонала, как, например, Reskilling в AT & T.
Наконец, поскольку проект цифровой трансформации предусматривает тесное взаимодействие между оператором и вендором(ами), нужно сделать несколько замечаний о политике вендоров в этом вопросе.
Вендоры, участвующие в проекте трансформации, должны стремиться к сотрудничеству в рамках проекта, проводя политику "кооперенции" (кооперация + конкуренция). Отсутствие такого подхода ярко проявилось в проекте Telefуnica, напоминавшем временами "крутящуюся дверь" в супермаркете, с назначением одних вендоров и смещением других. В конечном счете отсутствие "кооперенции" между вендорами ударит "бумерангом" по ним же самим в случае провала проекта.
Большой ошибкой вендоров, которая может привести к неуспеху проекта, является диктат своей экспертизы и компетенции и неуемная "сверхпродажа" (overselling) своих решений, маркетинговая политика: "выбери меня – птицу счастья завтрашнего дня". Опыт и компетенция оператора ничуть не меньше, а иногда и больше вендорского. Например, на форуме SDN World Forum в октябре 2016 года в Гааге (Нидерланды) многим из вендоров решений SDN и NFV пришлось выслушать немало упреков со стороны операторов, в частности Verizon, British Telecom и Orange. Вице-президент по инновациям Verizon Ш.Хакл в своем докладе указал, что его компанию не интересуют вертикально-интегрированные решения, где "все работает" только в рамках этой вертикали. По его мнению, вендоры должны делать больший упор на совместимость и взаимо-операбельность своих решений и выходить к заказчикам с такими продуктами SDN / NFV, функции которых оттестированы в мультивендорной среде. Обращаясь к поставщикам программных сетевых функций (VNF), он сказал: "Не заставляйте меня писать адаптеры для того, чтобы задействовать ваши VNF на моей сети. Это ваша работа, а не моя".
Часто вендоры делают большую ошибку при разработке решений для оператора, завышая потенциально достижимые финансовые результаты трансформации или предсказывая слишком короткие сроки их достижения. Как и в предыдущем пункте, это часто является маркетинговым "атавизмом", стремлением убрать конкурентов с "поляны". Такая политика очень недальновидна и для самих вендоров. Например, на конгрессе по SDN в Дюссельдорфе в октябре 2015 года вице-президент французского оператора Orange Н.Форэ говорил, что завышение финансовых оценок (overselling) SDN и NFV – контрпродуктивно. Это может привести к сокращению инвестиционных программ на следующий период планирования из-за завышенных объемов экономии как планируемого результата. Кроме того, это может вызывать у заказчика раздражение и разочарование в возможностях вендора.
Можно сделать общий вывод о том, что цифровая трансформация стала сложившимся трендом развития отрасли телекоммуникаций, однако она требует полного переосмысления бизнес-моделей, маркетинговой и технической политики, а также глобальных организационных преобразований как в среде операторов, так в среде вендоров. Немаловажную роль играет также переосмысление модели сотрудничества операторов и вендоров.
Отзывы читателей
