Разработка бизнес-требований к системе обработки заказов на подключение услуг IPTV

Мероприятия связанные с процессом интеграции различаются по степени сложности. Так, интеграция с видео серверами протекает легче, нежели с приставками. Меньше всего усилий требуется для интеграции с головной станцией, т. к. задачей Middleware в этом случае является передача приставке информации о вещаемом потоке видео. Самая трудоемкая - отладка с системой OSS/BSS, потому что интеграция происходит на фоне уже существующей системой оператора, имеющей свою специфику. Процесс интеграции каждого из компонентов с Middleware занимает от двух-трех недель до нескольких месяцев: все зависит от сложности механизма отладки. Преимуществом любого Мiddleware является наличие уже готовых интерфейсов для работы с продуктами любых производителей.

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

Доступ к услугам оператора IPTV возможен не только при помощи приставки и телевизора. Часто в состав Middleware входит еще и клиент PC, что позволяет просматривать видео на компьютере. За расшифровку в данном случае будет отвечать плеер, разработанный производителем CAS/DRM

Основной ценностью каждого Middleware являются услуги, которыми данное программное обеспечение управляет. Такие услуги как видео по запросу или виртуальный видеомагнитофон считаются первым шагом в мир настоящего интерактивного ТВ, которое способно предложить пользователям нереализованные ранее возможности. И базой для всего этого является Middleware - единая платформа, на основе которой возможно эффективное предоставление услуг. Учитывая открытую структуру такого решения, работа с Middleware позволяет оперативно расширять спектр услуг IP-телевидения и масштабировать все компоненты его структуры.

3.5 Абонентское устройство

Абонентское устройство (Set-Top Box или STB) выполняет функцию связующего звена между двумя системами: формирования и доставки контента. STB-устройство представляет собой миникомпьютер с собственной операционной системой и интегрированным WEB-браузером. На Рисунок схематически изображено место, занимаемое абонентским устройством в системе IPTV.

Рисунок 8: STB в системе IPTV

Абонентские устройства отличаются открытой архитектурой и комплектацией специализированными чипсетами (большими интегральными схемами или БИС). Все STB поставляются наряду с соответствующим ПО. Последнее является OS (operation system) для программ высокого уровня, реализующих процедуры приема и обработки сигналов цифрового ТВ.

Функции STB:

ь Отвечает за демультиплексирование цифрового потока, который поступает на STB;

ь Обеспечивает расшифровку цифрового сигнала формата MPEG-2;

ь Участвует в формировании телевизионного сигнала, который подается на ТВ приемник абонента;

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

Основной компонент STB - RISC-процессор. Эта составляющая делает абонентское устройство похожим на PC, ведь в его состав входят все основные элементы персонального компьютера: ЦП, ПЗУ, ОЗУ, OS и шина данных. На данный момент все специализированные большие интегральные схемы абонентских STB могут использоваться не только для приема сигналов цифрового ТВ-вещания, но и одновременно выполнять целый ряд функций, которые в полной мере реализуют глобальный подход к цифровому IP-телевидению.

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

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

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

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

В состав STB также может входить встроенный накопитель информации (HDD объемом не менее 15 ГБ). Дисковый накопитель сохраняет для последующего воспроизведения видео контент или любую другую дополнительную информацию, которая была получена в составе цифрового потока посредством канала-контейнера. Это необходимо для реализации услуги персонального видео-рекордера (PVR).

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

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

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

3.6 Система распределения контента

Построение услуг IPTV требует комплексной оценки всех элементов архитектуры сети. При этом сосредотачивать разные типы контента (аудио и видео материалы) в какой-то одной точке обмена неэффективно - это вызывает повышенную загрузку сети и нерациональное использование всех элементов системы. Для того, чтобы предоставлять по-настоящему качественные услуги большой аудитории пользователей используют систему распределения контента (рисунок 9). Грамотное распределение видео серверов в сети оператора IPTV позволяет:

ь минимизировать загрузку сетевой инфраструктуры поставщика услуг IPTV;

ь равномерно распределить нагрузки на все видео серверы.

.

Рисунок 9: схема работы системы распределения контента

Работа системы распределения контента строится следующим образом:

ь Сначала от Middleware приходит запрос абонентов на доступ к определенному контенту.

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

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

ь В случае, если на самом разгруженном и близком к абоненту сервере нет запрашиваемого контента, система перенаправляет абонента на другой сервер.

3.7 Видео сервер

