МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«РОССИЙСКИЙ УНИВЕРСИТЕТ ДРУЖБЫ НАРОДОВ»
Факультет физико-математических и естественных наук
Кафедра
прикладной информатики и теории вероятностей
«Допустить к защите»
Заведующий кафедрой
прикладной информатики
и теории вероятностей
д.т.н., профессор
____________ К.Е. Самуйлов
«
»
20
г.
Выпускная квалификационная работа
бакалавра
Направление 01.03.02 «Прикладная математика и информатика»
ТЕМА
«Пример анализа сетевой нарезки ресурсов с помощью модели Эрланга
с потерями»
Выполнил студент Лапшенкова Любовь Олеговна
(Фамилия, имя, отчество)
Группа НПМбд-02-17
Студ. билет № 1032172790
Руководитель выпускной
квалификационной работы
Гайдамака Ю.В., д.ф.-м.н., доц., проф.
(Ф.И.О., степень, звание, должность)
(Подпись)
Автор
(Подпись)
г. Москва
2021 г.
Федеральное государственное автономное образовательное учреждение
высшего образования
«Российский университет дружбы народов»
АННОТАЦИЯ
выпускной квалификационной работы
Лапшенковой Любови Олеговны
(фамилия, имя, отчество)
на тему:
Пример анализа сетевой нарезки ресурсов с помощью модели Эрланга
с потерями
В выпускной квалификационной работе бакалавра представлены модели
сетевого слайсинга, позволяющие проанализировать влияние применения стратегий
доступа к ресурсам и политик приема заявок в систему на средний доход поставщика
инфраструктуры.
Во введении обозначены актуальность темы исследования, цели и задачи
работы, объект и предмет дальнейших исследований, а также указаны публикации,
подготовленные по материалам ВКР.
В первой части выпускной квалификационной работы отражаются общая
концепция работы сетей 5G, технологии сетевого слайсинга и обозначаются
сложности, связанные с внедрением данных технологий.
Во второй части работы представлено подробное описание рассматриваемых
системной и математической моделей разделения ресурсов при слайсинге по
требованию и периодическом слайсинге, а также политик приема заявок и стратегий
доступа заявок в систему.
Третья часть содержит вычисления среднего, удельного и упущенного
доходов поставщика инфраструктуры рассматриваемой СМО, анализ полученных
результатов.
Заключение включает в себя выводы по проведённому исследованию, анализу
качества полученной модели. В нём отражены аспекты, которые могут улучшить
построенную модель в рамках дальнейшей работы.
Автор ВКР
Лапшенкова Л. О.
(Подпись)
(ФИО)
2
Оглавление
Список сокращений ...........................................................................................................4
Список условных обозначений ........................................................................................5
Введение .............................................................................................................................8
1. Технологические особенности сетевого слайсинга .................................................10
1.1 Основная информация о сетевом слайсинге .......................................................10
1.2 Применение концепции сетевого слайсинга .......................................................11
1.3 Проблемы, связанные с внедрением технологии сетевого слайсинга ..............15
2. Построение модели сетевого слайсинга ....................................................................16
2.1 Системная модель ..................................................................................................16
2.2 Математическая модель ........................................................................................22
3. Численный анализ .......................................................................................................28
3.1 Стратегия слайсинга по требованию ...................................................................28
3.2 Стратегия периодического слайсинга..................................................................34
Заключение.......................................................................................................................39
Приложение 1. К расчету числовых характеристик для случая слайсинга по
требованию .......................................................................................................................44
Приложение 2. К расчету числовых характеристик для случая периодического
слайсинга ..........................................................................................................................50
Приложение 3. Грамота за лучший доклад секции ......................................................69
3
Список сокращений
Список русскоязычных сокращений
БС
—
базовая станция
МП
—
Марковский процесс
ПО
—
пользовательское оборудование
СМО
—
система массового обслуживания
Список англоязычных сокращений
4G
—
мобильная связь 4-го поколения
5G
—
мобильная связь 5-го поколения
AA
—
Always Admit policy (политика постоянного допуска)
AT
—
Above Threshold policy (политика превышения порога)
BB
—
Best Bid policy (политика «лучшего предложения»)
FCFS
—
InP
—
Infrastructure Provider (поставщик инфраструктуры)
IoT
—
Internet of Things (интернет вещей)
MNO
—
Mobile Network Operator (оператор сотовой связи)
NFV
—
Network function virtualization (виртуализация сетевой функции)
QoS
—
Quality of Service (качество обслуживания)
SD
—
SDN
—
SI
—
SLA
—
Service Level Agreements (соглашение об уровне обслуживания)
SP
—
Service Provider (поставщик услуг, он же – арендатор слайсов)
VNA
—
Virtual Network Application (виртуальное сетевое приложение)
VNF
—
Virtual Network Function (виртуальная сетевая функция)
First-Come-First-Served policy (политика «первым пришел –
первым обслужен»)
State Dependent policy (множество политик, зависящих от
состояния)
Software defined networking (программно-определяемая сеть)
State Independent policy (множество политик, не зависящих от
состояния)
4
Список условных обозначений
Обозначение
Расшифровка
𝜌
—
интенсивность поступающей нагрузки, Эрл
C
—
общий объем ресурсов, ед. ресурса
𝜆
—
интенсивность поступления заявок, заявок/ед. вр.
𝜇
—
интенсивность обслуживания, заявок/ед. вр.
𝜉
—
случайная длительность обслуживания, ед. вр.
𝜂
—
случайная
длительность
интервала
между
поступлениями соседних заявок, ед. вр.
𝑇'()*)+,
—
период времени, в конце которого принимается
решение о приеме на обслуживание заявок
(периодический слайсинг), ед. вр.
𝜏)
—
моменты освобождения ресурса по окончании
предоставления услуги 𝑖-му пользователю
Δ0
—
моменты проведения 𝑘-х торгов
𝑛
—
общее число занятых слайсов в сети
𝛽
—
случайная
величина
тарифа
с
плотностью
распределения 𝑓5 на интервале [𝛽7 , 𝛽9 ]
𝛽𝜉
—
доход
поставщика
инфраструктуры
(периодический слайсинг), ден. ед.
[𝛽7 , 𝛽9 ]
—
интервал вариации цены, ден. ед./ед. вр.
𝛽7
—
минимальный
тариф,
принятый
поставщиком
инфраструктуры, ден. ед./ед.вр.
𝛽9
—
максимальный тариф, по которому арендаторы
готовы оплатить требуемую услугу, ден. ед./ед.вр.
𝑟
—
скорость, требуемая для предоставления услуги
арендатором в рассматриваемой зоне покрытия,
бит/с
𝐾
—
число пересчетов величины дохода поставщика
инфраструктуры
при
применении
стратегии
периодического слайсинга
5
𝑁
—
максимальное число слайсов, которое может быть
выделено
одновременно,
число
виртуальных
машин в облачном сервере
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑇'()*)+,
количество периодов 𝑇'()*)+, в имитационной
модели
𝒫+
—
политика для состояния 𝑛 – правило, возможный
критерий для принятия или отклонения входящих
заявок для состояния 𝑛
(𝒫F , … , 𝒫HIJ )
—
вектор политик приема заявки в систему
𝓟'M'NO7
—
политика для всех состояний системы – вектор
политик приема заявки в систему (для системы,
зависящей от состояния)
𝒟+
—
допустимый интервал торгов для состояния 𝑛, ден.
ед./ед.вр.
𝑝+
—
вероятность того, что заявка на новый слайс будет
принята в состоянии 𝑛
𝜋+
—
стационарная вероятность состояния 𝑛
𝑃TU7)N
—
вероятность того, что заявка на новый слайс будет
принята независимо от числа слайсов, занятых в
системе
𝑈
—
средний объем занятых ресурсов
𝑅X
—
средний
доход
поставщика
инфраструктуры,
ден. ед.
𝑅(Y'N
—
упущенный доход поставщика инфраструктуры,
ден. ед.
𝑅Z+)N
—
удельный доход поставщика инфраструктуры,
ден. ед.
𝑅0,H
—
доход
поставщика
инфраструктуры
для
фиксированного 𝑁, ден. ед.
𝑅0,H[\]^_\`
—
доход поставщика инфраструктуры для отдельного
𝑇'()*)+, , ден. ед.
6
𝛽+̇
—
порог приёма {применим для политики AT},
ден. ед./ед. вр.
̇
𝛽)+*
—
вектор пороговых значений приёма заявок на
обслуживание для каждого слайса (значения
вектора возрастают с ростом N), ден. ед./ед. вр.
̇
𝛽UO*
—
вектор пороговых значений приёма заявок на
обслуживание для каждого слайса (значения
вектора убывают с ростом 𝑁), ден. ед./ед. вр.
7
Введение
Каждые
несколько
лет
технология
мобильной
связи
претерпевает
революционные перемены. Такие быстрые изменения связаны со значительным
увеличением количества передаваемых данных за последние годы [1]. Пятое
поколение
сотовых
технологий
5G
стало
большим
скачком
в
сфере
телекоммуникаций. Наиболее известные преимущества данной технологии – это
скорость обмена данными, большая пропускная способность сети, простое и
быстрое массовое подключение устройств к сети. По сообщениям Ассоциации GSM,
самые быстрые сети 5G будут как минимум в 10 раз быстрее 4G (мобильная связь 4го поколения) LTE (Long-Term Evolution, стандарт беспроводной высокоскоростной
передачи данных для мобильных устройств). Фактическая скорость загрузки данных
будет зависеть от ряда факторов, включая местоположение и сетевой трафик [2].
В последнее время постоянный рост пользователей и нехватка ресурсов
несколько озадачили учёных в сфере телекоммуникаций. Оказалось, применение
концепции сетевого слайсинга (network slicing) в сетях с архитектурой 5G может
разрешить создавшиеся сложности, ведь нарезка сети обеспечивает создание
логических сетей путем разделения одной инфраструктуры. Затем виртуальные сети
настраиваются в соответствии с конкретными потребностями приложений, служб,
устройств, клиентов или операторов. Таким образом, внедрение нарезки сети
поставщиками инфраструктуры сможет предоставлять различные типы услуг,
предусмотренные в 5G [3].
В выпускной квалификационной работе бакалавра с помощью аппарата
теории массового обслуживания построена математическая модель разделения
ресурсов при сетевом слайсинге. Целью данной работы является анализ влияния
принятых стратегий доступа к ресурсам и политик приема заявок в систему на
средний доход поставщика инфраструктуры, который и является главной
интересующей метрикой. Основная задача работы – определить наиболее выгодную
стратегию доступа к ресурсам и политику приема заявок в систему для поставщика
инфраструктуры. Для построенной модели приведен численный пример, в котором
произведён
расчёт
среднего
дохода
поставщика
инфраструктуры
для
периодического слайсинга и слайсинга по требованию. Также получены графики
зависимости искомой величины от числа слайсов в системе с примененными
8
стратегиями периодического слайсинга и слайсинга по требованию, удельного
дохода поставщика инфраструктуры в зависимости от числа слайсов (для стратегии
слайсинга по требованию), а также отображена зависимость упущенного дохода
поставщика инфраструктуры от интенсивности поступления в систему заявок (для
стратегии периодического слайсинга).
Первая часть выпускной квалификационной работы бакалавра представляет
собой обзор существующих источников по теме сетевого слайсинга, а именно:
основных принципов работы технологии, её применения, проблем, связанных с
внедрением сетевого слайсинга.
Вторая
часть
работы
представляет
собой
подробное
описание
рассматриваемой системной и математической моделей разделения ресурсов при
слайсинге по требованию и периодическом слайсинге. В этой части также приведен
обзор политик приема заявок и стратегий доступа заявок в систему.
Третья часть – численный анализ среднего, удельного и упущенного доходов
поставщика инфраструктуры (для стратегий слайсинга по требованию и
периодического слайсинга) рассматриваемой системе массового обслуживания
(СМО), представление полученных результатов в виде графиков.
По результатам работы сделан доклад на Всероссийской конференции с
международным участием «Информационно-телекоммуникационные технологии и
математическое моделирование высокотехнологичных систем (ИТТиММВС 2021)»,
тезисы которого опубликованы в трудах конференции [36], который был признан
лучшим докладом в секции «Теория телетрафика и ее приложения» (Приложение 3).
9
1. Технологические особенности сетевого слайсинга
1.1 Основная информация о сетевом слайсинге
В последнее время появилась тенденция к внедрению сетей пятого поколения
(5G). Например, популярная в России компания МТС уже запустила тестирование
новой технологии в пилотных зонах для своих абонентов. По сообщениям РБК, сеть
следующего поколения доступна в 14 локациях города Москвы, при этом,
пользователям будет предоставлен интернет на скорости до 1,5 Гбит/с без какихлибо ограничений. При этом выбор участников, которым выпадет шанс первым
испытать данную технологию, осуществляется на основе анализа данных
пользователя о близости к местам с внедренной сетью 5G. Стоит отметить, на
данный момент спрогнозировано, что к 2030 году число пользователей МТС сети 5G
составит 50 миллионов человек [4].
Конечно, этот случай не является единичным, крупные компании по всему
миру борются за сохранение конкурентоспособной позиции на рынке услуг. Такие
характеристики, как возможность создания виртуальной среды, простота в
программируемости дают основание считать сеть пятого поколения надёжной,
высокоэффективной и недорогой [5]. В ближайшие годы сеть 5G позволит получить
широкий спектр новых специально адаптированных услуг довольно большому
кругу компаний, проектами которых являются: умные города, автономное
вождение, телемедицина, интернет вещей и т. д. [6, 7, 8].
Однако, стоит отметить, что предоставление услуг посредством технологии
пятого поколения обладает жёсткими требованиями, такими как высокие
пропускная способность, пиковая скорость передачи данных, энергоэффективность
сети, низкое время ожидания [9, 10]. Для борьбы с трудностями, связанными с
использованием и внедрением сетей нового поколения, ученые разработали
технологию сетевого слайсинга, при которой сетевая инфраструктура поделена на
логические сегменты (сетевые слайсы), работающие в облачной инфраструктуре [10,
11]. Данная технология позволит операторам сотовой связи (Mobile Network
Operators, MNOs) создавать отдельные слайсы под услуги, которые предоставляет
поставщик услуг (Service Provider, SP) путём обеспечения функционального и
операционного разнообразия на общей сетевой инфраструктуре [12]. Сетевой слайс
может
охватывать
несколько
сетей,
таких
как
сеть
радиодоступа,
сеть
10
транспортировки
сообщений
и
опорная
сеть
[10].
Однако,
поставщик
инфраструктуры не гарантирует наличие необходимого числа слайсов для
удовлетворения потребностей отдельного поставщика услуг [13].
1.2 Применение концепции сетевого слайсинга
С каждым новым этапом в развитии интернета вещей (Internet of Things, IoT)
специализированные приложения IoT становятся все популярнее. Одной из
основополагающих функций является многоадресная рассылка, передающая данные
от исходного узла в указанном направлении [14].
Проект умный город является частью множества интернета вещей. Его
внедрение позволит гражданам получать услуги, существенно улучшающие их
обыденную жизнь. Именно по этой причине правительства стран по всему миру
планируют возведение умных городов, где каждый уголок города будет соединен
друг с другом посредством инфраструктуры IoT. Основное преимущество данных
городов – это возможность своевременного устранения возникших неполадок
коммунальными службами. IoT устройства обладают различными функциями –
контроля, отслеживания, измерения и исполнения. Поскольку приоритетом служб
умного города является приватность, коммунальные предприятия предпочитают
устанавливать частные сети для подключения устройств. Однако, бюджетные и
технические ограничения, а также проблемы с производительностью не позволяют
поставщикам коммунальных услуг расширять свои частные сети. На сегодняшний
день сетевой слайсинг – лучший способ объединить весь умный город [15], ведь с
применением этой технологии откроется возможность создания отдельных
логических сетей на основе общей физической сети. Такая концепция поможет
облегчить работу служб интернета вещей, при этом удовлетворяя требованиям по
качеству обслуживания [16].
Телемедицина – это такой сегмент здравоохранения, который для проведения
дистанционной диагностики и лечения людей в отдаленных районах с плохим
состоянием здоровья использует преимущества медицинских технологий и
оборудования крупных больниц или специализированных медицинских центров. С
развитием технологии телекоммуникаций телемедицина перешла от простой
телефонной диагностики к интегрированной передаче цифрового изображения и
голоса через сеть. В настоящее время телемедицина включает в себя как
11
дистанционную хирургию, так и мониторинг здоровья. Данные услуги требуют от
сети наилучшие параметры следующих величин: пропускной способности,
задержки, надежности и т. д. Более того, некоторые категории телемедицины
предъявляют противоречивые требования к сети. Например, для удаленной
хирургии необходима высокая надежность и низкая задержка, в то время как для
диагностики изображений высокой четкости требуется широкополосная связь.
Единая сеть (“one-size-fits-all” network) не удовлетворяет этому спектру требований.
Внедрение сети 5G должно решить вышеупомянутые проблемы путем создания
множества виртуальных топологий. Внедрение технологии сетевого слайсинга
позволит обеспечить обслуживание заявок на предоставление различных услуг в
телемедицине [17].
По расчётам учёных сетевой слайсинг позволит увеличить доходы операторов
до 150% в сравнении с классической концепцией одной большой сети [12].
Технология сетевого слайсинга не является единичной, её, скорее, можно считать
объединением инновационных технологий [18]. Программно-определяемая сеть
(Software defined networking, SDN) и виртуализация сетевых функций (Network
function virtualization, NFV), наряду с облачными технологиями необходимы для
внедрения технологии сетевого слайсинга [19]. Технология SDN обеспечивает
прямое программируемое сетевое управление, при котором администраторы с
лёгкостью могут управлять сетями и программировать их. Во-вторых, SDN обладает
гибкими техниками управления, то есть сеть может динамически подстраиваться
под меняющиеся требования в различных ее местах. Более того, применение SDN
позволяет представить управляющие устройства как единый коммутатор для
различных подсистем обработки политик (policy engines). Технология SDN основана
на стандартах и является универсальный, что упрощает проектирование и
эксплуатацию сети [20]. В отличие от программно-определяемой сети NFV отделяет
сетевые функции (включая функции переадресации и управления сетью) от
аппаратного обеспечения [21]. То есть функции традиционно выделенного сетевого
оборудования
могут
предоставляться
в
качестве
программных
функций,
работающих на виртуальных машинах. Данная технология позволяет сэкономить
как на капитальных, так и на операционных затратах, поскольку выделенное
оборудование может работать на стандартных сетевых серверах. Кроме того,
12
отсутствует необходимость в обслуживании центров обработки данных или
сервисных центров, так как емкость сервера может быть изменена по требованию с
помощью соответствующих настроек программного обеспечения [21]. Подводя итог
вышесказанному, технология SDN обеспечивает гибкую переадресацию и
управление трафиком в физической или виртуальной сетевой среде, в то время как
NFV – гибкое размещение виртуализированных сетевых функций в сети и облаке
[22]. Для создания программируемой сети эти две технологии обычно дополняют
друг друга. Как было обозначено ранее, в контексте мобильных сетей технологии
SDN и NFV обеспечивает воплощение сетевого слайсинга [23]. Действительно, в
основном, сети 5G разработаны с учётом отделения плоскости контроля от
плоскости пользователя. Ввиду того, что большая часть трафика плоскости
пользователя требует довольно простой обработки, он может быть обслужен при
недорогом оборудовании. Отдельные объекты плоскости контроля, в свою очередь,
требуют более глубокой обработки в сравнении с плоскостью пользователя.
Внедрение
технологии
сетевого
слайсинга
обеспечивает
выгодное
масштабирование в зависимости от требований пользовательской плоскости, так как
плоскость управления не зависит от пользовательской плоскости [24].
Помимо SDN и NFV сети 5G используют ряд технологий, включая облачные
вычисления (cloud computing) и периферийные вычисления (edge computing), связь
между
устройствами
(Device-to-Device
communication),
связь
в
диапазоне
миллиметровых волн (Millimeter wave (mmWave) communication). Облачные
вычисления были введены для удовлетворения растущих потребностей в
управлении
ресурсами,
рассматриваются
в
хранении
качестве
данных.
перспективной
Периферийные
технологии
для
вычисления
расширения
возможностей экосистем 5G [25]. Связь между устройствами позволяет отдельным
частям IoT, находящимся в непосредственной близости друг от друга,
контактировать друг с другом, используя прямую связь, а не длинную
традиционную передачу сигнала [26]. Связь в диапазоне миллиметровых волн
обладает рядом преимуществ, в том числе большой пропускной способностью и
узкой направленностью (narrow beam), служащими средством для преодоления
проблем, вызванных ростом объема мобильного трафика [27].
13
В качестве примера применения технологии сетевого слайсинга представлена
следующая целостная нисходящая программируемая архитектура [28]. Принятая
схема виртуализации на основе SDN/NFV исследуется в рамках многоуровневой
архитектуры. В рамках этой архитектуры представлены:
•
уровень предметной области (business layer) – обеспечивает
обслуживание, которое возможно благодаря виртуальным сетевым функциям
(virtual network functions, VNF) и приложениям (virtual network applications,
VNA), создает специальный манифест слайсинга (slice manifest), в котором
содержатся сведения по управлению и использованию конкретной сетевой
архитектурой;
•
уровень обслуживания (service layer) – обеспечивает создание и
настройку пакета услуг в соответствии со сведениями, описанными в файле
манифеста слайсинга;
•
уровень инфраструктуры (infrastructure layer) – поддерживает
перенастраиваемую облачную экосистему и виртуализацию в режиме
реального времени для обеспечения сверхбыстрого обслуживания входящих
заявок.
Сети 5G должны справляться с широким спектром задач и удовлетворять
строгим требованиям к производительности. Сети 5G обладают широким
диапазоном применения – они могут быть использованы как в сфере общественной
безопасности, так и в IoT. Владелец сетевого слайса обозначает желаемый вариант
использования (например, IoT) на уровне предметной области. Уровень
обслуживания, в свою очередь, поддерживает все функции, используемые для
управления работой отдельного сетевого слайса (развертывание, внедрение,
управление,
контроль,
масштабирование
и
завершение
работы).
Уровень
обслуживания – уровень, на котором осуществляется преобразование шаблонов
сетевых слайсов в оперативный пакет ресурсов и услуг с учетом конкретного случая
использования.
Элементы
программируемые
оборудование
для
уровня
вычислительные
хранения
инфраструктуры
устройства,
данных,
включают
в
себя
сетевое
оборудование,
программируемое
радиочастотное
оборудование и программное обеспечение, любой тип программируемой сети,
облачные и сетевые (основанные на SDN) системы управления [29].
14
1.3 Проблемы, связанные с внедрением технологии сетевого слайсинга
Внедрение сетевого слайсинга является проблематичным, поскольку с
технологиями SDN и NVF связан ряд трудностей. Ввиду того, что традиционные
мобильные
сети
состоят
из
физического
оборудования
в
сочетании
со
специфической функциональностью, развертывание и операции данных сетей
являются модульными, в то время как сети с внедренной технологией сетевого
слайсинга обладают слоями с градацией сложности. Операторы мобильной связи
устанавливают специализированное оборудование в требуемых местах согласно
спросу (например, в густонаселенных районах города). В таком случае возникает
сложность в организации развертки и эксплуатации стандартных аппаратных
средств, внедрении и удалении необходимых функций программного обеспечения,
так как эти процессы необходимо производить в нескольких местах одновременно.
Софтверизация сетей является частью отрасли информационных технологий, в
которой существует большой пул серверов, нацеленный на эффективную обработку
данных. Отрасль технологии связи, в свою очередь, имеет совершенно иную цель,
так как в большей степени сосредоточена на передаче данных, чем на их обработке.
Соотнесение парадигмы программного обеспечения (отрасль информационных
технологий) с парадигмой передачи критически важных данных (отрасль
технологии связи) сама по себе является сложной задачей. Неудивительно, что
многие
организации
стремятся
разработать
оптимальные
технологии
для
реализации сетевого слайсинга [30].
15
2. Построение модели сетевого слайсинга
2.1 Системная модель
Системная модель изображена на Рис. 2.1 и включает в себя одного
поставщика инфраструктуры (Infrastructure Provider, InP) и несколько поставщиков
услуг. Полагаем, что пользовательское оборудование (ПО) находится в пределах
зоны обслуживания базовой станции (БС), которая принадлежит поставщику
инфраструктуры (Infrastructure Provider, InP). БС представляет собой точку доступа
к другим сетевым ресурсам, например, транзитному соединению, IP-сетям и
облачным
хранилищам.
Пользовательскому
оборудованию
может
быть
предоставлен доступ к нескольким услугам, каждая из которых обеспечивается
своим поставщиком услуг (Service Provider, SP). Полагаем, что ПО может получать
услугу только у одного SP. Это предположение не нарушает общности, если мы
считаем, что пользователь, получающий несколько услуг одновременно, имеет
отдельно ПО для каждой услуги. Для предоставления услуги своему пользователю
поставщики услуги SP арендует ресурсы поставщика инфраструктуры InP. Объем
ресурса, который InP выделяет для обслуживания заявки того или иного SP,
называется слайсом. В общем случае размеры слайсов для заявок разных SP могут
различаться, при этом для каждой заявки одного SP поставщик инфраструктуры
всегда выделяет слайс одного и того же размера. Заметим, что в литературе также
встречается подход, при котором слайсом называется объем ресурса, выделенный
арендатору для обслуживания всех его пользователей [31–35]. Объем ресурса,
имеющегося у поставщика инфраструктуры, измеряется в [бит/с].
На Рис. 2.1 обозначены два SPs – арендаторы ресурса, направляющие свои
заявки поставщику инфраструктуры InP, который имеет ресурс 𝐶 [бит/с], что
соответствует 𝑁 слайсам. Для каждого арендатора определены параметры 𝜆J и 𝜆c
[заявок/с] – интенсивность поступления заявок на предоставление соответствующей
услуги, 𝑟J и 𝑟c [бит/с] – скорости, требуемые для предоставления услуги
соответствующим арендатором, 𝜇J и 𝜇c [заявок/с] – интенсивность обслуживания
заявок соответствующего арендатора, 𝛽J и 𝛽c [ден. ед./ед. вр.] – случайная величина,
цена, которую арендатор предлагает поставщику инфраструктуры обслуживание
своей заявки.
16
Рис. 2.1 Системная модель предоставления слайсов.
Допустим, InP делит имеющиеся ресурсы, выделяя слайсы двум SP (Рис. 2.2).
Слайс на Рис. 2.2 соответствует ресурсу, выделенному пользовательскому
оборудованию для предоставления запрошенной услуги. Размеры слайсов для
разных услуг различаются и в общем случае являются случайными величинами с
разными функциями распределения (ФР). Размеры слайсов, выделенных разным
пользователям для получения одной и той же услуги, одинаковы, а в общем случае
являются случайными величинами с одной и той же ФР.
Рис. 2.2 Распределение ресурсов поставщика инфраструктуры по слайсам,
соответствующим заявкам от SP
17
Так же стоит отметить, что красный и синий цвета на Рис. 2.1 и 2.2 определяют
двух арендаторов слайсов (SPs). По аналогии окрашены слайсы, выделенные для
предоставления соответствующих услуг пользователям, и пользовательское
оборудование, обслуживаемое разными SPs (Рис. 2.1).
Поставщик
инфраструктуры
решает,
принимать
на
обслуживание
поступающую заявку или нет во время проведения торгов, исходя из политики
приема заявки в систему. Торги – процедура выбора заявок из поступивших в
систему для принятия к обслуживанию. Политика приема заявки в систему
учитывает как количество свободных ресурсов на момент принятия решения, так и
цену, которую SP предлагает за то, чтобы его заявку допустили к обслуживанию. Во
время проведения торгов InP проверяет наличие свободного ресурса, достаточного
для обслуживания поступившей заявки, и, при наличии, сравнивает цену 𝛽,
предлагаемую поступившей заявкой, с имеющимся у него диапазоном цены
[𝛽7 , 𝛽9 ]. Здесь [𝛽7 , 𝛽9 ] – интервал вариации цены, при этом 𝛽7 – минимальный
тариф, при котором поставщику инфраструктуры выгодно принять заявку на
обслуживание, 𝛽9 – максимальный тариф, устраивающий арендатора. Примерами
политик приема заявки в систему являются политика постоянного допуска (Always
Admit policy, AA), когда диапазон вариации цены [𝛽7 , 𝛽9 ] поставщика
инфраструктуры постоянен, или же политика превышения порога (Above Threshold
policy, AT), когда диапазон вариации цены d𝛽̇ , 𝛽9 e имеет плавающий порог допуска
заявок в систему 𝛽̇ . Указанные политики представляют собою различные модели
ценообразования для SP.
В общем случае предлагаемая арендатором цена 𝛽 – случайная величина с
произвольной плотностью 𝑓5 на интервале [𝛽7 , 𝛽9 ].
Пусть для примера с.в. 𝛽~𝑈[𝛽7 , 𝛽9 ] (распределение случайной величины
подчинено равномерному закону, 𝛽7 ≠ 𝛽9 ), тогда плотность распределения имеет
вид:
1
, 𝛽 ∈ [𝛽7 , 𝛽9 ],
𝑓5 = i 𝛽9 − 𝛽7
0,
иначе.
(2.1)
18
Политика приема заявки в систему 𝒫+ зависит от состояния 𝑛 системы и
представляет собой критерий, по которому InP решает принять или отклонить заявку
на выделение слайса в состоянии n (0 ≤ 𝑛 ≤ 𝑁 − 1, где 𝑁 = [𝐶/𝑟]):
принять заявку, 𝛽 ∈ 𝒟+ ⊂ [𝛽7 , 𝛽9 ],
𝒫+ = v
отклонить заявку,
иначе.
(2.2)
Здесь 𝒟+ – интервал вариации цены, который устанавливает InP в зависимости от
состояния 𝑛 системы.
Момент проведения торгов определяется стратегией управления доступом к
ресурсу. Далее рассмотрены стратегии управления доступом двух типов – т.н.
«слайсинг по требованию» (event-triggered), когда решение о приёме заявки на
обслуживание принимается (проводятся торги) в момент её поступления в систему,
и т.н. «периодический слайсинг» (time-triggered), когда вопрос о приёме заявок на
обслуживание рассматривается (проводятся торги) периодически одновременно для
всех заявок, которые поступили в систему с момента принятия последнего решения.
Далее будем строить модель для случая одного арендатора, который
предоставляет пользователям одну услугу. В этом случае к InP поступает один поток
заявок, обладающий следующими характеристиками: 𝑟 [бит/с] – скорость, требуемая
для предоставления услуги арендатором; 𝜆 [заявок/с] – интенсивность поступления
заявок; 𝜇 [заявок/с] – интенсивность обслуживания; 𝛽 [ден. ед./ед. вр.] – цена,
которую предлагает SP за обслуживание своей заявки, случайная величина,
подчиняющаяся распределению общего вида с плотностью 𝑓5 на фиксированном для
SP интервале [𝛽7 , 𝛽9 ]. Если общий объем ресурса, имеющийся у InP, 𝐶 [бит/с], тогда
максимальное число слайсов, которые могут быть выделены в системе, а значит, и
максимальное число заявок, которое может быть принято в систему, равно 𝑁 =
[𝐶/𝑟]. В рассматриваемом далее случае одного арендатора размеры всех слайсов на
Рис. 2.2 будут одинаковы, для обслуживания каждой заявки поставщик
инфраструктуры InP должен выделить один слайс объема 𝑟 [бит/с].
Между SP и InP заключается соглашение SLA (Service Level Agreements), в
котором уточняются детали сотрудничества, в частности, скорость (или диапазон
скоростей), которую поставщик инфраструктуры InP обязуется предоставить
арендатору SP для каждой из услуг в соответствии с требованиями к качеству
обслуживания (Quality of Service, QoS), цена (или диапазон цен), которую SP
19
обязуется заплатить арендатору за полученный ресурс, стратегия управления
доступом к ресурсу (не обязательно). На Рис. 2.3 приведена иллюстрация двух
стратегий управления доступом к ресурсу: а) слайсинг по требованию (event-driven),
когда перераспределение (reslicing, перенарезка) ресурсов происходит в моменты
наступления некоторых событий, а именно, в моменты поступления заявок в
систему; б) периодический слайсинг (time-triggered), при котором решение о приеме
на обслуживание заявок, полученных поставщиком инфраструктуры InP в
промежуток времени 𝑇'()*)+, , принимается в начале следующего промежутка
времени 𝑇'()*)+, .
а)
б)
Рис. 2.3 Стратегии управления доступом к ресурсу:
a) слайсинг по требованию; б) периодический слайсинг.
20
В случае периодического слайсинга, если на торгах обнаружена нехватка
свободного ресурса для приема на обслуживание всех заявок, поступивших в
течение текущего периода 𝑇'()*)+, , решение о выборе заявок для допуска в систему
на обслуживание принимается в соответствии с политикой приема заявок–
например, в систему принимаются заявки, которые принесут поставщику
инфраструктуры InP наибольший доход. При этом, в случае наличия нескольких
заявок с равными приоритетами, заявки на обслуживание из них выбираются
случайно или в соответствии с политикой приема заявки в систему «первым пришёл
– первым обслужен» (First-Come-First-Served, FCFS). Договор об обслуживании SLA
определяет как гарантированное качество обслуживания QoS (диапазон скоростей
для каждой услуги), так и цену 𝛽 [ден. ед./ед.вр], обязательную к оплате арендатором
слайса за используемый ресурс в течение срока пребывания в системе. Доход
поставщика инфраструктуры (𝛽𝜉 ) представляет собой произведение 𝛽 [ден.
ед./ед.вр] на случайное время 𝜉 [ед. вр.] аренды слайса провайдером услуги SP у
поставщика инфраструктуры InP.
На Рис. 2.3 для а) слайсинга по требованию и б) периодического слайсинга на
оси времени показаны моменты наступления следующих событий: моменты 𝑡)
поступления к поставщику инфраструктуры InP от арендатора SP 𝑖-й заявки на
выделение ресурса для предоставления услуги своему пользователю, моменты 𝜏)
освобождения ресурса по окончании предоставления услуги 𝑖-му пользователю,
моменты Δ0 проведения 𝑘-х торгов. Заметим, что для слайсинга по требованию
торги проводятся в момент поступления заявки на выделение слайса, а для
периодического
слайсинга
отмечены
постоянные
периоды
𝑇'()*)+,
между
проведением торгов.
Как было отмечено ранее, в результате торгов предполагается возможность
отклонения запросов слайсов провайдером инфраструктуры (на Рис. 2.3 отклонение
отображено рукопожатием со знаком запрета над ним) в зависимости от доступности
ресурса, полученных предложений по цене и принятой политики приема заявки в
систему.
Пример на Рис. 2.3 соответствует случаю максимального числа слайсов 𝑁 =
2. После того, как арендатор займёт оба слайса, его дальнейшая попытка получить
доступ к какому-либо из слайсов для обслуживания третьей заявки будет неудачной
21
(вне зависимости от предложенной SP цены) ввиду недостатка ресурсов у InP. По
окончании времени 𝜉 арендатору представится возможность в будущем получить
слайс для новой заявки – либо в момент её поступления при стратегии слайсинга по
требованию, либо в момент ближайших после поступления заявки торгов при
стратегии периодического слайсинга.
При стратегии периодического слайсинга, в случае политики «лучшего
предложения» (Best Bid, BB) будет принята заявка, которая предложит более
высокую цену 𝛽. Если обе заявки предлагают одинаковую цену, можно выбрать
заявку на поступление случайным образом или воспользоваться политикой FCFS,
при которой первая по очереди заявка будет принята в систему. Заметим, что для
реализации политики FCFS необходимо запоминать и хранить до ближайших торгов
моменты поступления заявок, поэтому случайный выбор заявок является менее
ресурсозатратным. Заметим, на Рис. 2.3 величиной 𝜉 обозначено время, в течение
которого будет осуществляться использование слайсов арендатором. Для обеих
стратегий управления доступом к ресурсу (слайсинга по требованию и
периодического слайсинга) на Рис. 2.3 приведен пример отказа в обслуживании для
третьей заявки, поступившей в систему. Что касается стоимости, SP платит за
слайсы только тогда, когда использует ресурсы, поэтому для случая б)
периодического слайсинга поставщик инфраструктуры не получает дохода с
момента 𝜏c до момента ближайших торгов.
2.2 Математическая модель
Пусть в СМО M|M|N|0 (Рис. 2.4) поступает пуассоновский поток заявок с
интенсивностью 𝜆, соответствующий потоку запросов на выделение слайса от
арендатора, при этом заявка может быть потеряна как из-за отсутствия свободных
слайсов для её обслуживания, так и вследствие политики приема заявки в систему.
Длительность обслуживания соответствует длительности удержания слайса
арендатора и является экспоненциально распределенной случайной величиной с
параметром 𝜇.
22
Рис. 2.4 Система массового обслуживания M|M|N|0
Процесс занятия ресурса поставщика инфраструктуры может быть описан
Марковским процессом (МП) с непрерывным временем 𝑿(𝑡) = †𝑛(𝑡), 𝒫+ (𝑡)‡, где
𝑛(𝑡) – число активных слайсов в момент времени 𝑡, 𝒫+ (𝑡) – политика приема заявки
на слайс в систему в момент времени 𝑡, c пространством состояний
𝕏 = {(𝑛, 𝒫+ )},
где 𝑛 ∈ [0, 𝑁 = ⌊𝐶/ 𝑟⌋], 𝒫+ – политика приема заявки в систему, которая зависит от
состояния 𝑛 системы и представляет собой критерий, по которому InP решает
принять или отклонить заявку на слайс:
принять заявку, 𝛽 ∈ 𝒟+ ⊂ [𝛽7 , 𝛽9 ],
𝒫+ = v
отклонить заявку,
иначе,
(2.3)
где 𝒟+ – интервал цены, при попадании в который заявка будет принята в систему
при наличии доступного ресурса.
Каждому состоянию МП 𝑿(𝑡) соответствует свой критерий для принятия или
отклонения входящих заявок на слайсы 𝒫+ , 𝑛 = 0, … , 𝑁 − 1, при этом 𝓟'M'NO7 =
(𝒫F , … , 𝒫H ). Политика 𝒫+ , 𝑛 = 0, … , 𝑁 − 1 может быть определена одним из
следующих способов:
a) для стратегии слайсинга по требованию:
1) политика AA: заявка будет принята, если цена 𝛽 ∈ 𝒟+•• = [𝛽7 , 𝛽9 ];
2) политика AT: заявка будет принята, если цена 𝛽 ∈ 𝒟+•Ž = d𝛽+̇ , 𝛽9 e, где
𝛽+̇ ≥ 𝛽7 , 𝛽+̇ – порог приёма;
b) для стратегии периодического слайсинга:
23
1) политика BB: из участвующих в торгах заявок будет принята заявка,
которая предложит более высокую цену 𝛽, при этом политика
применяется, пока не исчерпается свободный ресурс;
2) политика FCFS: из участвующих в торгах заявок будет заявка, дольше
остальных ожидающая начала торгов, при этом политика применяется,
пока не исчерпается свободный ресурс;
Вероятность того, что заявка будет принята в систему в состоянии n
определяется следующим образом:
(2.4)
𝑝+ †𝑓5 , 𝒫+ ‡ = 𝑝5∈𝒟• = ‘ 𝑓5 (𝛽 )𝑑𝛽 .
𝒟•
Здесь 𝑓5 – плотность случайной цены 𝛽, предлагаемой арендатором, из интервала
[𝛽7 , 𝛽9 ].
Рис. 2.5 Граф интенсивностей переходов для МП 𝑿(𝑡), реализующего
слайсинг по требованию
На Рис. 2.5 построен граф интенсивностей переходов для МП 𝑿(𝑡 ),
описывающего функционирование заявленной системной модели. Матрица
интенсивностей переходов (табличный вид) приведена ниже.
0
1
2
3
…
N-1
N
0
−𝑝F 𝜆
𝑝F 𝜆
0
0
…
0
0
1
𝜇
𝑝J 𝜆
0
…
0
0
2
0
𝑝c 𝜆
…
0
0
−(𝜇
+ 𝑝J 𝜆)
2𝜇
−(2𝜇
+ 𝑝c 𝜆)
24
3
0
0
3𝜇
⋮
⋮
⋮
⋮
−(3𝜇
+ 𝑝• 𝜆)
⋮
…
0
0
⋱
⋮
⋮
N-1
0
0
0
0
…
N
0
0
0
0
…
−†(𝑁 − 1)𝜇
+ 𝑝HIJ 𝜆‡
𝑁𝜇
𝑝HIJ 𝜆
−𝑁𝜇
В предположении о существовании стационарного режима определим
стационарные вероятности состояний МП 𝑿(𝑡):
𝜋˜ = lim P{𝑿(𝑡 ) = 𝑗}, 𝑗 ∈ 𝕏.
(2.5)
N→•
Нашей задачей является нахождение стационарных вероятностей 𝜋˜ , 𝑗 ∈ 𝕏¡,
что позволит получить в аналитическом виде выражения для основных
вероятностно-временных характеристик системы.
Расчёт
стационарных
вероятностей
произведён
в
зависимости
от
примененного множества политик приема заявок в систему: SD (State Dependent
Policy) или SI (State Independent Policy). Далее рассмотрим получение стационарных
вероятностей и вероятностно-временных характеристик для каждой их стратегий.
При применении множества политик приема заявки в систему SD вычисления
вероятностей 𝑝+ , 𝑛 = 1, … , 𝑁, проводятся по формуле (2.4) в зависимости от каждого
из состояний n. Стационарные вероятности 𝜋+ , 𝑛 = 1, … , 𝑁, получаем путем решения
системы линейных уравнений:
𝜋F λ𝑝F = 𝜋J 𝜇,
⎧ (
𝜋 λ𝑝 + 𝜇) = 𝜋F λ𝑝F + 𝜋c 2𝜇,
⎪ J J
𝜋c (λ𝑝c + 2𝜇 ) = 𝜋J λ𝑝J + 𝜋• 3𝜇,
⎨𝜋•(λ𝑝• + 3𝜇) = 𝜋c λ𝑝c + 𝜋§ 4𝜇,
...
⎪
⎩𝜋+ (𝜆𝑝+ + 𝑛𝜇) = 𝜋+IJ 𝜆𝑝+IJ + 𝜋+©J (𝑛 + 1)𝜇.
(2.6)
с условием нормировки:
ª
H
𝜋+ = 1.
+«F
Введя традиционную для обозначения нагрузки переменную
𝜆
𝜌= ,
𝜇
25
получили
1
, 𝑛 = 1, … , 𝑁,
𝜌) )IJ
H
1 + ∑)«J ∏(«F 𝑝(
𝑖!
𝜌+ )IJ
∏ 𝑝
𝑛! («F (
𝜋+ †𝜌, 𝑓5 , 𝑁, 𝓟'M'NO7 ‡ =
, 𝑛 = 1, … , 𝑁.
𝜌) )IJ
H
1 + ∑)«J ∏(«F 𝑝(
𝑖!
𝜋F †𝜌, 𝑓5 , 𝑁, 𝓟'M'NO7 ‡ =
(2.7)
Получив распределение стационарных вероятностей, мы можем найти некоторые
метрики, характеризующие производительность системы:
– вероятность того, что заявка на новый слайс будет принята в систему:
HIJ
𝑃TU7)N †𝜌, 𝑓5 , 𝑁, 𝓟'M'NO7 ‡ = ª 𝜋+ ∙ 𝑝+ , 𝑛 = 0, … , 𝑁 − 1,
(2.8)
+«F
– вероятность блокировки заявки из-за отсутствия свободного ресурса:
𝐵†𝜌, 𝑓5 , 𝑁, 𝓟'M'NO7 ‡ = 𝜋H ,
(2.9)
– вероятность блокировки заявки из-за несоответствия политике приема заявки в
систему имеет вид:
𝑃±O˜O*N = 1 − 𝑃TU7)N .
(2.10)
– средняя ожидаемая цена в соответствии исходя из политики приема заявки в
систему 𝒫+ , по которому арендатор будет платить за выделенный ему слайс:
𝑬[𝛽|𝛽𝜖𝒟+ ] = ‘
©•
I•
𝛽 ∙ 𝑝{5|5µ𝒟• } 𝑑𝛽 =
1
‘ 𝛽 ∙ 𝑓(𝛽 )𝑑𝛽.
𝑝+ 𝒟•
(2.11)
– средний доход, полученный поставщиком инфраструктуры:
HIJ
𝑅5 †𝜌, 𝑓5 , 𝑁, 𝓟'M'NO7 ‡ = 𝜌 ∙ ª 𝜋+ ∙ 𝑝+ ∙ 𝑬[𝛽|𝛽𝜖𝒟+ ].
(2.12)
+«F
Множество политик приема заявки в систему SI (State Independent Policy)
является частным случаем множества политик SD (State Dependent Policy). К SI
применимы формулы для множества политик доступа SD со следующими
поправками:
𝒫+ = 𝒫;
𝒟H = 𝒟;
(2.13)
𝑝+ = 𝑝.
26
По аналогии со случаем SD, для SI запишем расчетные формулы для тех же
величин. Учитывая (2.13), запишем (2.7) в следующем виде:
𝜋+†·,¸¹ ,H,𝒫‡
(𝜌 ∙ 𝑝 )+
𝑛!
=
.
(𝜌 ∙ 𝑝))
H
∑)«F
𝑖!
(2.14)
Воспользовавшись (2.13), из (2.8) имеем:
𝑃TU7)N †𝜌, 𝑓5 , 𝑁, 𝒫‡ = (1 − 𝜋H ) ∙ 𝑝.
(2.15)
Принимая во внимание (2.13), запишем формулу для нахождения дохода InP:
𝑅5 †𝜌, 𝑓5 , 𝑁, 𝒫‡ = 𝜌 ∙ 𝑃TU7)N ∙ 𝑬[𝛽|𝛽𝜖𝒟].
(2.16)
В частности, говоря о множестве SI, стоит упомянуть политику приема заявки
в систему AA. Для AA интервал имеет вид 𝒟 = [𝛽7 , 𝛽9 ], а вероятность 𝑝 = 1.
Как было заявлено ранее, математическая модель применима как для
периодического слайсинга, так и для слайсинга по требованию.
Для политики приема заявки в систему AT (политика превышения порога)
заявка SP с тарифом ниже 𝛽̇ не будет принята в систему, соответственно,
допустимый интервал торгов 𝒟+ выглядит следующим образом:
𝒟+•Ž = d𝛽+̇ , 𝛽9 e, где 𝛽̇+ ≥ 𝛽7 , 𝛽̇ – нижний порог приёма.
(2.17)
Исходя из выражения (2.17) можем переписать (2.4) в виде:
𝑝+•Ž †𝑓5 , 𝒫+ ‡
=‘
5¿
5̇•
𝑓5 (𝛽 )𝑑𝛽.
(2.17)
Можно считать, что политика AA является частным случаем AT, т. е.
𝒟+•• = 𝒟+•Ž при условии 𝛽̇+ = 𝛽7 .
(2.18)
По аналогии с AT, исходя из выражения (2.19), можем переписать (2.4) в виде
𝑝+•• †𝑓5 , 𝒫+ ‡
=‘
5¿
5Á
𝑓5 (𝛽 )𝑑𝛽.
(2.19)
Ситуация нехватки ресурса в состоянии, когда все слайсы поставщика
инфраструктуры заняты, моделируется с помощью определения интервала торгов
𝒟H = ∅, тогда вероятность того, что заявка на новый слайс будет принята в
состоянии 𝑁 равна 𝑝H = 0.
27
3. Численный анализ
В данном разделе представлены численные примеры и анализ результатов.
3.1 Стратегия слайсинга по требованию
Проведем работу с моделью разделения ресурсов с внедрённой стратегией
управления доступом к ресурсу слайсинга по требованию в случае применения
множества политик SD и SI.
Проанализируем поведение системы на малых размерностях (Табл. 3.1.).
Табл. 3.1. Параметры системы для слайсинга по требованию
Параметр
интенсивность
Обозначение
Значение
𝜆
5,15,30,100 заявок/с
𝜇
1 заявка/с
𝐶
20 Мбит/с
𝑆
1 поставщик услуг
𝑁
1, … ,10 слайсов
𝛽
~𝑈[𝛽7 , 𝛽9 ] евро/с
поступления заявок
интенсивность
обслуживания
заявок
общий объем
ресурса
число поставщиков
услуг (арендаторов
слайсов)
максимальное число
слайсов, которое
может быть
выделено
одновременно
случайная величина,
цена, предлагаемая
арендатором
поставщику
инфраструктуры за
обслуживание
поступающей заявки
28
интервал вариации
[𝛽7 , 𝛽9 ]
[3 евро/с, 20 евро/с]
цены
минимальный
𝛽7
3 евро/с
𝛽9
20 евро/с
𝜷̇
зависит от применяемой политики
тариф, принятый
поставщиком
инфраструктуры
максимальный
тариф,
устраивающий
арендаторов
вектор пороговых
значений цены
приема заявок в систему
приёма заявок на
обслуживание при
стратегии слайсинга
по требованию
вектор, все
𝜷𝒎 = (𝛽7 , … . , 𝛽7 )Ž (3,3, … ,3)Ž евро/с
компоненты
которого равны 𝛽7
вектор пороговых
𝜷̇𝒊𝒏𝒄
1) 2 евро/с
значений цены
2) (2,3)Ž евро/с
приёма заявок на
3) (2,3,4)Ž евро/с
обслуживание для
4) (2,3,4,5)Ž евро/с
политики приема
5) (2,3,4,5,6)Ž евро/с
заявки в систему AT
6) (2,3,4,5,6,7)Ž евро/с
(значения вектора
7) (2,3,4,5,6,7,8)Ž евро/с
возрастает с ростом
8) (2,3,4,5,6,7,8,9)Ž евро/с
𝑁)
9) (2,3,4,5,6,7,8,9,10)Ž евро/с
10) (2,3,4,5,6,7,8,9,10,11)Ž евро/с
вектор пороговых
𝜷̇𝒅𝒆𝒄
1) 19 евро/с
значений цены
2) (19,18)Ž евро/с
приёма заявок на
3) (19,18,17)Ž евро/с
29
обслуживание для
4) (19,18,17,16)Ž евро/с
политики приема
5) (19,18,17,16,15)Ž евро/с
заявки в систему AT
6) (19,18,17,16,15,14)Ž евро/с
(значения вектора
7) (19,18,17,16,15,14,13)Ž евро/с
убывает с ростом 𝑁)
8) (19,18,17,16,15,14,13,12)Ž евро/с
9) (19,18,17,16,15,14,13,12,11)Ž
евро/с
10) (19,18,17,16,15,14,13,12,11,10)Ž
евро/с
Отметим, для политики приема заявки в систему AA вектор пороговых
значений 𝜷̇ = 𝜷𝒎 ⇒ применено множество политик SI. Относительно политики
приема заявки в систему AT с примененным множеством политик SD выделено 2
случая:
1.
с повышением пороговых значений с ростом 𝑁 вектор 𝜷̇ = 𝜷̇𝒊𝒏𝒄 ;
2.
с понижением пороговых значений с ростом 𝑁 вектор 𝜷̇ = 𝜷̇𝒅𝒆𝒄 .
Построены графики, отображающие зависимость дохода от числа слайсов.
Стояла задача сравнить доход поставщика инфраструктуры для следующих случаев.
1.
InP применена политика приема заявки в систему AA из множества
политик SI, где 𝜷̇ = 𝜷𝒎 , на графике обозначение политики: AA;
2.
InP применена политика AT из множества политик SD, где 𝜷̇ = 𝜷̇𝒊𝒏𝒄 , на
графике обозначение политики: 𝐴TÓÔÕ ;
3.
InP применена политика AT из множества политик SD, где 𝜷̇ = 𝜷̇𝒅𝒆𝒄 , на
графике обозначение политики: 𝐴TÖ×Õ .
30
Ср. доход поставщика инфраструктуры, 𝑅
Ср. доход поставщика инфраструктуры, 𝑅
а) 𝜆 = 5
б) 𝜆 = 15
Ср. доход поставщика инфраструктуры, 𝑅
Число слайсов в системе, 𝑁
Ср. доход поставщика инфраструктуры, 𝑅
Число слайсов в системе, 𝑁
Число слайсов в системе, 𝑁
Число слайсов в системе, 𝑁
в) 𝜆 = 30
г) 𝜆 = 100
Рис. 3.1 Зависимость величины среднего дохода InP от максимального
количества слайсов в системе
Для указанного в табл. 3.1 набора значений исходных параметров сделаны
следующие выводы. При большой нагрузке выгодно уменьшать порог приема,
потому что при росте интенсивности поступления заявок на слайс доход не
упускается. При применении политики приёма заявок в систему SD: 𝐴TÓÔÕ доход
поставщика инфраструктуры несколько выше, чем при SD: 𝐴TÖ×Õ (Рис. 3.1 (в, г)), что
объясняется тем, что при SD: 𝐴TÓÔÕ InP получает основную долю дохода за счет
приема почти всех приходящих заявок (вероятность попадания в такой интервал
31
больше). Применение политики приёма заявок в систему SI: AA выгодно для
поставщика инфраструктуры в случае низкой нагрузки на систему (Рис. 3.1 (а)), так
как позволяет получить максимальный доход за счет отсутствия потерь заявок в
случае
несоответствия
предлагаемой
арендатором
цены
и
установленной
поставщиком порогом (для SI: AA пороговое значение 𝛽+̇ = 𝛽7 ).
Таким образом, проанализировав три случая и построив соответствующие
графики, отмечено, что максимальное число слайсов 𝑁 оказывает влияние на
изменение величины получаемого дохода. Проведенный анализ позволит выбрать
политику для получения наибольшего дохода поставщику инфраструктуры: для
случая большой нагрузки на систему рекомендовано использование SD: 𝐴TÓÔÕ , в то
время, как для малой – SD: 𝐴TÖ×Õ .
После расчёта среднего дохода, была рассмотрена зависимость удельного
дохода поставщика инфраструктуры от интенсивности поступления заявок в
систему (Рис. 3.2). Для нахождения удельного дохода 𝑅Z+)N была использована
следующая формула:
𝑅Z+)N =
𝑅
, при 𝑁 = 1, … 10.
𝑁
(3.1)
При применении политики приёма заявок в систему SI: AA значения 𝑅Z+)N
колеблются
в
одном
диапазоне,
то
есть
удельный
доход
поставщика
инфраструктуры не зависит от количества слайсов в системе и нагрузки на систему.
Применение данной политики выгодно для InP только в случае низкой нагрузки на
систему так как позволяет получить максимальный доход за счет отсутствия потерь
заявок (𝛽 ∈ 𝒟+•• = [𝛽7 , 𝛽9 ]).
При применении политики приёма заявок в систему SD: 𝐴TÓÔÕ для системы с
большой нагрузкой удельный доход поставщика инфраструктуры несколько выше,
чем при SD: 𝐴TÖ×Õ (Рис. 3.2 (в, г)), так как при SD: 𝐴TÓÔÕ поставщик инфраструктуры
получает основную долю дохода за счет приема почти всех приходящих заявок
•ŽÙÚÛ
(вероятность попадания заявки в интервал 𝒟+
̇
= d𝛽UO*
, 𝛽9 e больше). Как было
•
заявлено ранее, при большой нагрузке выгодно уменьшать пороговое значение для
приема заявок в систему, потому что при росте интенсивности поступления заявок
на слайс доход не упускается, как следствие, удельный доход InP в таком случае
выше.
32
Удельный доход InP (на 1 слайс), R Z+)N
Удельный доход InP (на 1 слайс), R Z+)N
а) 𝜆 = 5
б) 𝜆 = 15
Удельный доход InP (на 1 слайс), R Z+)N
Число слайсов в системе, 𝑁
Удельный доход InP (на 1 слайс), R Z+)N
Число слайсов в системе, 𝑁
Число слайсов в системе, 𝑁
Число слайсов в системе, 𝑁
в) 𝜆 = 30
г) 𝜆 = 100
Рис. 3.2 Зависимость величины удельного дохода InP от максимального
количества слайсов в системе
Таким образом, проанализировав три случая и построив соответствующие
графики, в общем случае отмечено, что максимальное число слайсов 𝑁 и нагрузка
на систему оказывают влияние на изменение величины получаемого дохода в расчёте
на 1 слайс (удельного дохода). Исходя из проведенного анализа поставщику
инфраструктуры открывается возможность выбора подходящей политики в
зависимости от количества слайсов в системе и интенсивности поступления заявок
на
обслуживание:
для
случая
малой
нагрузки
на
систему
поставщику
33
инфраструктуры рекомендовано использование SD: 𝐴TÖ×Õ , в то время, как для
большой – SD: 𝐴TÓÔÕ .
3.2 Стратегия периодического слайсинга
Перейдем к работе с моделью разделения ресурсов с внедрённой стратегией
управления доступом к ресурсу периодического слайсинга в случае применения
политик BB и FCFS.
Проанализируем поведение системы на малых размерностях (Табл. 3.2.).
Табл. 3.2. Параметры системы для периодического слайсинга
Параметр
Обозначение
Значение
интенсивность поступления заявок
𝜆
5, 100 заявок/с
интенсивность обслуживания заявок
𝜇
1 заявка/с
общий объем ресурса
𝐶
20 Мбит/с
число поставщиков услуг (арендаторов
𝑆
1
слайсов)
максимальное число слайсов, которое
поставщик
услуг
𝑁
1, … ,10 слайсов
𝛽
~𝑈[𝛽7 , 𝛽9 ]
может быть выделено одновременно
случайная величина, цена, предлагаемая
арендатором поставщику инфраструктуры
евро/с
за обслуживание поступающей заявки;
интервал вариации цены
[𝛽7 , 𝛽9 ]
[3
евро/с,
20
евро/с]
минимальный тариф, принятый
𝛽7
3 евро/с
𝛽9
20 евро/с
𝐾
200 шт.
поставщиком инфраструктуры
максимальный тариф, устраивающий
арендаторов
количество пересчетов величины дохода
поставщика инфраструктуры при
применении стратегии периодического
слайсинга
34
𝑇'()*)+,
период времени, в конце которого
3 ед. вр.
принимается решение о приеме на
обслуживание заявок
случайная длительность обслуживания
𝜉
~𝑒𝑥𝑝(𝜇 ) ед. вр.
случайная длительность интервала между
𝜂
~𝑒𝑥𝑝(𝜆) ед. вр.
Δ0
3,6,9 ед. вр.;
поступлениями соседних заявок
моменты проведения 𝑘-х торгов
Алгоритм работы имитационного средства для расчета среднего дохода представлен
на Рис. 3.3.
начало работы программы
ввод параметров системы
опредение условий приема
заявок на обслуживание в соответствии с политиками BB, FCFS
НЕТ
ДА
ДА
НЕТ
ДА
НЕТ
конец работы программы
Рис. 3.3 Алгоритм вычисления среднего дохода InP при применеии стратегии
периодического слайсинга
35
Для 𝑁 = 1, … , 10 слайсов были определены две политики доступа заявок в систему
для периодического слайсинга:
a) политика «первым пришёл – первым обслужен» (FCFS);
b) политика «лучшего предложения» (BB).
В конечном счёте было получено 10 значений (т. к. 𝑁 = 1, … , 10), каждое из которых
было пересчитано K раз.
𝑁=1
𝑁 =2
…
𝑁=9
𝑁 = 10
попытка 1
𝑅J,J
𝑅J,c
…
𝑅J,Þ
𝑅J,JF
попытка 2
𝑅c,J
𝑅c,c
…
𝑅c,Þ
𝑅c,JF
⋮
⋮
⋮
⋱
⋮
⋮
попытка 𝑘 − 1
𝑅0IJ,J
𝑅0IJ,c
…
𝑅0IJ,Þ
𝑅0IJ,JF
попытка 𝑘
𝑅0,J
𝑅0,c
…
𝑅0,Þ
𝑅0,JF
Значения в каждом столбце суммированы и поделены на количество произведенных
попыток 𝐾:
ß
1
𝑅H = ª 𝑅0,H .
𝐾
(3.2)
0«J
Таким образом, для каждого 𝑁 получены значения среднего дохода для обеих
политик.
Далее произведено построение графиков, отображающих зависимость
среднего дохода 𝑅H от числа слайсов 𝑁.
Была поставлена задача сравнить средний доход поставщика инфраструктуры
для случаев, когда:
1.
InP применена политика приема заявки в систему FCFS (Рис. 3.4);
2.
InP применена политика приема заявки в систему BB (Рис. 3.4).
36
Ср. доход поставщика инфраструктуры, 𝑅
Ср. доход поставщика инфраструктуры, 𝑅
Число слайсов в системе, 𝑁
Число слайсов в системе, 𝑁
а) 𝜆 = 5
б) 𝜆 = 100
Рис. 3.4 Зависимость величины среднего дохода InP от максимального количества
слайсов в системе
На Рис 3.4 заметна тенденция к возрастанию величины среднего дохода при
увеличении числа слайсов. При построении графиков с разной нагрузкой системы
отмечено, что число слайсов 𝑁 оказывает влияние на изменение величины
получаемого
среднего
дохода
поставщиком
инфраструктуры.
Исходя
из
проведённого анализа, можем сделать вывод о том, что политика BB является
наилучшей. С точки зрения вычислений поставщику инфраструктуры следует
помнить о том, что для ВВ необходимо хранить в памяти только цену, с которой
поступает заявка на обслуживание, в то время как для FCFS — только время
прибытия заявки.
Далее приведён расчет упущенного дохода поставщика инфраструктуры. В
расчете использована следующая формула:
𝑅(Y'N = 𝑅H«cFF (λ) − 𝑅H«à (λ),
(3.3)
при 𝑁 = 5; 𝜆 = 5,10,15,20,25,30,35,40,45,50,55,60,65,70.
37
Упущенный доход InP, R (Y'N
Интенсивность поступления заявок в систему, 𝜆
𝑁=5
Рис. 3.5 Зависимость величины упущенного дохода InP от интенсивности
поступления заявок
На Рис. 3.5 представлены графики, отображающие зависимость упущенного
дохода поставщика инфраструктуры от интенсивности поступления заявок в
систему. Отмечена тенденция к возрастанию величины упущенного дохода в
зависимости от интенсивности поступления заявок (как следствие, нагрузки на
систему). В независимости от нагрузки на систему различия в потерях при
применении политик BB и FCFS незначительны, однако, при применении политики
FCFS величина упущенного дохода несколько выше. При выборе политики для
применения поставщику инфраструктуры рекомендуется обратить внимание на
аспекты, связанные с вычислениями, а в частности, вычислительной мощностью.
Напомним,
для
воплощения
политики
BB,
приносящей
поставщику
инфраструктуры больший доход в сравнении с политикой FCFS, требуется
запоминание цены, с которой приходит заявка.
38
Заключение
В выпускной квалификационной работе бакалавра представлена системная и
математическая модели сетевого слайсинга, которые позволяют проанализировать
влияние применения стратегий доступа к ресурсам и политик приема заявок в
систему на средний доход поставщика инфраструктуры. Дано подробное описание
политик доступа заявок в систему для стратегий слайсинга по требованию и
периодического слайсинга, получены формулы для анализа основных показателей
эффективности системы: вероятность того, что заявка на новый слайс будет принята
в систему, вероятность блокировки заявки из-за отсутствия свободного ресурса,
вероятность блокировки заявки из-за несоответствия политике приема заявки в
систему, средняя ожидаемая цена в соответствии исходя из политики приема заявки
в систему 𝒫+ , по которому арендатор будет платить за выделенный ему слайс,
средний доход, полученный поставщиком инфраструктуры.
Исследовано поведение среднего, удельного и упущенного дохода в
зависимости от применяемой политики приема заявок в систему для двух стратегий
доступа к ресурсам. Для построенной модели проведен численный эксперимент, в
котором рассчитана таких характеристик системы, как средний, удельный и
упущенный доход поставщика инфраструктуры при различных политиках доступа
заявок в систему. Построены графики, отображающие зависимость этих величины
от числа слайсов в системе и интенсивности поступления заявок.
Задачей дальнейших исследований является усовершенствование имеющейся
математической модели путём изменения формирования цены 𝛽. Таким образом,
смоделировать эту величину используя не только равномерное распределение, но и
экспоненциальное, нормальное и т.д. Также определение задачи оптимизации для
данных
системной
и
математических
моделей,
её
решение,
построение
соответствующих графиков.
Автор работы выражает благодарность д.ф.-м.н., профессору кафедры
прикладной информатики и теории вероятностей Гайдамака Ю.В. за точную
постановку задач выпускной квалификационной работы, внимательное отношение
к студентам. Также автор выражает особую признательность аспиранту кафедры
прикладной информатики и теории вероятностей Москалевой Ф.А. за поддержку и
помощь во время всего периода работы над задачей сетевого слайсинга.
39
Список источников
1. Shafi M. et al. 5G: A Tutorial Overview of Standards, Trials, Challenges, Deployment,
and Practice // IEEE Journal on Selected Areas in Communications. – Vol. 35, no. 6 –
2017 – P. 1201-1221. DOI: 10.1109/JSAC.2017.2692307.
2. What is 5G? Your questions answered. / Duffy C. [Электронный ресурс]. Режим
доступа: https://edition.cnn.com/interactive/2020/03/business/what-is-5g/index.html
(дата обращения: 25.02.2021).
3. What is network slicing? / Kavanagh S. [Электронный ресурс]. Режим доступа:
https://5g.co.uk/guides/what-is-network-slicing/ (дата обращения: 28.02.2021).
4. МТС включила в Москве первую в стране пилотную сеть 5G для пользователей.
[Электронный ресурс]. Режим доступа: https://www.rbc.ru/technology_and_med
ia/05/03/2021/604200da9a7947035e686165 (дата обращения: 03.03.2021).
5. Lu Y., Chen X., Xi R. and Chen Y. An access selection mechanism in 5G network
slicing // 2020 IEEE International Conference on Smart Internet of Things (SmartIoT).
– Beijing, China – 2020 – P. 72-78. DOI: 10.1109/SmartIoT49966.2020.00020.
6. Matencio-Escolar A., Wang Q. and Alcaraz Calero J. M. SliceNetVSwitch: Definition,
Design and Implementation of 5G Multi-Tenant Network Slicing in Software Data
Paths // IEEE Transactions on Network and Service Management. – Vol. 17, no. 4 –
2020 – P. 2212-2225. DOI: 10.1109/TNSM.2020.3029653.
7. Santos J. F, Kist M., Rochol J. and DaSilva L. A. Virtual Radios, Real Services:
Enabling RANaaS Through Radio Virtualisation // IEEE Transactions on Network and
Service Managemen. – Vol. 17, no. 4 – 2020 – P. 2610-2619. DOI:
10.1109/TNSM.2020.3009863.
8. Liu Y., Ding J. and Liu X. A Constrained Reinforcement Learning Based Approach for
Network Slicing // 2020 IEEE 28th International Conference on Network Protocols
(ICNP). – Madrid, Spain – 2020 – P. 1-6. DOI: 10.1109/ICNP49622.2020.9259378.
9. Montero R., Agraz F., Pagès A., Spadaro S. Real‐time maintenance of latency‐
sensitive 5G services through network slicing // Photonic Network Communications.
DOI: 10.1007/s11107-020-00897-6.
10. De Domenico A., Liu Y. -F. and Yu W. Optimal Virtual Network Function Deployment
for 5G Network Slicing in a Hybrid Cloud Infrastructure // IEEE Transactions on
40
Wireless Communications. – Vol. 19, no. 12 – 2020 – P. 7942-7956. DOI:
10.1109/TWC.2020.3017628.
11. Wei F., Feng G., Sun Y., Wang Y., Qin S. and Liang Y. -C. Network Slice
Reconfiguration by Exploiting Deep Reinforcement Learning With Large Action
Space // IEEE Transactions on Network and Service Management. – Vol. 17, no. 4 –
2020 – P. 2197-2211. DOI: 10.1109/TNSM.2020.3019248.
12. Gligoroski D. and Kralevska K. Expanded Combinatorial Designs as Tool to Model
Network Slicing in 5G // IEEE Access. – Vol. 7 – 2019 – P. 54879-54887. DOI:
10.1109/ACCESS.2019.2913185.
13. Luu Q. -T., Kerboeuf S., Mouradian A. and Kieffer M. A Coverage-Aware Resource
Provisioning Method for Network Slicing // IEEE/ACM Transactions on Networking.
– Vol. 28, no. 6 –2020 – P. 2393-2406. DOI: 10.1109/TNET.2020.3019098.
14. Qin Y. et al. Enabling Multicast Slices in Edge Networks // in IEEE Internet of Things
Journal. – Vol. 7, no. 9 – 2020 – P. 8485-8501. DOI: 10.1109/JIOT.2020.2991107.
15. Zhou F. et al. Automatic Network Slicing for IoT in Smart City // IEEE Wireless
Communications. – Vol. 27, no. 6 – 2020 – P. 108-115.
DOI: 10.1109/MWC.001.2000069.
16. Onur A., Shin’ichi A., Masayuki M. SDN-Based Control of IoT Network by BrainInspired Bayesian Attractor Model and Network Slicing // Appl. Sci. 10. – no. 17: 5773
– 2020. DOI: 10.3390/app10175773.
17. Liu Y., Wang L., Wen X., Lu Z., Liu L. A Network Slicing Strategy for Telemedicine
based on Classification // 2020 IEEE/CIC International Conference on Comm. in
China.– 2020 – P. 191-196. DOI:10.1109/ICCCWorkshops49972.2020.9209918.
18. Kim D., Kim S. Network slicing as enablers for 5G services: state of the art and
challenges for mobile industry // Telecommun. Syst 71. – 2019 – P.517–527. DOI:
10.1007/s11235-018-0525-2.
19. Network slicing for 5G networks & services. [Электронный ресурс]. Режим
доступа: https://www.5gamericas.org/network-slicing-for-5g-networks-services/
(дата обращения: 28.03.2021).
20. Kreutz D., et al. Software-defined networking: A comprehensive survey // Proceedings
of the IEEE. Vol. 103 – 2015 – P.14–76. DOI: 10.1109/JPROC.2014.2371999.
41
21. SDN vs. NFV: What’s the difference? / Tittel E. [Электронный ресурс]. Режим
доступа: https://www.cisco.com/c/en/us/solutions/software-defined-networking/sdnvs-nfv.html (дата обращения: 30.03.2021).
22. Obraczka K., Rothenberg C., & Rostami A. SDN, NFV and their role in 5G. //
SIGCOM16. – Brazil – 2016.
23. Shafi M. et al. 5G: A Tutorial Overview of Standards, Trials, Challenges, Deployment,
and Practice // in IEEE Journal on Selected Areas in Communications. – Vol. 35, no.
6 – 2017 – P. 1201-1221. DOI: 10.1109/JSAC.2017.2692307.
24. A vision of the 5G core: flexibility for new business opportunities. [Электронный
ресурс]. Режим доступа: https://www.ericsson.com/en/reports-and-papers/ericssontechnology-review/articles/a-vision-of-the-5g-core-flexibility-for-new-businessopportunities (дата обращения: 01.04.2021).
25. Khan A. N., Kiah M. M., Khan S. U., Madani S. A. Towards secure mobile cloud
computing: A survey // Future Generation Computer Systems 29. – 2013 – P.1278–
1299. DOI: 10.1016/j.future.2012.08.003.
26. Kar U. N., Sanyal D. K. An overview of device-to-device communication in cellular
networks // ICT Express. DOI: 4. 10.1016/j.icte.2017.08.002.
27. Wang X., Kong L., Kong F., Qiu F., Xia M., Arnon S., Chen G. Millimeter Wave
Communication: A Comprehensive Survey // IEEE Communications Surveys &
Tutorials. – P. 1-1. DOI: 10.1109/COMST.2018.2844322.
28. Schiller E., Nikaein, N. Favraud R., Kostas K. & Stavropoulos D., Alyafawi I., Zhao
Z., Braun T., Korakis T. Network Store: Exploring Slicing in Future 5G Networks //
The 10th ACM Workshop on Mobility in the Evolving Internet Architecture (ACM
MobiArch) colocated with the 21st ACM Annual International Conference on Mobile
Computing and Networking (ACM MOBICOM). – Paris, France – 2015. DOI:
10.1145/2795381.2795390.
29. Kostas K., Nikaein N., Schiller E., Ksentini A., Braun T. Network Slices Towards 5G
Communications: Slicing the LTE Network // IEEE Communications Magazine. – no.
55 – 2017. DOI: 10.1109/MCOM.2017.1600936.
30. View on 5G Architecture (Version 2.0). 5G PPP Architecture Working Group.
[Электронный ресурс]. Режим доступа: https://5g-ppp.eu/wp-
42
content/uploads/2018/01/5G-PPP-5G-Architecture-White-Paper-Jan-2018-v2.0.pdf
(дата обращения: 05.04.2021).
31. Yarkina N., Gaidamaka Yu., Correia L. M., and Samouylov K. An analytical model for
5G network resource sharing with flexible SLA-oriented slice isolation, Mathematics.
– 8(7) – 1177 – 2020. DOI: 10.3390/math8071177.
32. Polyakov N.V., Yarkina N.V., Samouylov K.E. A simulator for analyzing a network
slicing policy with SLA-based performance isolation of slices, Discrete and
Continuous Models and Applied Computational Science. – 28 (1) – C. 1–17 – 2020.
DOI: 10.22363/2658-4670-2020-28-1-1-17.
33. Москалева Ф. А., Гайдамака Ю.В., Шоргин В. С. Влияние параметров изоляции
на разделение ресурсов при нарезке сети // Информатика и ее применение. 2020.
– Т. 14. №4 – С. 9-16. DOI: 10.14357/19922264200402.
34. Foukas X., Patounas G., Elmokashfi A. and Marina M. K. Network Slicing in 5G:
Survey and Challenges// IEEE Communications Magazine. – Vol. 55, no. 5 – 2017 –
P. 94-100. DOI: 10.1109/MCOM.2017.1600951.
35. Vincenzi M., Lopez-Aguilera E., Garcia-Villegas E. Maximizing Infrastructure
Providers’ Revenue Through Network Slicing in 5G // IEEE Access. – Vol. 7. – 2019.
– P. 128283-128297. DOI: 10.1109/ACCESS.2019.2939935.
36. Лапшенкова Л.О., Москалева Ф.А.., Гайдамака Ю.В. Сравнение доходов
поставщика инфраструктуры для двух политик доступа при нарезке
радиоресурсов сети 5G // Информационно-телекоммуникационные технологии
и математическое моделирование высокотехнологичных систем: материалы
Всероссийской конференции с международным участием. Москва, РУДН, 19–23
апреля 2021 г. — Москва: РУДН. — 2021. — C.59-64.
43
Приложение 1. К расчету числовых характеристик для случая слайсинга по
требованию
import numpy as np
import math
import scipy
import random
import matplotlib.pyplot as plt
aver_revenue_total_n_AA=[]
aver_revenue_total_n_AT_1=[]
aver_revenue_total_n_AT_2=[]
N_list=[]
N_infinity_list=[]
N_infinity_for_list=10
N_for_list=10
for i in range (1,N_for_list+1):
N_list.append(i)
for i in range (1,N_infinity_for_list+1):
N_infinity_list.append(i)
mu=1
betta_m=3
betta_M=20
lam_min=5
lam_max=31
udel_aa=[]
udel_at_1=[]
udel_at_2=[]
###________________________НАЧАЛО
ФУНКЦИЙ_____________________________###
def betta_dot_identification_AA():
global betta_dot
betta_dot=[]
del betta_dot[:]
for i in range (0,N):
betta_dot.append(betta_m)
return betta_dot
ВСПОМОГАТЕЛЬНЫХ
44
def betta_dot_identification_AT_1():
global betta_dot
betta_dot=[]
del betta_dot[:]
for i in range (0,N):
betta_dot.append(betta_M -(i+1))
return betta_dot
def betta_dot_identification_AT_2():
global betta_dot
betta_dot=[]
del betta_dot[:]
for i in range (0,N):
betta_dot.append(betta_m +(i+1))
#print(betta_dot)
return betta_dot
def probability_identification():
global probability
probability=[]
del probability[:]
for i in range (0,N):
probability.append((betta_M-betta_dot[i])/(betta_M-betta_m))
return probability
def stationary_probabilities_identification():
comp_pi_0=[]
del comp_pi_0[:]
comp_pi_0.append(probability[0])
if N>0:
for i in range (1,N):
comp_pi_0.append(comp_pi_0[i-1]*probability[i])
sum_pi_0=0
for i in range (1,N+1):
sum_pi_0=sum_pi_0+((((lam/mu)**i)/(math.factorial(i)))*comp_pi_0[i-1])
comp_pi_n=[]
del comp_pi_n[:]
comp_pi_n=comp_pi_0
global pi_n
45
pi_n=[]
del pi_n[:]
pi_0=1/(1+sum_pi_0)
pi_n.append(pi_0)
for i in range(1,N+1):
pi_n.append(((((lam/mu)**i)/(math.factorial(i)))*comp_pi_n[i-1])/(1+sum_pi_0))
summa=0
for i in range (N+1):
summa=summa+pi_n[i]
#print ("\n","Стационарные вероятности:",pi_n,"\n","\n","Сумма стационарных
вероятностей:",summa)
return pi_n
def admission_probability_identification():
admission_probability=0
for i in range (N):
admission_probability=admission_probability+pi_n[i]*probability[i]
#print("\n","Вероятность принятия заявок в систему:",admission_probability)
return admission_probability
def expected_tariff_identification():
global expected_tariff
expected_tariff=[]
del expected_tariff[:]
for i in range (N):
expected_tariff.append((1/(probability[i]*(betta_M-betta_m)))*(((betta_M**2)(betta_dot[i]**2))/2))
#print("\n","Предполагаемый тариф:",expected_tariff)
return expected_tariff
def average_revenue_identification_AA():
global average_revenue_AA
average_revenue_AA=0
summa_a_r=0
for i in range(N):
summa_a_r=summa_a_r+(pi_n[i]*probability[i]*expected_tariff[i])
average_revenue_AA=(lam/mu)*summa_a_r
#print("\n","Средний доход InP:",average_revenue_AA)
aver_revenue_total_n_AA.append(average_revenue_AA)
def average_revenue_identification_AT_1():
global average_revenue_AT_1
average_revenue_AT_1=0
46
summa_a_r=0
for i in range(N):
summa_a_r=summa_a_r+(pi_n[i]*probability[i]*expected_tariff[i])
average_revenue_AT_1=(lam/mu)*summa_a_r
#print("\n","Средний доход InP:",average_revenue_AT_1)
aver_revenue_total_n_AT_1.append(average_revenue_AT_1)
def average_revenue_identification_AT_2():
global average_revenue_AT_2
average_revenue_AT_2=0
summa_a_r=0
for i in range(N):
summa_a_r=summa_a_r+(pi_n[i]*probability[i]*expected_tariff[i])
average_revenue_AT_2=(lam/mu)*summa_a_r
#print("\n","Средний доход InP:",average_revenue_AT_2)
aver_revenue_total_n_AT_2.append(average_revenue_AT_2)
def plotting():
plt.figure(figsize=(5, 5))
plt.xlabel('Количество слайсов в системе, N', color='gray',fontsize = 16)
plt.ylabel('Средний доход поставщика инфраструктуры, R',color='gray',fontsize =
16)
plt.grid(True)
plt.scatter(N_infinity_list,aver_revenue_total_n_AA, s=15, c="b", marker="D",
linewidths=2, edgecolors="b")
plt.scatter(N_infinity_list,aver_revenue_total_n_AT_1,s=15, c="g", marker="D",
linewidths=2, edgecolors="g")
plt.scatter(N_infinity_list,aver_revenue_total_n_AT_2, s=15, c="r", marker="D",
linewidths=2, edgecolors="r")
plt.plot(N_infinity_list,aver_revenue_total_n_AA,'b')
plt.plot(N_infinity_list,aver_revenue_total_n_AT_1,'g')
plt.plot(N_infinity_list,aver_revenue_total_n_AT_2,'r')
plt.plot(N_infinity_list,aver_revenue_total_n_AA,'b',label='SI:AA')
plt.plot(N_infinity_list,aver_revenue_total_n_AT_1,'g',label='SD:AT_dec')
plt.plot(N_infinity_list,aver_revenue_total_n_AT_2,'r',label='SD:AT_inc')
plt.xlim([0, 11])
plt.ylim([0, 150])
plt.xticks(np.arange(0, len(N_infinity_list)+1, 1))
plt.yticks(np.arange(0, 180,10))
plt.legend(bbox_to_anchor=(1, 0.6),fontsize = 15)
plt.legend()
plt.show()
47
###________________________КОНЕЦ
ФУНКЦИЙ_____________________________###
ВСПОМОГАТЕЛЬНЫХ
def udelniy_dokhod_plotting():
plt.figure(figsize=(5, 5))
plt.xlabel('Количество слайсов, N', color='gray',fontsize = 16)
plt.ylabel('Удельный доход (на 1 слайс)',color='gray',fontsize = 16)
plt.grid(True)
plt.scatter(N_infinity_list,udel_aa, s=15, c="b", marker="D",
edgecolors="b")
plt.plot(N_infinity_list,udel_aa,'b',label='политика AA')
plt.scatter(N_infinity_list,udel_at_1, s=15, c="g", marker="D",
edgecolors="g")
plt.plot(N_infinity_list,udel_at_1,'g',label='политика AT_inc')
plt.scatter(N_infinity_list,udel_at_2, s=15, c="r", marker="D",
edgecolors="r")
plt.plot(N_infinity_list,udel_at_2,'r',label='политика AT_dec')
plt.xlim([0, 11])
plt.ylim([0, 20])
plt.xticks(np.arange(0, len(N_infinity_list)+1, 1))
plt.yticks(np.arange(0, 20,1))
#plt.legend()
plt.show()
def udelniy_dokhod_result():
linewidths=2,
linewidths=2,
linewidths=2,
del udel_aa[:]
del udel_at_1[:]
del udel_at_2[:]
for i in range(len(N_infinity_list)):
udel_aa.append(aver_revenue_total_n_AA[i]/N_infinity_list[i])
for i in range(len(N_infinity_list)):
udel_at_1.append(aver_revenue_total_n_AT_1[i]/N_infinity_list[i])
for i in range(len(N_infinity_list)):
udel_at_2.append(aver_revenue_total_n_AT_2[i]/N_infinity_list[i])
udelniy_dokhod_plotting()
for lam in range (lam_min,lam_max,5):
print ('lambda=',lam)
del aver_revenue_total_n_AA[:]
48
del aver_revenue_total_n_AT_1[:]
del aver_revenue_total_n_AT_2[:]
for N in range (1,N_infinity_for_list+1):
###________________________________AA__________________________________
_
betta_dot_identification_AA()
probability_identification()
stationary_probabilities_identification()
admission_probability_identification()
expected_tariff_identification()
average_revenue_identification_AA()
#print(aver_revenue_total_n_AA)
###_____________________________AT1(AT_dec)____________________________
_____
betta_dot_identification_AT_1()
probability_identification()
stationary_probabilities_identification()
admission_probability_identification()
expected_tariff_identification()
average_revenue_identification_AT_1()
#print(aver_revenue_total_n_AT_1)
###_____________________________AT2(AT_inc)_____________________________
____
betta_dot_identification_AT_2()
probability_identification()
stationary_probabilities_identification()
admission_probability_identification()
expected_tariff_identification()
average_revenue_identification_AT_2()
#print(aver_revenue_total_n_AT_2)
###_____________________________построение______________________________
___
plotting()
udelniy_dokhod_result()
49
Приложение 2. К расчету числовых характеристик для случая периодического
слайсинга
import numpy as np
import math
import scipy
import random
import matplotlib.pyplot as plt
revenue_array_n_fcfs=[]
revenue_array_n_bb=[]
lam_N_list_fcfs=[]
lam_N_list_bb=[]
infinity_r_fcfs=[]
infinity_r_bb=[]
delta_fcfs=[]
delta_bb=[]
lam_list=[]
lam_min=5
lam_max=61
for i in range(lam_min,lam_max,5):
lam_list.append(i)
lam=70
mu=1
modeling_time=9#[c]
modeling_interval=[0,modeling_time]
#N=2#количество слайсов
T_slicing=3#[c]
N_for_list=10
N_for_infinity_list=100
N_list=[]
N_infinity_list=[]
for i in range (1,N_for_list+1):
N_list.append(i)
for i in range (1,N_for_infinity_list+1):
N_infinity_list.append(i)
beta_m=3
beta_M=20
number_of_tries=200
delta=[]
nu=[]
50
ksi=[]
t=[]
T=[]
fcfs_enter_list=[]
fcfs_exit_list=[]
exists_1_fcfs=[]
exists_2_fcfs=[]
exists_3_fcfs=[]
exists_1_bb=[]
exists_2_bb=[]
exists_3_bb=[]
enter_time_1=[]
enter_time_2=[]
enter_time_3=[]
theoretical_revenue_1_fcfs=[]
theoretical_revenue_2_fcfs=[]
theoretical_revenue_3_fcfs=[]
theoretical_revenue_1_bb=[]
theoretical_revenue_2_bb=[]
theoretical_revenue_3_bb=[]
whole_fcfs_r_aver=[]
###_________________DELTA MOMENTS DETERMINING________________###
def delta_moments_determining():#определяем момент проведения торгов
del delta[:]
for i in range (3,modeling_time+1,T_slicing):
delta.append(i)
#print(delta)
#delta_moments_determining()
###_________________DELTA MOMENTS DETERMINING________________####
#################################################################
#################################################################
###_________________MODELING ENTER OF THE BIDS________________###
def bids_enter_time_for_the_1_delta():
del t[:]
nu_0=random.expovariate(lam)#определяем таким образом момент t1 когда
поступает первая заявка (начиная от 0)
t.append(nu_0)
i=0
51
while (t[i]+random.expovariate(lam))<=delta[0]:
t.append(t[i]+random.expovariate(lam))
i=i+1
global t_1_d
t_1_d = t[:]
#print('Моменты поступления заявок в систему до 1х торгов (3[c])',t_1_d)
#bids_enter_time_for_the_1_delta()
def bids_enter_time_for_the_2_delta():
del t[:]
nu_0=delta[0]+random.expovariate(lam)
t.append(nu_0)
i=0
while (t[i]+random.expovariate(lam))<=delta[1]:
t.append(t[i]+random.expovariate(lam))
i=i+1
global t_2_d
t_2_d=t[:]
#print('Моменты поступления заявок в систему до 2х торгов (6[c])',t_2_d)
#bids_enter_time_for_the_2_delta()
def bids_enter_time_for_the_3_delta():
del t[:]
nu_0=delta[1]+random.expovariate(lam)
t.append(nu_0)
i=0
while (t[i]+random.expovariate(lam))<=delta[2]:
t.append(t[i]+random.expovariate(lam))
i=i+1
global t_3_d
t_3_d=t[:]
#print('Моменты поступления заявок в систему до 3х торгов (9[c])',t_3_d)
#bids_enter_time_for_the_3_delta()
###_________________MODELING ENTER OF THE BIDS________________###
#################################################################
#################################################################
###_________________MODELING BIDS TARIFF________________#########
def beta_generation_for_delta_1():
global beta_d_1
beta_d_1=[]
beta_d_1=np.random.uniform(beta_m,beta_M,len(t_1_d))
52
#print('Цены за заявки для 1 дельты',beta_d_1)
#beta_generation_for_delta_1()
def beta_generation_for_delta_2():
global beta_d_2
beta_d_2=[]
beta_d_2=np.random.uniform(beta_m,beta_M,len(t_2_d))
#print('Цены за заявки для 2 дельты',beta_d_2)
#beta_generation_for_delta_2()
def beta_generation_for_delta_3():
global beta_d_3
beta_d_3=[]
beta_d_3=np.random.uniform(beta_m,beta_M,len(t_3_d))
#print('Цены за заявки для 3 дельты',beta_d_3)
#beta_generation_for_delta_3()
###_________________MODELING BIDS TARIFF________________########
################################################################
################################################################
###_________________MODELING EXIT OF THE BIDS________________###
def bids_exit_time_after_the_1_delta():
del T[:]
ksi_0=delta[0]+random.expovariate(mu)
T.append(ksi_0)
for k in range (1,len(t_1_d)):
T.append((delta[0]+random.expovariate(mu)))
global T_1_d
T_1_d=T[:]
#print('Теоретические моменты покидания заявок в систему после 1х торгов
(3[c])',T_1_d)
#bids_exit_time_after_the_1_delta()
def bids_exit_time_after_the_2_delta():
del T[:]
ksi_0=delta[1]+random.expovariate(mu)
T.append(ksi_0)
for k in range (1,len(t_2_d)):
T.append((delta[1]+random.expovariate(mu)))
global T_2_d
T_2_d=T[:]
#print('Теоретические моменты покидания заявок в систему после 2х торгов
(6[c])',T_2_d)
53
#bids_exit_time_after_the_2_delta()
def bids_exit_time_after_the_3_delta():
del T[:]
ksi_0=delta[2]+random.expovariate(mu)
T.append(ksi_0)
for k in range (1,len(t_3_d)):
T.append((delta[2]+random.expovariate(mu)))
global T_3_d
T_3_d=T[:]
#print('Теоретические моменты покидания заявок в систему после 3х торгов
(9[c])',T_3_d)
#bids_exit_time_after_the_3_delta()
###_________________MODELING EXIT OF THE BIDS________________###
################################################################
################################################################
###_________________MODELING
InP
REVENUE
FCFS________________########
def theoretical_InP_revenue_for_the_1_delta_fcfs():
del theoretical_revenue_1_fcfs[:]
for k in range(len(T_1_d)):
theoretical_revenue_1_fcfs.append(beta_d_1[k]*(T_1_d[k]-delta[0]))
#print('Теоретический доход 1',theoretical_revenue_1)
#theoretical_InP_revenue_for_the_1_delta()
def theoretical_InP_revenue_for_the_2_delta_fcfs():
del theoretical_revenue_2_fcfs[:]
for k in range(len(T_2_d)):
theoretical_revenue_2_fcfs.append(beta_d_2[k]*(T_2_d[k]-delta[1]))
#print('Теоретический доход 2',theoretical_revenue_2)
#theoretical_InP_revenue_for_the_2_delta()
def theoretical_InP_revenue_for_the_3_delta_fcfs():
del theoretical_revenue_3_fcfs[:]
for k in range(len(T_3_d)):
theoretical_revenue_3_fcfs.append(beta_d_3[k]*(T_3_d[k]-delta[2]))
#print('Теоретический доход 3',theoretical_revenue_3)
#theoretical_InP_revenue_for_the_3_delta()
###_________________MODELING InP REVENUE FCFS________________###
###########################################################
###########################################################
54
###_________________FCFS BIDS IDENTIFICATION____________###
def fcfs_bids_identification_for_the_1_delta(N):
global fcfs_exit_list_1
global fcfs_revenue_1
global whole_revenue_fcfs
fcfs_exit_list_1=[]
fcfs_revenue_1=[]
whole_revenue_fcfs=[]
if (len(T_1_d)>N)or(len(T_1_d)==N):
fcfs_exit_list_1=T_1_d[:N]
fcfs_revenue_1=theoretical_revenue_1_fcfs[:N]
whole_revenue_fcfs=fcfs_revenue_1[:N]
else:
fcfs_exit_list_1=T_1_d[:]
fcfs_revenue_1=theoretical_revenue_1_fcfs[:]
whole_revenue_fcfs=fcfs_revenue_1[:]
def fcfs_bids_identification_for_the_2_delta(N):
global fcfs_exit_list_2
global fcfs_revenue_2
fcfs_exit_list_2=[]
fcfs_revenue_2=[]
if (len(T_2_d)>N)or(len(T_2_d)==N):
fcfs_exit_list_2=T_2_d[:N]
fcfs_revenue_2=theoretical_revenue_2_fcfs[:N]
else:
fcfs_exit_list_2=T_2_d[:]
fcfs_revenue_2=theoretical_revenue_2_fcfs[:]
def fcfs_bids_identification_for_the_3_delta(N):
global fcfs_exit_list_3
global fcfs_revenue_3
fcfs_exit_list_3=[]
fcfs_revenue_3=[]
if (len(T_3_d)>N)or(len(T_3_d)==N):
fcfs_exit_list_3=T_3_d[:N]
fcfs_revenue_3=theoretical_revenue_3_fcfs[:N]
else:
fcfs_exit_list_3=T_3_d[:]
fcfs_revenue_3=theoretical_revenue_3_fcfs[:]
###_________________FCFS BIDS IDENTIFICATION____________###
55
###########################################################
###########################################################
###____________________BUSINESS CHECK 1_________________###
def business_existance_check_for_the_1_delta_fcfs():
b_existance_1_fcfs=[]
b_existance_1_fcfs=fcfs_exit_list_1[:]
for l in range(len(b_existance_1_fcfs)):
if b_existance_1_fcfs[l]>delta[1]:
exists_1_fcfs.append(b_existance_1_fcfs[l])
#if exists_1_fcfs==[]:
#print('No bids from the previous time!')
#print(exists_1,enter_time_1)
#business_existance_check_for_the_1_delta_fcfs()
###____________________BUSINESS CHECK 1_________________###
###########################################################
###########################################################
###__________________FORMING NEW LIST 2_________________###
def forming_new_list_for_delta_2_fcfs(N):
new_list_2_exit_fcfs=[]
new_list_2_exit_fcfs=exists_1_fcfs[:]
if len(new_list_2_exit_fcfs)<=N:
for h in range (len(fcfs_exit_list_2)):
new_list_2_exit_fcfs.append(fcfs_exit_list_2[h])
whole_revenue_fcfs.append(fcfs_revenue_2[h])
#print(new_list_2_enter,new_list_2_exit)
#forming_new_list_for_delta_2()
###__________________FORMING NEW LIST 2_________________###
###########################################################
###########################################################
###____________________BUSINESS CHECK 2_________________###
def business_existance_check_for_the_2_delta_fcfs():
b_existance_2_fcfs=[]
b_existance_2_fcfs=fcfs_exit_list_2[:]
for l in range(len(b_existance_2_fcfs)):
if b_existance_2_fcfs[l]>delta[2]:
exists_2_fcfs.append(b_existance_2_fcfs[l])
#if exists_2_fcfs==[]:
56
#print('No bids from the previous time!')
#print(exists_2,enter_time_2)
#business_existance_check_for_the_2_delta_fcfs()
###____________________BUSINESS CHECK 2_________________###
###########################################################
###########################################################
###__________________FORMING NEW LIST 3_________________###
def forming_new_list_for_delta_3_fcfs(N):
new_list_3_exit_fcfs=[]
new_list_3_exit_fcfs=exists_2_fcfs[:]
if len(new_list_3_exit_fcfs)<=N:
for h in range (len(fcfs_exit_list_3)):
new_list_3_exit_fcfs.append(fcfs_exit_list_3[h])
whole_revenue_fcfs.append(fcfs_revenue_3[h])
#print(new_list_3_enter,new_list_3_exit)
#forming_new_list_for_delta_3()
###__________________FORMING NEW LIST 3_________________###
###########################################################
###______________WHOLE REVENUE CALCULATING______________###
def whole_revenue_calculating_fcfs():
global s_fcfs
s_fcfs=0
for k in range(len(whole_revenue_fcfs)):
s_fcfs+=whole_revenue_fcfs[k]
#print (s_fcfs)
#whole_revenue_calculating()
###______________WHOLE REVENUE CALCULATING______________###
################################################################
##____________________MAXIMISING TARIFFS____________________####
def maximising_tariffs_1():
global M_beta_d_1
global M_T_1_d
M_beta_d_1=[]
M_T_1_d=[]
m_beta_d_1=beta_d_1[:]
m_T_1_d=T_1_d[:]
M_T_1_d = [x for _,x in sorted(zip(m_beta_d_1,m_T_1_d),reverse=True)]
M_beta_d_1=sorted(m_beta_d_1,reverse=True)
#print(M_beta_d_1)
57
#maximising_tariffs_1()
def maximising_tariffs_2():
global M_beta_d_2
global M_T_2_d
M_beta_d_2=[]
M_T_2_d=[]
m_beta_d_2=beta_d_2[:]
m_T_2_d=T_2_d[:]
M_T_2_d = [x for _,x in sorted(zip(m_beta_d_2,m_T_2_d),reverse=True)]
M_beta_d_2=sorted(m_beta_d_2,reverse=True)
#print(M_beta_d_2)
#maximising_tariffs_2()
def maximising_tariffs_3():
global M_beta_d_3
global M_T_3_d
M_beta_d_3=[]
M_T_3_d=[]
m_beta_d_3=beta_d_3[:]
m_T_3_d=T_3_d[:]
M_T_3_d = [x for _,x in sorted(zip(m_beta_d_3,m_T_3_d),reverse=True)]
M_beta_d_3=sorted(m_beta_d_3,reverse=True)
#print(M_beta_d_3)
#maximising_tariffs_3()
##____________________MAXIMISING TARIFFS____________________####
################################################################
################################################################
###_________________MODELING InP REVENUE________________########
def theoretical_InP_revenue_for_the_1_delta_bb():
del theoretical_revenue_1_bb[:]
for k in range(len(M_T_1_d)):
theoretical_revenue_1_bb.append(M_beta_d_1[k]*(M_T_1_d[k]-delta[0]))
#print('Теоретический доход 1',theoretical_revenue_1)
#theoretical_InP_revenue_for_the_1_delta()
def theoretical_InP_revenue_for_the_2_delta_bb():
del theoretical_revenue_2_bb[:]
for k in range(len(M_T_2_d)):
theoretical_revenue_2_bb.append(M_beta_d_2[k]*(M_T_2_d[k]-delta[1]))
#print('Теоретический доход 2',theoretical_revenue_2)
#theoretical_InP_revenue_for_the_2_delta()
58
def theoretical_InP_revenue_for_the_3_delta_bb():
del theoretical_revenue_3_bb[:]
for k in range(len(M_T_3_d)):
theoretical_revenue_3_bb.append(M_beta_d_3[k]*(M_T_3_d[k]-delta[2]))
#print('Теоретический доход 3',theoretical_revenue_3)
#theoretical_InP_revenue_for_the_3_delta()
###_________________MODELING InP REVENUE________________###
###########################################################
###########################################################
###_________________BB BIDS IDENTIFICATION____________#####
def bb_bids_identification_for_the_1_delta(N):
global bb_exit_list_1
global bb_revenue_1
global whole_revenue_bb
bb_exit_list_1=[]
bb_revenue_1=[]
whole_revenue_bb=[]
if (len(M_T_1_d)>N)or(len(M_T_1_d)==N):
bb_exit_list_1=M_T_1_d[:N]
bb_revenue_1=theoretical_revenue_1_bb[:N]
whole_revenue_bb=bb_revenue_1[:N]
else:
bb_exit_list_1=M_T_1_d
bb_revenue_1=theoretical_revenue_1_bb
whole_revenue_bb=bb_revenue_1
#bb_bids_identification_for_the_1_delta()
def bb_bids_identification_for_the_2_delta(N):
global bb_exit_list_2
global bb_revenue_2
bb_exit_list_2=[]
bb_revenue_2=[]
if (len(M_T_2_d)>N)or(len(M_T_2_d)==N):
bb_exit_list_2=M_T_2_d[:N]
bb_revenue_2=theoretical_revenue_2_bb[:N]
else:
bb_exit_list_2=M_T_2_d
bb_revenue_2=theoretical_revenue_2_bb
#bb_bids_identification_for_the_2_delta()
def bb_bids_identification_for_the_3_delta(N):
59
global bb_exit_list_3
global bb_revenue_3
bb_exit_list_3=[]
bb_revenue_3=[]
if (len(M_T_3_d)>N)or(len(M_T_3_d)==N):
bb_exit_list_3=M_T_3_d[:N]
bb_revenue_3=theoretical_revenue_3_bb[:N]
else:
bb_exit_list_3=M_T_3_d
bb_revenue_3=theoretical_revenue_3_bb
#bb_bids_identification_for_the_3_delta()
###_________________BB BIDS IDENTIFICATION____________#####
###########################################################
###########################################################
###____________________BUSINESS CHECK 1_________________###
def business_existance_check_for_the_1_delta_bb():
b_existance_1_bb=[]
b_existance_1_bb=bb_exit_list_1[:]
for l in range(len(b_existance_1_bb)):
if b_existance_1_bb[l]>delta[1]:
exists_1_bb.append(b_existance_1_bb[l])
#if exists_1_bb==[]:
#print('No bids from the previous time!')
#print(exists_1,enter_time_1)
#business_existance_check_for_the_1_delta_bb()
###____________________BUSINESS CHECK 1_________________###
###########################################################
###########################################################
###__________________FORMING NEW LIST 2_________________###
def forming_new_list_for_delta_2_bb(N):
new_list_2_exit_bb=[]
new_list_2_exit_bb=exists_1_bb[:]
if len(new_list_2_exit_bb)<=N:
for h in range (len(bb_exit_list_2)):
new_list_2_exit_bb.append(bb_exit_list_2[h])
whole_revenue_bb.append(bb_revenue_2[h])
#print(new_list_2_enter,new_list_2_exit)
#forming_new_list_for_delta_2()
60
###__________________FORMING NEW LIST 2_________________###
###########################################################
###########################################################
###____________________BUSINESS CHECK 2_________________###
def business_existance_check_for_the_2_delta_bb():
b_existance_2_bb=[]
b_existance_2_bb=bb_exit_list_2[:]
for l in range(len(b_existance_2_bb)):
if b_existance_2_bb[l]>delta[2]:
exists_2_bb.append(b_existance_2_bb[l])
#if exists_2_bb==[]:
#print('No bids from the previous time!')
#print(exists_2,enter_time_2)
#business_existance_check_for_the_2_delta_bb()
###____________________BUSINESS CHECK 2_________________###
###########################################################
###########################################################
###__________________FORMING NEW LIST 3_________________###
def forming_new_list_for_delta_3_bb(N):
new_list_3_exit_bb=[]
new_list_3_exit_bb=exists_2_bb[:]
if len(new_list_3_exit_bb)<=N:
for h in range (len(bb_exit_list_3)):
new_list_3_exit_bb.append(bb_exit_list_3[h])
whole_revenue_bb.append(bb_revenue_3[h])
#print(new_list_3_enter,new_list_3_exit)
#forming_new_list_for_delta_3()
###__________________FORMING NEW LIST 3_________________###
###########################################################
###______________WHOLE REVENUE CALCULATING______________###
def whole_revenue_calculating_bb():
global s_bb
s_bb=0
for k in range(len(whole_revenue_bb)):
s_bb+=whole_revenue_bb[k]
#print (s_bb)
#whole_revenue_calculating()
###______________WHOLE REVENUE CALCULATING______________###
61
################################################################
##____________________MAXIMISING TARIFFS____________________####
def maximising_tariffs_1():
global M_beta_d_1
global M_T_1_d
M_beta_d_1=[]
M_T_1_d=[]
m_beta_d_1=beta_d_1[:]
m_T_1_d=T_1_d[:]
M_T_1_d = [x for _,x in sorted(zip(m_beta_d_1,m_T_1_d),reverse=True)]
M_beta_d_1=sorted(m_beta_d_1,reverse=True)
#print(M_beta_d_1)
#maximising_tariffs_1()
def maximising_tariffs_2():
global M_beta_d_2
global M_T_2_d
M_beta_d_2=[]
M_T_2_d=[]
m_beta_d_2=beta_d_2[:]
m_T_2_d=T_2_d[:]
M_T_2_d = [x for _,x in sorted(zip(m_beta_d_2,m_T_2_d),reverse=True)]
M_beta_d_2=sorted(m_beta_d_2,reverse=True)
#print(M_beta_d_2)
#maximising_tariffs_2()
def maximising_tariffs_3():
global M_beta_d_3
global M_T_3_d
M_beta_d_3=[]
M_T_3_d=[]
m_beta_d_3=beta_d_3[:]
m_T_3_d=T_3_d[:]
M_T_3_d = [x for _,x in sorted(zip(m_beta_d_3,m_T_3_d),reverse=True)]
M_beta_d_3=sorted(m_beta_d_3,reverse=True)
#print(M_beta_d_3)
#maximising_tariffs_3()
##____________________MAXIMISING TARIFFS____________________####
################################################################
################################################################
###_________________MODELING InP REVENUE________________########
62
def theoretical_InP_revenue_for_the_1_delta_bb():
del theoretical_revenue_1_bb[:]
for k in range(len(M_T_1_d)):
theoretical_revenue_1_bb.append(M_beta_d_1[k]*(M_T_1_d[k]-delta[0]))
#print('Теоретический доход 1',theoretical_revenue_1)
#theoretical_InP_revenue_for_the_1_delta()
def theoretical_InP_revenue_for_the_2_delta_bb():
del theoretical_revenue_2_bb[:]
for k in range(len(M_T_2_d)):
theoretical_revenue_2_bb.append(M_beta_d_2[k]*(M_T_2_d[k]-delta[1]))
#print('Теоретический доход 2',theoretical_revenue_2)
#theoretical_InP_revenue_for_the_2_delta()
def theoretical_InP_revenue_for_the_3_delta_bb():
del theoretical_revenue_3_bb[:]
for k in range(len(M_T_3_d)):
theoretical_revenue_3_bb.append(M_beta_d_3[k]*(M_T_3_d[k]-delta[2]))
#print('Теоретический доход 3',theoretical_revenue_3)
#theoretical_InP_revenue_for_the_3_delta()
###_________________MODELING InP REVENUE________________###
###########################################################
###########################################################
###_________________BB BIDS IDENTIFICATION____________#####
def bb_bids_identification_for_the_1_delta(N):
global bb_exit_list_1
global bb_revenue_1
global whole_revenue_bb
bb_exit_list_1=[]
bb_revenue_1=[]
whole_revenue_bb=[]
if (len(M_T_1_d)>N)or(len(M_T_1_d)==N):
bb_exit_list_1=M_T_1_d[:N]
bb_revenue_1=theoretical_revenue_1_bb[:N]
whole_revenue_bb=bb_revenue_1[:N]
else:
bb_exit_list_1=M_T_1_d
bb_revenue_1=theoretical_revenue_1_bb
whole_revenue_bb=bb_revenue_1
#bb_bids_identification_for_the_1_delta()
def bb_bids_identification_for_the_2_delta(N):
63
global bb_exit_list_2
global bb_revenue_2
bb_exit_list_2=[]
bb_revenue_2=[]
if (len(M_T_2_d)>N)or(len(M_T_2_d)==N):
bb_exit_list_2=M_T_2_d[:N]
bb_revenue_2=theoretical_revenue_2_bb[:N]
else:
bb_exit_list_2=M_T_2_d
bb_revenue_2=theoretical_revenue_2_bb
#bb_bids_identification_for_the_2_delta()
def bb_bids_identification_for_the_3_delta(N):
global bb_exit_list_3
global bb_revenue_3
bb_exit_list_3=[]
bb_revenue_3=[]
if (len(M_T_3_d)>N)or(len(M_T_3_d)==N):
bb_exit_list_3=M_T_3_d[:N]
bb_revenue_3=theoretical_revenue_3_bb[:N]
else:
bb_exit_list_3=M_T_3_d
bb_revenue_3=theoretical_revenue_3_bb
#bb_bids_identification_for_the_3_delta()
###_________________BB BIDS IDENTIFICATION____________#####
###########################################################
###########################################################
###____________________BUSINESS CHECK 1_________________###
def business_existance_check_for_the_1_delta_bb():
b_existance_1_bb=[]
b_existance_1_bb=bb_exit_list_1[:]
for l in range(len(b_existance_1_bb)):
if b_existance_1_bb[l]>delta[1]:
exists_1_bb.append(b_existance_1_bb[l])
#if exists_1_bb==[]:
#print('No bids from the previous time!')
#print(exists_1,enter_time_1)
#business_existance_check_for_the_1_delta_bb()
###____________________BUSINESS CHECK 1_________________###
###########################################################
64
###########################################################
###__________________FORMING NEW LIST 2_________________###
def forming_new_list_for_delta_2_bb(N):
new_list_2_exit_bb=[]
new_list_2_exit_bb=exists_1_bb[:]
if len(new_list_2_exit_bb)<=N:
for h in range (len(bb_exit_list_2)):
new_list_2_exit_bb.append(bb_exit_list_2[h])
whole_revenue_bb.append(bb_revenue_2[h])
#print(new_list_2_enter,new_list_2_exit)
#forming_new_list_for_delta_2()
###__________________FORMING NEW LIST 2_________________###
###########################################################
###########################################################
###____________________BUSINESS CHECK 2_________________###
def business_existance_check_for_the_2_delta_bb():
b_existance_2_bb=[]
b_existance_2_bb=bb_exit_list_2[:]
for l in range(len(b_existance_2_bb)):
if b_existance_2_bb[l]>delta[2]:
exists_2_bb.append(b_existance_2_bb[l])
#if exists_2_bb==[]:
#print('No bids from the previous time!')
#print(exists_2,enter_time_2)
#business_existance_check_for_the_2_delta_bb()
###____________________BUSINESS CHECK 2_________________###
###########################################################
###########################################################
###__________________FORMING NEW LIST 3_________________###
def forming_new_list_for_delta_3_bb(N):
new_list_3_exit_bb=[]
new_list_3_exit_bb=exists_2_bb[:]
if len(new_list_3_exit_bb)<=N:
for h in range (len(bb_exit_list_3)):
new_list_3_exit_bb.append(bb_exit_list_3[h])
whole_revenue_bb.append(bb_revenue_3[h])
#print(new_list_3_enter,new_list_3_exit)
65
#forming_new_list_for_delta_3()
###__________________FORMING NEW LIST 3_________________###
###########################################################
###______________WHOLE REVENUE CALCULATING______________###
def whole_revenue_calculating_bb():
global s_bb
s_bb=0
for k in range(len(whole_revenue_bb)):
s_bb+=whole_revenue_bb[k]
#print (s_bb)
#whole_revenue_calculating()
###______________WHOLE REVENUE CALCULATING______________###
def revenue_matrix_calculating():
global M
global m_revenue_array_n_fcfs
global m_revenue_array_n_bb
M=number_of_tries
m_revenue_array_n_fcfs = np.zeros((len(N_infinity_list),M))
m_revenue_array_n_bb = np.zeros((len(N_infinity_list),M))
for m in range (0,M):
system_identifying()
program_completing_fcfs()
program_completing_bb()
for n in range (0,len(N_infinity_list)):
m_revenue_array_n_fcfs[n][m]=revenue_array_n_fcfs[n]
m_revenue_array_n_bb[n][m]=revenue_array_n_bb[n]
def average_revenue_calculating():
global r_aver_fcfs
global r_aver_bb
r_aver_fcfs=np.zeros(len(N_infinity_list))
r_aver_bb=np.zeros(len(N_infinity_list))
for n in range (0,len(N_infinity_list)):
r_aver_fcfs[n]=sum(m_revenue_array_n_fcfs[n])/M
r_aver_bb[n]=sum(m_revenue_array_n_bb[n])/M
#print(r_aver_fcfs)
#print(r_aver_bb)
def av_revenue_plotting():
plt.figure(figsize=(7, 7))
plt.xlabel('Количество слайсов, N', color='gray',fontsize = 16)
plt.ylabel('Ср доход поставщика инфраструктуры, R',color='gray',fontsize = 16)
66
plt.grid(True)
plt.scatter(N_infinity_list,r_aver_fcfs, s=15, c="b", marker="D", linewidths=2,
edgecolors="b")
plt.plot(N_infinity_list,r_aver_fcfs,'b',label="FCFS")
plt.scatter(N_infinity_list,r_aver_bb, s=15, c="g", marker="D", linewidths=2,
edgecolors="g")
plt.plot(N_infinity_list,r_aver_bb,'g',label="BB")
plt.xlim([0, N_for_infinity_list+1])
plt.ylim([0, 5000])
plt.xticks(np.arange(0, len(N_infinity_list)+1, 10))
plt.yticks(np.arange(0, 5000,250))
plt.legend()
plt.show()
for lam in (lam_list):
print("lambda=",lam)
del delta_fcfs[:]
del delta_bb[:]
revenue_matrix_calculating()
average_revenue_calculating()
av_revenue_plotting()
def delta_r_plotting():
plt.figure(figsize=(7, 7))
plt.xlabel('Интенсивность поступления заявок, $\lambda$', color='gray',fontsize =
16)
plt.ylabel('Упущенный доход поставщика инфраструктуры, R',color='gray',fontsize
= 16)
plt.grid(True)
plt.scatter(lam_list,delta_fcfs, s=15, c="b", marker="D", linewidths=2, edgecolors="b")
plt.plot(lam_list,delta_fcfs,'b',label="FCFS")
plt.scatter(lam_list,delta_bb, s=15, c="g", marker="D", linewidths=2, edgecolors="g")
plt.plot(lam_list,delta_bb,'g',label="BB")
plt.xlim([0, lam_max])
plt.ylim([0, 2000])
plt.xticks(np.arange(0, lam_max, 5))
plt.yticks(np.arange(0, 2000,100))
plt.legend()
plt.show()
del infinity_r_fcfs[:]
del infinity_r_bb[:]
del delta_fcfs[:]
67
del delta_bb[:]
N_part=5#CAN BE CHANGED
for lam in (lam_list):
revenue_matrix_calculating()
average_revenue_calculating()
infinity_r_fcfs.append(r_aver_fcfs[N_for_infinity_list-1])
infinity_r_bb.append(r_aver_bb[N_for_infinity_list-1])
for i in range(len(infinity_r_fcfs)):
delta_fcfs.append(infinity_r_fcfs[i]-r_aver_fcfs[N_part])
delta_bb.append(infinity_r_bb[i]-r_aver_bb[N_part])
delta_r_plotting()
68
Приложение 3. Грамота за лучший доклад секции
ГРАМОТА ЗА ЛУЧШИЙ ДОКЛАД
XI Всероссийской конференции
(с международным участием)
«Информационно-телекоммуникационные
технологии и математическое моделирование
высокотехнологичных систем»
19 – 23 апреля 2021 года
в секции Теория телетрафика и ее применения
вручается
Любови Олеговне Лапшенковой
за доклад
Любовь Олеговна Лапшенкова, Фаина Александровна Москалева, Юлия Васильевна
Гайдамака. Сравнение доходов поставщика инфраструктуры для двух политик доступа
при нарезке радиоресурсов сети 5G
Председатель программного комитета,
д.т.н., профессор
К.Е. Самуйлов
69
Отзывы:
Авторизуйтесь, чтобы оставить отзыв