Размещено на http://www.allbest.ru/

Оглавление

• Введение
• 1. Обзор предметной области
• 1.1 Деятельность транзитного оператора связи
• 1.2 Маршрутизация с использованием LCR
• 1.3 Биллинговые системы
• 2. Обзор существующих решений
• 2.1 Функциональные возможности IP Studio AMBS
• 2.2 Протокол RADIUS
• 2.3 MVTS
• 2.4 SIP
• 2.5 H.323
• 2.6 ODBC
• 2.7 Анализ слабых сторон IP Studio AMBS
• 3. Лингвистическое обеспечение
• 3.1 SQL
• 3.2 Microsoft Visual Basic for Applications
• 3.3 Основные определения
• 4. Информационное обеспечение
• 5. Описание структуры данных
• 5.1 Этап 1. Формирование маршрутной таблицы
• 5.1.1 Структура входных данных
• 5.1.2 Структура внутренних данных
• 5.1.3 Структура выходных данных
• 5.2 Этап 2. Проверка качества связи
• 5.2.1 Структура входных данных
• 5.2.2 Структура внутренних данных
• 5.2.3 Структура выходных данных
• 6. Разработка алгоритма
• 7. Конструкторско-технологическая часть
• 7.1 Выбор программного обеспечения
• 7.1.1 Microsoft Office Access
• 7.1.2 Обоснование использования Microsoft Access
• 7.2 Разработка программы
• 7.2.1 SQL-запросы
• 7.2.2 Алгоритмы процедур
• 7.2.2.1 Экстраполяция тарифов
• 7.2.2.2 Формирование LCR
• 7.3 Разработка интерфейса
• 7.3.1 Основные требования к графическому интерфейсу пользователя
• 7.3.2 Создание формы в Microsoft Access при помощи средств VBA
• 7.3.3 Функции используемых элементов
• 7.4 Технология отладки программы
• 7.4.1 Основные типы ошибок
• 7.4.2 Средства отладки кода в VBA
• 7.4.2.1 Режим прерывания
• 7.4.2.2 Пошаговое выполнение программы
• 7.4.2.3 Наблюдение за значениями переменных
• 7.4.2.4 Обработчик ошибок
• 7.5 Решение задачи на ЭВМ
• 8. Охрана труда
• 8.1 Охрана труда
• 8.2 Микроклимат рабочей зоны
• 8.3 Рекомендации по поддержанию оптимального микроклимата
• 9. Экологическая часть
• 9.1 Природа электромагнитного излучения
• 9.2 Источники электромагнитного излучения
• 9.3 Влияние электромагнитного излучения на здоровье человека
• 9.4 Меры защиты от ЭМИ
• 9.5 Рекомендации для безопасной работы за ПЭВМ
• Заключение
• Список использованной литературы
• Приложение 1. Содержимое внешнего модуля
• Приложение 2. Содержимое модуля формы

Введение

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

IP-телефония представляет собой реализацию телефонной связи по IP-сети, осуществляемую при помощи набора протоколов, технологий и специализированного оборудования. Передача голоса по сети происходит путем его переведения в цифровой вид, сжатия и разбиения на пакеты с последующим извлечением, декодированием и преобразованием в аналоговый сигнал на другой стороне. Будучи используемой для установления двусторонней связи, IP-телефония является частным случаем более общей технологии VoIP (Voice over IP), подразумевающей любую передачу голосового трафика по IP-протоколу [1].

Услуги IP-телефонии предоставляются операторами связи на коммерческой основе путем заключения договоров с абонентами. По масштабам охватываемой территории операторы подразделяются на локальных (город, район), региональных, национальных (страна) и транснациональных (международная связь) [2]. Для получения возможности осуществления своей деятельности операторы в большинстве стран мира, в том числе и в России, обязаны получать государственные лицензии на оказание услуг связи соответствующего профиля. Произошедшая в 1990-х годах демонополизация рынка услуг связи привела к появлению большого числа альтернативных операторов, конкурирующих между собой.

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

Таким образом, можно сказать, что одной из важнейших технологических задач IP-телефонии является маршрутизация вызовов, представляющая собой задание маршрута для обработки звонков, соответствующее требуемым условиям. Главным принципом маршрутизации вызовов является технология LCR (Least Cost Routing, маршрутизация по наименьшей стоимости звонка), обеспечивающая самую низкую себестоимость установления соединения внутри сети.

