Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
66
Добавлен:
14.04.2015
Размер:
14.22 Mб
Скачать

9.5.3. Распределенная структура убс

Важным аспектом рассмотрения структуры УБС является определение возможно­сти распределения ее элементов по сети связи. Как мы упоминали выше, для оказа­ния широкого спектра услуг биллинга одновременно для пользователей различных сетей связи предлагается использовать два типа узлов услуг: центральный (CBSN) и периферийные (PBSN). Важно отметить, что в части реализации процесса съема и обработки CDR нет необходимости в распределении узлов предоставления услуг биллинга по узлам телекоммуникационной сети, поскольку этот процесс не зависит от расположения узла биллинга. Единственным ограничением является производи­тельность узла. Однако это ограничение может быть снято реализацией скорее рас­пределенной обработки информации, нежели разнесением узлов.

Более важным фактором при решении вопроса разнесения узлов является необ­ходимость обработки запросов в реальном времени. Запросы, формирующие CDR, приходят с узлов оказания услуг, в частности с узлов ГИС. Поэтому для реализации процесса обработки запросов в реальном времени необходимо или иметь бы­струю сеть передачи этих запросов, или размещать PBCN в переферийных узлах ГИС. В отличие от CBSN, в PBSN достаточно иметь только пункты SSP и SCP. В отдельных случаях на этих узлах может иметься пункт поддержки данных (SDP) в полном или ограниченном объеме. Однако в PBSN отсутствуют пункты SMP, SCEP, SMAP. Реализация функций этих пунктов в PBCN осуществляется удаленно через соответствующие шлюзы на основе соответствующих запросов и сообще­ний. Аналогичным образом осуществляется доступ к SDP CBSN при отсутствии его на PBSN.

CBSN и PBSN подключаются к сетям связи через систему соответствующих шлюзов. Шлюзы различаются по типу сети, с которой они взаимодействуют, и каж­дый из них может осуществлять взаимодействие с сетью связи по виду реализуе­мой функции, а именно по запросам или записям.

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

9.5.4. Принципы взаимодействия гис с сетью связи

Для рассмотрения принципов взаимодействия ГИС с сетью связи, межузлового взаимодействия, а также взаимодействия функциональных составляющих в рамках узла необходимо определить контент этого взаимодействия, его протоколы и ин­терфейсы [5].

Как было показано выше, в части обработки CDR УБС взаимодействует только с узлами коммутации и маршрутизации телекоммуникационной сети и, следова­тельно, не зависит от способов построения сети и взаимодействия между этими уз­лами. При обработке запросов от узлов предоставления услуг аналогичная ситуа­ция сохраняется для CBSN и PBSN в рамках этих узлов, однако имеется корреля­ция со способами построения телекоммуникационной сети в случае их взаимодей­ствия, в том числе в зависимости от «развитости» сети.

Как и ранее, мы предполагаем, что телефонная сеть не однородна, т.е. построе­на на основе широкого спектра коммутационных систем и каналов связи. Однако либо коммутационные системы должны иметь программно-аппаратные средства для накопления CDR, либо все вызовы с АТС, которые не имеют таких средств, должны соединяться через коммутационный узел, имеющий эти средства. Наличие соответствующих программно-аппаратных средств предполагает доступ к ним по каналам связи. Таким образом, шлюз GOt SSP (рис.9.5) может быть реализован на основе канального модема, а обмен информацией между этим шлюзом и программ­но-аппаратными средствами накопления CDR может осуществляться по протоколу Х.25. Что касается коммутатора мобильной сети, то для передачи файла CDR мо­жет быть использован также протокол Х.25, а для передачи CDR в режиме on-line при наличии сети ОКС №7 — протокол INAP. Как мы упоминали выше, для систем подвижной связи третьего поколения, базирующихся на подходе, который предусматривает использование двух технологий: коммутацию каналов и коммутацию пакетов. Таким образом, одни и те же сетевые ресурсы будут использоваться для съема CDR обеих сетей.

Для сбора CDR с серверов доступа сети пакетной коммутации (например, CDR постоянного доступа в сеть Интернет, а также CDR Интернет-сервисов) шлюз GOi SSP (см. рис. 5.5) должен поддерживать протокол NetFlow, поскольку данная технология используется большинством производителей. Кроме того, мно­гие производители серверов доступа используют собственные протоколы обмена для съема CDR суммарного трафика (например, IP Accounting для аппаратуры фирмы Cisco).

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

В части обработки запросов предоставления услуг телефонной или подвижной сети SCP биллинга должен иметь шлюз GHt. Как уже говорилось выше, могут быть два источника запросов. В первом случае источником запроса может быть SCP не­которой внешней ИСС или SCP другого узла ГИС, а получателем — SCP рассмат­риваемого узла биллинга. При запросах от других узлов ГИС может быть использо­ваны два варианта. В случае развитой сети, когда между узлами сети, к которым подключены узлы ГИС, используется сигнализация ОКС №7, применяется прото­кол IN АР. Когда между узлами сети связи используются другие виды сигнализа­ции, необходим выделенный межстанционный канал, по которому передаются эти запросы. В этом случае целесообразно использовать протокол Х.25.

Во втором случае, когда SSP УБС и SSP ГИС имеют единую локальную сеть, для обработки запросов биллинга услуг телефонной и подвижной сетей с шлюзами достаточно поддерживать протокол ТСРЛР.

Для биллинга услуг сетей пакетной коммутации, например коммутируемого доступа в Интернет или IP-телефонии, шлюз GHi должен поддерживать протокол Radius.

Важный вопрос при рассмотрении вопросов взаимодействия процессов обра­ботки вызовов — вопрос внутреннего взаимодействия между пунктами CDSN, т.е. взаимодействия (в терминах КТ) между серверами предоставления услуг и сервера­ми приложений. В соответствии с большинством известных стандартов (например, NAGTAP2 для биллинговых систем) эти серверы легко объединяются в локальную сеть на основе протокола TCP/IP.

Соседние файлы в папке OBTKC-12