Механизмы оплаты для ip-мультимедийных услуг

Механизмы оплаты для ip-мультимедийных услуг

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится к механизмам оплаты IP-Мультимедиа услуг, применимых в том числе и к услугам полудуплексной сотовой связи - Push-to-talk over Cellular ("нажми, чтобы говорить в сотовой сети").

Уровень техники

IP-Мультимедиа услуги предоставляют динамическое объединение голосовых данных, видеоданных, сообщений и т.п. в рамках одного и того же сеанса связи. При росте числа основных приложений и средств передачи информации, которые возможно скомбинировать, число услуг, предоставляемых конечному пользователю, будет расти экспоненциально и возможности межличностного общения возрастут. Это приведет к новому поколению адресных, мультимедийных коммуникационных услуг.

IP-Мультимедиа Подсистема (IMS) представляет собой технологию, заданную Партнерским Проектом Третьего Поколения (3GPP), для предоставления IP-Мультимедиа услуг по 3G сетям мобильной связи. IMS предоставляет основные опции для повышения эффективности конечному пользователю при связи субъект-субъект посредством объединения и взаимодействия услуг. IMS позволяет теперь в варианте субъект-субъект (абонент-абонент) и субъект-поставщик информации (абонент-сервер) осуществлять IP сетевую связь. IMS использует Протокол Инициализации Сеанса (SIP) и Протокол Предоставления Услуг (SDP) для установки и управления вызовами или сеансами связи между пользовательскими терминалами (или пользовательскими терминалами и web-серверами). На Фиг.1 схематически показано как IMS встраивается в архитектуру мобильной сети.

Существующие операторы сотовой телефонной сети почувствовали большой рост числа абонентов, выбирающих для себя так называемое "предоплатное" абонирование, т.е. когда абоненты переводят своим операторам некоторую сумму (кредитный баланс), расходуемую при последующем пользовании услугами абонентом. Ожидается, что "предоплатное" абонирование станет одинаково популярным и у пользователей IPVV-услуг. Несомненно, что предоставление услуг предоплаты станет широко распространенной формой оплаты IPVV-услуг.

При использовании онлайн/оперативных (в реальном времени) механизмов оплаты (как для пользователей с предоплатой) общим правилом для IPMM Сервисного Элемента (SE), обеспечивающего доступ к требуемой услуге, должен быть запрос на кредитную авторизацию перед предоставлением доступа мобильного узла к затребованной услуге. Однако это неизбежно приведет к увеличению времени установления сеанса связи для абонентов с предоплатой, поскольку IPMM SE должен провести операцию кредитной авторизации с Узлом Управления Оплатой, обозначаемым также как Система Предоплаты (PPS), или Системой Онлайновой Оплаты (OCS).

Для некоторых услуг на основе IPMM/IMS время установления сеанса связи оказывается критическим. Это относится, например, к так называемым Push-to-talk over Cellular (PoC) услугам, например к случаю Прямого Персонального Разговора и Ad-hoc Прямого Группового Разговора, когда исходящая сторона нажимает PoC кнопку на своем терминале для приглашения одного или нескольких пользователей к сеансу дуплексной связи и ожидает немедленного контакта с приглашаемой стороной/сторонами (в отличие от традиционных телефонных услуг с вызовом, звонком, ответом). Введение механизма предоплаты в существующем варианте может приводить к недопустимой потере времени установления PoC-сеанса связи или может привести к неоптимальным пользовательским возможностям вследствие дополнительной задержки, вызванной этапом кредитной авторизации.

Сущность изобретения

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

В соответствии с первым объектом настоящего изобретения предоставляется способ резервирования кредита для мобильного абонента по отношению к IP-Мультимедиа услуги, причем способ содержит:

вслед за первичной регистрацией абонента для IP-Мультимедиа услуги, но до запроса IP-Мультимедиа услуги использование начальной процедуры установления сеанса связи для резервирования кредитной суммы на узле управления оплатой и для извещения Сервисного IP-Мультимедиа Элемента о кредитном резервировании,

после чего при запросе упомянутой IP-Мультимедиа услуги Сервисный IP-Мультимедиа Элемент может немедленно быть задействован в сеансе связи.

Ясно, что начальная процедура установления сеанса связи будет содержать обмен соответствующими сообщениями между Сервисным IP-Мультимедиа Элементом и узлом управления оплатой. Сообщения могут удовлетворять требованиям протокола DIAMETER.

Начальная процедура установления сеанса связи обычно используется для согласования услуги (например, обмена адресами для передачи информации и типами кодека) между терминалом абонента (UE) и IMS-Сервером.

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

Изобретение применимо, в частности, хотя и необязательно, к услугам полудуплексной сотовой связи - Push-to-talk over Cellular (PoC).

