Mobile edge computing это

Обновлено: 06.07.2024

Mobile Edge Computing (MEC): серия исследований 2 в эпоху 5G

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

Распространение расчета приложений

Итак, какие приложения нужно рассчитывать в пограничном облаке? Или сколько вычислений и какое количество вычислений необходимо вычислить на граничном облаке. Есть три варианта ответа на этот вопрос:

1. Локальная обработка, все расчеты производятся в терминале;

2. Весь трафик обрабатывается MEC;

3. Часть локальной обработки, часть обработки MEC;

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

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

Данные, которые больше подходят для обработки с помощью MEC, - это распознавание лиц, сканирование на вирусы и т. Д. Все эти приложения должны передавать данные в огромную внутреннюю базу данных. Как правило, база данных подходит для развертывания в MEC из-за ее больших ресурсов хранения.

Срез приложения

Поскольку приложение имеет полный жизненный цикл, данные, которые необходимо обработать, должны быть разрезаны в соответствии с определенными правилами. Например, данные, которые необходимо обработать в приложении, разделены на 1-10 частей, для которых установлено значение Необязательно, а затем эти 10 частей данных При определенной стратегии он может обрабатываться локально или полностью с помощью MEC. То, как вычислять и обрабатывать, основано на определенной политике. Например, текущие сетевые условия и политики, сгенерированные загрузкой MEC, указывают, что политики 4, 5, 7, 8 и 10 обрабатываются MEC, а остальные обрабатываются локально терминалом. Кроме того, для объема данных, подходящего для локальной обработки, будет установлено значение «Не выгрузка», после чего эти объемы данных будут обрабатываться терминалом локально. Как показано ниже:

Зависимость от данных

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

В настоящее время академические круги определяют некоторые компоненты, как решить проблему перераспределения (разгрузки) количества расчетов приложений:

1. Профилировщик кода, чтобы определить, какие данные необходимо обрабатывать удаленно;

2. Системный профилировщик для определения необходимой пропускной способности, количества байтов, потребления ресурсов и других параметров;

3. Механизм принятия решений определяет, какие данные необходимо обрабатывать удаленно;

Алгоритм определения того, нужно ли вычислять удаленную обработку, должен удовлетворять требованиям сокращения потребления вычислительных ресурсов терминала и минимизации задержки, а также достижения баланса между этими двумя показателями. При выборе вычислительных узлов, если объем вычислений не может быть разделен на части, то для вычислений может использоваться только один вычислительный узел; как правило, при требованиях с низкой задержкой объем выгружаемых данных будет помещен в ближайший MEC. Если ближайших ресурсов MEC недостаточно, Затем он должен быть отправлен в удаленное место для расчета, и он должен одновременно соответствовать низкому энергопотреблению и низкой задержке. Поскольку MEC может иметь несколько кластеров, необходимо также рассмотреть вопрос о том, как полностью использовать ресурсы каждого кластера.

Vm migration

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

1. Стоимость миграции ВМ (Cost M), время миграции и количество ресурсов, необходимых для миграции;

2. Увеличение времени задержки миграции VM (Gain M), сокращение ресурсов, сэкономленных путем;

3. Объем расчета на самом целевом сервере;

В соответствии с указанными выше тремя переменными необходимо изучить алгоритм, чтобы определить, нужно ли переносить виртуальную машину. Кроме того, необходимо найти подходящий узел MEC для миграции, чтобы удовлетворить потребности в коротких каналах связи с терминалами и низком потреблении сетевых ресурсов. 1 Если качество связи от оконечного устройства к серверу низкое, рассчитайте его локально. Если на самом целевом сервере имеется небольшой объем вычислений, качество связи хорошее, и приложение может соответствовать ситуации локальной временной обработки данных, вызванной короткой передачей обслуживания, то его можно перенести.

Автор: магия маленького осьминога

Эта статья предоставлена партнерами сообщества Yunqi "Сокровищница Linux"можно обратить внимание на актуальную информацию" Сокровищница Linux ”。