Видео сервер представляет собой совокупность (массив) дисковых накопителей значительной емкости с установленным для работы в системе IPTV специальным программным обеспечением. Основным назначением видео серверов является вещание видео контента и реализация таких, требующих больших объемов памяти, услуг, как PVR, NVoD и VoD. На рисунке 10 схематически изображено место видео серверов в системе IP-телевидения.

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



Рисунок 10: видео серверы в архитектуре IPTV

Требования к аппаратному обеспечению в большинстве своем такие же, как и для серверов с большими объемами трафика. Т.е видео сервер должен обладать большим объемом оперативной памяти, несколькими процессорами и оптимизированной дисковой подсистемой, которая предназначена для передачи файлов. Например, такой сервер может быть оснащен RAID-контроллерами, которые имеют собственные процессоры ввода-вывода. Это могут быть процессоры i960 от Intel. Наличие драйверов, которые написаны в соответствии с Intelligent I/O, I2O, стандартом интеллектуального ввода-вывода, позволяет контроллерам повысить производительность всего сервера на 65% и более. Самые загруженные видео серверы часто включаются в Storage Area Network (сеть устройств хранения). Основным отличием между видео сервером и обычным сервером является разница в программном обеспечении. Так, основным предназначением стандартных HTTP или FTP серверов является обеспечение надежной загрузки. При этом используется протокол TCP, который нумерует каждый пакет так, что в результате получателем могут быть правильно восстановлены все данные. Протокол TCP гарантирует, что в конце концов адресат получит все пакеты. Даже если какой-то из них потеряется, идет повторный запрос на недостающие пакеты. Когда сеть становится близка к насыщению, TCP применяет специальный механизм контроля потока, для снижения нагрузки на сервер через ограничение скорости соединения.

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

Именно поэтому, большая часть крупнейших производителей видео серверов отказывается от применения HTTP и TCP. Ставка при этом делается на протокол UDP, использующийся в качестве базового для транспорта пакетов с потоковыми данными. При этом UDP не гарантирует доставку всех пакетов. Основной его задачей является именно быстрота доставки потока. Отсюда, собственно, потоковое видео и получило свое название.

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

Рассмотрим работу видео серверов на примере двух поколений продуктов RealNetworks. Версия до RealServer 5.0, первое поколение, в котором RealPlayer являлся клиентским программным обеспечением, инициирующим связь при помощи установления соединения по протоколу TCP. Сначала такое соединение служит только для передачи на RealPlayer данных о потоке (текстовой информации о названии, продолжительности, авторских правах на контент). После установки первоначального TCP-соединения RealServer первого поколения создает канал по UDP, который и задействуется в процессе доставки медиаконтента плейеру.

В RealSystem первого поколения соединение TCP могло использоваться плейером для передачи команд RealServer, используя собственный протокол PNM - Progressive Networks Media, когда появились функции начала и остановки воспроизведения. Вторым поколением RealNetworks стала RealSystem G2. Она опиралась, в большей степени, на стандартные протоколы и основным ее предназначением было улучшение взаимодействия между плейером и сервером. RealSystem G2 позволяет регулировать ширину потока, если случается перегрузка сети и требуется меньшая пропускная способность информационного наполнения.

Взаимодействие с RealSystem G2 начинается так же как и в случае с первым поколением, т.е с установления полнодуплексного соединения по протоколу TCP. Часто это осуществляется через порт 554. Но в случае с G2 используется потоковый протокол Real-Time Streaming Protocol, RTSP, т.е протокол реального времени предназначенный для управления прикладного уровня в RFC 2326. Так, с помощью RTSP реализуется большая часть поиска по времени в объеме видео контента. Им же контролируется доставка содержимого при рассылке по множеству адресов.

Как и в случае с RealSystem первого поколения весь контент доставляется через канал UDP плейеру, но только по протоколу передачи в режиме реального времени или RTP-протоколу (Real-Time Transfer Protocol). Этот протокол является также стандартом ITU (H.225.0) и предложением по стандарту IETF (RFC 1889). Real-Time Transfer Protocol предусматривает порядковую нумерацию, отметки о времени и многие другие механизмы, обеспечивающие правильное упорядочивание поступающих пакетов данных. При этом заголовки могут содержать определяющий формат полезной нагрузки и схемы компрессии-кодинга, идентификаторы типа. Одни типы полезной нагрузки прописаны в RFC 1890, другие могут быть введены путем спецификации расширяемого формата полезной нагрузки.