Маршрутизация обычно реализуется с помощью маршрутных таблиц, составленных на основе данных о действующих тарифах. Эти таблицы используются VoIP-коммутаторами (VoIP-switch), которые осуществляют реализацию телефонных соединений.

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

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

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

Областью применения разработки служит система биллинга и менеджмента IP Studio AMBS, используемая оператором связи ООО "ГЛОБАЛСАТ".

Сферой деятельности компании ГЛОБАЛСАТ является создание сетей спутниковой связи и предоставление услуг телефонии на их основе. Сервисы компании рассчитаны как на частных лиц, так и на предприятия малого и среднего бизнеса.

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

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

Актуальность разработки состоит в следующем:

- Ее применение позволит за счет автоматизации сократить объем работы, выполняемый оператором биллинговой системы вручную;

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

- Улучшение качества маршрутной таблицы позволит увеличить операционную прибыль компании;

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

В рамках выполнения данного дипломного проекта необходимо выполнить следующие задачи:

1) Рассмотреть функциональные возможности существующей системы биллинга и менеджмента IP Studio AMBS, используемой оператором связи; определить ее функциональные недостатки;

2) Спроектировать и разработать программу динамической маршрутизации звонков при помощи средств СУБД Microsoft Access;

3) Создать интерфейс для удобства работы оператора системы;

4) Внедрить и отладить разработанную программу в биллинговую систему IP Studio AMBS;

5) Протестировать работоспособность системы;

6) Изучить вопросы охраны труда и экологии на рабочем месте, сделать выводы;

7) Оформить пояснительную записку к дипломному проекту.

1. Обзор предметной области

1.1 Деятельность транзитного оператора связи

Транзитными называются такие операторы связи, которые не взаимодействуют напрямую с конечными абонентами. Эти операторы перенаправляют трафик (голос и служебную сигнализацию в сети) от оригинаторов к терминаторам соединений, устанавливая соединение как минимум с двумя встречными операторами (см. рис. 1). Оригинатор - это оператор, инициирующий вызов и присылающий его транзитному оператору. Терминатор - оператор-получатель вызова.

Рис. 1. Схема перенаправления вызова транзитным оператором

1.2 Маршрутизация с использованием LCR

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

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

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

Качество связи может отличаться как у разных операторов, так и у одного оператора в разные периоды времени. Его обычно измеряют при помощи таких показателей, как Answer Seizure Ratio (коэффициент дозвона, ASR = успешные попытки соединений /все попытки соединений) и Average Call Duration (ACD, средняя длительность звонка). Если ACD очень мала, то очевидно, что качество связи настолько низкое, что абоненты не могут поговорить и вешают трубку. В случае значительных расхождений в значениях ACD по доступным маршрутам оператору нужно отдавать приоритет тем маршрутам, где ACD выше.

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

1.3 Биллинговые системы

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

Системы биллинга (иногда в нормативных документах употребляется и другое название - автоматизированные системы расчета, АСР) - это разновидность прикладного программного обеспечения, используемая предприятиями связи для поддержки бизнес-процессов (рис. 2). Главное предназначение биллинговых систем - обеспечение автоматизации расчетов с клиентами и другими операторами, начиная от заключения договора оказания услуг связи и заканчивая выставлением счетов за них.

Рис. 2. Схема взаимодействия биллинговой системы

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

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

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

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

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

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

2. Обзор существующих решений

В данном дипломном проекте рассматриваются функциональные возможности системы биллинга и менеджмента пользователей IP-телефонии IP Studio AMBS (рис. 3), на основании которой будет разработана подсистема, устраняющая недостатки в составлении таблицы маршрутизации.

Рис. 3. Веб-интерфейс IP Studio AMBS

2.1 Функциональные возможности IP Studio AMBS

IP Studio AMBS представляет собой автоматизированную систему для управления и расчетов VoIP-трафика в работе крупных и средних операторов связи, разработанную компанией IP Studio Inc. Структура программы состоит из ядра, которым является сама биллинговая система, и дополнительно подключаемых модулей, расширяющих ее функционал [3].

Возможности данной системы позволяют осуществлять внешнее управление одним или несколькими VoIP-коммутаторами MVTS, оставляя за ними только функции проксирования сигнального и речевого трафика. В число остальных задач, решаемых системой AMBS самостоятельно, входят:

- Аутентификация операторов связи, то есть определение источников входящих вызовов;

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

- Маршрутизация звонков - перенаправление каждого вызова по определенному направлению на список доступных встречных операторов в соответствии с маршрутной таблицей. В IP Studio AMBS статическая таблица маршрутизации звонков формируется вручную оператором биллинговой системы через веб-форму на основании данных из справочника направлений и списка операторов (рис. 4);

