3.3.4. Создание логики услуг

Создание логики услуг базируется на функциях среды создания услуг (SCEF), управления событиями (ECF) и поддержки данных услуг (SDF). Таким образом, созданная в SMP и информационно поддерживаемая SDP логика услуг реализуется в пункте управления услугами (SCP). Существуют два подхода к созданию логики услуг. Первый подход заключается в разработке индивидуальной логики каждой услуги и доработке ее при необходимости создания новой услуги. Второй подход заключается в построении такой логики услуги, который позволяет, создав некото- рую универсальную логику, путем исключения из нее отдельных компонент полу- чать требуемый спектр услуг. Первый подход часто используют при создании логи- ки услуг для классических ИСС, а второй — более пригоден для создания логики услуг в приложениях компьютерной телефонии. Поскольку мы ориентируемся на реализацию ГИС средствами компьютерной телефонии, видимо, использование второго подхода было бы предпочтительным. Однако, как показали практические попытки реализации такого подхода «в чистом виде», разработка полностью уни- версальной логики услуги не ведет к оптимизации процесса создания спектра ус- луг. Более простым и оптимальным оказался подход, при котором разработка уни- версальной логики ведется в пределах некоторого определенного класса услуг.

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

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

–транзитные транспортные услуги;

–оконечные услуги;

–дополнительные услуги передачи данных.

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

Транзитные транспортные услуги. Если рассмотреть услуги, которые мы от-

носим к транзитным транспортным услугам, например, сокращенный набор (Abbreviated Dialing, ABD), направленный вызов (Call Forwarding, CF), конференция (Conferencing, CON), универсальный номер (Universal Access Number, UAN), виртуаль-

ная сеть (Virtual Private Network, VPN), услуги доступа к сетям передачи данных и другие аналогичные услуги, то из анализа свойств этих услуг видно, что они могут состоять из набора одних и тех же функциональных компонент. Практически все перечисленные выше простые услуги реализуются, как следует из описания ГИС, как услуги обработки вызовов. Поэтому, как следует из вышеизложенного, реализа- ция логики услуг осуществляется на основе функциональных компонент участвую-

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

Набор функциональных компонент транспортных услуг конечен и реализуется несколькими типами функциональных блоков. Как уже указывалось выше, можно выделить простые (Sf) и составные (SF) функциональные компоненты. Так, напри- мер, для сетей с коммутацией каналов можно определить следующий набор этих компонент: Sf11 — соединение, SF11 — обработка вызова, SF12 — анализ информа- ции вызова (вид услуги, атрибуты вызывающего и вызываемого пользователя), SF13

— запрос информации по услуге, SF14 — принятие решения, SF15 — выдача управ- ляющего воздействия коммутационному оборудованию, Sf12 — отключение услуги.

Рассмотрим конкретный пример, а именно, проектирование услуги VAN. Для реализации этой услуги некоторому пользователю выделяется многоканальный те- лефонный номер, с которого в зависимости от заданных параметров, например по времени суток, необходимо осуществить переадресацию на заданные номера теле- фонов. Функциональная компонента Sf11, осуществив соединение, вызывает SF11, которая фиксирует вызываемый номер (т.е. набранный абонентом номер многока- нального телефона, а также, если это возможно, номер вызывающего абонента), SF12 определяет, что это услуга VAN, и производит запрос по данной услуге (SF13) к базе данных, передавая в виде элементов запроса принятую информацию. SF14 анализирует параметры переадресации и получает номер, на который необходимо переадресовать вызов. (Реально SF13 и SF14 могут представлять единую компонен- ту, которая в терминах взаимодействия с базами данных реализуется в виде храни- мой процедуры.) При этом, если в услуги заложены возможности переадресации в зависимости не только от времени суток, но и от номера телефона вызывающего абонента, то это также отражается на выборе номера телефона переадресации. Да- лее SF15 передает номер телефона переадресации коммутационному оборудованию, а функция Sf12 регулирует отключение услуги.

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

Логика каждой из вышеперечисленных услуг строится также на основе функ- циональных компонент и, как упоминалось выше, их отдельного класса — функ- циональных ресурсов. Необходимо иметь в виду, что в отличие от ИСС функцио- нальные компоненты событий разделяются на компоненты по обработке вызовов, запросов и сообщений. Кроме того, каждая из них может относиться как к сетям с коммутацией каналов, так и к сетям пакетной коммутации. Таким образом, хотя на- бор функциональных компонент, как и в случае транзитных услуг, конечен, но их количество значительно больше.

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

Первый пример — реализация совокупной услуги аудиотекса по опросу (теле- голосованию). Технология услуги заключается в том, что при проведении услуги

телеголосования абонент дополнительно в диалоговом режиме передает информа- цию о себе (принцип социологического опроса). На рис. 3.10 приводится состав и последовательность действия функциональных компонент (функциональный алго- ритм). В создании логики данной услуги участвуют как функциональные компо- ненты вызовов, так и ресурсы. Обработка вызова заключается или в приеме «ре- зультата голосования» — вызываемого номера телефона или, в случае единого те- лефона, приеме дополнительной цифры. Далее в зависимости от компоненты «ус- ловия вызова ресурса» (CR) подключается речевой ресурс, воспроизводящий во- прос. Функциональные компоненты приема цифр ответа на вопрос и записи этой информации позволяют зафиксировать ответ в базе данных, а затем вновь перейти к условию вызова ресурса. Данная логика услуг является универсальной для мно- гих услуг аудиотекса и других аналогичных услуг.

Рис. 3.10. Функциональный алгоритм услуги «телеголосование»

Второй пример — реализация стандартной услуги call-центра (рис. 3.11). На- помним, что под стандартной услугой call-центра мы понимаем услугу распределе- ния вызовов по рабочим местам операторов-телефонисток с выдачей им макси- мально возможной информации о звонящем абоненте, а также предоставления дос-

тупа к различным информационным базам данных с тем, чтобы оператор дал ответ абоненту на его запрос. Показанный на рис. 3.11 набор функциональных компонент будет одинаков независимо от того, на каких принципах (коммутации каналов или пакетной коммутации) будет реализован call-центр. Надо отметить, что различные дополнительные услуги call-центра, например, автоинформатор, передача факсов и другие услуги, могут быть реализованы также набором дополнительных функцио- нальных компонент и ресурсов из первого примера.

Рис. 3.11. Функциональный алгоритм услуги «call-центр»

Третий пример — услуга по обмену электронными сообщениями с выводом этих сообщений в виде SMS и на пейджер. Качественный характер услуги заключа- ется в том, что сообщения, пришедшие на электронный адрес абонента, отсылают- ся ему на пейджер или как SMS на его мобильный телефон, а сообщения, пришед- шие в абоненту в виде SMS, пересылаются в виде E-mail на его электронный адрес. Исходными данными для реализации логики данной услуги является занесенная в базу данных информация об адресах, указанных пользователем для входящих и ис- ходящих сообщений. На рис. 3.12 показана одна из возможных реализаций логики этой услуги. В качестве ресурсов для создания логики этого типа услуг являются функции приема того или иного типа сообщений, преобразования их в формат дру- гого типа сообщений и подготовка к их отправке абоненту. Данный пример может служить образцом для создания логики услуг, связанных с обработкой сообщений.

Рис. 3.12. Функциональный алгоритм услуги «обмен сообщениями»

Дополнительные услуги передачи данных. К дополнительным услугам пе-

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