где
- нагрузка создаваемая абонентами PSTN подключенными к
третьему шлюзу;
- нагрузка, создаваемая абонентами ISDN подключенными к
третьему шлюзу.
При этом данная нагрузка обрабатывается разными кодеками, их процентное соотношение было приведено выше.
Для кодека G.711:
Для кодека G.723 h/r:
Рассмотрим СМО с потерями.
Пользуясь калькулятором Эрланга, определим число соединений, необходимое для обслуживания нагрузки, обрабатываемой кодеком определенного типа (х), с условием, что вероятность потери вызовов ρ = 0,001:
Для кодека G.711: x = 73;
Для кодека G.723 h/r: x = 37;
Таким образом, транспортный поток на выходе кодеков
G.711 и G.723 h/r:
Тогда транспортный поток на выходе первого шлюза:
Нанесем полученные результаты на схему шлюза (рисунок
4.4).
Рисунок 4.4 - Распределение подключения абонентов
Общий транспортный поток в интерфейсе подключения
шлюзов к коммутатору доступа:
Рассмотрим СМО с ожиданием.
Определим λ для каждого вида кодека:
Теперь можно рассчитать общую интенсивность
поступления пакетов в канал:
Предельно допустимая задержка доставки IP-пакета от одного пользователя услуг VoIP к другому не должна превышать S = 100 мс.
Зная величину задержки и интенсивность поступления
заявок, определим интенсивность обслуживания заявок в канале:
Рассчитав значения интенсивности поступления и обслуживания заявок,
определим нагрузку канала:
Зная транспортный поток, поступающий в канал, и зная, что этот поток
может максимально нагружать канал на величину ρ, определим общий требуемый объем канала
τ:
4.2 Расчет основных параметров коммутатора
доступа
Возможны разные варианты построения сети ОбТС-П на железных дорогах. На сети ОбТС-П должны сохраниться магистральный и дорожный уровни иерархии. Внутри железной дороги должны быть образованы районы, в каждом из которых используется единая 5-значная нумерация. В пределах одного или нескольких районов должен быть центр технического обслуживания сети ОбТС-П. Количество районов сети ОбТС-П зависит от конкретной железной дороги. В частности один район может совпадать с одним отделением железной дороги. На рисунке 4.5 в качестве примера показана общая схема построения сети ОбТС-П на одной железной дороге с пятью районами. В каждом районе находятся устройства, управляющие соединениями: коммутаторы Softswitch и/или SIP-серверы, а также сервер конференцсвязи. На схеме для районов 1, 2 и 3 показаны только коммутаторы Softswitch, SIP-серверы и серверы конференцсвязи. На рисунке штрихпунктирные линии указывают на логические соединения между узлами сети и с узлами других сетей. Так, например, SIP-сервер района 2 может маршрутизировать вызовы к коммутаторам Softswitch районов 1 и 5 и к SIP-серверу района 4. Предполагается, что все узлы сети ОбТС-П включены в дорожную IP-сеть.
На дорожной сети в главном районе (на рисунке 4.5 - район 1), в котором находится Управление железной дороги, должен устанавливаться коммутатор Softswitch, выполняющий роль дорожного узла (ДУ). Этот коммутатор логически связан с SIP-серверами и коммутатором Softswitch других районов. Через него осуществляются соединения внутри района и между районами железной дороги, а также с другими дорожными узлами на магистральном уровне. Коммутатор Softswitch ДУ обеспечивает соединения с сетью общего пользования для абонентов района 1.
В других районах преимущественно должны устанавливаться SIP-серверы, а в наиболее крупных - коммутаторы Softswitch (на рисунке 4.5 - район 5). SIP-сервер или коммутатор Softswitch обслуживает вызовы внутри одного района, устанавливая соединения между абонентами этого района и внешние соединения с другими районами сети ОбТС-П и с сетью ОП. Эти же устройства устанавливают транзитные соединения между районами. В каждом районе для включения аналоговых телефонных аппаратов должны применяться шлюзы различной емкости, распределяемые по разным железнодорожным станциям. Шлюзы логически связаны с SIP-сервером или коммутатором Softswitch. Возможен вариант объединения шлюзов с управлением от контроллера MGC по протоколу MGCP адаптеры.
Как видно из рисунка 4.5, на сети ОбТС-П предусматривается не менее двух маршрутов установления соединений между районами, что повышает живучесть сети и предотвращает перегрузки отдельных SIP-серверов и коммутаторов Softswitch при установлении транзитных соединений.
В каждом районном центре или в одном центре, обслуживающем несколько
районов, должны устанавливаться серверы конференцсвязи, с помощью которых
организуются аудио конференции для абонентов одного и/или разных районов.
Ресурсы конференц-серверов могут быть распределены между сетями ОбТС и ОТС.
Рисунок 4.5 - Пример построения сети ОбТС-П
Взаимодействие с сетью ОП должно происходить в каждом районе на местном уровне. Управление соединениями с сетью ОП должно осуществляться SIP-сервером или коммутатором Softswitch соответствующего района. Если телефонная сеть ОП является пакетной, то SIP-сервер или коммутатор Softswitch сети ОбТС обменивается сигнальной информацией с узлом управления сети ОП, например, с коммутатором Softswitch сети ОП (на рисунке 3.6 - район 4). С целью пропуска речевого и сигнального трафика IP-сеть ОбТС должна быть напрямую связана с IP-сетью ОП (на рисунке 4.5 - IP-сети не показаны). При взаимодействии с TDM-сетью ОП, должны использоваться шлюзы соединительных линий, причем в одном районе может быть несколько точек присоединения к сети ОП (на рисунке 4.5 для района 5 показаны две точки присоединения). На сети ОП каждая точка присоединения организуется для отдельной АТС.
Для сети ОбТС характерно множество железнодорожных станций небольшой емкости, расположенных вдоль одной линии. Доступ пользователей этих станций к IP-сети железной дороги может осуществляться разными способами. Рассмотрим варианты сети доступа с применением цифровых линий xDSL и коммутаторов локальной сети.
Расчет нагрузки создаваемой IP абонентами (SH и LAN) производится аналогично шлюзу. При этом необходимо учитывать, что кодек встроен в аппарат и всю работу он выполняет индивидуально для абонента.
Общая нагрузка, создаваемая абонентами SH:
где
- количество абонентов SH;
- удельная нагрузка на одну абонентскую линию.
Общая нагрузка, создаваемая абонентами LAN:
где
- количество абонентов LAN;
- удельная нагрузка на одну абонентскую линию.
Нагрузка обрабатывается разными кодеками.
Требуемое число соединений:
Транспортный поток на выходе кодека:
Тогда общий транспортный поток:
Требуемый объем канала:
Для передачи сигнального трафика создается отдельный логический канал, параметры которого необходимо определить.
Протокол управления транспортным шлюзом H.248/Megaco является развитием протокола MGCP. Так же, как и протокол MGCP, он является внутренним протоколом, который работает между функциональными блоками распределенного шлюза, а именно - между MGC и MG. Принцип действия этого протокола тот же - master/slave (ведущий/ведомый). Устройство управления MGC является ведущим, а транспортный шлюз MG - ведомым, т.е. шлюз MG выполняет команды, которые поступают к нему от устройства управления.
В коммутаторе доступа для обмена сообщениями протокола MEGACO,
используемого для управления шлюзом, должен быть предусмотрен транспортный
ресурс, который определяется формулой:
где общее количество абонентов, подключенных при помощи сетей LAN, PBX и V5, а также аналоговых PSTN и цифровых ISDN абонентов и ранее рассчитанные значения.
Примем значение ksig = 5, что соответствует нагрузке в 0,2 Эрл, т.е. одна пятая часть времени сеанса тратится на передачу сигнальной информации.
Для передачи сигнальной информации с целью обслуживания вызовов различных типов требуются следующие размеры полосы пропускания:
Где LV5UA - средняя длина сообщения протокола V5UA;V5UA - среднее количество сообщений протокола V5UA при обслуживании одного вызова;IUA - средняя длина сообщения протокола IUA;IUA - среднее количество сообщений протокола IUA при обслуживании одного вызова;SH - средняя длина сообщения протоколов SIP/H.323;SH - среднее количество сообщений протоколов SIP/H.323 при обслуживании одного вызова.
Общий поток сигнальной информации:
Общая требуемая пропускная способность коммутатора доступа:
Результаты расчетов приведены на рисунке 4.5.
Рисунок 4.6 - Распределение потоков данных коммутатора доступа
4.3 Расчет оборудования гибкого коммутатора
Основной задачей гибкого коммутатора при построении распределенного абонентского концентратора является обработка сигнальной информации обслуживания вызова и управление установлением соединений.
Рассчитаем общую интенсивность потока вызовов от источников всех типов,
обрабатываемых гибким коммутатором:
Теперь определим нижний предел производительности гибкого коммутатора при
обслуживании потока вызовов с интенсивностью PCALL:
где
,
,
,
- поправочные коэффициенты для каждого вида абонентов.
Общий поток сигнальной информации, поступающий через коммутатор доступа и
рассчитанный ранее:
Рисунок 4.7 - Распределение сигнальных потоков распределенного
абонентского концентратора
5.
РАСЧЕТ ТРАНСПОРТНОГО РЕСУРСА, НЕОБХОДИМОГО ДЛЯ ВЗАИМОДЕЙСТВИЯ СЕТЕВЫХ ЭЛЕМЕНТОВ
5.1 Расчет оборудования транспортных шлюзов
Общая нагрузка между сетями ОбТС и ТфОП:
Определим необходимое число потоков E1 для обслуживания данной нагрузки.
Пользуясь первой формулой Эрланга или одноименным калькулятором определяем число линий, необходимых для облуживания данной нагрузки при вероятности потерь 0,001: x = 68. Это соответствует числу первичных потоков 68 / 30 = 2,267 ≈ 3Е1.
С учетом 20% запаса число линий увеличивается до 68∙1,2 = 81,6 ≈
82. Соответственно требуемое число потоков E1 составит:
Округляем до 4Е1 так как в одной плате содержится 2 потока Е1, то есть количество каналов четное.
Удельная нагрузка на один канал 64 кбит/с в потоке E1 составит:
Рассчитаем общую нагрузку с учетом резерва, поступающую на транспортный
шлюз от АТС ТфОП:
Нагрузка обрабатывается разными кодеками:
Требуемое число соединений:
Транспортный поток на выходе кодека:
Тогда общий транспортный поток:
Требуемый объем канала:
Рассчитаем транспортный ресурс, необходимый для передачи сообщений
протокола MEGACO:
Таким образом, общий транспортный ресурс MGW будет равен:
Результаты расчетов приведены на рисунке 5.1.
Рисунок 5.1 - Распределение потоков данных транзитного коммутатора
доступа
5.2 Расчет оборудования гибкого коммутатора
Интенсивность потока вызовов, поступающих на транспортный шлюз,
определяется формулой:
Интенсивность потока вызовов, поступающих на гибкий коммутатор:
В рассчитываемой нами сети количество шлюзов L = 1, следовательно, значения PSX и Pl_GW будут совпадать: