182 |
ГЛАВА 5 |
|
|
сматривает использование двух технологий: коммутацию каналов и коммутацию пакетов. Таким образом, одни и те же сетевые ресурсы будут использоваться для съема CDR обеих сетей.
Для сбора CDR с серверов доступа сети пакетной коммутации (например,
CDR постоянного доступа в сеть Интернет, а также CDR Интернет-сервисов) шлюз GOi SSP (см. рис. 5.5) должен поддерживать протокол NetFlow, поскольку
данная технология используется большинством производителей. Кроме того, мно-
гие производители серверов доступа используют собственные протоколы обмена для съема CDR суммарного трафика (например, IP Accounting для аппаратуры фирмы Cisco).
Подход, которого автор придерживается в настоящей книге, заключается в вы- делении узла услуг как интеллектуальной надстройки над всеми видами сетей, что дает возможность использовать весь набор существующих протоколов и интерфей- сов для взаимодействия системы биллинга и ГИС.
В части обработки запросов предоставления услуг телефонной или подвижной сети SСP биллинга должен иметь шлюз GHt. Как уже говорилось выше, могут быть два источника запросов. В первом случае источником запроса может быть SCP не- которой внешней ИСС или SCP другого узла ГИС, а получателем — SCP рассмат- риваемого узла биллинга. При запросах от других узлов ГИС может быть использо- ваны два варианта. В случае развитой сети, когда между узлами сети, к которым подключены узлы ГИС, используется сигнализация ОКС №7, применяется прото- кол INAP. Когда между узлами сети связи используются другие виды сигнализа- ции, необходим выделенный межстанционный канал, по которому передаются эти запросы. В этом случае целесообразно использовать протокол X.25.
Во втором случае, когда SSP УБС и SSP ГИС имеют единую локальную сеть, для обработки запросов биллинга услуг телефонной и подвижной сетей с шлюзами достаточно поддерживать протокол TCP/IP.
Для биллинга услуг сетей пакетной коммутации, например коммутируемого
доступа в Интернет или IP-телефонии, шлюз GHi должен поддерживать протокол
Radius.
Важный вопрос при рассмотрении вопросов взаимодействия процессов обра- ботки вызовов — вопрос внутреннего взаимодействия между пунктами CDSN, т.е. взаимодействия (в терминах КТ) между серверами предоставления услуг и сервера- ми приложений. В соответствии с большинством известных стандартов (например,
NAGTAP2 для биллинговых систем) эти сервера легко объединяются в локальную сеть на основе протокола TCP/IP.
5.2. Функциональные компоненты биллинговых систем
В главе 4 были определены основные технологические принципы универсального биллинга, которые должны быть реализованы представленной в этой главе концеп- туальной моделью. В основе такой модели лежит создание логики услуг, которая, в свою очередь, основана на выборе модели услуги как с точки зрения поставленной
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
183 |
|
|
задачи, так и с точки зрения возможности реализации услуги средствами, имеющи- мися в распоряжении УБС, и оборудования, предоставляющего услуги связи, что определяется набором функциональных компонент.
Каждая из функциональных компонент должна быть определена в трех облас- тях: в области функциональных свойств, в области допустимых значений входной информации (описаний точек входа — POI) и в области допустимых значений вы- ходной информации (описаний точек выхода — POR).
Исходя из изложенных выше принципов построения универсальной УБС, плос- кость услуг ее информационного уровня (ИУ) должна включать в себя следующие основные технологии реализации функциональных компонент:
–авторизация пользователя по номеру терминала или паролю доступа;
–генерация платежных инструментов и их поддержку;
–ведение счетов платежных инструментов;
–генерация текущих и лицевых счетов;
–ведение лицевых счетов пользователя;
–ведение текущих счетов пользователей;
–создание CDR (для режима hot-line);
–съем и предобработка CDR (для режимов on-line и off-line);
–тарификация CDR (для всех режимов биллинга);
–генерация отчетов (для всех режимов биллинга).
Кроме того, ИУ системы универсального биллинга в рамках создания и под- держки услуг должен включать в себя:
–взаимодействие с КУ;
–статистическую обработку накопленной информации;
–мониторинг системы биллинга;
–программно-техническую поддержку.
Необходимо еще раз обратить внимание, что перечисленные выше компоненты могут отличаться для биллинга услуг различных сетей связи как в части содержа- ния однотипных операций, из которых они состоят, так и в части последовательно- сти выполнения этих операций.
На клиентском уровне (КУ) система универсального биллинга должна включать
всебя следующие технологии:
–организация взаиморасчетов с пользователями и партнерами;
–ведение бухгалтерского учета;
–поддержка административных и информационных служб оператора;
–поддержка технических служб оператора.
Вопросы реализации технологий вспомогательного уровня и его взаимодейст- вие с основным уровнем будут рассмотрены ниже.
Несколько в стороне от данной темы стоит функциональная компонента генера- ции пин-кодов платежных инструментов. Такая компонента, хотя и косвенно, отно- сится к процессу биллинга и является практически обязательной компонентой бил- линговых систем, осуществляющих расчеты по скретч-картам. Учитывая это, дан- ный вопрос вынесен в Приложение 5.2.
184 |
ГЛАВА 5 |
|
|
5.2.1. Аутентификация и авторизация
Под аутентификацией обычно понимают принадлежность пользователя к системе предоставления услуг, а под авторизацией пользователя, как и ранее, подразумева- ется проверка прав пользователя на получение услуг, выполняемая по номеру тер- минала или паролю доступа.
Для режимов on-line и off-line при предоставлении услуги производится аутен- тификация при записи CDR в системах коммутации (номер телефона) или в систе- мах маршрутизации (IP-адрес), а затем авторизация при обработке CDR в SCP сис- темы биллинга. В режиме hot-line аутентификация и авторизация должна произво- дится самой биллинговой системой при создании CDR. При этом аутентификация и авторизация могут производиться как виде единой операции, так и последователь- но. При последовательном запросе сначала определяется принадлежность абонента к данной системе предоставления услуг, а затем, когда абонент производит запрос услуги, в рамках авторизации определяется его права на пользование данной услу- гой (т.е. открыта или нет услуга для использования данным абонентом) и финансо- вые возможности абонента для получения запрашиваемой услуги. В случаях, когда первоначально известен и абонент, и запрашиваемая услуга, аутентификация и ав- торизация выполняются одновременно.
Как говорилось выше, аутентификация проводится по запросам из ГИС, при этом в случае аутентификации по номеру телефона (что справедливо как для сис- тем с коммутацией каналов, так и для систем IP-телефонии) этот номер пересылает- ся из ГИС в SCP УБС. Если система взаимодействия ГИС с оборудованием опера- тора не предусматривает автоматического опознавания номера вызывающего або- нента, то аутентификация по номеру телефона в режиме hot-line невозможна.
Различают два типа аутентификации по паролю доступа в режиме hot-line. Для сетей с коммутацией каналов и IP-телефонии авторизация по паролю доступа про- изводится набором числового пароля (пин-кода). Для предоставления dial-up досту- па к сети Интернет аутентификация может осуществляться передачей так называе- мого логина и пароля. При этом для пользователей, ранее зарегистрированных в системе (например, путем заключения договора с оператором), введенные логин и пароль сравниваются с хранимыми в системе. Для пользователей, которые впервые оплачивают услугу по карте, аутентификация реализуется путем передачи номера платежного документа, при этом логин соответствуют номеру платежного доку- мента, а пароль — пин-коду. При этом, если каждой из услуг соответствует свой номер доступа или свой шлюз, то аутентификация и авторизация производится од- новременно.
Аутентификация и авторизация осуществляется с использованием функций
RqCF, RqCAF, UIF, ISRF и ISRF.
Аутентификация по паролю доступа для услуг сетей с коммутацией каналов мо- жет быть представлена совокупностью следующих операций:
–прием пароля доступа;
–анализ пароля доступа (например, путем запроса в базу данных);
–ответ о результате аутентификации.
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
185 |
|
|
Аутентификация для услуг сетей пакетной коммутацией может содержать до- полнительную операцию, если пароль доступа представлен совокупности логина и пароля. В этом случае, например, дополнительной промежуточной операцией мо- жет быть поиск пароля доступа по логину и паролю.
5.2.2. Ведение счетов
При реализации универсальной логики услуг необходимо наличие в УБС средств отражения состояния текущих взаиморасчетов как по платежным инструментам, так и по договорам с пользователями и партнерами. Такими средствами являются счета пользователей и партнеров в системе биллинга. Для универсальной логики услуг необходима многоуровневая система счетов (рис. 5.6), которая может быть избыточна для случаев, например, отсутствия расчетов по платежным инструмен- там, или в случаях, когда оператор оказывает одну услугу. Для универсального биллинга целесообразно использовать предлагаемую систему счетов.
Рис. 5.6. Многоуровневая система счетов
Верхний уровень — лицевые счета (в терминологии главы 4 — Lb). Лицевые сче- та могут быть персональные (Lbp), т.е. содержать все атрибуты пользователя-персо-
ны, или неперсонифицированные (Lbu), т.е. не содержащие этих атрибутов. Анало- гичное разделение можно ввести и для платежных инструментов: персональные (Cp) для кредитных платежных документов и «на предъявителя» (Cu) для дебетовых.