Меня зовут Игорь Хапов. Я руководитель разработки в Научно-техническом центре IBM. И сегодня я хотел бы вам помочь окунуться в мир периферийных вычислений, или edge computing, как его ещё называют. Я расскажу о том, что же такое edge computing и как он может повлиять на наш с вами мир. Также хотелось бы пояснить различия между edge computing и fog computing, какие преимущества даёт этот подход. В статье я также описал референсную архитектуру приложения на edge computing. И под конец немного расскажу о проекте с открытым исходным кодом Open Horizon, который совсем недавно присоединился к Linux Foundation.

Что же такое edge computing

Согласно определению Гартнера, edge computing — это подвид распределенных вычислений, в котором обработка информации происходит в непосредственной близости к месту, где данные были получены и будут потребляться. Это основное отличие edge computing от облачных вычислений, при которых информация собирается и обрабатывается в публичных или частных датацентрах. Основным отличием от локальных вычислений является то, что обычно edge computing — это часть большей системы, которая включает в себя сбор статистики, централизованное управление и удаленное обновление приложений на edge устройствах.

Что же такое edge устройство? Многие считают, что edge computing — это когда приложение работает на Raspberry Pi или других микрокомпьютерах. На самом деле edge computing может быть и на мобильных устройствах, персональных ноутбуках, умных камерах и других устройствах, на которых можно запустить приложение по обработке данных.

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

Edge computing и IoT

Довольно часто звучит вопрос — "Чем же отличается edge computing от IoT". IoT можно назвать дедушкой edge computing. IoT — это множество устройств, связанных между собой, и способных передавать информацию друг другу. А edge computing это скорее подход к организации вычислений и управлению edge устройствами. Как вы отлично понимаете, любое приложение необходимо обновлять, мониторить и осуществлять прочие обслуживающие функции. В результате edge computing подразумевает использование определенных подходов и фреймворков, о которых я расскажу чуть позже.

edge computing vs fog computing

Когда я однажды рассказал коллеге про edge computing, он ответил — ”так это же fog computing”. Давайте попробуем разобраться, в чём же разница. С одной стороны, edge computing и fog computing часто используются как синонимы, однако fog computing, или "туманные вычисления", все-таки немного отличаются.

И edge computing, и fog computing — это вычисления, которые находятся в непосредственной близости к получаемым данным. Различие заключается в том, что при туманных вычислениях обработка осуществляется на устройствах, которые постоянно подключены к сети. В edge computing вычисления осуществляются как на сенсорах, умных устройствах – без передачи на уровень gateway, так и на уровне gateway и на микрокластерах.

Для меня было открытием, что edge computing может работать в кластерах Kubernetes или OpenShift. Оказывается, что существует достаточно много задач, где кроме оконечных устройств необходимо выполнять обработку информации в локальном кластере и передавать в централизованные дата центры только результирующие данные. И такие вычисления — тоже edge computing.

Преимущества и недостатки edge computing

При выборе технологий для своего проекта я в первую очередь основываюсь на двух критериях — "Что я от этого получу?" и "Какие проблемы я от этого получу?".
Начнём с преимуществ:

Во-первых, это снижение количества трафика, передаваемого по сети, за счет обработки информации на самом устройстве и передачи только результирующих данных. Особенно виден эффект при использовании edge computing при обработке видеопотока и большого количества фотографий, а также при работе с несжатым звуком.
Во-вторых, это уменьшение задержек, если необходимо оперативно отреагировать на те или иные результаты обработки данных.
Для многих систем также важно, чтобы персональные данные не выходили из определённого контура. С введением электронных медицинских карт данное требование является крайне актуальным на сегодняшний день.
Возможность для устройства быть независимым, определённое время работать без доступа к центральным серверам также повышают отказоустойчивость системы. А централизованный сбор результирующей информации защищает от потери данных при отказе edge-устройства.

Хотя, конечно, проектируя систему с edge computing, не стоит забывать, что как и любую другую технологию её стоит использовать в зависимости от требований к системе, которую вам необходимо реализовать.