Способ может содержать одновременно с Элементом IP-Мультимедиа Услуги и узлом управления оплатой оценку кредитной суммы, соответствующей IP-Мультимедиа услуге. Предпочтительно, эта оценка выполняется на узле управления оплатой.

В случае абонента с предоплатой узел управления оплатой является сервером системы предоплаты (PPS), расположенным в домашней сети абонента.

Предпочтительно, способ содержит при запросе IP-Мультимедиа услуги выполнение операции кредитной авторизации между Элементом IP-Мультимедиа Услуги и узлом управления оплатой исходя из реальной услуги, затребованной/запрошенной для установления исправленной кредитной суммы. Оцененная кредитная сумма заменяется исправленной кредитной суммой.

В соответствии со вторым объектом настоящего изобретения предоставляется способ работы Сервисного IP-Мультимедиа Элемента, организованного для облегчения доступа мобильных абонентов к IP-Мультимедиа услуге, причем способ содержит:

вслед за первичной регистрацией абонента для IP-мультимедиа услуги, но до инициализации IP-мультимедиа сеанса связи инициализацию начальной процедуры установления сеанса связи с узлом управления оплатой для резервирования кредитной суммы на узле управления оплатой.

В соответствии с третьим объектом настоящего изобретения предоставляется способ работы узла управления оплатой, организованного для управления доступом абонента к IP-Мультимедиа услугам, причем способ содержит:

участие в предшествующей процедуре установления сеанса связи, следующей за первичной регистрацией абонента для IP-Мультимедиа услуги, но до запроса IP-Мультимедиа услуги оценку узлом управления оплатой соответствующей кредитной суммы, резервируемой для будущего сеанса связи.

Краткое описание чертежей

Фиг.1 схематически изображает архитектуру мобильной сети, включающую в себя IP-Мультимедиа Подсистему;

Фиг.2 - упрощенная логическая архитектура онлайновой оплаты IPMM-услуг;

Фиг.3 - архитектура PoC согласно Версии 2;

Фиг.4 - схема передачи сигналов, относящаяся к начальной процедуре установления сеанса связи для PoC Прямого Персонального Разговора; и

Фиг.5 и 6 - схема передачи сигналов, относящаяся к процедуре установления сеанса связи вслед за начальным установлением сеанса связи при реально запрошенной услуге.

Подробное описание некоторых вариантов осуществления изобретения

При сеансе связи IP-Мультимедиа Подсистемы (IMS) возможно наличие некоторого количества пользователей, являющихся абонентами нескольких различных IMS-операторов. При любой общепринятой процедуре оплаты каждый из IMS-операторов должен иметь возможность получить оплату от своих собственных абонентов независимо в соответствии с их собственной политикой оплаты. Это означает, что различные модели оплаты могут применяться в различных сетях при одном и том же IMS-сеансе связи. Кроме того, различные модели оплаты могут применяться к различным группам абонентов для одних и тех же IPMM-услуг/опций в пределах имеющейся у оператора сети.

В соответствии с 3GPP R5 TS 32.225 и TS 32.200 и IETF DCC (Интернет-проект "Применение протокола Diameter для Управления Кредитом") различаются два сценария IMS онлайновой оплаты:

1) Сценарий "Одноразовое Событие с Непосредственным Дебетом". Модель "Немедленная Оплата События" в 3GPP. Модель "Кредитная Авторизация с Непосредственным Дебетом" в IETF DCC.

2) Сценарий "Предоставление Кредита по Сеансу Связи". Модель "Оплата События с Резервированием Единицы" в 3GPP. Модель "Кредитная Авторизация с Резервированием Денег" в IETF DCC.

В обеих моделях IP-Мультимедиа Сервисные Элементы (IPMM SE), то есть клиент управления кредитом, запрашивает кредитную авторизацию от Системы Онлайновой Оплаты (OCS)/Системы Предоплаты (PPS), то есть от управляющего кредитом сервера, причем до разрешения на предоставление какой-либо услуги конечному пользователю. Сценарий Предоставления Кредита при Сеансе Связи считается наиболее подходящим для большинства IPMM-услуг и именно он рассматривается в данном случае.

