Rambler's Top100
Статьи ИКС № 01-02 2016
Александр ГЕРАСИМОВ  15 марта 2016

Облачная трансформация оператора физической сети связи

Облачные технологии меняют подходы не только к использованию разнообразных информационных систем, но и к строительству и модернизации сетей связи, а также открывают новые способы их монетизации.

Александр ГЕРАСИМОВ

С развитием облачных технологий стало возможным при модернизации сети связи не усложнять, а наоборот, существенно упрощать ее, устанавливать стандартизированное оборудование вместо специализированного и сокращать его номенклатуру, вынося реализацию сложного функционала на программный аппаратно-независимый уровень. Такая ситуация сложилась, наверное, впервые за всю историю развития отрасли связи. Но особенно непривычно, что подобную виртуальную среду (называемую также облаком оператора) нельзя купить в готовом виде. Ее оператор может только создать сам – из программных продуктов, требующих инсталляции на его стороне, и из облачных сервисов, заменяющих физическое оборудование и аппаратно-зависимый софт. Таким образом, строительство и модернизация сети связи сегодня – это в первую очередь создание облака оператора.

Как оператору создать свое облако?

Переход в операторское облако означает следующее: вместо строго иерархической сети, уровни которой (оборудование и аппаратно-зависимые приложения) физически отделены друг от друга, оператор получает сеть всего с двумя уровнями (рис. 1):

  • физическим, т.е. уровнем активного оборудования и среды передачи данных, называемым уровнем Т (transport);
  • облачным уровнем С (cloud), содержащим как минимум виртуализованные функции сетевого оборудования (VNF) и приложения SDN-управления.

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

 Рис. 1. Трансформация множества физических уровней сети в облако оператора и единый физический уровень Т
 Рис. 1. Трансформация множества физических уровней сети в облако оператора и единый физический уровень Т (Источник: Current Analyzes)
 Источник: Current Analyzes

Речь идет об отказе на уровне сетей доступа от крупных узлов сети – концентраторов трафика: базовых станций в сотовых сетях и маршрутизаторов широкополосного удаленного доступа (BRAS) в проводных (рис. 2) – как от физических аппаратно-программных комплексов. Взамен на уровне узлов агрегации трафика и ядра сети предлагается использовать модульный принцип построения аппаратной платформы на базе унифицированных вычислительных средств стандартной архитектуры. А на уровне локальных/домашних сетей – операторские управляемые точки доступа Wi-Fi или простейшие роутеры, фактически играющие лишь роль коннекторов и выполняющие функции маршрутизации в облаке оператора.

 Рис. 2. Виртуализация узлов сети доступа и агрегации

 
Источник: ЦПИКС 

При таком построении уровень Т приобретает способность к гипермасштабированию подобно вычислительным ресурсам в дата-центрах облачных провайдеров, что никогда ранее сетям связи свойственно не было. Всегда масштабирование сети требовало сложных действий по умощнению оборудования узлов связи и/или развертыванию новых.

За счет того, что функции маршрутизации и управления трафиком реализуются на аппаратно-независимом программном уровне, производительность активного сетевого оборудования на узлах доступа и агрегации также перестает быть «узким местом». Поэтому расширение и умощнение такой двухуровневой сети сводится, собственно, к двум действиям:

  • прокладке оптоволокна и установке простейшего активного оборудования, которые не требуют высокой квалификации персонала и могут выполняться внешними строительными организациями;
  • создание слоя виртуализации, который, собственно, и определяет характеристики сети, – это уже прерогатива оператора, его ключевая компетенция.

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

Но и это еще не все. Переход к облаку оператора – это не только виртуализация функций сетевого оборудования и функций управления ими, но и трансформация всех основных операционных и бизнес-процессов оператора во взаимодействующие через открытые API облачные сервисы.

Как уже было отмечено, уровень С – это структура, лишенная привычной иерархичности сети. То же самое относится к операционным и бизнес-процессам оператора. В облаке они трансформируются в различные по функционалу приложения, реализованные в формате облачных сервисов, взаимосвязанные и взаимодействующие по принципу «равный с равным» и образующие сложные самоподобные структуры, так называемые фракталы.

Эта трансформация никак не укладывается в привычную операторам модель Frameworkx, в которую только недавно усилиями AT&T начали вноситься существенные изменения на основе первых результатов программы Domain 2.0. В частности, на это направлена инициатива ZOOM (Zero-touch Orchest­ration, Operations and Management).

Кардинальная трансформация роли средств автоматизации OSS/BSS приводит к необходимости изменений в организационной структуре оператора, функциях подразделений и отдельных сотрудников и характере их взаимодействия. Облако оператора позволит автоматически исполнять не только рутинные операции, но и такие ранее не поддававшиеся формализации и соответственно автоматизации процессы, как вывод на рынок новых услуг, масштабирование сети и внедрение новых технологий, взаимодействие с вендорами и партнерами. Как следствие, персонал перестанет быть лишь непосредственным исполнителем процессов управления сетью, портфелем услуг и т.д., а превратится в разработчиков алгоритмов и правил автоматического выполнения всех основных операционных и бизнес-процессов оператора.