- Учет и тарификация состоявшихся соединений, расчет стоимости покупки и продажи звонка;

- Формирование счетов за выбранный период времени (например, за месяц);

- Ведение статистики трафика, автоматическое формирование необходимых отчетов за выбранный период времени по любым операторам.

Рис. 4. Форма параметров маршрутизации

В базу данных IP Studio AMBS загружаются периодически обновляемые прайс-листы на услуги операторов-партнеров, приведенные в стандартизированный формат. Помимо этого, в ней хранится справочник направлений. На основании этих данных формируется маршрутная таблица, которая содержит наиболее выгодные маршруты прохождения телефонного звонка из пункта оригинации в пункт терминации. С этой таблицей через протокол RADIUS связана система MVTS, которая взаимодействует с другими коммутаторами посредством протоколов SIP и H.323. Для передачи речевого трафика коммутаторами используется протокол RTP.

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

Общая структура взаимодействия представлена на рис. 5.

Рис. 5. Схема взаимодействия программного обеспечения и оборудования в сети IP-телефонии

2.2 Протокол RADIUS

RADIUS (Remote Authentication in Dial-In User Service) - это протокол, разработанный для систем тарификации пользователей, работа которого осуществляется через обмен данными между центральной платформой и оборудованием.

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

Протокол RADIUS реализует аутентификацию (проверку подлинности субъекта), авторизацию (определение его полномочий доступа к различным сервисам) и сбор сведений об использованных каждым абонентом ресурсах (учет трафика) [4].

По своей форме сообщение RADIUS представляют собой заполненное поле данных пакета UDP.

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

- Создание, хранение и управление учетными записями пользователей;

- Блокирование доступа пользователя к учетной записи на основании достижения им установленного лимита;

- Сбор статистики и анализ проведенных сессий;

- Формирование отчетов по выбранным параметрам статистики;

- Выставление счетов к оплате, их печать и рассылка.

2.3 MVTS

биллинг маршрутизация телефонный интерфейс

MVTS (MERA VoIP Transit Softswitch) - это используемый операторами связи пограничный контроллер сессий с широкими возможностями управления голосовым трафиком в сетях IP-телефонии. В частности, MVTS осуществляет проксирование голосового и сигнального трафика, соединение и концентрацию VoIP-потоков, а также их распределение по сетям с различными стандартами сигнализации. Коммутатор MVTS использует информацию заголовков пакетов в стеках протоколов 4 уровня модели OSI (Open Systems Interconnection, модель взаимодействия открытых систем) для управления приложениями и серверами, за счет чего его технологии позволяют осуществлять интеллектуальное управление трафиком, защиту сети и межсетевое взаимодействие.

Благодаря своей распределенной архитектуре MVTS подходит для работы крупных операторов связи, упрощая администрирование сети. Несколько взаимосвязанных серверов MVTS оперируют единым набором баз данных, осуществляя централизованный сбор и обработку трафика с программных коммутаторов (softswitch) и привратников (gatekeeper). Сокрытие сетевой структуры, встроенный контроль установления соединений и защита от проникновений извне позволяют обеспечить сетевую безопасность. В число функций описываемого контроллера сессий также входит сбор детальной статистики о работе сети.

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

Помимо этого, существует возможность подключения к MVTS внешних систем маршрутизации через протокол RADIUS, что позволяет операторам самостоятельно настраивать необходимые параметры и режимы маршрутизации вызовов [5].

2.4 SIP

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

Протокол SIP осуществляет взаимодействие абонентов по клиент-серверной схеме. Клиент отправляет на сервер запрос на предоставление какого-либо сервиса, который сервер обрабатывает и выполняет, посылая клиенту ответное сообщение о статусе исполнения запроса. Сервер также может осуществлять переадресацию вызова в соответствии с местоположением адресата [1].

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

В SIP используется адресация по имени домена или IP-адресу пользователя. Поддержка подобного формата позволяет интегрировать услуги SIP в существующую систему серверов DNS (Domain Name System, система имен доменов), преобразующих имена доменов в IP-адреса. Имея уникальный идентификатор, пользователь может пользоваться всеми услугами оператора, свободно перемещаясь в пределах сети.

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

2.5 H.323