Предоставление Кредита при Сеансе Связи является операцией, при которой PPS тарифицирует запрос от IPMM SE, резервирует подходящую сумму денег из бюджета пользователя и извещает IPMM SE о соответствующей сумме кредитных средств. Конечно, "кредитные средства" не обязательно подразумевают реальный денежный кредит: кредитные средства могут быть предоставлены в виде контролируемых единиц (например, пространственных или временных данных). При получении благоприятного ответа о кредитной авторизации с некоторой суммой кредитных средств IPMM SE разрешает поставку услуги конечному пользователю и приступает к мониторингу использования выделенных средств. Когда выделенные конечному пользователю кредитные средства израсходованы или услуга уже предоставлена или завершена, IPMM SE уведомляет в свою очередь PPS об использованной сумме, и PPS вычитает использованную сумму из суммы пользователя (PPS может выполнить тарификацию и произвести новое кредитное резервирование, если предоставление услуги продолжается). Эта операция включает в себя первый запрос, возможные промежуточные запросы и окончательный запрос. И IPMM SE, и PPS нуждаются в информации о предоставлении кредита при сеансе связи.

Верхняя схема на Фиг.2 изображает общую архитектуру онлайновой оплаты для IPMM, а нижняя схема изображает упрощенную архитектуру PoC. Система Онлайновой Оплаты(OCS)/Система Предоплаты (PPS) обеспечивают предоставление оплаты для механизма оплаты в реальном времени. Система Предоплаты включает в себя Менеджера Учета Баланса и Пользовательские Счета, Систему Тарификации и Тарифную Информацию. Система Тарификации обеспечивает значения тарифа для сеансов связи/услуг или событий, не оцененных поставщиком, то есть для которых сервисные элементы не имеют цены. Для онлайновой оплаты элементы IPMM SE, способные обеспечить ввод оплаты на PPS, - это Элемент Управления Вызовом Услуги при Сеансе связи (S-CSCF), Управление Средством Мультимедиа (MRFC) и Сервер Приложений (AS). Для полудуплексной связи (PoC), обеспечивающей платежный взнос SE для PPS является PoC Сервер (который объединяет функциональность MRF и AS). Интерфейс между элементами IPMM SE и PPS основан на Базовом Протоколе Diameter (DBP) и Приложения Diameter к Предоставлению Кредита (DCC), как было определено проектом 3GPP в Версиях 5 и 6.

Фиг.3 изображает архитектуру PoC Версии 2, причем функциональные объекты PoC отмечены жирными линиями. На Фиг.3 показаны следующие интерфейсы:

it: Управление минимальным уровнем и среда передачи данных

itn: Управление минимальным уровнем и среда передачи данных

is: Передача сигналов от PoC-клиента на Прокси-сервер

if: Передача сигналов от Прокси-сервера на PoC-Сервер

in: Передача сигналов от Прокси-сервера на Прокси-сервер

im: от сервера Группового управления к PoC-клиенту

ik: от сервера Группового управления к PoC-Серверу

io: от OTAP-сервера к PoC-клиенту.

Архитектура PoC соответствует двум функциям PoC-Сервера - функционального/логического объекта Управляющего PoC-Сервера и функционального/логического элемента Компонентного PoC-Сервера. В каждом PoC переговорном сеансе связи задействован только один Управляющий PoC-Сервер, а Компонентных PoC-Серверов может быть более одного. Управляющий PoC-Сервер обрабатывает центральные задачи, которые не должны обрабатываться больше чем одним PoC-Сервером в PoC переговорном сеансе связи. PoC-Сервер функционирует либо как Управляющий PoC-Сервер, либо как Компонентный PoC-Сервер исходя из PoC переговорного сеанса связи.

Реальный PoC-Сервер (то есть физический элемент/узел) может работать и как Управляющий PoC-Сервер, и как Компонентный PoC-Сервер одновременно и для одного и того же PoC переговорного сеанса связи. В случае Прямого Персонального Разговора и Ad-hoc-Прямого Группового Разговора PoC-Сервер приглашенного пользователя является Управляющим PoC-Сервером. В случае Группового Разговора в Чате и Прямого Группового Разговора Управляющий PoC-Сервер является PoC-Сервером, располагающим/размещающим групповую идентичность (Общую Групповую Идентичность). Прочие подробности этих PoC-услуг приведены ниже в Приложении.

Выше было отмечено, что обычный подход к кредитному резервированию для PoC-сеанса связи с большой вероятностью приводит к значительной задержке установления сеанса связи. В данном случае предлагается альтернативный способ резервирования кредита для чувствительных к задержке PoC-услуг/опций (то есть Прямых Персональных Разговоров и Ad-Hoc-Прямых Групповых Разговоров), который сохраняет все характеристики режима предоплаты (то есть предоставление кредита оператором, предоставление в реальном времени информации о тратах конечному пользователю). Этот способ использует процедуру установления так называемого "начального сеанса связи" для резервирования кредита для PoC-опций при критическом времени установления сеанса связи до инициализации конечным пользователем переговорного сеанса связи, то есть до запроса реальной PoC-опции. Начальная процедура установления сеанса связи используется с целью согласования услуги (например, связи номера IP-адреса/порта с RTR/RTCP и типами кодека) между UE и собственным домашним PoC-Сервером. Начальный сеанс связи может быть установлен немедленно вслед за IMS-регистрацией или любой более поздней временной точкой. Начальная процедура установления сеанса связи определена в архитектуре PoC-Версии 2.0.