Кроме использования соединений RTSP и TCP, сервером RealServer второго поколения используется еще и третий полнодуплексный канал UDP, предназначенный для протокола управления трафиком реального времени (Real-Time Control Protocol, RTCP). Его основным предназначением является обеспечение обратной связи, касательно качества доставки пакетных данных по Real-Time Transfer Protocol. RTCP разработан с учетом того, чтобы управляющий трафик никогда не превышал 5% общего объема трафика во время всего сеанса. Именно благодаря этому, функция изменения ширины потока стала возможной без реализации неэффективного TCP.

Превалирующим большинством всех коммерческих продуктов для видео серверов сегодня используются RTCP, RTP и RTSP, или, в крайнем случае, UDP. Другим важным отличием для видео серверов является наличие или отсутствие поддержки трансляции с помощью многоадресной рассылки.

Еще одной важной функцией современных видео серверов является поддержка управления контентом. Для этого может быть создана специфическая среда, с целью упрощения кодинга, отслеживания и размещения новых данных или комплексная система, включающая подсистему поддержки платных просмотров, идентификацию плейеров и автоматической вставки рекламных блоков. Зачастую видео серверы взаимодействуют с БД, такими как Microsoft SQL Server, что позволяет осуществлять автоматическое обновление всех узлов.

Программное обеспечение, установленное на видео серверах, реализует unicast-трансляцию, когда речь идет об услуге VoD и multicast-трансляцию видео контента для услуги NVoD. Видео сервер позволяет производить перехват и запись multicast-потоков, то есть осуществлять услугу PVR. Для видео серверов в архитектуре IPTV поставляется следующий набор программных пакетов:

ь ПО для сервиса VoD

В программном обеспечении реализована поддержка протокола RTSP, посредством которого запрашивается видео поток с абонентского STB и происходит управление самим потоком (перемотка, пауза, установка закладок). При этом такой сервер легко встраивается в разные сети. Среди множества поддерживаемых видео серверами форматов: HD Video, MPEG 2, MPEG 4.

ь ПО сервисов NVoD и SVoD

Видео сервер осуществляет постоянную рассылку видео потоков в IP сеть (multicast). Всю необходимую информацию о программах и каналах он получает из базы данных.

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

ь ПО для Timeshift TV

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

Когда абонент нажимает на кнопку Rew со своего пульта ДУ, он активирует сервис телевидения со сдвигом (Timeshift TV) и система запрашивает записанную телепередачу. Услуга видеомагнитофона реализуется таким же образом. Форматы, поддерживаемые ПО сервисов такие же, как и для сервиса VoD.

ь ПО для NPVR

NPVR (Network Personal Video Recorder) позволяет записывать телевизионную программу вне зависимости от того включено абонентское устройство или нет. Абонент помечает интересующую его программу на запись и на видео сервере происходит запись трансляции со спутника. После этого запись появляется в телевизионном архиве абонента, что позволяет просматривать ее в любое удобное время.

4. Постановка требований к системе обработки заказов

4.1 Иерархическая декомпозиция бизнес-процессов

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

Рисунок 11: декомпозиция блока операционной деятельности

Порядок выполнения каждого отдельного блока в дальнейшем будет описан с помощью блок-схем. На приведённом рисунке декомпозиция произведена только для группы процессов обработки заказов. Два оставшихся процесса, а именно "Конфигурация и активация услуг" и "Обеспечение услуги ресурсами", будут подвергнуты декомпозиции на отдельных рисунках. Это позволит избежать лишнего усложнения при прочтении работы. Третий уровень декомпозиции в данном случае имеет пятизначную нумерацию в соответствии со стандартами TeleManagement Froum [4].



Рисунок 12: декомпозиция блока "Конфигурация и активация услуг"

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

Рисунок 13: декомпозиция блока "Обеспечение услуги ресурсами"

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

Стоит заметить, что вышеописанные процессы второго уровня выполняются в том же порядке, в котором они были изображены:

1) Обработка заказов.

2) Конфигурация и активация услуг.

3) Обеспечение услуги ресурсами.

Потом снова начинается обработка заказов (заказ закрывается, например).

4.2 Описание потоковых бизнес-процессов

Блок-схемы в данном разделе показывают условия и последовательность выполнения процессов-элементов в ходе выполнения процесса-потока. В качестве процессов-элементов здесь используются процессы уровня 3 и 4 карты eTOM. Такая детализация оказывается полезна, если необходимо подчеркнуть использование в ходе выполнения процесса конкретной функциональности элемента:

Уровень 3

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

Следующим действием является закрытие заказа, а также оповещение клиента о его выполнении. На этом данный процесс-поток заканчивается.

"Отключение услуги" - рисунок 15. Процесс отключения услуги начинается закрытия заказа сервиса и высвобождения сервиса. После этого идёт закрытие заказа ресурса. Далее происходит завершение выполнения заказа, предоставление отчета по обработке заказа и его закрытие.



Рисунок 14: Подключение услуги

Рисунок 15: Отключение услуги

Уровень 4



Рисунок 16: Подключение - Определение выполнимости заказа

2.1.1.5.1.1 "Проверка адреса клиента" в качестве входных данных требует клиентский адрес. Цель процесса - удостовериться в том, что по этому адресу оператор может предоставить клиенту IPTV и услуги на его базе. Процесс проверки может производиться с использованием базы данных технического учёта оператора, откуда извлекается информация о коммутаторах доступа и зоне их обслуживания. Также проверку можно осуществлять с помощью технического специалиста, который сможет определить, есть ли по конкретному адресу необходимое для предоставления услуги оборудование оператора. Данная проверка имеет организационный характер, а не технический, т. е. проверяется, разрешено ли предоставление услуги по данному адресу.

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

Таблица 1: требования к сети ШПД

Параметр	Качество видеоизображения
	SD 576i (MPEG-2)	SD 576i (MPEG-4)	HD 720p (MPEG-2)	HD 720p (MPEG-4)
Минимальная полоса пропускания	4 Мбит/с	2 Мбит/с	14 Мбит/с	7 Мбит/с
Максимальная задержка	100 мс
Максимальный джиттер	50 мс
Технологии доступа	Ethernet10/100, ADSL Annex A, ADSL Annex B, SDSL, SHDSL, ADSL2+, VDSL, все DOCSIS, PON, Wi-Fi, WiMAX, LTE	Ethernet10/100, xDSL (кроме UDSL), DOCSIS (1, 2, 3), PON, Wi-Fi, WiMAX, LTE	Ethernet100, ADSL2+, VDSL, DOCSIS (1, 2, 3), PON, WiMAX, LTE	Ethernet10/100, ADSL Annex A, ADSL Annex B, SDSL, SHDSL, ADSL2+, VDSL, DOCSIS (1, 2, 3), PON, WiMAX, LTE

2.1.1.5.1.3 "Проверка сетевого оборудования от головной станции до клиента" основывается на данных о протоколах, которые будут обеспечивать реализацию заказа. Цель процесса - определить, поддерживают маршрутизаторы необходимые для предоставления услуг IPTV протоколы. Чтобы передавать потоковое видео в режиме реального времени, все устройства от головной станции до клиента должны поддерживать протокол RTP. Эти потоки передаются в режиме multicast, а чтобы управлять мультикаст-потоками, обязательна поддержка протокола IGMP маршрутизаторами. Протоколы RTSP и HTTP не являются обязательными, но их поддержка маршрутизаторами потребуется для реализации дополнительных услуг (HTTP - интерактивные сервисы, его должен поддерживать STB; RTSP - видео по запросу). Эта процедура может выполняться как автоматически (проверка в базе данных технического учёта), так и с помощью технического персонала оператора.



Рисунок 17: Подключение - Выделение и инсталляция ресурса

2.1.3.2.1.3 "Инсталляция ресурса (STB)" выполняется с учётом требований, предъявляемых клиентом, таких как наличие\отсутствие определённых функций у приставки, способ (самостоятельно\с помощью специалиста) и время инсталляции, выполнение работ по протяжке кабелей в квартире и т.д. Цель процесса - доставка, монтаж и подготовка к работе STB. Стоит упомянуть, что STB может входить в состав продаваемого оператором связи продукта или покупаться клиентом отдельно.

Рисунок 18: Подключение - Внедрение, конфигурация и активация сервиса

2.1.2.2.4.2 "Конфигурация услуги IPTV" состоит в создании записи в базе данных технического учёта и вызове процессов конфигурации ресурсов (с передачей процессам необходимых данных). Под ресурсами подразумеваются маршрутизаторы и STB. Запись содержит информацию о том, что данному клиенту теперь будет предоставляться новый сервис. Цель процесса - сделать все необходимые настройки сети и платформ оператора для предоставления услуги IPTV конкретному клиенту. Для услуги телевидения такой информацией является количество телеканалов, стоимость, наличие\отсутствие рекламы, разрешение\запрет на запись телепрограмм, разрешение\запрет постановки на паузу и т.д.