H.323 - рекомендация Международного союза электросвязи (ITU-T), определяющая набор стандартов, описывающих сетевые протоколы, алгоритмы, процедуры и компоненты для пакетной передачи по сетям аудио- и видеоданных. Помимо этого, рекомендация Н.323 используется при решении задач управления адресацией, полосой пропускания сети и администрирования конечных пользователей. При помощи транслирующих сигнализацию и форматы данных шлюзов возможно обеспечение взаимодействия с сетями других типов связи [1]. В дополнение к этому стандарт H.323 позволяет использовать при создании сети устройства разных производителей.

Стек Н.323 состоит из следующих протоколов:

- RTP (Real-time Transport Protocol, транспортный протокол реального времени) - используется для восстановления аналоговой информации реального времени. Пакеты RTP передаются при помощи протокола UDP (User Datagram Protocol, протокол пользовательских датаграмм), в то время как контроль доставки данных осуществляется управляющим протоколом RTCP (Real-time Transport Control Protocol);

- Кодеки G.711, G.723.1, G.729 и др. - определяют алгоритмы компрессии и декомпрессии передаваемых по сети аудио- и видеоданных;

- Q.931 - протокол сигнализации для установления и завершения соединения между абонентами;

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

- RAS (Registration Admission Status, протокол регистрации, допуска и состояния) - протокол сигнализации, применяющийся для контроля доступа в сеть, информирования о состоянии полосы пропускания, регистрации пользователей в доменах и прекращения сеанса связи. Функционал протокола RAS реализуется путем обмена служебными сообщениями между контроллером зоны Н.323 и сетевыми терминалами, представляющими собой ПК или другие мультимедийные устройства, способные осуществлять передачу голоса (видео);

- H.450 - набор протоколов, обеспечивающих дополнительные виды обслуживания в сети H.323.

2.6 ODBC

ODBC (Open Database Connectivity, открытый механизм взаимодействия с базами данных) - это стандартный программный интерфейс уровня вызова (Call Level Interface, CLI) для доступа приложений к базам данных. Данный стандарт служит для унификации взаимодействия программ с СУБД различных поставщиков вне зависимости от программно-аппаратной платформы [6]. Такая возможность реализуется благодаря наличию специально разработанных драйверов для всех БД и прочих источников данных, например, электронных таблиц или текстовых файлов.

Доступ к БД интерфейс ODBC предоставляет на основе стандарта ANSI языка SQL. При вызове функций ODBC приложение, которому необходимо указать только имя источника данных, устанавливает соединение с сервером БД, передает соответствующую команду SQL в качестве аргумента функции и обрабатывает полученный результат. Драйвер ODBC способен модифицировать запрос приложения так, чтобы он удовлетворял синтаксису SQL конкретной СУБД.

Структура ODBC включает в себя следующие компоненты:

- ODBC API (Application Programming Interface, интерфейс создания приложений) - динамически подключаемая библиотека функций вызовов драйверов поддерживаемых СУБД. В свою очередь драйверы подразделяются на одно- и многоуровневые. Драйверы первой категории используются для работы с локальными БД, преобразуя синтаксис ANSI SQL в инструкции более низкого уровня для непосредственной обработки содержимого БД. Вторая категория драйверов работает по модели клиент-сервер, в дополнение к ANSI SQL поддерживая собственные инструкции используемой реляционной СУБД и используя ее сервер для обработки SQL-запросов;

- Driver Manager (диспетчер драйверов) ODBC - библиотека, управляющая обработкой имен источников данных и загрузкой драйверов БД приложением;

- Драйверы БД ODBC - динамически подключаемые библиотеки для обработки вызовов ODBC для используемых СУБД;

- Библиотека курсоров ODBC - реализованный как уровень между диспетчером драйверов и драйверами ODBC компонент доступа к данным, создающий блочные или статические курсоры в случае, если драйвер их не поддерживает;

- Администратор источника данных ODBC - инструмент для создания источников данных и управления ими.

2.7 Анализ слабых сторон IP Studio AMBS

Несмотря на широкие возможности, предоставляемые оператору, рассматриваемая система имеет ряд серьезных недостатков в управлении маршрутизацией вызовов:

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

2) При формировании таблицы LCR (Least Cost Routing) доступно составление очень маленького числа маршрутов (не более трех), что может приводить к возникновению проблемы полного недозвона по определенным направлениям. Необходимо увеличить количество возможных выборов для обеспечения большей надежности соединения;