При начальном установлении сеанса связи PoC-Сервер выполняет кредитное резервирование для PPS (посылкой Учетного Запроса по протоколу Diameter (ACR) с Типом Учетной Записи=START) до продолжения обработки запроса на начальное установление сеанса связи. PPS предварительно тарифицирует услугу (на этом этапе неизвестно, какая PoC-опция будет запрошена пользователем позднее) и, если пользовательский кредитный баланс достаточен, то PPS резервирует необходимую сумму денег со счета пользователя и возвращает соответствующую сумму кредитных единиц на PoC-Сервер (в сообщении ACA по протоколу Diameter с Типом Учетной Записи = START). После успешного кредитного резервирования PoC-Сервер продолжает обработку запроса на начальное установление сеанса связи. Этап кредитной авторизации не особенно чувствителен ко времени, если PoC-опция еще не запрошена.

В случае, если кредитное резервирование произведено неудачно (например, пользовательский кредитный баланс исчерпан), то PPS инициирует процедуру Немедленного Прекращения Услуги возвращением сигнала отказа на PoC-Сервер (в сообщении ACA по протоколу Diameter с:

Результирующим Кодом = DIAMETER_END_USER_SERVICE_DENIED).

PoC-Сервер возвращает SIP-сигнал ошибки на сервисный IMS-Центр. Сигнал ошибки возвращается на UE и к конечному пользователю.

Как уже отмечалось, если кредит зарезервирован при начальном установлении сеанса связи, то PoC-Сервер не извещается, пока PoC-опция не будет запрошена в более позднее время или не будет использовано выполнение UE начальной процедуры установления сеанса связи при его начале (инициатором сеанса) или завершении (участником) конечным пользователем. Таким образом, при начальном установлении сеанса связи PoC-Сервер может обеспечить только ограниченные входные данные о тарификации на Систему Предоплаты. При начале сеанса связи (то есть на этапе действия PoC-опции запрос/установка соединения) PoC-Сервер обрабатывает запрос услуги немедленно исходя из зарезервированного ранее кредита. PoC-Сервер при этом может предоставить на PPS точное значение входных данных о тарификации (в сообщении ACR согласно протоколу Diameter с Типом Учетной Записи=INTERIM). Этот этап кредитной авторизации опять-таки не особенно чувствителен ко времени, поскольку оцененная кредитная сумма уже зарезервирована, снижая риск для провайдера услуги. Запрос услуги может быть обработан немедленно, причем одновременно выполняется вторая кредитная авторизация для уточнения тарифа.

Фиг.4 изображает передачу сигналов, относящуюся к начальной процедуре установления сеанса связи при дополнительном кредитном резервировании с опцией Прямой Персональный Разговор. Этот сценарий для начальной процедуры установления сеанса связи работает с обеих сторон (NB. Передача сигналов не показывает начало и окончание Базы IMS). Различные этапы передачи сигнала таковы:

А-Сетевое начальное установление сеанса связи

1а. UE-A начинает начальное установление сеанса связи (непосредственно после первичной IMS-регистрации или в некоторой более поздней временной точке, например, когда пользователь активизирует услугу Прямого Персонального разговора от UE) посылкой SIP INVITE на PoC-Сервер А через Базу A IMS (то есть UE посылает SIP INVITE на Базу A IMS). База A IMS возвращает SIP 100 "Trying" на UE A. База A IMS выявляет создающийся запуск, после чего посылает SIP INVITE на PoC-Сервер А. SIP INVITE включает в себя:

Запрос-URI абонентский узел устанавливает в предварительно сконфигурированную строку "Ad-hocGroupRequest" (строка конфигурируется в UE).

Принятие Соединения включает в себя ярлык опции "+g.poc.talkburt=TRUE"

Для = URI абонентский узел устанавливает в предварительно сконфигурированную строку "Ad-hocGroupRequest"

По = приглашается пользовательский Открытый Идентификатор Пользователя

Тело Сообщения с Содержимым Типа "заявка/sdp", содержит SDP Предложение 1

2а. PoC-Сервер А следит, чтобы начальный сеанс связи поддерживался. Согласно этому сценарию предполагается, что начальный сеанс связи поддерживается. PoC-Сервер А может послать SIP 100 Trying на Базу A IMS.

Оплата в Сети А, первый запрос

