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

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

Таким образом, видно, что все вызовы создаются абонентами оконечной АТС и маршрутизируются к SSP по соединительным линиям, причем ни АТС, ни линии не рассчитаны на «взрывной» характер нагрузки. Если в узлах IN средства борьбы с перегрузками, вызванными «взрывным» характером трафика, предусмотрены, то предотвратить описанную выше ситуацию на участке от оконечной АТС до SSP можно лишь с помощью процедур предотвращения перегрузок в АТС и правильно выбранной платой за вызов. Влияние на перегрузки могут оказать и увеличение общего числа телевизионных каналов (как в США), и разнообразие телеопросов, и продумывание тем опросов на каждом из них.

4.3.7.2 Все яйца в одной корзине

При традиционном способе реализации услуг каждая АТС выполняет функции предоставления услугтолько своим абонентам. IN дает возможность централизованногоуправленияуслугами. При нарушении связи SSP с SCP (или выходе SCP из строя) абонентам соответствующей части сети (или всей сети связи) будет отказано во всех услугах IN. Для обеспечения постоянной доступности услуг приобретает важнейшее значение проблема надежности сети.

Чтобы решить эту проблему, совершенно необходимо обеспечить резервные сигнальные маршруты между SSP и SCP, а сами SCP должны быть сгруппированы в связанную(ые) пару(ы) так, чтобы каждый из них мог взять на себя обслуживание абонентов всей сети при выходе из строя другого. Целесообразно иметь в сети, как минимум, дваЗЗР и по одному тракту от каждой оконечной АТС для связи с каждым из них.

SCP-a

Поставщик услуги W


SCP-b

Поставщик услуги Z

Рис. 4.3.10 Повышение надежности

При объединении ЗСР в связанные пары оба члена одной пары содержат идентичные данные, которые одновременно обновляются изЗМР. Если в сети предоставляются, например, две услуги, то один из ЗСР может использоваться в качестве основного для первой ус-



Луги и в качестве резервного для второй, а другой - наоборот. Транзитный пункт сигнализации STP сети ОКС обеспечивает необходимые функции маршрутизации, а при отсутствии STP организуются прямые звенья сигнализации для каждой связи SSP-SCP. Таким образом, наряду с обеспечением надежности достигается равномерное разделение нагрузки между SCP (см. рис. 4.3.10).

Одно из преимуществ IN - возможность уменьшения сроков и значительное упрощение самого процесса создания услуг Однако все, что можно сделать быстро и просто, сопряжено с определенным риском. Можно ожидать большого количества разных вариантов реализации в разных сетях одних и тех же услуг (большого числа диалектов), которые, кроме того, могут быть определенным образом модифицированы под требования разных абонентов.

Рост количества услуг при отсутствии стандартных принципов их взаимодействия (не говоря уже об отдельных диалектах) приводит к необходимости спецификации правил разрешения конфликтных ситуаций. Классическим примером нежелательного взаимодействия между услугами является шутка абонента с заказом на свой номер услуги автоматической побудки и с одновременным заказом безусловной переадресации вызова на номер своего «приятеля». Другой пример - запрос услуги с дополнительной оплатой во время пользования услугой бесплатной связи.

4.3.8 Начисление платы за услуги и взаиморасчеты

4.3.8.1 Сценарии начисления платы за пользование услугами

Процесс начисления платы за услуги связи очень трудно поддается стандартизации. Не явилась исключение и ситуация с услугами IN. ETSI предложено несколько вариантов поддержки в INAP для CS-1 функций начисления платы, описание которых вынесено в приложение В к стандарту ETS 300 374-1. Хотя перечень сообщений и параметров для поддержки вынесенных в приложение сценариев начисления платы определен в основной части стандарта, детали кодирования параметров оставлены на усмотрение администрации каждой сети IN.

В стандарте рассмотрены следующие процессы, относящиеся к системе начисления платы за услуги IN:

• процесс определения условий (DET) отвечает за определение плательщика (вызывающая сторона, абонент услуги, или оба), базовой цены (тарифа), услуг и функций, подлежащих оплате;

• процесс генерации (GEN) осуществляет генерацию импульсов учета, сигналов с данными о начисляемой плате для процессов.



работающих в реальном времени, или учетной информации для процессов, не работающих в реальном времени;

• процесс регистрации (REG) обеспечивает создание учетных записей о вызовах или управление счетчиками тарифных импульсов.

Выбор сценария начисления платы предоставлен оператору сети. Стандартом ETSI выделены четыре следующих сценария (в таблице 4.3.5 приведены те из них, которые поддерживаются протоколом INAP-R):

Сценарий 1: начисление платы, полностью осуществляемое ТФОП с использованием собственных механизмов учета (например, подсчет тарифных импульсов с определением тарифа по коду доступа куслуге).

Сценарий 2: начисление платы, полностью проводимое средствами сети IN. Коммутационные станции ТФОП определяют, например, по коду услуги, что активизировать функции начисления платы не нужно, поскольку оно выполняется средствами IN. Управление начислением платы всегда ведется в SCP, но регистрация учетных записей о вызовах может проводиться, по разным сценариям, либо в SSP (сценарий 2.2), либо в SCP (сценарий 2.3), либо и втом, и в другом (сценарий 2.4).

Сценарий 3: начисление платы совместно средствами IN и ТФОП. В этом случае SCP сообщает SSP о необходимости передачи информации об оплате (сценарий 3.2). SSP, используя возможности сигнализации, передает команду к оконечной АТС, которая, в свою очередь, запускает тарифный счетчик или создает стандартную запись учета стоимости.

Сценарий 4: начисление платы в SCP при поддержке SSP. SCP имеет всю необходимую учетную информацию и инструктирует SSP, каким образом следует произвести расчет стоимости для конкретного вызова. Инструкции содержат сведения об условиях, в отношении которых SSP должен запросить от SCP дополнительную информацию (например, о превышении заданного лимита). Регистрация начисленной платы ведется либо в SCP (сценарий 4.1), либо в SSP (сценарий 4.2).

Дополнительные сценарии, помеченные в таблице 4.3.5 как INAP-R, необходимы для случая, когда SSP и SCP одной сети IN находятся в собственности разных операторов. В этом случае необходимо иметь учетную информацию как в SSP, так и в SCP. Сценарии INAP-R при расчете по картам, с одной стороны, позволяют независимо начислять плату по тарифам, заложенным в SSP каждого оператора, и, с другой стороны, вести в SCP контроль кредита в базе данных.



[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.001