3) Предложения операторов могут отличаться друг от друга, поскольку каждый из них ориентируется на свой собственный справочник направлений (телефонных кодов). Это может приводить к тому, что формируемое транзитным оператором совокупное предложение может содержать определенные неоднозначности. Например, один из партнеров предлагает конкретное направление в виде одного (короткого) телефонного кода, а другой партнер предлагает то же самое направление по более высокой цене в виде группы более длинных (дочерних) кодов. Простая консолидация предложений приведет к тому, что в маршрутной таблице фактически будут задействованы эти дочерние коды с более высокой ценой. Для решения этой проблемы необходимо привести все тарифные предложения к единому стандарту. Это может быть достигнуто применением процедуры экстраполяции тарифов;

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

3. Лингвистическое обеспечение

3.1 SQL

SQL (Structured Query Language) - язык структурированных запросов, формальный непроцедурный информационно-логический язык программирования. Широко применятся в системах управления базами данных (СУБД) для описания, модификации и извлечения данных в реляционных БД [7].

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

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

SQL-запрос представляет собой допустимый набор ключевых слов, идентификаторов, операторов, констант и прочих символов, предваряемый каким-либо ключевым словом.

Ключевым (зарезервированным) называется такое слово, которое имеет определенное значение в SQL, и его применение определено строгими правилами. Стиль программирования SQL предполагает написание операторов и прочих зарезервированных слов прописными буквами.

Идентификатор - это наименование объекта БД (таблицы, столбца и т.д.), которое не должно быть длиннее 128 знаков. В качестве идентификаторов также нельзя использовать ключевые слова. Каждый SQL-запрос должен заканчиваться точкой с запятой.

Возможности SQL позволяют создавать следующие виды запросов:

- создание новых объектов путем описания их типов и структуры;

- изменение уже существующих в БД объектов;

- осуществление выборки данных из одной или нескольких таблиц согласно заданному условию;

- добавление новых данных;

- удаление данных;

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

SQL-запросы представляют собой операции над таблицами в БД либо над отдельными записями или строками таблиц, описанных через перечисление полей с указанием связей между таблицами (ключевых полей), типов значений, содержащихся в полях и информации для формирования индексов. Результатом выполнения SQL-запросов является формирование соответствующих заданным условиям выборок и совершение необходимых операций над записями в наборе.

По своим выполняемым функциям все операторы SQL можно отнести к четырем группам:

1) Язык определения данных (Data Definition Language, DDL) - позволяет определять хранящиеся в базе данных структуры, такие как таблицы, индексы, роли, или другие объекты, использование которых допускается в данной СУБД.

2) Язык манипуляции данными (Data Manipulation Language, DML) - позволяет осуществлять извлечение данных из таблиц, вставку, изменение и удаление записей в базе данных.

3) Язык определения доступа к данным (Data Control Language, DCL) - дает возможность контролировать доступ конкретных пользователей или их групп к объектам БД посредством предоставляемых и отменяемых привилегий.

4) Язык управления транзакциями (Transaction Control Language, TCL) - позволяет контролировать процесс обработки транзакций в базе данных, где транзакция - это последовательность из одной или нескольких команд SQL, рассматривая СУБД как логическое неделимое целое.

Язык SQL является декларативным - это предполагает, что СУБД сама решает, какие операции необходимо выполнить для обработки запроса, в то время как программисту достаточно просто описать те данные, которые нужно извлечь или модифицировать. При этом стоит отметить, что при работе со сложными запросами возможны различные варианты их конструирования, дающие одинаковый результат, но в то же время выполняющиеся с разной скоростью.

Большим преимуществом языка SQL является то, что он по большей части не зависит от конкретной СУБД, благодаря наличию международного стандарта ANSI SQL-92. Тем не менее, существуют незначительные отличия диалектов это языка, связанные со спецификой различных СУБД.

Выбор языка SQL при разработке дипломного проекта обусловлен тем, что реализация проекта будет осуществляться непосредственно в рамках СУБД Microsoft Access, одним из инструментов управления которой является SQL.

3.2 Microsoft Visual Basic for Applications

Microsoft Visual Basic for Applications (VBA) - совокупность среды разработки и разновидности языка Visual Basic, получившая широкое распространение из-за включения в пакет Microsoft Office. VBA, как более простую реализацию VB, удобно использовать в тех случаях, когда необходимо быстро разработать прототип программы, написать макрос или приложение для базы данных. Отдельно стоит отметить, что созданные в VBA скрипты выполняются собственно в среде приложений Office. Инструменты среды разработки также позволяют визуально конструировать пользовательский интерфейс.

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