3а. Управляющий PoC-Сервер начинает сеанс с управлением кредитом по отношению к пользовательской Системе Предоплаты А при продолжающейся обработке принятого запроса/SIP INVITE на установление сеанса связи. Система Предоплаты А идентифицируется ECF-адресом, загружаемым как часть профиля А-пользователя от Домашней Абонентской Системы (HSS) на S-CSCF в Базе A IMS за время регистрации А-пользователя в IMS и переносится в SIP INVITE от S-CSCF в Базе A IMS на PoC-Сервер А.

4а. Управляющий PoC-Сервер посылает ACR-Diameter на Систему Предоплаты А. ACR-Diameter включает в себя:

Тип Записи Счета=START_RECORD

Подпись идентификатора (Тип=END_USER_SIP_URL, Данные='user-A SIP URI')

M-S-C-C(#1)

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-owner)

Запрашиваемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='pre-configured value')

Информация Сервисного Параметра (Тип=ExtensionNumberA,

Значение=например, "общее время сеанса связи пошло"

M-S-C-C(#2)

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-owner)

Запрашиваемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='pre-configured value')

Информация Сервисного Параметра (Тип=ExtensionNumberC,

Значение=например, "число распределенных переговорных пакетов"

M-S-C-C(#n)

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-participant)

Запрашиваемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='pre-configured value')

Информация Сервисного Параметра (Тип=ExtensionNumberBB,

Значение=например, "число посланных и/или принятых разговорных пакетов"

ПРИМЕЧАНИЕ: В этом примере включены/показаны три M-S-C-C AVP. В общем случае может быть включено несколько M-S-C-C AVP, по одному для каждого способа измерения, поддерживаемого IPMM SE для соответствующего сочетания типа услуги и имени абонента.

5а. Система А Предоплаты предварительно тарифицирует услугу (на этом этапе неизвестно, будет ли будущая затребованная услуга Прямого Персонального Разговора или Ad-hoc- Прямого Группового Разговора), исходя из содержимого принятой Информации Сервисного Параметра производит кредитное резервирование со счета конечного пользователя (которое покрывает ожидаемую стоимость услуги) и возвращает сообщение Diameter ACA на PoC-Сервер. В данном сценарии предполагается, что кредитный баланс достаточен. Diameter ACA включает в себя:

Результирующий Код=DIAMETER_SUCCESS

Тип Учетной Записи=START_RECORD

Счетный Временной Интервал ('значение устанавливается Системой Предоплаты')

Подпись Идентификатора (Тип=END_USER_SIP_URL, Data='user-A SIP URI')

M-S-C-C (#a)

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-owner)

Предоставляемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='Система Предоплаты устанавливает Предоставляемую Сервисную Единицу значение = значение Запрашиваемой Сервисной Единицы')

Информация Сервисного Параметра (Тип=ExtensionNumberC,

Значение=например, "число распределенных разговорных пакетов"). Примечание: модель оплаты остается в силе, если пользователь позднее будет инициатором сеанса связи.

M-S-C-C (#b)

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-participant)

Предоставляемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='Система Предоплаты устанавливает Предоставляемую Сервисную Единицу значение = значение Запрашиваемой Сервисной Единицы')

Информация Сервисного Параметра (Тип=ExtensionNumberBB,

Значение="послать разговорные пакеты"). Примечание: модель оплаты остается в силе, если пользователь позднее будет участником сеанса связи.

Управляющий PoC-Сервер А начинает мониторинг использования предоставленных сервисных единиц.

Действия при начальном установлении сеанса связи

6а. PoC Сервер А посылает SIP 202 Принятый для UE через IMS-Базу А. Принятый SIP 202 включает в себя:

Установление связи, содержащее временный ad-hoc-групповой идентификатор обеспечивается Управляющим PoC-Сервером.

Тело сообщения с Типом Содержания "заявка/sdp" содержит SDP-Ответ 1.

7а. UE А посылает SIP ACK на PoC-Сервер A через IMS-Базу A.

Начальное установление сеанса связи в сети B и первый запрос оплаты

Параллельно этапам 1а-7а в Сети А реализуются этапы 1b-7b в Сети В (включая Пользователя В, UE B, IMS-База B, PoC-Сервер B, Система Предоплаты B).

Начальный сеанс связи - подключение

После завершения процедуры начального установления сеанса связи, показанной на Фиг.4, абонентом инициализируется процедура подключения (UE А в этом случае). Фиг.5 и 6 изображают передачу сигналов, связанную с установлением Прямого Персонального Разговора (то есть установление подключения). Опять-таки процесс передачи сигналов не демонстрирует начала и завершения IMS-Базы. Этапы передачи сигналов указаны ниже.

Установление подключения с начальным сеансом связи