Как монетизировать?

Сервисные и бизнес-модели для описываемой двух­уровневой адаптивной сети, как и подходы к ее строительству, кардинально отличаются от привычных.

Если традиционный подход к созданию сервисных моделей в телекоме состоит в основном в установке и настройке оборудования, и он по сути и определяет услуги, которые могут быть оказаны на базе создаваемой сети, их стоимость, географию предоставления и другие условия, то в случае с облаком оператора все совершенно иначе.

Здесь речь идет уже о гораздо более сложной, так называемой двусторонней модели монетизации ресурсов сети. В такой модели ОТТ-сервис, при предостав­лении которого «провайдер сети не контролирует OTT-сервис, а OTT-сервис не контролирует сеть и не гарантирует качество сервиса» (формулировка Мин­ком­связи), – это уже не тот страшный зверь, который «убивает» традиционный операторский бизнес и которого так боятся операторы физических сетей связи.

В двусторонней сервисной модели, базирующейся на адаптивной двухуровневой сети связи, сервис внешнего по отношению к оператору сети провайдера взаимодействует с этой сетью через механизм открытых API (рис. 3) и именно за счет такого взаимодействия монетизируется и оператором, и сервис-провайдером. И это уже не ОТТ-, а облачный сервис.

 Рис. 3. Архитектура SDN
 

Такая сеть позволяет провайдеру приложения/сервиса предоставить пользователю сквозное, вплоть до абонентского устройства, управляемое качество в соответствии с ключевыми критериями, зафиксированными в SLA (например, уровень доступности и безопасности услуги). Благодаря этому оператор может встроиться в цепочку формирования добавленной стоимости прикладного сервиса.

Во взаимоотношениях абонента с оператором сети связи появляется третья сторона – внешний поставщик сетенезависимых сервисов, как перепродаваемых без изменений, так и комплексируемых оператором с другими внешними сервисами с целью создания новой потребительской ценности. И возникает вопрос разграничения зон ответственности не только между абонентом и оператором, но и между оператором и провайдером внешнего по отношению к операторской сети сервиса. Это требует от оператора выработки четкой политики и механизмов взаимодействия с провайдерами внешних сервисов по модели, близкой к модели магазинов приложений для умных персональных устройств (смартфонов, фаблетов, планшетов, телевизоров и т.д.).

Для реализации базовой части характеристик QoS, являющихся функцией виртуализованной операторской сети (доступность канала, его пропускная способность и задержка сигнала), оператору целесообразно выступать реселлером внешнего сервиса (например, на принципах разделения доходов) и предоставлять абоненту возможность выбрать QoS прикладного сервиса. А провайдер внешнего сервиса может прямо монетизировать свои сервисы за счет различных уровней QoS для них.

Управляемое качество сетевого подключения чрезвычайно важно для реализации таких бизнес-сервисов, как Desktop as a Service, для предоставления бизнес-приложений по модели SaaS, а также видео- и VoIP-сервисов.

Далее оператор может расширить набор контролируемых параметров качества, включив в него уровень информационной безопасности – ключевой показатель для многих критичных приложений, в частности для систем телеметрии и телеуправления дорожным движением. Так, в 2014 г. из-за проникновения вируса в систему автоматической фиксации нарушений в Московской области все камеры этой системы на несколько недель были выведены из строя.

SDN/NFV-сеть позволяет реализовать в качестве сетевых сервисов такие ИБ-функции, как виртуальные межсетевые экраны, DPI, защита от DDoS-атак и т.д. Продавать такое расширенное качество конечным пользователям целесообразно без участия поставщика внешнего сервиса.

Более сложной, но при этом и более перспективной моделью взаимоотношений оператора сети связи и провайдера внешних сервисов является модель, в которой оператор играет роль интегратора различных базовых внешних сервисов в собственный прикладной сервис.

С чего начать

Начать развитие двусторонней модели монетизации имеет смысл с реализации сервиса интеллектуального видеонаблюдения в партнерстве с провайдерами услуг пультовой охраны. Интеллектуальная обработка ви­део­информации с камер наблюдения позволит избежать недоразумений и непонимания, возникающих при попытках предоставить абонентам доступ к данным, которые получаются с эксплуатируемых оператором камер видеонаблюдения, установленных, скажем, в подъездах и на улице.

В этом случае абонент не получает доступ непосредственно к изображениям с видеокамер. Эти изображения в сочетании с данными датчиков движения, открытия дверей и т.п. анализируются системой на предмет выявления потенциально опасных ситуаций. Если такие ситуации выявляются, выдается тревожный сигнал, который поступает абоненту сервиса. А если помещение подключено к системе пультовой охраны, то и провайдеру соответствующих услуг – с вызовом на место экипажа быстрого реагирования. Такой сервис позволит не только снизить количество ложных вызовов, но и документировать факт противоправного действия.  

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!