2.1.2.2.4.3 "Активация услуги IPTV " завершает то, что было сделано в процессе конфигурации. Цель процесса - отметить заказанную услугу как «предоставляется». Это важно, например, для выставления счета (когда услуга активирована - с того времени и берем деньги). Или если клиент уходит «в минус» мы не будем отключать ему услугу (все что сконфигурировали ранее), мы просто отметим ее как «приостановлена». Активация является завершающим шагом, в ходе которого производится установка в клиентской базе данных отметки о том, что услуга теперь находится в статусе «предоставлена».

Рисунок 19: Подключение - Конфигурация и активация ресурса

2.1.3.2.2.1 "Конфигурация сетевого оборудования" основывается на данных о том, какие функции предстоит выполнять этому оборудованию (например, функции ретрансляции multicast-потока). Цель процесса - осуществить необходимую настройку всего оборудования оператора, которое будет отвечать за предоставление новой услуги данному клиенту. А именно, нужно активировать поддержку протокола IGMP на тех маршрутизаторах, где она была по-умолчанию отключена, а также убрать для данного клиента ограничения по скорости загрузки в отношении мультикастного трафика от головной станции, если такие ограничения были предусмотрены клиентским тарифом на услугу передачи данных. Ограничения также убираются на маршрутизаторах.

2.1.3.2.2.2 "Конфигурация клиентского оборудования" выполняется в соответствии с данными о том, какие функции будет выполнять STB. А именно, включается поддержка кодека MPEG-4, просмотр шифрованных телеканалов, формирование плейлистов, только декодирование, либо декодирование и запись (имеется ввиду разрешение/запрет записи видео на HDD приставки). Цель - настройка приставки с целью обеспечения работы услуг IPTV. Эту операцию может производить как технический специалист оператора, так и сам клиент (в зависимости от используемых абонентских устройств и бизнес-модели оператора). Также этот процесс может быть автоматизирован с помощью использования протокола управления абонентским оборудованием через глобальную сеть по спецификации TR-069.

2.1.3.2.2.3 "Добавление записи в базу данных" происходит на основе информации, полученной от клиента. Эта информация включает в себя данные о том, какие услуги предоставляются клиенту. Цель процесса - внесение необходимой информации о клиенте в базу данных пользователей IPTV, чтобы впоследствии этой информацией можно было воспользоваться всем уполномоченным службам оператора. Главное, что к этой записи мы будем обращаться каждый раз, когда клиент будет включать свой STB, чтобы проверить, предоставлять ли ему вообще услуги и какие.

2.1.3.2.2.4 "Активация ресурса" в качестве входных данных ничего не получает. Цель процесса - закрепить изменения, произведённые во время конфигурации. Под ресурсом в данном случае понимается то оборудование, которое до этого было сконфигурировано. Скажем, у маршрутизаторов при выполнении активации произведённые изменения должны быть записаны в ПЗУ.

Рисунок 20: Подключение - Сквозное тестирование сервиса

2.1.2.2.5.1 "Тестирование пропускной способности" осуществляется с учётом требуемых значений полосы пропускания. Цель процесса - определить реальную пропускную способность до клиента. Требования зависят от объёма и качества передаваемой видео-информации.

2.1.2.2.5.3 "Тестирование конечной услуги" в качестве входных данных имеет информацию о завершении предыдущих этапов тестирования. Цель процесса заключается в определении субъективного восприятия видео-информации на стороне клиента. Для телевидения это означает наличие\отсутствие прерывистости, рассыпаемости картинки, а также определение качества звука. Осуществить подобную проверку можно путём снятия данных с пробника в сегменте сети, где расположен клиент.

Рисунок 21: Подключение - Тестирование ресурса

2.1.3.2.3.1 "Тестирование сетевого оборудования" выполняется на основе тех же данных, что и процесс 2.1.3.2.2.1 "Конфигурация сетевого оборудования". Цель процесса - определение того, правильно ли была выполнена конфигурация сетевого оборудования. Процесс тестирования заключается в поочерёдной проверке каждой функции, предусмотренной данной услугой.

2.1.3.2.3.2 "Тестирование клиентского оборудования" происходит на основе той же информации, которая требуется для процесса 2.1.3.2.2.2 " Добавление записи в базу данных". Цель этого тестирования - узнать, правильно ли была осуществлена конфигурация STB. Чтобы это проверить, необходимо воспользоваться всеми возможностями приставки, предусмотренными в данной услуге.

2.1.3.2.3.3 "Тестирование базы данных" осуществляется на основе информации, необходимой для выполнения процесса 2.1.3.2.2.3 "Конфигурация базы данных". Цель данного тестирования - это проверка соответствия записанной в базе информации и информации, полученной изначально. Например, ячейка базы данных с адресом клиента должна содержать ту же информацию, что и заявка клиента.

Рисунок 22: Модификация - Определение выполнимости заказа

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

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

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

Рисунок 23: Модификация - Выделение необходимых параметров сервиса для сервисов

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

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

2.1.2.2.4 "Модификация необходимого качества обслуживания" основывается на информации об уровне качества обслуживания, который требуется для предоставлению клиенту модифицированных услуг. Цель процесса - привести в соответствие качество обслуживания с требованиями клиента в этом отношении. Процесс предполагает, что клиент стал требовать больше (или наоборот меньше) качества к предоставляемой в данный момент услуге. К примеру, если у клиента подключена услуга телевидения и он хочет включить в пакет предоставляемых ему телеканалов HD-каналы, то результатом этого шага будет увеличение качества обслуживания.

Рисунок 24: Модификация - Выделение и инсталляция ресурса

2.1.3.2.1.1 "Модификация необходимой полосы пропускания" в качестве входных данных требует новое значение пропускной способности, которое затребовал клиент путём модификации соответствующих услуг. Цель процесса состоит в изменении зарезервированного количества бит\с, которые используются в данный момент для обеспечения этой услуги. Например, для HD-каналов полоса пропускания должна быть в несколько раз выше, чем для SD-каналов.

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

Рисунок 25 - Модификация - Внедрение, конфигурация и активация сервиса

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

2.1.2.2.4.3 "Активация модифицируемой услуги" выполняется при условии завершения конфигурации. Цель процесса - закрепить изменения, произведённые во время конфигурации. Активация является завершающим шагом, в ходе которого производится установка в клиентской базе данных отметки о том, что услуга модифицирована.



Рисунок 26: Модификация - Конфигурация и активация ресурса

2.1.3.2.2.1 "Конфигурация сетевого оборудования" основывается на данных о том, какие функции теперь предстоит выполнять этому оборудованию (например, функции ретрансляции multicast-потока). Цель процесса - осуществить необходимую перенастройку всего оборудования оператора, которое будет отвечать за предоставление модифицированной услуги данному клиенту.

2.1.3.2.2.2 "Конфигурация клиентского оборудования" выполняется в соответствии с данными о том, какие функции теперь будет выполнять STB (например, только декодирование, либо декодирование и запись). Цель - перенастройка приставки с целью обеспечения работы услуг IPTV. Эту операцию может производить как технический специалист оператора, так и сам клиент (в зависимости от используемых абонентских устройств и бизнес-модели оператора).

2.1.3.2.2.3 "Добавление записи в базу данных" происходит на основе информации, полученной от клиента (например, ФИО, список услуг, адрес и т.д.). Цель процесса - изменение необходимой информации о клиенте в базе данных, чтобы впоследствии этой информацией можно было воспользоваться любому оборудованию оператора, которому потребуются данные клиента, а также в случае необходимости техническим специалистам и всем уполномоченным службам оператора.

2.1.3.2.2.4 "Активация ресурса" в качестве входных данных получает информацию о завершении конфигурации. Цель процесса - закрепить изменения, произведённые во время конфигурации. До этого момента клиент является пользователем немодифицированной услуги, а после активации - уже модифицированной.

Рисунок 27: Модификация - Сквозное тестирование сервиса

2.1.2.2.5.1 "Тестирование пропускной способности" осуществляется с учётом требуемых значений полосы пропускания. Цель процесса - проверка выделенной величины бит\с на соответствие требованиям, которые предъявляются модифицированной услугой. Требования зависят от объёма и качества передаваемой видео-информации.

2.1.2.2.5.3 "Тестирование конечной услуги" в качестве входных данных имеет информацию о завершении предыдущих этапов тестирования. Цель процесса заключается в определении субъективного восприятия видео-информации на стороне клиента. Для телевидения это означает наличие\отсутствие прерывистости, рассыпаемости картинки, а также определение качества звука.

Рисунок 28: Модификация - Тестирование ресурса

2.1.3.2.3.1 "Тестирование сетевого оборудования" выполняется на основе тех же данных, что и процесс 2.1.3.2.2.1 "Конфигурация сетевого оборудования". Цель процесса - определение того, правильно ли была выполнена переконфигурация сетевого оборудования. Процесс тестирования заключается в поочерёдной проверке каждой функции, предусмотренной модифицированной услугой.