1. Конечный пользователь на UE A, абонент Сети А, нажимает на кнопку PoC для инициализации сеанса Прямого Персонального Разговора с конечным пользователем на UE B, абонентом Сети B.

2. UE A посылает SIP REFER на PoC-Сервер A через IMS Базу A. SIP REFER включает в себя:

Обращение: приглашение пользовательского Открытого Идентификатора Пользователя (то есть SIP URI или номер E.164)

3. Вызывающий Компонентный PoC-Сервер A распознает тип сеанса связи как Прямой Персональный Разговор исходя из информации в SIP REFER (то есть один Открытый Идентификатор Пользователя).

Вызывающий Компонентный PoC-Сервер A выполняет функции Управляющего PoC-Сервера. Функции Вызывающего Компонентного PoC-Сервера логически совмещаются с функцией Управляющего PoC-Сервера. Это означает, что для Прямого Персонального Разговора PoC-Сервером, назначенным для приглашенного пользователя, является Управляющий PoC-Сервер.

Управляющий PoC Сервер выполняет:

Авторизацию приглашенного к переговорному сеансу связи пользователя;

Интерпретацию SIP REFER как неявный запрос на направление результирующего пакета для каждого исходящего SIP INVITE/REFER (то есть приглашающий UE будет принимать информацию об окончательном SIP-отклике приглашенного пользователя в SIP NOTIFY) и Интерпретацию SIP REFER как неявный "запрос минимального уровня".

Оплата в Сети А, промежуточный запрос

4. Управляющий PoC-Сервер осуществляет промежуточный запрос для предоставления новых/дополнительных вводных данных о тарифе на Систему Оплаты А, то есть Управляющий PoC-Сервер имеет теперь информацию о том, что сеанс связи является Прямым Персональным Разговором.

5. Управляющий PoC-Сервер посылает Diameter ACR на Систему Предоплаты А. Diameter ACR включает в себя:

Тип Учетной Записи=INTERIM_RECORD

Подпись Идентификатора (Тип=END_USER_SIP_URL, Данные='пользователь-A SIP URI')

M-S-C-C

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_INSTANT_PERSONAL_TALK)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-owner)

Запрашиваемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='предварительно сконфигурированное значение')

Используемая Сервисная Единица (Тип= SERVICE_CREDIT_EVENT,

Значение='количество используемых сервисных единиц')

Информация Сервисного Параметра (Тип=ExtensionNumberC,

Значение=например, "число распределенных переговорных пакетов")

6. Система Предоплаты А вычитает использованную сумму из счета конечного пользователя, тарифицирует услугу исходя из содержания принятой Информации Сервисного Параметра, производит новое резервирование кредита из счета конечного пользователя (которая покрывает стоимость услуги) и возвращает Diameter ACA. В этом сценарии кредитный баланс предполагается достаточным. Diameter ACA включает в себя:

Результирующий Код=DIAMETER_SUCCESS

Тип Учетной Записи=INTERIM_RECORD

Расчетный Промежуточный Интервал ('значение, установленное Системой Предоплаты')

Подпись Идентификатора (Тип=END_USER_SIP_URL, Данные='пользователь-A SIP URI')

M-S-C-C

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_INSTANT_PERSONAL_TALK)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-owner)

Предоставленная Сервисная Единица (Тип= SERVICE_CREDIT_EVENT,

Значение='Система Предоплаты устанавливает Предоставленную Сервисную Единицу значение = значение Запрашиваемой Сервисной Единицы')

Информация Сервисного Параметра (Тип=ExtensionNumberC,

Значение= например, "число распределенных переговорных пакетов")

7. Управляющий PoC-Сервер A продолжает мониторинг использования предоставленных сервисных единиц.

8. Управляющий PoC-Сервер A посылает SIP 202, Принятый для UE A через IMS Базу A.

9. Управляющий PoC-Сервер A посылает SIP INVITE (SDP Предложение 2) на Компонентный PoC-Сервер B. Очевидно, что это сообщение может быть послано непосредственно PoC-Сервером A вслед за приемом сообщения SIP REFER от UE A, то есть это сообщение может быть послано до или во время обмена сообщениями DIAMETER (5 и 6).

Компонентный PoC-Сервер B извлекает (из возможностей GLMS) флажок Не Распределять, таблицу доступа (прием/отклонение) и режим ответа приглашенного пользователя. Компонентный PoC-Сервер B авторизует запрос исходя из флажка Не Распределять и таблицы доступа (приема/отклонения) приглашенного пользователя. В этом сценарии предполагается, что Компонентный PoC-Сервер B определяет, что флажок DnD не установлен, приглашенный пользователь не находится в таблице отклонения и режим ответа приглашенного пользователя установлено на "автоответ".

