Главная  Новые телекоммуникационные услуги 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [ 145 ] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159]

Шаг 1: «Т1МАризация» базы данных об услугах IN. На этом этапе функции SDF и/или SMF начинают выполняться компонентами TINA. Такой подход позволяет воспользоваться методами моделирования данных, применяемыми в TINA, и прозрачным распределением данных, которое обеспечивает DPE. При этом требуется иметь блок AU, обеспечивающий доступ SCF Интеллектуальной сети к рабочим данным об услугах и данным для управления услугами платформы TINA. Сценарий отдельной «TINApизaции» на шаге 1 функций SDF и эксплуатационного управления SMF, скорее всего, нереален, поскольку разделяет логикууслуги и базу данных об услугах, что вступает в противоречие с объектно-ориентированной концепцией TINA, предпо-логающий их интеграцию.

Шаг 2: Согласованная «TINApизaция» функций SMF, SCF и SDF с целью максимального использования преимуществ архитектуры ycлyгTINA и объектно-ориентированного подхода. Это означает, что «TINApизyютcя», т.е. реализуются посредством объектов СО системы TINA в среде DPE, функции оперативного и эксплуатационного управления услугами IN. Из архитектуры IN остаются только функции SSF, поскольку на них падает основная доля сделанных ранее инвестиций в ТФОП и IN. Данный сценарий позволяет операторам сети продолжать использовать существующее коммутационное оборудование и интерфейсы INAP. При этом требуются специальные блоки AU, чтобы обеспечить взаимодействие объектов СО системы TINA, в которых реализованы функции SCF/SDF и SMF, с функциональными объектами SSF сети IN.

Шаг 3: Внедрение TINA в коммутационные станции. Данный сценарий предусматривает замену вычислительными объектами TINA также и функций SSF, что становится реальным при внедрении новых широкополосных систем коммутации. На этом шаге модифицируются или вовсе удаляются функции, связанные с моделью базового процесса BCSM, а объекты DPE вводятся непосредственно в коммутационный узел или в соответствующий блок AU, адаптирующий станционные интерфейсы управления KTINA-архитектуре управления услугами и соединениями. При таком подходе интерфейс на основе INAP больше не требуется, и коммутационные узлы могут вызывать операции, предусмотренные в СО TINA, непосредственно через DPE.

Ограниченный объем книги не позволяет рассмотреть пошаговую «TINApизaцию» более подробно. Отметим лишь, что блок AU между SSF и подсистемой TINA, называемый IN(-SCF)-AU, должен отображать операции INAP системы ОКС-7, вызываемые FE SSF, на вызовы по методу СО TINA через DPE, и наоборот Таким образом, IN(-SCF)-AU дает возможность устанавливать управляющие связи между SSF в области IN и менеджером сессии услуги (SSM) в области TINA, т.е.



SSM в TINA управляет SSF в IN через AU. Определение IN(-SCF)-AU в значительной степени зависит от способа моделирования услуг IN и пользователей услуг в среде TINA.

5.6.5 Взаимодействие IN и TINA

Уже отмечалось, что между функционально-ориентированной архитектурой IN и объектно-ориентированной архитектурой TINA существуют принципиальные различия, и что различна организация связи между системными компонентами в IN и в TINA: в то время как IN использует систему сигнализации ОКС-7, в TINA используются услуги среды распределенной обработки (DPE). Тем не менее, общая функциональная направленность IN и TINA (предоставление услуг связи) ставит вопрос об их взаимодействии, т.е. о возможности доступа пользователей TINA к уже существующим услугам IN. Обратный доступ от IN к логике услуг TINA также может быть востребован для предоставления пользователям IN тех услуг и возможностей TINA, которые не поддерживаются в IN.

Чтобы обеспечить взаимодействие систем с разными технологиями, между ними должен быть помещен блок сопряжения IWU. Для связи между IN и IWU, содной стороны, каки между TINA и IWU, с другой, должны использоваться стандартизованные интерфейсы. На стороне IN наиболее приемлемым протоколом обмена информацией логики услуг выглядит протокол INAP для интерфейса SCF-SCF, определённый в CS-2. На стороне TINA должна быть выбрана подходящая опорная точка TINA.

В дополнение к взаимодействию на уровне логики услуг потребуется также и взаимодействие на уровне средств доставки информации. Сказанное касается всех услуг, при предоставлении которыхдолж-но быть установлено соединение между пользователем в IN и пользователем в TINA. Поскольку относится это, главным образом, к взаимодействию между узкополосной ISDN (N-ISDN) и TINA, на стороне IN для связи с IWU может использоваться протокол ISUP. На стороне TINA должна быть выбрана подходящая опорная точка TINA.

Взаимодействие на уровне средств доставки информации при установлении соединения, инициированного со стороны IN (т.е. в N-ISDN), становится необходимым, когда в процессе предоставления услуги IN запрос установить соединение передается ко входящей стороне, находящейся в сети TINA. Согласование протоколов управления услугами IN (INAP) и TINA в этом случае не требуется, но зато требуется обеспечить взаимодействие протоколов N-ISDN (ISUP) и TINA. При взаимодействии на уровне средств доставки сеть TINA должна восприниматься со стороны IN (N-ISDN) как часть сети N-ISDN, т.е. подчиняться правилам N-ISDN. На другой стороне соединения сеть N-ISDN рассматривается с точки зрения TINA как совместимая с TINA сеть, принадлежащая другому домену. Запрос со-



единения со стороны N-ISDN воспринимается как запрос этим вторым доменом соединения в собственном домене сети. Чтобы преодолеть барьер, разделяющий разные технологии, между N-ISDN и TINA также должен быть помещён блок IWU.

Рассмотрим пример реализации услуги Freephone в случае TINA-ризованного SCP. Ни один из участников предполагаемой связи не находится в области TINA, но квази-IN возможности управления услугами полностью моделируются вычислительными объектами TINA, то есть пользовательским приложением UAP,, и менеджером сессии услуги SSM, которые используют необходимые именно для Freephone объекты (SSO - Service specific object), например базы абонентских данных и логических номеров. Со стороны ЗЗГблокАи выглядит KaKSCF, а со стороны TINA - как терминал пользователя и посему содержит, кроме UAP,,, агента поставщика РА и конечную точку сессии общего рода (GSEP - Generic session endpoint). Следовательно, AU описанного типа может быть соотнесен с опорной точкой RetRP бизнес-модели TINA (см. рис. 5.6.11).

IN(-SCF)-AU

TINA



Ret-RP

Рис. 5.6.11 Применение TINA для реализации услуги квази-IN

После набора пользователем логического номера запрос услуги обнаруживается функциями SSF сети IN, и соответствующая индикация передается в операции INAP InitialDP к блоку адаптации IN(-SCF)-AU. Приняв запрос, AU передает его к UAP,,, который при помощи РА инициирует организацию сессии услуги. Чтобы организовать сессию доступа, РА взаимодействует с UA в административной области поставщика услуги. После того как «фабрика услуг» SF создаст SSM, UAP,, взаимодействует с SSM,, с целью обмена информацией управления. В контексте этих диалогов производится обмен информацией, относящейся к преобразованию логического номера в физический. Получив физический номер, AU передает операцию Connect к SSF. Преобразование операций INAP в вызовы объектов TINA и обратно обеспечивается UAP,,.



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [ 145 ] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159]

0.0012