Среди недостатков edge computing можно выделить следующие:

Крайне тяжело обеспечить гарантию отказоусточивости для всех edge-устройств.
Устройства могут иметь различные платформы и версии OS, для чего, вероятно, потребуется создавать несколько версий сервисов (например, для x86 и ARM).
Для управления большим количеством устройств потребуется платформа, решающая технические задачи edge computing.

С одной стороны, последний пункт является наиболее критичным, но, к счастью, консорциум Linux Foundation Edge (LF EDGE) включает в себя всё больше и больше проектов с открытым исходным кодом, а их зрелость стремительно растет.

Принципы компании IBM при создании платформы edge computing

Компания IBM, являясь одним из лидеров в области гибридных облаков, использует определённые принципы при разработке решений для edge computing:

Развивать инновации (Drive Innovation)
Обеспечить безопасность данных (Secure data)
Управлять в масштабе (Manage at scale)
Открытость исходного кода (Open Source)

IBM применяет эти принципы при декомпозиции задачи построения фреймворка edge computing.

Как вы можете видеть, всё решение разбито на 4 сегмента использования:

Edge-устройства
Edge-сервера или шлюзы
Edge-облако
Гибридное облако в частном или публичном дата центре

Помимо основных принципов и подходов, IBM разработала референсную архитектуру для решений, основанных на edge computing. Референсная архитектура — это шаблон, показывающий основные элементы системы и детализированный настолько, чтобы иметь возможность адаптировать его под конкретное решение для заказчика. Давайте рассмотрим такую архитектуру более подробно.

Референсная архитектура edge computing

Edge devices

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

Модель обработки данных, например, предобученная ML-модель
Сервис аналитики, который является средой исполнения модели
Пользовательский интерфейс для отображения результатов или инициирования аналитики
Легковесная база данных для хранения промежуточных результатов и кеширования на случай сбоя связи с центральным сервером
Любые другие сервисы в зависимости от решаемых на данном устройстве задач

Hybrid multicloud

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

Edge server and Edge micro data center

Как мы уже говорили, можно встретить промежуточные (близкие) кластеры обработки данных на уровне шлюзов или микро-датацентров с установленной поддержкой кластерных технологий.

Edge framework

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

Именно наличие данного фреймворка раскрывает преимущества edge computing перед разнородными разнесёнными вычислениями.

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

Open Horizon и IBM Edge Application Manager

Именно для решения задач в области edge computing IBM разработала и выложила в open-source проект Open Horizon. Если вы помните, один из принципов, которые IBM заложила в edge computing – все компоненты должны быть основаны на open source технологиях. В мае 2020 года проект Open Horizon вошел в Linux Foundation Edge — Международный фонд open-source технологий для созданий edge-решений. Также Open Horizon является ядром нового продукта от RedHat и IBM — IBM Edge Application Manager, решения для управления приложениями на всех устройствах edge computing: от Raspberry Pi до промежуточных кластеров обработки данных.

Несмотря на то, что проект Open Horizon вошел в консорциум только в мае, он уже достаточно давно развивается как open-source проект. И мы в Научно-техническом центре IBM не только успели его попробовать, но и довести свое решение до промышленного использования. О том, как мы разрабатывали проект с использованием edge computing, и что у нас получилось — будет отдельная статья, которая выйдет в ближайшие несколько недель.

С одной стороны, edge computing framework — это специализированное решение для определённого круга задач, но оно нашло применение во многих индустриях.
В своё время, когда я изучал работу московских камер “Стрелка”, я понял, что это в чистом виде edge computing, с вычислениями "прямо на столбе" и промежуточной обработкой данных в раздельных вычислительных кластерах у различных ведомств.
Сценарии нашлись в финансовом секторе, в продажах при самообслуживании, в медицине и секторе страхования, торговле и конечно при производстве. Именно в создании решения для автоматизации и оценки качества произведённого оборудования, основанного на edge computing, мне с коллегами из Научно-технического центра IBM и посчастливилось принять участие. И на своем опыте попробовать, как создаются решения edge computing.