Оплата в Сети B, промежуточный запрос

11. Компонентный PoC-Сервер осуществляет промежуточный запрос для предоставления новых/дополнительных вводных данных о тарифе на Систему Оплаты А, то есть Компонентный PoC-Сервер имеет теперь информацию о завершении PoC-сеанса связи.

12. Компонентный PoC-Сервер посылает Diameter ACR на Систему Предоплаты B. Diameter ACR включает в себя:

Тип Учетной Записи=INTERIM_RECORD

Подпись Идентификатора (Тип=END_USER_SIP_URL, Данные='пользователь-A SIP URI')

M-S-C-C

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-participant)

Запрашиваемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='предварительно сконфигурированное значение')

Используемая Сервисная Единица (Тип=SERVICE_CREDIT_EVENT,

Значение='количество используемых сервисных единиц')

Информация Сервисного Параметра (Тип=ExtensionNumberBB,

Значение="послать переговорный пакет")

13. Система Предоплаты B вычитает использованную сумму из счета конечного пользователя, тарифицирует услугу исходя из содержания принятой Информации Сервисного Параметра, производит новое резервирование кредита из счета конечного пользователя (которая покрывает стоимость услуги) и возвращает Diameter ACA. В этом сценарии кредитный баланс предполагается достаточным. Diameter ACA включает в себя:

Результирующий Код=DIAMETER_SUCCESS

Тип Учетной Записи=INTERIM_RECORD

Расчетный Промежуточный Интервал ('значение, установленное Системой Предоплаты')

Подпись Идентификатора (Тип=END_USER_SIP_URL, Данные='пользователь-A SIP URI')

M-S-C-C

Информация Сервисного Параметра (Тип=ExtensionNumber1,

Значение=POC_ANY_TALK_SESSION)

Информация Сервисного Параметра (Тип=ExtensionNumber2,

Значение=session-participant)

Предоставленная Сервисная Единица (Тип= SERVICE_CREDIT_EVENT,

Значение='Система Предоплаты устанавливает Предоставленную Сервисную Единицу значение = значение Запрашиваемой Сервисной Единицы')

Информация Сервисного Параметра (Тип=ExtensionNumberBB,

Значение= "послать переговорный пакет")

14. Компонентный PoC-Сервер B начинает мониторинг использования предоставленных сервисных единиц.

Установление подключения при продолжении начального сеанса связи

15. UE B имеет установившийся начальный сеанс связи и настроен на режим автоответа; таким образом, Компонентный PoC-Сервер выбирает начальный режим передачи информации.

16. Компонентный PoC-Сервер B посылает SIP 200 OK (SDP Ответ 2) на Управляющий PoC-Сервер.

17. SIP ACK посылается от Управляющего PoC-Сервера A на Компонентный PoC-Сервер B. Следует отметить, что как и с сообщением (9) SIP INVITE, посылка сообщений SIP ACK и SIP 200 OK не зависит от обмена сообщений DIAMETER (5, 6, 12, 13).

18. Управляющий PoC-Сервер посылает RTCP "выбран минимальный уровень" на UE B через Компонентный PoC-Сервер B.

19. "Индикация прослушивания" дается пользователю B.

20. Управляющий PoC-Сервер посылает RTCP "предоставлен минимальный уровень" на UE A. Следует отметить, что как и с сообщением (9) SIP INVITE, посылка сообщений RTCP "выбран минимальный уровень" (18) и RTCP "предоставлен минимальный уровень" (20) не зависит от обмена сообщений DIAMETER (5, 6, 12, 13).

21. "Индикация разговора" дается пользователю A (и "SIP 202 Принято", несущее SDP Ответ и "RTCP предоставлен минимальный уровень", указывающее, что PoC-Сервер готов обрабатывать переданную информацию, требуются для взаимодействия пользователя с системой).

Пользователь A начинает разговор

22. Пользователь A приступает к разговору.

23. "RTP разговорный пакет" (информация) передается от UE A к UE B через Управляющий PoC-Сервер и Компонентный PoC-Сервер B.

24. Пользователь A выслушивает речевую фразу пользователя B.

25. В результате предшествующей "неявной подписи для состояния приглашенного пользователя" после получения SIP 200 OK Управляющий PoC-Сервер посылает запрос SIP NOTIFY на IMS-Базу A. IMS-База A посылает SIP NOTIFY на UE A. SIP NOTIFY включает в себя:

Событие=обращение

Тело сообщения с Содержанием Типа "сообщение/sip-фрагмент" содержит:

Линию состояния SIP-отклика, который получен PoC-Сервером от приглашенного пользователя, "SIP/2.0 200 OK" в этом сценарии; и

