БАЗОВЫЕ ЛЕКЦИИ И ПРЕЗЕНТАЦИИ ПО ДИСЦИПЛИНАМ

ПРОЕКТИРОВАНИЕ И ЭКСПЛУАТАЦИЯ СИСТЕМ КОММУТАЦИИ (ПЭСК)

ПРОЕКТИРОВАНИЕ И ЭКСПЛУАТАЦИЯ СИСТЕМ СВЯЗИ (ПЭСС)
ОСНОВЫ ЭКСПЛУАТАЦИИ СЕТЕЙ СВЯЗИ (ОЭСС)
Фак. ВиЗО
Каф. ИКС доц. Шалаев А.Я.
Ноябрь 2015г.

ПРЕЗЕНТАЦИЯ

Тема 8. ПРОЕКТИРОВАНИЕ
СИСТЕМ ЭКСПЛУАТАЦИОННОГО УПРАВЛЕНИЯ
СЕТЯМИ И УСЛУГАМИ СВЯЗИ
• Общие принципы проектирования
1. Системный подход к проектированию
2. Основные проектные документы
3. Задачи планирования телекоммуникационных сетей
• Элементы проектирования систем эксплуатационного
управления
1. Этапы проектирования NGOSS. Методология SANRR
2. Развитие NGOSS – FRAMEWORX
• Проектная оценка надежности
1
 СПИСОК ИСТОЧНИКОВ 1

Учебная литература
1. Атцик А. А., Гольдштейн А. Б., Гольдштейн Б. С.
Расчет и проектирование сетевого оборудования NGN/IMS:
учебное пособие для курсового проектирования. ГОУВПО
СПбГУТ. СПб, 2011.

2. Проектирование и техническая эксплуатация цифровых

телекоммуникационных систем и сетей. Учебное пособие для
вузов/Е.Б. Алексеев, В.Н. Гордиенко и др. – М.:Горячая линия –
Телеком, 2008. -392 с. (реализация применительно к ЦСП).

Научно-технические книги
1. Соколов Н.А. Задачи планирования сетей электросвязи. – СПб.:
Техника связи, 2012. – 432 с.
2. Семенов Ю.В. Проектирование сетей связи следующего
поколения. – СПб.: Наука и Техника, 2005. – 240 с.
3. NGOSS: Построение эффективных систем поддержки
эксплуатации сетей для оператора связи/ Джон Райли, Мартин
Кринер. –Пер. с англ.- М.:Альпина Бизнес Букс, 2007. – 192с.

ИНТЕРНЕТ источники
6. Материалы TeleManagement Forum.
http://www.tmforum.org/BestPracticesStandards/1669/home.ht
ml

2
 Системный подход к проектированию
Системный подход к проектированию предполагает изучение системы и её
поведения как единого целого объекта, выполняющего определенные
функции в конкретных условиях, с учетом взаимодействия и взаимного
влияния отдельных частей, оказывающих наиболее существенное
влияние на достижение конечных целей.
Системный подход может осуществляться на различных этапах проектирования
(предварительный проект, технический проект, НИР, ОКР и т.д.), однако
наибольший эффект достигается на этапе
предварительного проектирования, когда выбирается
структурная схема системы и оцениваются её основные параметры.
Основные принципы системного подхода в области оптимального проектирования
могут быть сформулированы следующим образом.
1. Система, состоящая из оптимальных частей, в общем случае не является
оптимальной.
2. Оптимизация системы должна проводиться по количественно определенному и
единственному критерию, который в математической форме отражает цель
оптимизации.
3. Система должна оптимизироваться в условиях количественно определенных
ограничений на оптимизируемые параметры. 3
 Основные проектные документы
• Исходные данные на проектирование
• Задание на проектирование
• Системный проект
• Рабочий проект
• Проект

Проектирование является одним из основных

этапов проектной подготовки строительства в
инвестиционном процессе.
Разработка проектной документации выполняется
организацией, имеющей лицензию на данный
вид деятельности. 4
 Исходными данными для проектирования
являются:

- схема организации связи;

- технические характеристики на оборудование
различных производителей, включая надежность
и стоимость;
- требуемая пропускная способность, в том числе и
на перспективу;
- требуемые показатели качества и надежности
работы.
Проектные организации совместно с заказчиком
осуществляют разработку технико-
экономического обоснования (ТЭО).
5
Проектные решения оформляются в виде проектной
документации:
• Проектирование типовых или относительно несложных
объектов связи осуществляется в одну стадию
(одностадийное проектирование), основными проектными
документами для которого являются задание на
проектирование (ЗП) и рабочий проект.
Задание на проектирование составляется заказчиком
совместно с проектировщиком на основе решений,
принятых на этапе разработки ТЭО.
• Проектирование сложных сооружений связи, при
использовании новых телекоммуникационных технологий,
при отсутствии типовых или подобных проектов ведется в
две стадии (двухстадийное проектирование). При этом
обязательными проектными документами являются:
проект и рабочая документация. 6
 При рабочем проектировании NGN должны
быть разработаны следующие разделы рабочего проекта

- услуги, классы обслуживания для каждой категории

пользователей, а также потребность в ширине полосы
пропускания;

- объем оборудования и линейных сооружений;

- номенклатура, площади и размещение оборудования;
- внутристанционная проводка, заземления и защита;
- измерительная и проверочная аппаратура;

- режим работы оборудования и требования к

эксплуатационному управлению и обслуживающему
персоналу;
- обеспечение техники безопасности;

- организация охраны окружающей среды. 7

 Задачи планирования
телекоммуникационных сетей [Соколов]
В англоязычной литературе словосочетание
«планирование сети» (network planning) во многих
публикациях используется применительно к группе
важнейших задач, решаемых в процессе
проектирования сети (network designing).
Такими задачами в планировании сети считаются:
o выбор структуры,
o расчет пропускной способности и производительности
основных элементов,
o оценка экономических показателей.
В отечественной практике проектирования сетей термин «network
planning» иногда рассматривается как «системный проект»,
что весьма удачно отражает перечень выполняемых действий и
ожидаемых результатов. 8
 Элементы проектирования
cистем эксплуатационного управления

Этапы проектирования NGOSS. Методология

SANRR

Развитие NGOSS – FRAMEWORX

9
10
 Методология SANRR для разработки
функциональности модулей NGOSS
Методология SANRR
Определение предполагает
Анализ
границ использование
следующих пяти шагов:
1) Определение границ

Рационализация

Корректировка
Нормализация
(Scope)
2) Анализ (Analyze)
3) Нормализация
(Normalize)
4) Рационализация
(Rationalize)
Развернутая структура
5) Корректировка
приложений (Rectify)
11
 Методология SANRR:
пример использования

Определение
границ Анализ

Определение границ:

Рационализация
1) Требования к

Корректировка
Нормализация

приложению
2) Определение
функциональности
приложения
Развернутая структура
приложений

12
 Методология SANRR, шаг 1.1 :
Формулирование общих требований к приложению
«Управление пользовательскими устройствами»

Концепция «любая услуга в любом месте на любом типе

устройства» подразумевает выполнение следующих
требований:

Автоматическая настройка пользовательского устройства в

режиме реального времени

Предоставление услуг в соответствии с соглашением об

уровне обслуживания (Service License Agreement, SLA)

Предоставление пользователям услуг с выбором технологии в

зависимости от конфигурации устройства и доступной
инфраструктуры (Например, услуга «доступ в интернет» может
быть предоставлена с помощью различных технологий – Wi-Fi,
GPRS, EDGE, EV-DO, ADSL и т.д. )
13
 Методология SANRR, шаг 1.2 :Определение основной функциональности приложения

Идентифицировать тип/спецификацию активного пользовательского устройства, составлять отчеты

о типе/спецификации устройства для использования другими модулями
Отслеживать и предоставлять отчеты о статусе активного пользовательского устройства
Получить список услуг, который был специфицирован пользователем для активного устройства и
инициировать активацию специфицированных услуг. Если списки услуг для конкретных
пользовательских устройств не заданы, то применить сценарий по умолчанию
Инициировать настройку активного пользовательского устройства в соответствии с
подключенными услугами
Инициировать персонификацию пользовательского устройства (телефонная книга, настройки
браузера и т.д.)
Получить информацию (если имеется) о предпочитаемых пользователем технологиях для
подключенных услуг
Определить технологии, поддерживаемые активным пользовательским устройством
Определить список услуг (согласно портфолио сервис-провайдера), доступных для использования
на активном пользовательском устройстве
Определить список услуг согласно портфолио, выбранных пользователем для активного
пользовательского устройства
Определить список услуг согласно портфолио сервис-провайдера, которые доступны
пользователю, но не подключены на активном пользовательском устройстве
Предоставлять отчеты об услугах, которые доступны пользователю данного сервис-провайдера, но
не подключены на активном пользовательском устройстве (для использования маркетинговым
отделом компании)
Определить список услуг, которые подключены пользователем для активного пользовательского
устройства, но не могут быть предоставлены сервис-провайдером в данной географической точке в
14
данный момент времени
 Методология SANRR, шаг 1.2 : Определение основной функциональности приложения