Вдобавок стоит упомянуть, что скорость работы приложений на VBA достаточно мала, поскольку реализация большинства встроенных функций языка осуществляется через библиотеку времени исполнения (runtime library), значительную часть времени работы которой занимает проверка и преобразование типов.

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

Возможно совмещение VBA с другими языками программирования, например C++, за счет реализации на нем только пользовательского интерфейса. В качестве функциональной части программы в таком случае выступают динамически подключаемые библиотеки (DLL).

При выборе VBA в качестве языка разработки программного обеспечения были учтены его сильные и слабые стороны. Сформулируем основные выводы:

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

- Функциональных возможностей языка VBA вполне достаточно для реализации дипломного проекта в короткие сроки.

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

3.3 Основные определения

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

Маршрут вызова - это именованное направление для терминации вызова. Обычно под маршрутом понимается наименование оператора связи.

Маршрутная таблица - упорядоченная совокупность строк и столбцов, отображающая определенную последовательность маршрутов для каждого телефонного направления.

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

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

Консолидированная таблица - сводная таблица тарифных предложений операторов связи.

4. Информационное обеспечение

В качестве информационного обеспечения подсистемы динамической маршрутизации вызовов выступают таблицы базы данных IP Studio AMBS и СУБД для работы с ней. Взаимодействие с приложением осуществляется при помощи драйвера MySQL Connector ODBC на платформе CentOS.

База данных (БД) - это совокупность хранимых взаимосвязанных данных, организованных в соответствии с некоторыми правилами для их просмотра, обработки и извлечения.

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

СУБД MySQL Server 5.0

MySQL - свободная реляционная система управления базами данных (СУБД), разработка и поддержка которой осуществляется компанией Oracle Corporation. Реляционная модель данных предполагает хранение нормализованных данных в виде взаимосвязанных двумерных таблиц для удобства представления. Как правило, MySQL используется в качестве сервера для удаленной работы пользователей или приложений. Достоинством такой модели использования является удобство централизованной обработки клиентских запросов сервером, доступность данных, их надежное и безопасное хранение.

СУБД написана на языках С и С++, распространяется с открытым программным кодом и работает на большинстве современных платформ. MySQL Server 5.0 поддерживает стандарт языка SQL ANSI 92. Для соединения с приложениями используется драйвер MyODBC. Многие языки программирования имеют библиотеки для доступа к базам данных MySQL в своих интерфейсах создания приложений (API).

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

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

5. Описание структуры данных

5.1 Этап 1. Формирование маршрутной таблицы

5.1.1 Структура входных данных

В качестве входных данных на этом этапе используются 5 таблиц системы IP Studio AMBS, загружаемых с сервера. Описания полей не документированы разработчиком системы, поэтому будут добавлены дополнительно, чтобы прояснить структуру формирования SQL-запросов.

1) AMBS_RATE_NAMES - таблица имен тарифов (рис. 6).

Рис. 6. Таблица AMBS_RATE_NAMES

Поля:

- ID - ключевое поле, код тарифного плана;

- RATENAME - имя тарифного плана;

- minsec, unpaidsec, discr_sec - параметры для определения числа нетарифицируемых при вызове секунд и округления в расчетах биллинговой системы, в проекте не использованы;

- TYPE - направление трафика (входящий/исходящий);

- SUBPAY - параметр расчетов биллинговой системы, в проекте не использован;

- CURRENCY - валюта тарифного плана;

- LAST_DATE - дата и время последнего обновления тарифного плана.

2) AMBS_RATES - дочерняя таблица AMBS_RATE_NAMES, содержащая различные характеристики тарифов (рис. 7).

Рис. 7. Таблица AMBS_RATES

Поля:

- ID - ключевое поле, уникальный идентификатор записи тарифного значения;

- CODE_ID - идентификатор телефонного кода;

- RATE_ID - код тарифного плана;

- PRICE - значение тарифа;

- RATE_DATE - начальная дата действия тарифа;

- TIME_ID, ROUND_ID - идентификаторы параметров расчетов биллинговой системы, в проекте не использованы;

- STOP_DATE - дата окончания действия тарифа;

- minsec, unpaidsec, discr_sec, round_sec - параметры для определения числа нетарифицируемых при вызове секунд и округления в расчетах биллинговой системы, в проекте не использованы;

- from_tm - начальная граница времени суток действия тарифа;

- to_tm - конечная граница времени суток действия тарифа;

- state - статус тарифа: действующий (0) или закрытый (1);

- fround, ncnt, close_hour - дополнительные временные параметры, в проекте не использованы;

- capacity - пропускная способность линии;