Открытый Идентификатор Пользователя приглашенного пользователя (SIP URI или MSISDN).

26. UE A посылает SIP 200 OK как отклик на SIP NOTIFY на IMS-Базу A. IMS-База A посылает SIP 200 OK на Управляющий PoC-Сервер.

Пользователь A завершает разговор

27. Пользователь A отпускает PoC-кнопку.

28. UE A посылает "RTCP минимальный уровень отпущен" на Управляющий PoC-Сервер.

29. Управляющий PoC-Сервер посылает "RTCP минимальный уровень свободен" на UE A.

30. Управляющий PoC-Сервер посылает "RTCP минимальный уровень свободен" на Компонентный PoC-Сервер B, который направляет его на UE B.

31. Индикация "минимальный уровень свободен" дается пользователю B.

Больше разговорных пакетов могут быть посланы/приняты пользователем A и пользователем B

Другие разговорные пакеты могут быть посланы/приняты пользователем A и пользователем B.

Может иметь место другой промежуточный запрос на предоставление кредита.

Пользователь A отключается от разговорного сеанса связи

32. Пользователь A требует выхода из разговорного сеанса связи.

33. UE A посылает "RTCP BYE" на Управляющий PoC-Сервер.

34. Управляющий PoC-Сервер выявляет пассивный режим окончания связи. В соответствии с порядком завершения сеанса связи Управляющий PoC-Сервер требует разъединения в разговорном сеансе связи.

35. Управляющий PoC-Сервер посылает "RTCP BYE" на Компонентный PoC-Сервер B, который направляет его на UE B.

36. Индикация прекращения сеанса связи дается пользователю B.

37. Управляющий PoC-Сервер посылает SIP BYE на Компонентный PoC-Сервер B.

38. Компонентный PoC-Сервер B отвечает посредством SIP 200 OK (для SIP BYE).

Оплата в Сети A, окончательный запрос

39. Управляющий PoC-Сервер посылает Diameter ACR на Систему Предоплаты A. Diameter ACR включает в себя:

Тип Учетной Записи=STOP_RECORD

Подпись Идентификатора (Тип=END_USER_SIP_URL, Данные='пользователь-A SIP URI')

Используемая Сервисная Единица (Тип= SERVICE_CREDIT_EVENT,

Значение='количество используемых сервисных единиц')

40. Система Предоплаты A возвращает Diameter ACA. В этом сценарии предполагается, что кредитный баланс пользователя достаточен. Diameter ACA включает в себя:

Результирующий Код=DIAMETER_SUCCESS

Тип Учетной Записи=STOP_RECORD

Оплата в Сети B, окончательный запрос

41. Компонентный PoC-Сервер посылает Diameter ACR на Систему Предоплаты B. Diameter ACR включает в себя:

Тип Учетной Записи=STOP_RECORD

Подпись Идентификатора (Тип=END_USER_SIP_URL, Данные='пользователь-A SIP URI')

Используемая Сервисная Единица (Тип= SERVICE_CREDIT_EVENT,

Значение='количество используемых сервисных единиц')

42. Система Предоплаты B возвращает Diameter ACA. В этом сценарии предполагается, что кредитный баланс пользователя достаточен. Diameter ACA включает в себя:

Результирующий Код=DIAMETER_SUCCESS

Тип Учетной Записи=STOP_RECORD

Из приведенного выше описания должно быть очевидно, что введение опции предоплаты (необходимой для широкого рыночного использования некоторых опций PoC) организовано таким образом, что этап кредитной авторизации не влияет на время установления PoC разговорного сеанса связи. IPMM Сервисный Элемент (например, PoC-Сервер) осуществляет кредитную авторизацию по отношению к Системе Предоплаты для резервирования кредита несколько позднее первичной регистрации IMS-пользователя как часть "PoC начальной процедуры сеанса связи"; то есть перед тем, как конечным пользователем будет запрошена срочная PoC сервисная опция (то есть Прямой персональный Разговор, Ad-hoc Прямой Групповой Разговор). Если конечный пользователь запрашивает опцию PoC-услуги, то IPMM Сервисный Элемент может обрабатывать запрос услуги непосредственно, полагаясь на предварительно зарезервированный кредит; в то же самое время IPMM Сервисный Элемент осуществляет вторую кредитную авторизацию для обеспечения Системы Предоплаты уточненными тарифными входными данными (например, реально запрошенная PoC-опция, имя исходящей стороны сеанса связи). В результате этап кредитной авторизации не влияет на время установления PoC разговорного сеанса связи.

Специалистам в данной области техники должно быть очевидно, что для рассмотренных выше вариантов реализации возможны различные модификации б