Если Вас заинтересовала данная тематика, следите за обновлениями в хабраблоге компании IBM и смотрите видео в разделе Ссылки. Наши зарубежные коллеги к настоящему моменту уже осветили многие технические вопросы и описали, какие сценарии уже работают и применяются в различных отраслях.

Компания Huawei провела ежегодное мероприятие MEC Summit в интерактивном онлайн-формате с возможностью обратной связи от аудитории. Одним из основных вопросов, который поднимался на форуме, стало будущее рынка периферийных вычислений с множественным доступом (Multi-Access Edge Computing, ранее — Mobile Edge Computing, MEC) в свете развития 5G.

Huawei провел ежегодный MEC Summit в Москве

Компания Huawei — один из мировых лидеров в области MEC-технологий, а потому саммиты в российской столице каждый год собирают солидную аудиторию. Правда, в этот раз участникам пришлось переместиться в онлайн-формат, но статусность мероприятия это не снизило. Открыл форум вице-президент Huawei в Евразии, президент бизнес-группы по работе с операторами Чжао Лэй. В своей вступительной речи он особо подчеркнул, что если в 2019 г. рынок только-только присматривался к периферийным вычислениям с множественным доступом, то теперь дело дошло до реального применения. В одном только Китае Huawei реализовала более 270 инновационных кейсов в десятке различных индустрий, среди которых — здравоохранение, промышленное производство, энергетика, добыча ископаемых и так далее. Эти успехи поспособствовали началу разработки китайскими специалистами соответствующих индустриальных стандартов.

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

По оценкам международных экспертов, рынку MEC уготован взрывной рост в ближайшие годы. Этому серьезно поспособствует развитие сетей 5G, так как MEC-узлы способны напрямую повлиять как на развертывание таких сетей, так и всю экосистему связанных с 5G услуг. Об объеме рынка MEC в своем выступлении на форуме говорил руководитель департамента по внедрению новых технологий «ВымпелКом» Александр Балюк, по мнению которого, для верхнеуровневой оценки количества узлов МЕС, которые можно развернуть в сети, для В2С-сегмента можно отталкиваться от количества узлов CDN-сети. Если же говорить о сегментах B2G и B2B, то тут логичнее ориентироваться на показатели цифровизации городов-миллионников и объектов критической инфраструктуры в тех отраслях, которые уверенно стоят на пути автоматизации.

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

Как MEC применяют на практике

В онлайн-мероприятии приняли участие представители многих видных компаний, которые поделились своим видением развития MEC как в мире, так и в России. В частности, согласно исследованию J’Son and Partners Consulting, которое представил директор по анализу процессов цифровой трансформации компании Александр Герасимов, уже сейчас в структуре трафика, которым наполнены существующие сети связи, большую часть занимает трафик распределенных приложений, которые имеют клиентскую и серверную части. Эксперты J’Son and Partners Consulting считают, что именно MEC даст возможность их максимального сближения этих двух частей.

«Услуги на базе МЕС ориентированы на приложения, требовательные к доступности и безопасности. Услуга МЕС охватывает как вычислительную, так и сетевую компоненту, представляя собой единый централизованно управляемый сервис. Оказание такой услуги намного сложнее по сравнению с тем, что делают телеком операторы и провайдеры услуг сейчас. Понятие конвергентной услуги на базе МЕС приближает нас к понятию сетевого слоя», — отмечено в официальном пресс-релизе Huawei.

Исполнительный менеджер по маркетингу Huawei в Евразии Дмитрий Полпуденко справедливо указал на то, что значительное число глобальных компаний пытаются разработать единые правила размещения приложений на узлах периферийных вычислений, а также внедрения узлов периферийных вычислений в сети операторов.

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

Денис Панасенко, руководитель 5G Лаборатории MTС StartUp Hub, представил участникам саммита результаты работы компании по развитию экосистемы новых услуг. Периферийные вычисления с множественным доступом достаточно давно вызывают интерес в МТС. Он обусловлен как раз перспективами запуска новых продуктов и решений в сетях 5G: MEC приносит с собой высокую скорость передачи данных, крайне низкую задержку и значительные вычислительные мощности. Именно поэтому периферийные вычисления с множественным доступом используются в большей части кейсов, разработанных резидентами Центра 5G МТС. В качестве примеров Денис Панасенко привел компанию Ariellium, разработчики которой создали АR-решение для ритейла, платформу стриминга игр LoudPlay, а также систему автоматического контроля качества серийной промышленной продукции BID Technologies.

Как раз представитель LoudPlay — руководитель отдела развития и эксплуатации инфраструктуры компании Сергей Евсеев — со ссылкой на накопленную экспертизу отметил, что для определения эффективности внедрения MEC необходимо ориентироваться на характеристики сетевой инфраструктуры, из-за чего наиболее выгодным партнером при любом взаимодействии в части MEC можно считать телеком-оператора, который способен обеспечить работу как с инфраструктурой, так и с каналами связи.

Говоря о реализованном LoudPlay кейсе, Сергей Евсеев рассказал, что компания развернула инфраструктуру платформы приложений в центре региона обслуживания. После этого выяснилось, что задержка предоставления услуги достаточно велика для удаленных пользователей, и иногда достигает 100 мс, что прямо провоцирует негативный пользовательский опыт. После миграции услуги на МЕС время задержки сократилось кратно, что наглядно доказывает состоятельность и эффективность этого подхода.

Финальное слово на саммите взял вице-президент по маркетингу и продажам операторского бизнеса Huawei в Евразии Лю Юнган. Он вернулся к теме роста интереса MEC, приведя в качестве доказательства данные исследования, согласно которым к 2024 г. объем мировых инвестиций в узлы МЕС составит $2,4 млрд. Средний ежегодный рост в этот период достигнет космические 135%. По словам Лю Юнгана, Huawei считает наиболее приоритетными отраслями для МЕС-решений ритейл, государственные и публичные сервисы, транспорт и логистику. Китайский гигант готов помогать российским организациям на этом пути, продвигая лучшие практики на отечественном рынке.

Концепция «граничных вычислений» Edge Computing предусматривает размещение облачных IT-ресурсов для виртуализации сети ближе к конечным пользователям, на периферии (edge) операторской сети.

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

Появление и развитие Edge Computing в международном масштабе потребует большого объёма инвестиций, как в новое оборудование (серверы, СХД нового типа), так и в разработку принципиально нового класса приложений.

Применительно к сетям мобильной связи, введен термин Mobile Edge Computing (MEC).

Можно сказать, что МЕС – это инфраструктура NFV (NFVI) вкупе с программной «платформой приложений» или, т.н. middleware, в мобильных сетях.

Выглядит это примерно так:

Рис. 1. Положение MEC в архитектуре виртуализированной мобильной сети.

На этом рисунке используется также термин FOG – это своеобразное расширение Edge Computing, захватывающее также область конечных устройств пользователя которые также могут использоваться как вычислительные узлы, а также устройств Интернета Вещей IoT. Название Fog (туман) дано по аналогии с устоявшимся термином CLOUD (облако). Edge/Fog Computing – локальное облако более низкого уровня, как туман в низине. Есть еще понятие Dew (Роса) – это уже связь непосредственно между конечными устройствами. Таким образом, налицо тенденция проникновения облака всё ближе к пользователю.

MEC: NFV для мобильности

В то время как термин NFV уже достаточно долго используется, концепция MEC – относительно новая. Популярность NFV растет вследствие того, что эта технология дает возможность операторам связи заменять аппаратное сетевое оборудование на программные модули, реализующие те же функции, что и специализированное «железно». Конечно, программы тоже не могут работать без оборудования. Однако, в случае с NFV – это не дорогое специализированное оборудование, опустошающее бюджеты развития сети операторов (часто без видимого эффекта), а стандартные серверы COTS (Commercial Off The Shelf), располагающиеся в дата-центрах (ЦОД, центрах обработки данных). Это дает сокращение расходов, как капитальных, так и операционных, и кроме того, способствует более быстрому вводу сервисов, и ускорению развития новых приложений, а также гибкости развития сети (более подробно тут).

