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

[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]

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

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

Необходимо подчеркнуть, что большинство функциональных возможностей IN относится к гибким системам проверки полномочий пользователей, маршрутизации в зависимости от разных условий и начисления платы. В TINA подобные функциональные возможности относятся, по большей части, к сессии доступа, а не к сессии услуги. Все это приводит ктому, что взаимно однозначного отображения услуг IN на услуги TINA и объектов IN на объекты TINA не существует.

Некоторые сравнительные оценки этих двух архитектур приведены в таблице 5.6.1. Конвергенция представленных (и ряда не представленных) в таблице характеристик концепций IN и TINA идет в двух направлениях, рассматриваемых в следующих параграфах данной главы: миграции и взаимодействия. Эти термины взяты из названия проекта Р508 EURESCOM «Эволюция, пути миграции к TINA и аспекты взаимодействия».

Таблица 5.6.1

Критерии

TINA

Принципы организации интерфейсов

Сообщения

Объекты, методы

Поддержка расширяемости

Хорошая, но ограничена возможностями INAP

Отличная, благодаря платформе DPE

Разделение услуг и сети

Физическое

Логическое

Эффективность создания услуг

Услуги создаются очень быстро, если не требуется модификация INAP

Начальные вложения могут быть большими, чем в IN, но потом используются многократно



Миграция или эволюция платформы на базе IN в направлении платформы TINA означает пошаговую «TINApизaцию» элементов платформы Интеллектуальной сети, т.е. пошаговую замену функциональных объектов IN соответствующими компонентами услуг TINA -СО верхнего уровня DPE. По очевидным соображениям практического характера такая замена начнётся с тех функциональных объектов IN, которые установлены в небольшом количестве, например SMF и/или SCF/SDF. Образующаяся при этом платформа будет состоять из двух взаимодействующих частей (подсистем): исконной части IN и новой «TINApизoвaннoй» части. Для отображения операций INAP на операции, обеспечиваемые объектами TINA, и наоборот должны быть определены соответствующие адаптерные блоки (AU).

Взаимодействие между системами Интеллектуальной сети и TINA становится необходимым и в тех случаях, когда оператор развернул платформу на базе TINA и ему нужно обеспечить ее согласованную работу с платформами IN других операторов для предоставления межсетевых услуг Возникает необходимость иметь блок сопряжения (IWU), обеспечивающий взаимодействие на прикладном уровне, к примеру, между SCF/SDF в зоне оператора IN и набором компонентов на верхнем уровне DPE в зоне оператора системы TINA.

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

Так, Alcatel, развивавший первоначально закрытую технологию классической IN, вводит в своей новой версии SCE интерфейсы на основе CORBA для приложений, разработанных сторонними поставщиками. Ведутся также работы в рамках исследовательского проекта ALCIN, ориентированного на оценку концепции TINA науровне прототипов. Alcatel Corporate Research Center и KPN Research совместно разработали несколько услуг в управляемой по принципам TINA инфраструктуре, которая демонстрировалась на Telecom 99. Разработка базируется на платформе Alcatel Mu3S, которая представляет собой прототип, выполненный в соответствии с архитектурой TINA.

Siemens и Italtel ведут работы по проекту SISTINA, призванному создать конкурентоспособную архитектуру, базирующуюся на концепции TINA и позволяющую оператору сети общего пользования получать доходы от продажи услуг IN в условиях будущей интегрированной сети с продвижением «интеллекта» к краям сети.



Отмеченные выше тенденции развития концепций и технологий предоставления услуг позволяют утверждать, что архитектура TINA будет определять облик телекоммуникационных сетей XXI века. Более того, даже вне связи с конкретной архитектурой TINA в практике разработки телекоммуникационного ПО широчайшее применение найдет технология CORBA.

5.6.4 Этапы миграции IN к TINA

Миграция IN kTINA означает постепенную замену отдельных компонентов Интеллектуальной сети соответствующим оборудованием TINA, названную в предыдущем параграфе пошаговой «TINApH-зацией» элементов платформы IN, т.е. замену функциональных объектов IN адекватными наборами взаимодействующих вычислительных объектов TINA на базе DPE. Сказанное означает, что в вычислительных объектах TINA реализуются услуги квази-IN и одновременно определяются соответствующие функции адаптации - так называемые адаптерные блоки AU. Эти блоки должны поддерживать взаимодействие между существующей подсистемой IN и новой «TINApH-зованной» подсистемой. В данном контексте возможны следующие основные шаги эволюции, намеченные в проекте Р508 EURESCOM и представленные на рисунке 5.6.10.


Т1МАризованный Т1МАризованный SCF/SDF

Объекты TINA

INAP

1 /

£

ШагО

(Только IN)


Шаг1

Шаг 2

ШагЗ (Только TINA)

Время

Рис. 5.6.10 Пошаговая миграция IN к TINA



[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