2.1.3.2.3.2 "Тестирование клиентского оборудования" происходит на основе той же информации, которая требуется для процесса 2.1.3.2.2.2 "Конфигурация клиентского оборудования". Цель этого тестирования - узнать, правильно ли была осуществлена переконфигурация STB. Чтобы это проверить, необходимо воспользоваться всеми возможностями приставки, предусмотренными в модифицированной услуге.

2.1.3.2.3.3 "Тестирование базы данных" осуществляется на основе информации, необходимой для выполнения процесса 2.1.3.2.2.3 "Конфигурация базы данных". Цель данного тестирования - это проверка соответствия перезаписанной в базе информации и информации, полученной от клиента в запросе на модификацию. Например, ячейка базы данных с адресом клиента должна содержать ту же информацию, что и запрос клиента.

Рисунок 29: Доп. услуга (VOD) - Определение выполнимости заказа

2.1.1.5.1.7 "Проверка загрузки сервера" производится с учётом данных о том, какова должна быть загрузка сервера для приемлемой скорости обработки заказа клиента. Цель процесса - это определение сервера с минимальной нагрузкой, который находится максимально близко к пользователю и одновременно содержит нужную абоненту информацию. Определив оптимальный вариант, система позволяет пользователю получить запрашиваемые данные с выбранного ею сервера. Процесс определения нужного сервера может быть осуществлён как путём прямого сравнения уровня загрузки различных серверов, так и по более сложным алгоритмам. Решение о том, какой применять алгоритм (и какова должна быть его сложность) принимает оператор.

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

Рисунок 30: Доп. услуга (VOD) - Выделение необходимых параметров сервиса для сервисов

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

2.1.2.2.2.3 "Выделение необходимого качества обслуживания" производится на основе данных о том, какой уровень качества нужно обеспечить для предоставления услуги VOD. Цель процесса - обеспечить непрерывность видео-потока с учётом используемых кодеков и качества изображения. Технически это означает установление более высокого приоритета для трафика, который относится к услугам VOD. Отличие от услуги телевидения состоит лишь в том, что видео-поток транслируется с сервера оператора.

Рисунок 31: Доп. услуга (VOD) - Выделение и инсталляция ресурса

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

2.1.3.2.1.3 "Инсталляция ресурса (перепрограммирование STB)" выполняется с учётом требований, предъявляемых клиентом, таких как наличие\отсутствие определённых функций у приставки, способ (самостоятельно\с помощью специалиста) и время инсталляции, выполнение работ по протяжке кабелей в квартире и т.д. Цель процесса - монтаж и подготовка к работе STB. В отличие от услуги телевидения, в этом случае, скорее всего, вся инсталляция может быть произведена автоматически путём перепрограммирования приставки, либо с помощью её замены.

Рисунок 32: Доп. услуга (VOD) - Внедрение, конфигурация и активация сервиса

2.1.2.2.4.2 "Конфигурация VOD" происходит при инициировании записи в клиентской базе данных о том, что данному клиенту теперь будет предоставляться новый сервис. Цель процесса - внесение в клиентскую базу данных информации о том, какая именно услуга будет предоставляться клиенту и на каких условиях. Для услуги VOD такой информацией является количество видео-материала, его качество (битрейт), стоимость, наличие\отсутствие рекламы, время пользования и т.д.

2.1.2.2.4.3 "Активация VOD" выполняется при условии завершения конфигурации. Цель процесса - закрепить изменения, произведённые во время конфигурации. Активация является завершающим шагом, в ходе которого производится установка в клиентской базе данных отметки о том, что услуга теперь находится в статусе "предоставлена".

Рисунок 33: Доп. услуга (VOD) - Конфигурация и активация ресурса

2.1.3.2.2.1 "Конфигурация сетевого оборудования" основывается на данных о том, какие функции предстоит выполнять этому оборудованию (например, функции ретрансляции multicast-потока). Цель процесса - осуществить необходимую настройку всего оборудования оператора, которое будет отвечать за предоставление новой услуги данному клиенту.

2.1.3.2.2.2 "Конфигурация клиентского оборудования" выполняется в соответствии с данными о том, какие функции будет выполнять STB (например, только декодирование, либо декодирование и запись). Цель - настройка приставки с целью обеспечения работы услуги VOD. Эту операцию может производить как технический специалист оператора, так и сам клиент (в зависимости от используемых абонентских устройств и бизнес-модели оператора).

2.1.3.2.2.3 "Добавление записи в базу данных" происходит на основе информации, полученной от клиента (например, ФИО, список услуг, адрес и т.д.). Цель процесса - внесение необходимой информации о клиенте в базу данных, чтобы впоследствии этой информацией можно было воспользоваться любому оборудованию оператора, которому потребуются данные клиента, а также в случае необходимости техническим специалистам и всем уполномоченным службам оператора.

