В спецификациях AIN/0.0 предусмотрено до 75 речевых уведомлений. Эти спецификации базируются на ANSI-варианте подсистемы ТСАР (Transaction capabilities application part) версии 1 и предусматривают единственное сообщение ТСАР для всех трех триггер-ных точек.

1.1.5.2 Архитектура AIN/0.1

AIN/0.1 имеетдва основных отличия от AIN/0.0. Первое отличие -формальная модель процесса обслуживания вызова, второе - набор сообщений между коммутационной станцией и SCP. Модель процессав AIN/0.1 разделена на две части - исходящую и входящую, в отличие от AINO.O, где исходящая и входящая стороны не различались.

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

Увеличение числа триггерныхточек расширяет возможности воздействия на процесс обслуживания вызова со стороны логики услуг, находящейся в SCP. В качестве дополнительной функции SCP получил возможность активизировать и деактивизировать триггерные точки в коммутационной системе, а также следить за состоянием ее ресурсов. Кроме передачи инструкций для маршрутизации, SCP может поручить SSP следить за состоянием определенной абонентской линии (свободна она или занята) и сообщать ему об изменении ее состояния. Спецификация AIN/0.1 поддерживает все стандартные возможности ISDN (конечно, определенные ANSI).

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

Спецификации AIN/0.1 основаны на ANSI-варианте ТСАР версии 2, в которой набор сообщений отличается от набора сообщений предыдущей версии. Если первой версией предусматривалось одно сообщение от SSP к SCP для всех триггерных точек, то во второй версии ТСАР определены отдельные сообщения для каждой изчетырехтриг-герных точек процесса обслуживания на исходящей стороне и одно - для триггерной точки процесса на входящей стороне.

1.1.5.3 Архитектура AIN/0.2

Несмотря на то, что основным стимулом разработки спецификации AIN/0.2 было желание поддержать услугу персональной свя-

зи PCS (Personal communication service) и возможность приема от абонента цифр номера речевым способом VAD (Voice activated dialling), все требования к архитектуре остались независимыми от вида услуг.

Основными особенностями BTopoi?i фазы спецификаци!?! стали интерфе1?1с между коммутационно!?! станцие:?! и внешним устро1?1ст-вом, например, IP, и новые триггерные точки - «занятость абонента» и «отсутствие ответа». Еще одно нововведение - обработка списка событи1?1. Для этого, кроме триггерныхточек, были определены точки обнаружения событий (EDP - Event detection points). Теперь SCP мог передать в SSP список тех событи1?1, которые тот должен отслеживать в процессе организации связи, и, в случае их возникновения, уведомлять об этом SCP. Примерами таких событи1?1 могут быть занятость вызываемого абонента, отсутствие ответа, доступность ресурса и т.д.

AIN/0.2 предусматривает также, для определенных ситуаци!?!, маршрутизацию вызовов по умолчанию. Это означает, что в случае c6oi?iHoi?i ситуации вызов, вместо обычного отказа в обслуживании, может быть автоматически направлен на заданньм заранее номер, или же абоненту может быть передано речевое извещение о причине отказа. Архитектура AIN/0.1, каки AIN/0.0, предполагала, что речевые извещения обеспечиваются ресурсами коммутационно!?! станции, т.е. SSP. С введением AIN/0.2 появилась возможность размещать такие извещения в отдельно стоящем внешнем оборудовании, а именно в интеллектуально!?! периферии IP.

1.1.6 Стандартизация назрела

в течение первого десятилетия своего существования IN была чисто американским феноменом, что легко объясняется ранним возникновением конкуренции на рынке услуг связи США, уникально!?! ситуацие!?! с разделением компании AT&T, быстрым введением се-Tei?! ОКС и использованием решени!?!, основанных на применении сетевых баз данных.

Однако в конце 80-х годов, после того как ITU-T принял международные стандарты для системы сигнализации ОКС-7, и когда появились первые признаки конкуренции в отрасли связи в Старом Свете, некоторые европейские страны ввели в своих сетях новые услуги на базе технологии, аналогичной той, которая существовала на ранней стадии развития IN в США. Американские производители вышли на европейский рынок и создали в отдельных странах (Англия - 1988; Италия и Испания - 1991) сети IN в соответствии с Североамериканскими стандартами. В Японии компания NTT ввела архитектуру с сетевой базой данных в 1985 году.

Некоторые из новых услуг (VPN, Calling Card) no CBoei?i природе требовали международно:?! стандартизации. Следуя требованиям времени, ITU-T в 1989 году начал разработку серии рекомендаци!?! для Интеллектуально!?! сети. Ставилась задача создать концепцию, которая могла бы стать ochoboi?! для едино:?!, в мировом масштабе, архитектуры IN. Такая архитектура должна была определить сетевые элементы, функциональные объекты, модели программных процессов, машины состояни!?! и протоколы, которые могли бы быть сравнительно просто интегрированы в существующие телефонные сети.

Аналогично тому, как это было при стандартизации протоколов сигнализации, процесс стандартизации IN предполагает поэтапную разработку спецификаци!?! серии Q.1200. На каждом этапе разрабатывается пакет рекомендаци!?!, специфицирующи!?! некоторьм набор возможностей создания и предоставления услуг с определенными атрибутами. Специфицировать сами услуги в ITU-T, как правило, не предполагается, чтобы оставить на рынке услуг место для конкуренции производителей и операторов. К настоящему времени ITU-T выпустил рекомендации для наборов возможностей, предусматриваемых на двух первых этапах развития IN, - наборов CS-1 и CS-2. Готовится выпуск рекомендаций для CS-3, а с 2000 года началась работа над CS-4.

Рекомендации, относящиеся к CS-1, имеют номера Q.121X. Работа над ними велась с 1989 года. Первая версия спецификаций была одобрена в 1992 году, после чего они были пересмотрены в 1995 году. Услуги, которые должен поддерживать набор CS-1, ограничены пересчетом номерной информации, гибкой тарификацией и ведением диалога с пользователем.

Работа над спецификацией CS-2 была начата в 1992 году и завершена в 1997 году. Рекомендации, относящиеся к CS-2, имеют номера Q.122X. К возможностям, введенным в CS-1 .добавлены возможности, позволяющие создавать услуги, которые допускаютуправ-ление несколькими участниками связи, услуги, при предоставлении которых возможно взаимодействие разных сетей, услуги, связанные с мобильностью пользователя.

Работа над спецификацией CS-3 начата в 1996 году и должна быть закончена в 2000 году. Первоначально предполагалось, что в рамках архитектуры CS-3 будут полностью поддерживаться системы мобильной и персональной связи, как для стационарных, так и для мобильных сетей, в соответствии с требованиями Универсальной системы мобильной связи (UMTS) и Международной подвижной связи (1МТ-2000), а также интеграция с сетями эксплуатационного управления (TMN) и с широкополосной сетью интегрального обслуживания (B-ISDN).