Определить список услуг, которые подключены пользователем для активного пользовательского

устройства и не могут быть предоставлены сервис-провайдером в данной географической точке в
данный момент времени, но доступны от других сервис-провайдеров
Отслеживать процессы конфигурации и активации согласно специфицированному для активного
пользовательского устройства списку услуг
Отслеживать процессы конфигурации активации услуг, предоставляемых посредством
инфраструктуры других сервис-провайдеров
Определить требования к предоставляемым услугам в соответствии с соглашением об уровне
обслуживания и отследить выполнение этих требований
Предоставлять возможность производителям пользовательских устройств отслеживать активацию
и возможность взаимодействия с владельцами устройств (н-р, проведение маркетинговых
исследований и маркетинговых акций)
Отслеживать конфигурирование ресурсов (если необходимо) для обеспечения возможности
предоставления услуг пользователю на активном устройстве
Отслеживать конфигурирование и/или модифицирование ресурсов и/или продуктов сторонних
сервис-провайдеров (если необходимо) для обеспечения возможности предоставления услуг
пользователю на активном устройстве
Track configuring active user device (if needed) for every service subscribed by the customer on active
device
Track fault management for service activation problems (Where are the boundaries between the faults
that are subject to device manufacturer consideration and the faults that are subject to service provider
consideration?)
Manage and track redirecting trouble ticket to suppliers (device manufacturers) if need
15
 Причины перехода от NGOSS к FRAMEWORX

• продолжающиеся ценовые тенденции снижения стоимости

услуг, вынуждающие повышать эффективность бизнеса и
предложение новых услуг;
• появление сложных цепочек поставки услуг;
• повышение роли потребителя и потребность в постоянном
предложении все более сложных и комплексных услуг по
меньшим ценам;
• серьезные технологические изменения, позволяющие
предоставлять несколько услуг с помощью одной общей
инфраструктуры IP, но при существенном усложнении
компонентов ПО;
• появление архитектур, ориентированных на услуги (Service
Oriented Architectures – SOA)

16
Общая архитектура Frameworx

17
 Характеристика Frameworx

• Является отраслевой наиболее объемлющей

бизнес-архитектурой;
• Обеспечивает гибкость для вендора и
технологически-независимую разработку;
• Позволяет сервис-провайдеру реализовать
совместимые с ITIL внедрения через Структуру
бизнес-процессов eTOM (Business Process
Framework);
• Полностью поддерживается рядом коммерческих
продуктов.

18
Элементы Frameworx

19
Общая схема SOA

20
Структура SOA

21
 Проектная оценка надежности

Общие положения и исходные данные

Методика расчета и оценка показателей
надежности
• Обоснование выбора общего подхода
• Надежность аппаратного обеспечения
• Надежность программного обеспечения
• Оценка показателей надежности
Технические и организационные меры по
обеспечению надежности
22
 Задачи оценки надежности при проектировании

а) Обоснование и задание требований по надежности к

системе и её составным частям и выбора путей их
достижения.
В рамках задачи «задание требований» возможны два варианта поиска
множества возможных решений (в виде интервала значений показателей
надежности). Либо поиск минимального значения показателей надежности,
при котором обеспечивается нормальное функционирование системы
(выполняются требования по эффективности), либо поиск максимально
достижимого значения показателей надежности при выполнении
ограничений на затраты.

б) Принятие решений, обеспечивающих требуемую

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

д) Задачи распределения располагаемых ресурсов на

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

24
 Уровень надежности
зависит от уровней надежности, достигаемых на
каждой стадии жизненного цикла системы

Рпр - надежность системы достигнутая на этапе проектирования

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

25