Хотя МEC сама по себе не является NFV, однако использует те же принципы, что и NFV, а также оптимизирует их для среды радиодоступа в мобильных сетях.

Вот что у них общего:

Стандартнаяплатформа.Как и NFV, MEC строится из стандартных компонентов, включая компьютерные платформы и уровень виртуализации.
Открытаясреда.MEC, как и NFV, заточен на «открытость», что способствует инновациям.
Ориентациянапрограммируемость. Как NFV, так и MEC, работают на стандартных вычислительных платформах COTS, причём упор сделан на перенос функционала в программную часть. Это дает преимущества в масштабируемости, гибкости бизнес-моделей, скорости внедрения инноваций и развития

Стандартизация архитектуры MEC

Как и NFV, стандарт MEC разрабатывается в Европейском Институте ETSI, который еще в сентябре 2014 г. опубликовал исходную «белую статью» (white paper). На рис. 9 стр. 19 этой white paper показана архитектура MEC.

Рис. 2. Архитектура MEC согласно стандарту ETSI.

Не удивительно, что архитектура MEC сильно напоминает схему NFVI. Основное отличие – платформа приложений MEC (MEC Application Platform) и связанные с ней сервисы.

Так в чем же различие MEC и NFV?

NFV и MEC имеют много общего в своих источниках. В чем же они различны, и почему MEC обособилась?

NFV и MEC различны по типу, местоположению и диапазону приложений.

Тип приложений. NFV применимо к большинству существующих сетевых функций и приложений, включая маршрутизацию, VPN, межсетевое экранирование (firewall), безопасность, а также голосовые приложения, включая IMS, и другие функции. Каждое из них независимо, и располагается в NFVI.

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

Диапазон приложений: MEC предназначен для поддержки приложений мобильности и дает возможность операторам, провайдерам ОТТ, а также корпоративным клиентам операторов, быстро создавать усовершенствованные приложения мобильности, небольшие по размеру и переносимые. NFV же предназначено для гораздо более широкого набора различных сетевых приложений.
Размещение приложений: пользователи жаждут быстрого доступа к «тяжелым» приложениям, т.е. потребляющим большой трафик, таким, как, например, онлайновые видеоигры. Развитие сетей 5G ужесточает требования к ширине полосы и быстроте отклика приложений. MEC потому и размещается непосредственно в сети доступа (в первой точке агрегации), чтобы эти требования удовлетворить. В отличие от NFV, MEC распределяется по сети равномерно, а не гнездится в «центральных офисах», согласно концепции CORD (Central Office Redesigned as Data center).

Могут ли сосуществовать MEC и NFV?

Не только могут, но и должны, хотя детали такого сосуществования еще прорабатываются. Подробнее об этом можно найти в приложении Appendix A.5 к документу ETSI “Framework and Reference Architecture” (ETSI GS MEC 003 V1.1.1), где указывается, что MEC и NFV являются взаимодополняющими концепциями.

Возможные примеры такого сосуществования:

Базовая станция может иметь виртуализованные при помощи NFV функции управления и передачи данных, которые реализованы на стандартных серверах COTS, располагаемых непосредственно на сайте базовой станции или рядом.
Тот же сервер может использоваться для хостинга среды MEC, которая управляет радиоресурсами, чтобы создавать сервисы для расширения требуемой полосы и снижать задержки непосредственно в месте расположения MEC.

МЕС на радиосети оператора связи

На рисунке ниже показан пример виртуализации базовых станций при помощи технологии MEC. Достоинства такого подхода:

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

Рис. 3. Использование MEC при виртуализации сотовой радиосети доступа.

Читайте также: