Triple Play Service Calculator

Triple Play Service Calculator
Triple Play Service Calculator – это приложение для расчёта зависимостей вероятности
блокировки телефонных звонков и среднего времени пребывания в системе заявок на
просмотр видео и передачу данных. Оно состоит из GPSS World проекта (файл
GPPSProject.gps), в котором содержатся функции для выполнения модели СМО и сама модель,
и из динамической библиотеки (файл \dll\GPSSLibrary.dll), которая требуется для задания
параметров исполнения модели и для вывода полученных результатов. Пользователь
выбирает тип результирующего графика, затем вводит параметры системы и запускает
моделирование. В результате выводится график зависимости от нагрузки выбранного типа:
o вероятности блокировки для голосовых заявок (Blocking probability of voice requests);
o среднего времени пребывания в системе для видео заявок (Average stay time of video
requests);
o среднего времени пребывания в системе заявки на передачу данных (Average stay time
of data request).
Данное приложение позволяет смоделировать и получить статистические отчеты о процессах
в системе, построенной по принципу Triple Play. Эти отчеты могут быть представлены в виде
графика или таблицы. Triple Play Service Calculator будет полезен инженерам,
занимающимся разработкой и анализом Triple Play систем.
Далее рассмотрим более подробно систему Triple Play и входящие в нее сервисы.
1
Triple Play
Сегодня есть три основных массовых информационно-коммуникационно-развлекательных
сервиса: телефония, телевидение и интернет-коммуникации (условно - передача данных). В
прошлом они были разделены технологически и организационно: каждый базировался на
собственной инфраструктуре и разные услуги предоставляли, соответственно, разные
операторы. Для пользователя это выглядело как телефонный провод, телевизионный кабель и
«интернетный» провод или розетка. Сегодня же оператор мультисервисной сети, который
обеспечивает своим абонентам широкополосное IР-подключение (со скоростью не менее
нескольких мегабит в секунду), способен все три наиболее массовых и привычных сервиса
предоставлять одновременно через IР-канал. Этот способ предоставления услуг получил
название Triple Play.
Оператор такой мультисервисной сети не просто воспроизводит старые услуги на новой
технологической базе, но и делает их более интересными, качественно иными и обязательно
расширяет этот список новыми услугами, которые отсутствовали в традиционных сетях.
Например, наряду с телепрограммами (видео) в IР- сети можно вещать и радиопрограммы
(аудио), причем с любым качеством, вплоть до многоканального Dolby Stereo Surround 5.1.
Сегодня в IР-сети доступны и весьма популярны сетевые компьютерные игры, web-чаты,
всевозможные интернет-пейджеры (типа Skype и ICQ).
Технологически используемые IР-каналы могут быть разными, главное, чтобы они
обеспечивали нужную полосу пропускания и были управляемыми с точки зрения качества:
поддерживали приоритизацию различных типов трафика, различные уровни обслуживания.
Исследование систем такого рода относится к задачам, решаемым в одном из разделов
теории телетрафика, называемом теорией систем массового обслуживания (СМО). Одним из
способов исследования является построение имитационных моделей, которые позволяют
получить статистические отчеты о процессах в системе. Для программирования имитационных
моделей применяются особые системы моделирования, основанные на использовании
специализированных языков описания процессов в СМО. Одним из наиболее удобных и
эффективных из таких специализированных языков является GPSS (General Purpose Simulation
System). В приложении он используется для реализации имитационной модели СМО Triple
Play.
2
Модель
В данной системе пропускная способность канала распределяется между голосовыми (voice),
видео (video) заявками и заявками данных (data). Под голосовыми заявками подразумеваются
запросы на установление телефонной связи. Видео заявки представляют собой запросы на
просмотр телевидения (IPTV) или конкретных видеоматериалов (VOD). Заявками на передачу
данных считаются пакеты, которые передаются во время Интернет-соединения.
Для обработки трафика каждого типа выделяются заданные пользователем части ресурса.
В приложении и далее в описании часть ресурса, выделенную под тот или иной тип трафика,
будем называть набором серверов, выделенных для обработки этого вида трафика.
Принцип распределения серверов для обработки заявок следующий: для каждого типа
трафика выделяется определенное число серверов. Голосовые заявки блокируются в случае,
если все предоставленные для их обработки сервера заняты обработкой голосовых заявок,
пришедших ранее. Видео заявки в случае, если их сервера заняты, поступают в буфер
(очередь). Заявки типа «данные» при занятости всех предоставленных им серверов проверяют
на занятость сервера, выделенные для голосового и видео трафика. Если среди них есть
свободные, то заявка встает на обслуживание. Однако она будет вытеснена оттуда в случае
поступления голосовой или видео заявки, соответствующей типу занятого сервера, т.к.
последние имеют более высокий приоритет.
Транзакции (заявки) всех трех типов генерируются со средним интервалом между
поступлениями, распределенным по экспоненциальному закону, как наиболее
приближенному к реальному. Т.о., входной поток заявок описывается следующей
формулой:
1
F ( x)  e

xa
b
b
где b – среднеквадратичное отклонение,
a – математическое ожидание.
По этой же причине время обслуживания всех типов транзакций серверами
распределено также по экспоненциальному закону.
Каждому типу транзакций соответствуют свое среднее время обработки и средний интервал
между поступлениями заявок.
Среднее время обработки заявки сервером в модели задается переменными voice_x, video_x
и data_x. Для голосовых транзакций значение voice_x по умолчанию равно 98 секунд. Это
средняя продолжительность занятия аналоговой абонентской линии индивидуального
пользования в вечерний ЧНН (Час Наибольшей Нагрузки) при 6-значной нумерации согласно
документу РД 45.120-2000. В случае если проектируемая сеть не удовлетворяет данным
условиям для исходящей нагрузки, то значение voice_x следует искать в РД 45.120-2000.
Среднее значение времени обслуживания видео заявок по умолчанию равно 13620 секунд
(так как по данным TNS Gallup Media средний россиянин смотрит телевизор в день 227 минут
или 13620 секунд) и заявок данных равно 100 секунд (эта величина была получена в
результате статистических исследований сетей передачи данных – анализа трафика в
локальной сети, передачу данных через Интернет). Однако все эти параметры могут быть
заданы пользователем (см. рис 3, 4, 5).
3
Средний интервал между поступлениями заявок в модели соответствует переменным voice_t,
video_t и data_t. Значение этих параметров определяются по формуле t 
x
, где
0  k  
x – среднее время обработки заявки соответствующего типа сервером,
 0 – величина начальной нагрузки,

определяется по формуле:
 
end  0
N 1 ,
k – целое число, изменяющееся от 0 до N-1,
end - величина конечной нагрузки,
N – количество точек моделирования.
 
Значения величин x , 0 , end и N задаются пользователем. В зависимости от типа
результирующего графика изменяется значение нагрузки для одного вида трафика. Для
остальных типов такие параметры как
значение t при k  0 .
end и N не требуются, рассчитывается только одно
Константы и параметры
В модели используются следующие константы:
o MaxTranzToWrite, отвечающая за количество моделируемых транзакций.
o Num_of_DS, Num_of_VoS, Num_of_ViS, соответствующие количеству
выделенных для data, voice и video трафика.
серверов,
Для индикации состояния серверов (0 – свободен, 1 – занят обработкой голосовой заявки, 2 –
занят обработкой видео заявки, 3 – занят обработкой заявки данных) в модели создана
матрица Serv_Indication_Row. В ней одна строка, а количество столбцов соответствует
количеству серверов. При поступлении заявки на обработку и освобождении сервера матрица
обновляется.
Serv_Indication_Row
Nothing
Voice
Video
Data
MATRIX
EQU
EQU
EQU
EQU
,1,5
0
1
2
3
В модели параметром №1 заявки задается тип трафика: 1 – голос, 2 – видео, 3 – данные. Для
заявок на передачу данных также используется параметр residual_time для записи времени
дообслуживания.
Заявки на передачу данных
После того, как транзакция данных была сгенерирована, происходит проверка на наличие в
системе свободных серверов: вначале проверяются сервера, выделенные под данные. Если
среди них есть свободные, то заявка встает на обработку в найденный свободный сервер.
PTR3
ASSIGN
ASSIGN
GATE U
TEST L
ASSIGN
LOOP
Data_Serv_Quantity,Num_of_DS
Data_Serv_Num,(Num_of_VoS+Num_of_ViS+1)
((Num_of_VoS+Num_of_ViS+Num_of_DS)-P$Data_Serv_Quantity+1),to_serv3
P$Data_Serv_Num,(Num_of_VoS+Num_of_ViS+Num_of_DS),PTR4
Data_Serv_Num+,1
Data_Serv_Quantity,PTR3
4
Если нет, то аналогичным образом проверяются voice и video сервера. Если после проверки
всех серверов свободные найдены не были, то заявка поступает в очередь и ждет, пока какойнибудь сервер не освободится.
При обработке заявки происходит проверка значения параметра residual_time. Если оно
больше нуля, это значит, что заявка была вытеснена и время ее обработки принимается
равным residual_time. В противном случае время обработки рассчитывается по
экспоненциальному закону со средним, равным data_x.
to_serv3
add_op
rel_serv3
SEIZE
MSAVEVALUE
TEST E
DEPART
ADVANCE
TRANSFER
DEPART
ADVANCE
RELEASE
MSAVEVALUE
P$Data_Serv_Num
Serv_Indication_Row,1,P$Data_Serv_Num,Data
P$residual_time,0,add_op
P1
(EXPONENTIAL(1,0,V$data_x))
,rel_serv3
P1
P$residual_time
P$Data_Serv_Num
Serv_Indication_Row,1,P$Data_Serv_Num,Nothing
После окончания обработки заявка выводится из системы.
Голосовые заявки
После того, как голосовая транзакция была сгенерирована, проверяется наличие свободных
серверов для голосового трафика. Если такие сервера обнаружены, транзакция поступает на
обработку.
PTR1
ASSIGN
ASSIGN
GATE U
TEST L
ASSIGN
LOOP
Voice_Serv_Quantity,Num_of_VoS
Voice_Serv_Num,1
(Num_of_VoS-P$Voice_Serv_Quantity+1),to_serv1
P$Voice_Serv_Num,Num_of_VoS,check1
Voice_Serv_Num+,1
Voice_Serv_Quantity,PTR1
Если же все сервера оказываются занятыми, то происходит проверка на наличие серверов,
отведенных для голосового трафика, но занятых обработкой транзакции данных.
check1
PTR9
ASSIGN
ASSIGN
TEST E
TEST L
ASSIGN
LOOP
Voice_Serv_Quantity,Num_of_VoS
Voice_Serv_Num,1
MX$Serv_Indication_Row(1,P$Voice_Serv_Num),Voice,to_serv1
P$Voice_Serv_Num,Num_of_VoS,voice_end
Voice_Serv_Num+,1
Voice_Serv_Quantity,PTR9
Если сервер, удовлетворяющий этому условию, найден, то находящаяся на обработке dataзаявка вытесняется в очередь и голосовая транзакция поступает на обработку в
освободившийся сервер. В противном случае голосовая заявка блокируется.
to_serv1
rel_serv11
PREEMPT
TEST E
MSAVEVALUE
ADVANCE
RELEASE
MSAVEVALUE
P$Voice_Serv_Num,PR,preempted_voice,residual_time,RE
P1,1,for_data
Serv_Indication_Row,1,P$Voice_Serv_Num,Voice
(EXPONENTIAL(1,0,V$voice_x))
P$Voice_Serv_Num
Serv_Indication_Row,1,P$Voice_Serv_Num,Nothing
Видео заявки
Поведение видео заявок аналогично поведению голосовых транзакций за исключением того,
что при отсутствии свободных или занятых данными видео серверов заявка не блокируется, а
поступает в очередь.
5
Запись в файл
Полученная в результате моделирования статистика записывается во временный файл
“data.$$$” в формате:
data
общая нагрузка для данных
среднее время пребывания заявки типа «данные» в системе
voice
общая голосовая нагрузка
среднее значение вероятности блокировки голосовой заявки или No voice transactions в
случае отсутствия голосовых заявок
video
общая нагрузка для видео
среднее время пребывания видео заявки в системе
Этот файл используется при построении графика и удаляется при закрытии приложения.
Ограничения


Результаты, полученные для случая полной загруженности серверов (нагрузка на каждый
сервер 100%), могут быть некорректными в силу пуассоновского входного потока и
экспоненциального распределения времени обработки.
При вводе The average stay time (рис. 3, 4, 5) обратите внимание на то, что единицы
измерения времени для всех типов трафика должны быть едиными (если для голосовых
заявок average stay time дано в секундах, то и для видео заявок и заявок данных и оно тоже
должно быть проставлено в секундах). Тогда в полученных результатах моделирования 1 time
slot будет равен используемой при вводе average stay time единице измерения (в примере, 1
секунде).
Блок-схема
Ниже представлена блок-схема модели (рис. 1).
Рис. 1.
6
Установка и запуск приложения
1. Распакуйте содержимое архива (GPPSProject.gps и \dll\GPSSLibrary.dll) в одну директорию,
путь до которой содержит только латинские буквы, например, C:\TriplePlayCalculator.
2. Откройте файл GPPSProject.gps с помощью GPSS World:
Меню File > Open…
3. Оттранслируйте проект, для этого запустите команду из меню
Command > Create Simulation.
4. Запустить проект на выполнение командой CONDUCT ExecProc()
Меню Command > CONDUCT.
Описание работы приложения
Рис. 2.

В появившемся диалоговом окне (рис. 2) сначала требуется задать вид зависимости, график
которой будет построен по результатам моделирования (Select output type).
Можно выбрать:
o Вероятность блокировки голосовых заявок (Blocking probability of voice requests);
o Среднее время пребывания в системе заявок на просмотр видео (Average stay time of video
requests);
o Среднее время пребывания в системе заявок на передачу данных (Average stay time of data
request).
Затем указать количество транзакций, которое пройдёт через систему за один цикл
моделирования (The number of generated transactions). Далее нажать кнопку Next.
7
Рис. 3.
 В данном диалоговом окне (рис. 3) задаются параметры голосовых заявок (Set Voice requests
parameters):
o Величина нагрузки для общего числа серверов, обрабатывающих голосовые заявки (The
load, start value, %), т.е. если задаётся 2 сервера, то максимальная величина нагрузки
может быть 200%. Если бы тип результирующего графика был выбран «вероятность
блокировки голосовых заявок», то значение в этом поле имело бы смысл начальной
величины нагрузки для процесса моделирования, и следующее поле «The load, end value,
%» было бы доступно для редактирования и обозначало бы конечную величину нагрузки.
o Величина среднего времени нахождения заявок в сервере на обработке (The average stay
time).
o Количество серверов для обработки голосовых заявок (The number of servers).
o Количество точек для построения графика (The number of points). Если бы тип
результирующего графика был выбран «вероятность блокировки голосовых заявок», то это
поле было бы активным, а в данном случае, оно недоступно для редактирования.
Далее нажимаете кнопку Next.
Рис. 4.

В данном диалоговом окне (рис.4) задаются параметры видео заявок (Set Video requests
parameters), такие как:
o Величина начальной нагрузки для общего числа серверов, обрабатывающих видео заявки
(The load, start value, %), т.е. если задаётся 100 серверов, то максимальная величина
8
начальной нагрузки может быть 10000%. Именно с этого значения будет начинаться
моделирование потока видео-заявок.
o Величина конечной нагрузки для процесса моделирования (The load, end value, %), при
заданных 100 серверах максимальная величина начальной нагрузки может быть 10000%,
но нужно учесть условие, что величина начальной нагрузки должна быть меньше
конечной.
o Величина среднего времени нахождения заявок в сервере на обработке (The average stay
time).
o Количество серверов для обработки видео заявок (The number of servers).
o Количество точек для построения графика (The number of points), оно должно быть не
меньше двух, т.к. результирующий график строится минимум по двум точкам.
Далее нажимаете кнопку Next.
Рис. 5.
 В данном диалоговом окне (рис. 5) задаются параметры заявок данных (Set Data requests
parameters):
o Величину нагрузки для общего числа серверов, обрабатывающих заявки данных (The load,
start value, %), т.е. если задаётся 1 сервер, то максимальная величина нагрузки может быть
100%. Если бы тип результирующего графика был выбран «среднее время пребывания в
системе заявки на передачу данных», то значение в этом поле имело бы смысл начальной
величины нагрузки для процесса моделирования, и следующее поле «The load, end value,
%» было бы доступно для редактирования и обозначало бы конечную величину нагрузки.
o Величину среднего времени нахождения заявки в сервере на обработке (The average stay
time).
o Количество серверов для обработки заявок данных (The number of servers).
o Количество точек для построения графика (The number of points). Если бы тип
результирующего графика был выбран «среднее время пребывания в системе заявки на
передачу данных», то это поле было бы активным, а в данном случае, оно недоступно для
редактирования.
Далее нажимаете кнопку Next.
9
Рис. 6.
В данном окне (рис. 6) можно проверить введённые ранее настройки, и вернуться назад для
их редактирования путём нажатия на кнопку Back. И если все настройки соответствуют
требуемым, то можно начать моделирование нажатием кнопки Calculate.
Во время моделирования будет отображаться окно с информацией о текущем прогрессе
операции.
По окончании процесса моделирования появится окно с итоговым графиком и текстовой
информацией (рис. 7).
Рис. 7
На графике строится указанная в первом пункте зависимость (в данном случае это
зависимость среднего времени пребывания в системе заявки на просмотр видео от величины
поступающей нагрузки – T(Ro), T измеряется в тайм-слотах, нагрузка в процентах).
10
Справа в блоке текстовой информации находятся значения величин нагрузки и
соответствующих искомых величин (для голосовых заявок это вероятность блокировки – Pb,
для заявок видео и данных – это среднее время нахождения в системе – T). Для зависимости,
график которой построен, выводятся все значения, использованные для построения (в случае
видео трафика, который представлен на рис. 7, это зависимость среднего времени
пребывания в системе заявки на просмотр видео от величины поступающей нагрузки). Для
остальных типов трафика выводятся средние значения искомых величин, т.к. нагрузка этих
видов трафика остаётся постоянной в процессе моделирования (в данном случае для заявок
данных). Если определённый вид трафика не создаёт нагрузки, то выводится
соответствующая информация об этом (в данном случае для заявок голоса «No Voice traffic»).
Полученные результаты можно сохранить в виде CSV-файла, по формату совместимого с
Excel. Для этого нужно нажать на кнопку «Save results» и указать в открывшемся окне
сохранения файла желаемое имя. По-умолчанию, в качестве имени файла предлагается
текущая дата в формате ГГГГ-ММ-ддTчч-мм-сс. Сохранённый файл содержит отображаемую в
правом текстовом блоке информацию: величины нагрузки и соответствующие искомые
величины для голосовых, видео заявок и заявок данных, разделённые знаками «;».
Известные проблемы

При преждевременном завершении эксперимента, которое может произойти, если во время
его работы выполнить команду HALT (меню GPSS World: Command > HALT), на экране
останется незакрытым диалоговое окно с информацией о текущем состоянии симуляции. Это
связано с тем, что данное окно обрабатывается программой отдельно от симуляции, а так как
GPSS World не имеет средств для обработки события HALT, то его нельзя закрыть
автоматически. На проведение последующих экспериментов присутствие на экране этого
окна не оказывает никакого влияния. Убрать его можно закрытием окон проекта (заголовок
GPSSProject.gps) и журнала симуляции (заголовок GPSSProject.#.sim – JOURNAL, где # –
порядковый номер симуляции).
Сведения об авторах



Гусев Д.А. – студент 4 курса Нижегородского Государственного Технического университета
(НГТУ) Института Радиоэлектроники и Информационных Технологий (ИРИТ), специальность
Сети Связи и Системы Коммутации (ССК). В процессе работы над данным проектом занимался
разработкой интерфейсной части программы, её взаимодействием с GPSS World и
интеграцией модели СМО с исполняемым кодом эксперимента.
Кувшинова Н.В. – студентка 4 курса Нижегородского Государственного Технического
университета (НГТУ) Института Радиоэлектроники и Информационных Технологий (ИРИТ),
специальность Сети Связи и Системы Коммутации (ССК). В процессе работы над данным
проектом занималась разработкой части модели СМО, отвечающей за обработку заявок
данных.
Ивашкина М.Е. – студентка 4 курса Нижегородского Государственного Технического
университета (НГТУ) Института Радиоэлектроники и Информационных Технологий (ИРИТ),
специальность Сети Связи и Системы Коммутации (ССК). В процессе работы над данным
проектом занималась разработкой части модели СМО, отвечающей за обработку голосовых и
видео заявок.
11