- GRP, DENY_GRP - коды групп, в проекте не использованы;

- TZ_ID - идентификатор временной зоны;

- DB_DATE - время создания или модификации записи;

- FEE_LIMIT - лимит платежа.

3) AMBS_DEST - таблица-справочник направлений (рис. 8).



Рис. 8. Таблица AMBS_DEST

Поля:

- ID - ключевое поле, уникальный идентификатор записи;

- DEST_NAME - наименование направления;

- COUNTRY_CODE - телефонный код страны;

- DEST_CODES - список телефонных кодов направления;

- CITY_NAME - название города;

- DEST_TYPE - тип направления: фиксированный, мобильный или спутниковый.

4) AMBS_DEST_CODE - дочерняя таблица AMBS_DEST, хранящая телефонные коды направлений (рис. 9).



Рис. 9. Таблица AMBS_DEST_CODE

Поля:

- DEST_ID - уникальный идентификатор направления;

- CODE - телефонный код направления.

5) AMBS_SITE - справочник маршрутов и их характеристик (рис. 10).

Рис. 10. Таблица AMBS_SITE

Поля:

- ID - ключевое поле, уникальный идентификатор записи;

- SITENAME - наименование маршрута.

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

5.1.2 Структура внутренних данных

Внутренними данными для работы программного модуля на первом этапе являются 4 локальные таблицы:

1) Offer_Consolidated_Item - таблица, создаваемая путем запроса на выборку полей и значений из пяти входных таблиц (рис. 11).

Рис. 11. Таблица Offer_Consolidated_Item

Поля:

- COUNTRY_CODE - телефонный код страны;

- DEST_TYPE - тип направления: фиксированный, мобильный или спутниковый;

- DEST_NAME - наименование направления;

- RouteName - наименование маршрута;

- Prefix - телефонный код направления;

- RateEff - тариф в рублях.

2) Offer_Consolidated - таблица с переменным количеством столбцов, содержащая актуальные тарифы операторов (рис. 12). После процедуры экстраполяции таблица становится консолидированной, так как заполняется недостающими значениями тарифов.

Рис. 12. Таблица Offer_Consolidated

Поля:

- Prefix - телефонный код направления.

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

3) Offer_Consolidated_Dest - справочная таблица направлений, используемая для установления ограничений в режиме экстраполяции (рис. 13).

Рис. 13. Таблица Offer_Consolidated_Dest

Поля:

- Prefix - телефонный код направления;

- DEST_NAME - наименование направления;

- DEST_TYPE - тип направления: фиксированный, мобильный или спутниковый;

- COUNTRY_CODE - телефонный код страны.

4) Route_List - таблица, содержащая список маршрутов для каждого телефонного кода (рис. 14).

Рис. 14. Таблица Route_List

Поля:

- Prefix - телефонный код направления;

- Rate 1-6 - минимальные тарифы в рублях, упорядоченные по возрастанию;

- Route 1-6 - операторы, предлагающие данные тарифы.

5) Route_Param - таблица, данные из которой в итоге загружаются на сервер AMBS и используются для маршрутизации звонков в сети IP-телефонии (рис. 15). Route_Param получается из таблицы Route_List переходом от телефонных кодов к названиям направлений для удобства работы с коммутаторами. Для одновременной загрузки на сервер доступны 3 маршрута.

Рис. 15. Таблица Route_Param

Поля:

- dest_id - цифровой системный код направления;

- DEST_NAME - наименование направления;

- first_route, second_route, third_route - уникальные цифровые системные коды данных операторов;

- Rate1-3 - упорядоченные по возрастанию минимальные тарифы в рублях;

- Route1-3 - операторы, предлагающие данные тарифы.

5.1.3 Структура выходных данных

Результатом работы программного модуля на этом этапе является загрузка составленных маршрутов на сервер в таблицу AMBS_rparam, используемую системой AMBS для управления коммутаторами (рис. 16).

Рис. 16. Таблица AMBS_rparam

Поля:

- dest_id - цифровой системный код направления;

- first_route, second_route, third_route - соответственно первый, второй и третий маршруты вызова по данному направлению.

Остальные поля содержат различные параметры маршрутизации, идентификаторы и коды записей; в проекте не используются.

5.2 Этап 2. Проверка качества связи

5.2.1 Структура входных данных

Для этого этапа входными данными служит таблица AMBS_CDR_CUR, содержащая данные тарификации состоявшихся соединений (CDR, Call Detail Record) в текущем месяце (рис. 17).