2.1.3.2.2.4 "Активация ресурса" в качестве входных данных получает информацию о завершении конфигурации. Цель процесса - закрепить изменения, произведённые во время конфигурации. Под ресурсом в данном случае понимаеся то оборудование, которое до этого было сконфигурировано. Скажем, у маршрутизаторов при выполнении активации произведённые изменения должны быть записаны в ПЗУ.



Рисунок 34: Доп. услуга (VOD) - Сквозное тестирование сервиса

2.1.2.2.5.1 "Тестирование пропускной способности" осуществляется с учётом требуемых значений полосы пропускания. Цель процесса - проверка выделенной величины бит\с на соответствие требованиям, которые предъявляются услугой VOD. Требования зависят от объёма и качества передаваемой видео-информации.

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

2.1.2.2.5.3 "Тестирование конечной услуги" в качестве входных данных имеет информацию о завершении предыдущих этапов тестирования. Цель процесса заключается в определении субъективного восприятия видео-информации на стороне клиента. Для видео по запросу это означает наличие\отсутствие прерывистости, рассыпаемости картинки, а также определение качества звука.

Рисунок 35: Доп. услуга (VOD) - Тестирование ресурса

2.1.3.2.3.1 "Тестирование сетевого оборудования" выполняется на основе тех же данных, что и процесс 2.1.3.2.2.1 "Конфигурация сетевого оборудования". Цель процесса - определение того, правильно ли была выполнена конфигурация сетевого оборудования. Процесс тестирования заключается в поочерёдной проверке каждой функции, предусмотренной услугой VOD.

2.1.3.2.3.2 "Тестирование клиентского оборудования" происходит на основе той же информации, которая требуется для процесса 2.1.3.2.2.2 "Конфигурация клиентского оборудования". Цель этого тестирования - узнать, правильно ли была осуществлена конфигурация STB. Чтобы это проверить, необходимо воспользоваться всеми возможностями приставки, предусмотренными в услуге VOD.

2.1.3.2.3.3 "Тестирование базы данных" осуществляется на основе информации, необходимой для выполнения процесса 2.1.3.2.2.3 "Конфигурация базы данных". Цель данного тестирования - это проверка соответствия записанной в базе информации и информации, полученной изначально. Например, ячейка базы данных с количеством видео-материала должна содержать ту же информацию, что и заявка клиента.

4.3 Информационная модель SID

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

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

Ресурс - это элементы инфраструктуры оператора связи, которые используются для предоставления услуг IPTV.

1. Физический ресурс - это материальные объекты, входящие в состав сети оператора.

· Оборудование доступа - это то оборудование, через которое клиентская приставка подключается к транспортной сети оператора связи (например, коммутатор или DSLAM).

2. Логический ресурс - это нематериальные объекты, которые поддерживаются физическим ресурсом.

· Ключи доступа хранятся в базе данных на сервере VCAS. Они используются при шифровании контента и его расшифровке на стороне клиента. Подробнее об этом в п.п. 3.3.

· Каталог видео по запросу - это логический ресурс видео сервера. Он используется для предоставления услуги видео по запросу.

· Middleware - это серверное приложение, которое построено с учетом открытых стандартов и позволяет управлять видео, интерактивными и коммуникационными сервисами в различных сетях связи. Подробно описывается в п.п. 3.4.

Рисунок 36 - Информационная модель SID

3. Комбинированный ресурс - это объекты, сочетающие в себе функции логических и физических ресурсов.

· База данных Middleware - это ресурс, располагаемый на серверах оператора связи и испольуемый в работе промежуточного ПО.

· Видео серверы представлюет собой совокупность (массив) дисковых накопителей значительной емкости с установленным для работы в системе IPTV специальным программным обеспечением. Подробнее об этом написано в п.п. 3.7.

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

· Set-Top Box представляет из себя приставку к телевизору. Она является абонентским устройством, обеспечивающим связь между двумя системами: формирования и доставки контента. Подробнее о ней написано в п.п. 3.5.

При составлении информационной модели учитывались рекомендации в [6]-[9].

4.4 Выводы

Таким образом, в результате проделанной работы имеется:

1) Необходимая декомпозиция карты eTOM, содержащая используемые в подключении услуг IPTV бизнес-процессы.

2) Блок-схемы процессов-потоков, отображающих порядок выполнения действий при выполнении поставленной задачи.