Что такое «композитный сервис» и зачем его создавать?
Определение «композитный сервис» применительно к сетевому сервису означает некий нестандартный сервис, составленный из определенным образом настроенных базовых сетевых сервисов. В основном это сетевые сервисы уровней 3-7 семиуровневой сетевой модели. Эти базовые сервисы могут определяться как программно-аппаратно, то есть аппаратно зависимо (оборудование BRAS, CGNAT, Firewall, DPI, AntiDDOS и пр.), как это есть сейчас, либо полностью программно, то есть аппаратно независимо (тоже самое, но с приставкой «virtual»). Виртуализованные сетевые сервисы (функции) vBRAS, vCGNAT, vFirewall и другие могут быть реализованы в сетях NFV с автоматическим программным управлением (SDN).
Таким образом, речь идет создании так называемых «цепочек сервисов», формирующих «композитный сервис» (Рис. 1). Вот какое определение техники создания «цепочек сервисов» дает Heavy Reading в своей White Paper, посвященной концепции Service Chaining [1]: «Создание цепочек сервисов – это нарождающийся набор технологий и процессов, позволяющих оператору динамически переконфигурировать базовые сетевые сервисы на программном уровне, без необходимости внесения изменений в сеть на аппаратном уровне. Путем маршрутизации потоков трафика в соответствии с «графами сервиса», техника service chaining позволяет реализовать как задачи оптимизации сети добиваясь лучшей утилизации сетевых ресурсов, так и задачи монетизации через предоставление композитных сервисов, автоматически оптимизированных под нужды конкретного клиента.
Рис. 1. Концепция формирования «композитных сервисов» путем создания различных цепочек из базовых сетевых сервисов
Считается, что такая кастомизация нужна в основном для предоставления виртуальных сетевых функций облачным приложениям, которые требуют динамического изменения конфигурации сети. Но это не совсем так. Техника service chaining нужна и для кастомизации базовых сервисов, таких как, например, ШПД, потребляемых просто для доступа в сеть Интернет и никак не привязанных к конкретному прикладному сервису. Цель — оптимизация потребительских характеристик продукта под требования узкого сегмента рынка или даже конкретного клиента, причем в автоматическом режиме и с минимальными издержками, то есть не только для крупных корпоративных клиентов, но и для массовых.
Как создавать «композитный» сервис?
Как было отмечено выше, «композитный сервис» может быть создан и в традиционных сетях путем настройки соответствующего оборудования. Но это довольно долгий и затратный путь, не имеющий перспектив на массовом рынке. А вот в сетях SDN и NFV «композитный сервис» может создаваться автоматически через механизм service chaining, представленный функционалом SDN-контроллера (Control Plane), когда из ограниченного количества базовых виртуализованных сетевых функций можно «собирать» их цепочки, формируя таким образом сколь угодно разнообразные по своим характеристикам «композитные» продукты.
Архитектура решения представлена на Рис. 2.
Рис. 2. Техническая архитектура решения, позволяющего создавать цепочки сетевых функций
Не буду пересказывать подробно описанную в white paper Heavy Reading и других источниках технику service chaining, а остановлюсь на одном чрезвычайно важном аспекте, обычно выпускаемом из виду в многочисленных публикациях по рассматриваемой теме.
В представленной на Рис. 2 сетевой конструкции обращает на себя внимание отсутствие важной компоненты. Дело в том, что продукт – это не только функции сети, но и функции, формируемые процессами технического обслуживания и клиентского взаимодействия. Это означает, что в «композитный» продукт необходимо встраивать не только виртуализованные сетевые функции, но и функции систем биллинга, CRM и контакт-центра, ERP и так далее, для чего их также необходимо виртуализовать, то есть избавиться от ручного труда при осуществлении таких процессов.
В результате, в гипотетической модели полностью цифрового оператора, обладающего не только виртуализованными сетевыми функциями, но и виртуализованными (цифровизованными) процессами клиентского сервиса и эксплуатации сети, появляется возможность предоставить абоненту практически неограниченную свободу в выборе сервисов и их комбинаций, метрик и значений QoS по ним, и возможность менять их любой момент времени. То есть дать возможность потреблять именно то, именно столько и с таким качеством, сколько абоненту необходимо в конкретный момент времени.
Пожалуй, единственным в мире телекомов примером такого подхода является реализуемая AT&T программа трансформации Domain 2.0, цель которой сформулирована как создание «определяемой пользователем сети» (User Defined Network).
Основные положения этой трансформации указаны в таблице 1. Синим выделены трансформационные задачи, связанные с виртуализацией сетевых функций, а красным – с виртуализацией производственных и бизнес-процессов. Из таблицы видно, что задач, отмеченных желтым, намного больше, чем задач, отмеченных синим.
Таблица 1. Комплексность подхода AT&T по созданию сети, определяемой пользователем (User Defined Network)
| Как есть | Как будет |
| Аппартно-центричная | Программно-центричная |
| Отдельная ИТ/вычислительная и сетевая/коммуникационная инфраструктуры | Единая технологическая инфраструктура |
| Дискретное обновление программного обеспечения (раз в квартал, год и т.д.) | Непрерывный процесс обновления (совершенствования) программного обеспечения, «доставка» программных приложений непосредственно из среды разработки |
| Территориально-разнесенное узкоспециализированное сетевое оборудование | Высоко динамичная и глубоко конфигурируемая топология сети и роли |
| Результат сбоя – «падение» (недоступность) сервиса | Результат сбоя – сокращение емкости |
| Специфичные комбинации ресурсов для каждого вида сервиса | Профайлы, шаблоны и комбинации универсальных ресурсов |
| Тесная связь между сетевым оборудованием и системами управления этим оборудованием, а также другими компонентами OSS/BSS | Аппаратная независимость OSS/BSS |
| Разделение на основные и обеспечивающие системы | Единая сквозная оркестрация, автоматизация и виртуализация всех систем и элементов |
| Аппаратные средства мониторинга | Программный аппаратно-независимый мониторинг |
| Раздельные процессы настройки ресурсов и их выделения потребителю | Единые конфигурируемые по каталогам/правилам фреймворки |
| Нацеленность на оптимизацию процессов эксплуатации сети | Нацеленность на улучшение пользовательского опыта (Quality of Experience, QoE) |
| Ограниченные по своим возможностям, узкоспециализированные и изолированные от других панели ручного управления | Интегрированные и высокоавтоматизированные панели управления по настраиваемым оператором и/или самим абонентом политикам |
| Ограниченные качественные характеристики предоставляемых сервисов | Мультифасетчатые (гипермасштабируемые с различным шагом) количественные характеристики |
| Крайне затрудненный процесс обмена данными между сетью и ИТ-системами оператора | Сквозной обмен данными в рамках единой информационной среды |
| Крайне медленный и затрудненный процесс изменения функциональности, требующий программирования | Быстрое внесение изменений по политикам/правилам |
| Управление сетью | Управление пользовательским опытом (QoE) |
| Длительный и сложный процесс выделения ресурсов, имеющий жесткие ограничения на уровне аппаратных средств, а также на уровне операционных и бизнес-процессов | Выделение ресурсов в режиме реального времени |
| Статичный биллинг и выставление счетов | Динамичный биллинг и выставление счетов по фактическому потреблению, управление подписками и финансовое управление |
Подчеркну еще раз: телекоммуникационный сервис, даже относительно простой, для клиента определяется не только базовыми сетевыми сервисами. Это и сервисы клиентского обслуживания, биллинга и так далее. И все эти сервисы необходимо выстраивать в цепочки вместе с чисто сетевыми сервисами, что намного сложнее чем виртуализация только базовых сетевых сервисов. Фактически речь должна идти о виртуализации всех функций, выполняемых оператором при предоставлении той или иной услуги (таблица 2).
Таблица 2. Use case использования интеллектуальной OSS/BSS применительно к обеспечению автоматического вывода на рынок нового сервиса (модель DevOps)
| Use case | Описание |
| Автоматическое масштабирование сети (расширение емкости сети) | В случае выявления роста спроса на существующие сервисы, который не может быть удовлетворен ввиду исчерпания виртуальной и/или физической емкости, система мониторинга емкости сети запускает процесс умощнения ресурсов сети (виртуальных сетевых функций VNF и/или виртуализованной сетевой инфраструктуры NFVI)
Новая NFVI может быть автоматически обнаружена и настроена выдачей панелью управления профиля конфигураций, основывающихся на политике конфигурации виртуализованной сетевой инфраструктуры. Новая VNF может быть также автоматически сконфигурирована на основе предварительно заданного в системе управления профиля конфигураций. Созданные NFVI и VNF включаются в каталог ресурсов OSS. |
| Добавление новых NFVI, VNF и/или технологий (качественное развитие сети) | Реализация новых сетевых функций (UDC/UDR, PCRF, DRA, ANDSF), технологий (LTE, SON) и/или добавление виртуализованной инфраструктуры (сервера, системы хранения данных, оптическая сеть и т.п.) может выполняться аналогично процедуре масштабирования сети. Отличием будет то, что выполнение этой процедуры даст возможность реализовывать новые сервисы, которые были бы невозможны без соответствующих технологий, как, например, широкополосный доступ на скорости 300 Мбит/с по технологии LTE-A с выдерживанием QoS.
Возможности, предоставляемые новыми сетевыми ресурсами, технологиями и сервисами, автоматически моделируются в сервисном каталоге, инициируются, а новые ресурсы сети добавляются в каталог OSS. |
| Создание новых сервисов на основе существующих ресурсов | Система осуществляет автоматический мониторинг неиспользуемых виртуализованных ресурсов и создает очередь неиспользуемых ресурсов на формирование новых сервисов на их основе.
При наличии запроса на новый сервис, но при отсутствии свободных ресурсов, автоматически запускается процесс умощнения сети. |
В рамках программы Domain 2.0 задача трансформации операционных и бизнес-процессов в автоматически исполняемые облачные выделена в отдельный проект создания так называемой «платформы реализации сервисов» (Service Realization Excellence platform, SRE). В рамках данного проекта уже разработано более 6о «инструментов» (модулей) для полностью программного исполнения жизненного цикла продукта – от разработки до его внедрения и измерения коммерческих результатов. В настоящее время платформа SRE используется AT&T как основная для исполнения всех сетевых операций.
Это, в свою очередь, знаменует кардинальное изменение не только подходов к модернизации сетей, но и к организационной и бизнес-трансформации. AT&T формулирует это так: перейти от модели, ориентированной преимущественно на вопросы эксплуатации физической сети связи, к модели постоянного совершенствования (Development&Operations) виртуальной среды. В результате длительный процесс модернизации физической сети связи, закупки аппаратных и программных средств, кастомизации и внедрения приложений OSS/BSS и так далее сводится к процессу разработки виртуальной среды, а этап внедрения как таковой фактически не требуется, что кардинально повышает скорость изменений. В настоящее время это ключевой фактор выживания оператора в столь быстро и радикально меняющейся бизнес-среде.
В отличие от модели SOA, положенной в основу Frameworkx, OSS/BSS нового поколения будут, вероятно, представлять собой экосистемы взаимодействующих между собой через механизм открытых API облачных сервисов. Такой подход позволит реализовать любую модель формирования облачных сервисов (компонент OSS/BSS): частную (полностью на стороне оператора), публичную (полностью на стороне провайдера OSS/BSS aaS) или гибридную.
Важно отметить, что в значительной степени усилиями AT&T в модель Frameworkx начинают вноситься существенные изменения на основе первых результатов проекта Domain 2.0. В частности, это программа ZOOM (Zero-touch Orchestration, Operations and Management).
Это означает, что и для других операторов, в том числе для российских, появляется возможность использовать полученные в ходе реализации программы Domain 2.0 наработки, без необходимости инвестировать в НИОКР десятки миллиардов долларов, как вынужден делать выступающий локомотивом процесса цифровизации в телеком отрасли AT&T, чтобы сохранить за собой статус самого дорогого (по капитализации) оператора связи в мире.