Рис. 17. Таблица AMBS_CDR_CUR

Поля:

- CID - уникальный идентификатор звонка;

- TBLTYPE - тип таблицы (содержит данные о нулевых или ненулевых соединениях);

- BILL_DATE - дата осуществления тарификации;

- SRC_PRICE - тариф продажи в валюте контракта;

- DST_PRICE - тариф покупки в валюте контракта;

- SRC_SYS_PRICE - тариф продажи в валюте системы (USD, доллары США);

- DST_SYS_PRICE - тариф покупки в валюте системы;

- SRC_SITE - наименование оператора-отправителя;

- DST_SITE - наименование оператора-получателя;

- SRC_OPER - код оператора-отправителя звонка;

- DST_OPER - код оператора-получателя звонка;

- SRC_DEST - телефонный код направления в прайсе продажи;

- DST_DEST - телефонный код направления в прайсе закупки;

- SRC_RID, DST_RID - параметры операторов-отправителей и получателей, в проекте не использованы;

- SCR_CODE - префикс в прайс-листе продажи;

- DST_CODE - префикс в прайс-листе закупки;

- MAX_CODE - максимальное значение префикса, в проекте не использовано;

- DST_NUMBER_BILL - полный телефонный номер;

- SRC_BILL_TIME - время тарификации у отправителя;

- DST_BILL_TIME - время тарификации у получателя;

- SRC_BILL_DATE - дата тарификации у отправителя;

- DST_BILL_DATE - дата тарификации у получателя;

- SERVER_ID - код сервера AMBS;

- VHOUR - код интервала времени суток;

- SUCC_FLAG - признак осуществления удачного соединения.

5.2.2 Структура внутренних данных

Tmp_Term_Stat - промежуточная таблица, в которую помещаются данные статистики с коммутаторов (рис. 18).



Рис. 18. Таблица Tmp_Term_Stat

Поля:

- FirstPrefix - первый телефонный код, закрепленный за направлением (используется в связи с тем, что число телефонных кодов у различных направлений может варьироваться);

- DEST_NAME - наименование направления;

- DEST_ID - уникальный идентификатор направления;

- RATE_ID - код тарифного плана;

- Terminator - оператор, принимающий звонок;

- Attempts - число попыток;

- Calls - число успешно осуществленных звонков по данному направлению;

- Minutes - общая длительность трафика по данному направлению;

- ASR - Answer Seizure Ratio, коэффициент дозвона;

- ACD - Average Call Duration, средняя продолжительность звонка.

5.2.3 Структура выходных данных

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

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

Блокировка выбранных маршрутов из таблицы Tmp_Term_Stat происходит путем изменения значений поля state с 0 на 1 в таблице AMBS_RATES на сервере.

6. Разработка алгоритма

В работе созданной подсистемы можно выделить следующие этапы:

1) Загрузка актуальных тарифов и направлений звонков из базы данных на сервере в таблицу Offer_Consolidated_Item;

2) Создание консолидированной таблицы предложений Offer_Consolidated с помощью SQL-запроса;

3) Создание справочной таблицы Offer_Consolidated_Dest, используемой программой для проведения экстраполяции тарифов;

4) Экстраполяция консолидированной таблицы Offer_Consolidated с помощью скрипта на VBA;

5) Формирование LCR-таблицы Route_List с помощью скрипта на VBA;

6) Создание таблицы Route_Param при помощи SQL-запроса путем перехода от телефонных кодов к названиям направлений;

7) Загрузка данных из таблицы Route_Param в маршрутную таблицу системы AMBS на сервере;

8) Анализ статистики с коммутатора путем получения детализированных записей обо всех соединениях (CDR), определение каналов с низкой пропускной способностью и формирование промежуточной демонстрационной таблицы Tmp_Term_Stat;

9) Корректировка базы данных в соответствии с полученной статистикой посредством пометок перегруженных каналов как недоступных.

Схема алгоритма изображена на рис. 19.



Рис. 19. Алгоритм работы приложения

7. Конструкторско-технологическая часть

7.1 Выбор программного обеспечения

7.1.1 Microsoft Office Access

Microsoft Access - реляционная система управления базами данных (СУБД), являющаяся одним из продуктов пакета Microsoft Office. MS Access относится к категории СУБД, ориентированных на конечных потребителей, поскольку ее возможности позволяют вести работу с базами данных, не имея навыков программирования. Как правило, Access используется для создания и эксплуатации настольных БД небольшого объема, а также для доступа к данным организации или предприятия, хранящимся на сервере.