СПОСОБ СВЯЗИ МЕЖДУ УЗЛАМИ ПОДСИСТЕМЫ IP-МУЛЬТИМЕДИА

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

IMS представляет собой технологию, определенную Проектом Партнерства третьего поколения (3GPP) для обеспечения услуг IP-мультимедиа в сетяx мобильной связи. IMS предоставляет возможности для улучшения межабонентского взаимодействия конечных пользователей через интеграцию и взаимодействие между услугами. IMS делает возможными усовершенствованные личные взаимодействия между людьми (клиент-клиент), а также между человеком и контентом (клиент-сервер) через IP-сеть. IMS использует протокол инициирования сеанса (SIP), чтобы установить и управлять вызовами или сеансами между абонентскими терминалами (или абонентскими терминалами и серверами приложений). Протокол описания сеанса (SDP), передаваемый посредством SIP-сигнализации, используется для описания и согласования медиа-компонентов сеанса. В то время как SIP был создан в качестве межпользовательского протокола, IMS дает возможность операторам и поставщикам услуг управлять доступом пользователя к услугам и соответственно производить тарификацию пользователей. Другими протоколами, которые используются для передачи и управления медиа, являются протокол передачи в реальном времени и протокол управления передачей в реальном времени (RTP/RTCP).

В сети IMS функциональные блоки управления вызовами (CSCF) выполняют обработку и маршрутизацию сигнализации. CSCF обрабатывают установление сеанса, изменение и прекращение сеансов IP-мультимедиа, используя стек протоколов SIP/SDP. Спецификация 3GPP TS23.228 описывает логические узлы P-CSCF, I-CSCF, S-CSCF, E-CSCF и BGCF. S-CSCF соответствует спецификации 3GPP TS 24.229 и выполняет услуги по управлению сеансами для абонентского оборудования (UE). Он поддерживает состояние сеанса для поддержки услуг и выполняет следующие функции:

он выступает в качестве регистратора в соответствии с [RFC3261] при регистрации;

он уведомляет подписчиков об изменениях регистрации;

он обеспечивает управление сеансами зарегистрированных пользователей;

он обрабатывает SIP-запросы и либо обслуживает их внутри, либо переадресует их на следующий узел; и

он взаимодействует с серверами приложений IMS.

S-CSCF выполняет SIP-маршрутизацию в соответствии с процедурами маршрутизации 3GPP.

Большинство SIP-сеансов в IMS, таких как вызовы, которые инициированы абонентским оборудованием, подлежат тарификации оператором. Архитектура IMS предусматривает две различных модели тарификации: тарификацию в автономном режиме и тарификацию в режиме реального времени.

Тарификация в режиме реального времени основывается на так называемой предоплатной модели подписки. Как правило, абонент покупает некоторое количество кредитов у оператора. Если SIP-сеанс инициирован SIP-запросом, отправленным с абонентского оборудования на S-CSCF, S-CSCF связывается с сервером приложений, осуществляя Функцию инициирования тарификации (CTF). Функция СTF описывается в спецификациях 3GPP TS 32.260 и 3GPP TS 32.299. Она поддерживает тарификацию для пользователей, использующих инфраструктуру и услуги IMS. Узел CTF определяет, подлежит ли запрашиваемый сеанс тарификации или нет. Если запрашиваемый сеанс подлежит тарификации, то узел CTF связывается с узлом системы тарификации в режиме реального времени (OCS), в которой хранится текущий кредит абонента. Если на счету абонента содержится достаточный кредит для предоставления SIP-запроса, OCS отвечает соответственно на CTF, который удовлетворяет запрос. Точно так же, если кредит недостаточен, SIP-запрос может быть отклонен, или может быть предоставлен сеанс на ограниченное количество времени.

Узлы CTF и OCS реализуют функциональность тарификации в режиме реального времени для архитектуры IMS. Связь между узлами CTF и OCS осуществляется посредством интерфейса Ro, описанного в спецификации 3GPP TS32.299, и осуществляется по протоколу DIAMETER. Более конкретно, CTF отправляет сообщения запроса кредитного контроля (CCR) по протоколу DIAMETER, тогда как OCS отвечает сообщениями ответа кредитного контроля (CCA) по протоколу DIAMETER. Эти сообщения описаны в RFC 4006.

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

Однако проблемы возникают когда линия связи, реализующая интерфейс Ro, используемый для соединения CTF и OCS, является ненадежной. Например, запрос транзакции может поступить на узел CTF тогда, когда OCS недоступен из-за того, что линия связи между CTF и OCS вышла из строя. В случае ошибки при обработке сообщения запроса кредитного контроля, OCS отправляет пару значений атрибутов (AVP) ′сбой обработки кредитного запроса контроля′, как определено в RFC 4006, на CTF. AVP указывает ПРОДОЛЖИТЬ (CONTINUE) запрашиваемый сеанс, ПРЕКРАТИТЬ (TERMINATE) запрашиваемый сеанс или ПОВТОРИТЬ и ПРЕКРАТИТЬ (RETRY и TERMINATE). В стандартном режиме, который выполняется CTF, если OCS совсем не направляет никакого ответа, то выполняется ПРЕКРАТИТЬ (TERMINATE). Оператору необходимо настроить CTF так, чтобы он мог принять решение о том, нужно ли удовлетворить запрос, полагая поведение по умолчанию ПРОДОЛЖИТЬ (CONTINUE), или сбросить его без доступа к состоянию кредита абонента, инициирующего транзакции.

При консервативном подходе CTF может по умолчанию отклонить запрос сеанса, если OCS недоступен. Такая политика дает возможность оператору избежать каких-либо потерь выручки в случае, если кредитный баланс абонента в действительности недостаточно высок для того, чтобы удовлетворить транзакцию. С другой стороны, если кредитный баланс абонента достаточно высок, чтобы провести транзакцию, абонент может быть не удовлетворен качеством услуги, так как транзакция не произошла независимо от кредитного баланса абонента.

При менее консервативном подходе CTF может разрешить продолжение сеанса независимо от кредитного баланса абонента, в случае если OCS недоступен. Такая политика ведет к высокой доступности услуги, но может привести к серьезным потерям выручки для оператора, в случае если кредитный баланс абонента недостаточно высок для проведения транзакций.

В соответствии с существующими и предлагаемыми в настоящее время архитектурами IMS отсутствует легкий способ конфигурации узла CTF и/или узла OCS таким образом, чтобы разрешить данное неудовлетворительное поведение в модели IMS для тарификации в режиме реального времени.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

В соответствии с первым аспектом настоящего изобретения, предусмотрен способ связи между двумя узлами, обеспечивающими функциональность тарификации в режиме реального времени в сети подсистемы IP-мультимедиа (IMS). Первый узел выполнен с возможностью функционировать в качестве функционального блока инициирования тарификации (CTF), и второй узел выполнен с возможностью функционировать в качестве служебного блока тарификации в режиме реального времени (OCS). Способ содержит этап приема на узле CTF запроса по протоколу установления сеанса (SIP), относящегося к SIP-сеансу, с сетевого узла. Кроме того, способ содержит предоставление уведомления на узел CTF. Уведомление указывает, что узел OCS недоступен. Если уведомление включает в себя указание того, что запросы ССR, относящиеся к SIP-сеансу, должны быть буферизированы, способ дополнительно содержит этап сохранения информации запроса кредитного контроля (ССR) на узле CTF. Сохраненная информация CCR соответствует упомянутому SIP-сеансу и подлежит отправке на OCS. Узел CTF хранит ее в буфере памяти. Узел CTF обрабатывает запросы, относящиеся к упомянутому SIP-сеансу, при том допущении, что были предоставлены соответствующие запросы CCR. Кроме того, узел CTF передает упомянутую буферизированную информацию CCR на упомянутый OCS после получения уведомления о том, что узел OCS доступен. Способ дополнительно содержит обработку упомянутой предварительно буферизированной информации CCR на узле OCS.

В соответствии со вторым аспектом настоящего изобретения, предусмотрен способ обработки запроса по протоколу установления сеанса (SIP) в узле подсистемы IP-мультимедиа (IMS), выполненном с возможностью функционировать в качестве функционального блока инициирования тарификации (CTF). Способ содержит этап приема на узле CTF запроса по протоколу установления сеанса (SIP), относящегося к SIP-сеансу, с сетевого узла. Кроме того, способ содержит предоставление уведомления на узел CTF. Уведомление указывает на то, что узел OCS недоступен. Если уведомление включает в себя указание того, что запросы ССR, относящиеся к SIP-сеансу, должны быть буферизированы, то способ дополнительно содержит этап сохранения информации запроса кредитного контроля (ССR) на узле CTF. Сохраненная информация CCR соответствует упомянутому SIP-сеансу и подлежит отправке на OCS. Узел CTF сохраняет ее в буфере памяти. Узел CTF обрабатывает запросы, относящиеся к упомянутому SIP-сеансу, при допущении того, что были предоставлены соответствующие запросы CCR. Кроме того, узел CTF передает упомянутую буферизированную информацию CCR на упомянутый OCS после получения уведомления о том, что OCS является доступным.

В соответствии с третьим аспектом настоящего изобретения, предусмотрен способ обработки сообщения запроса кредитного контроля (CCR) в сетевом узле подсистемы IP-мультимедиа (IMS), выполненном с возможностью функционировать в качестве служебного блока тарификации в режиме реального времени (OCS). Способ содержит этап приема предварительно буферизированной информации CCR от узла CTF. Способ дополнительно содержит обработку упомянутой предварительно буферизированной информации CCR. Предпочтительно, узел OCS может дополнительно направить уведомление на функциональный блок инициирования тарификации (CTF), указывающее на то, что узел OCS недоступен.

Уведомление о недоступности может предпочтительно быть передано от узла OCS на узел CTF.

Более предпочтительно, уведомление о недоступности может быть передано посредством ответного сообщения с ответом на запрос кредитного контроля (CCA), и оно может содержать указание о том, что запросы ССR, относящиеся к SIP-сеансу, должны быть буферизированы.

Предпочтительно, ответное сообщение ССА может содержать указание ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER).

Буферизированная информация ССR может быть предпочтительно передана в, по меньшей мере, одном запросе ССR, включая указание того, что информация была буферизирована.

В соответствии с четвертым аспектом настоящего изобретения, предусмотрено устройство, содержащее первый узел, выполненный с возможностью функционировать в качестве функционального блока инициирования тарификации (CTF), в сети подсистемы IP-мультимедиа (IMS). Устройство содержит первый приемный модуль для приема SIP-запросов, второй приемный модуль для приема ответных сообщений ССА, первый передающий модуль для отправки SIP-сообщений, второй передающий модуль для отправки запросов ССR; память, выполненную с возможностью буферизации информации CCR; и модуль обработки. Модуль обработки выполнен с возможностью генерации информации ССR, соответствующей принятому SIP-запросу и относящейся к SIP-сеансу. При условии предоставления уведомления, указывающего на то, что услуга OCS недоступна, и что запросы ССR, относящиеся к SIP-сеансу, должны быть буферизированы, модуль обработки конфигурируется следующим образом. Он выполнен с возможностью соxранять упомянутую информацию CCR в буфере. Mодуль обработки, помимо всего прочего, выполнен с возможностью обрабатывать SIP-запросы, относящиеся к упомянутому SIP-сеансу, при допущении того, что предоставлены упомянутые запросы ССR, и считывать упомянутую информацию CCR с упомянутого буфера, перед передачей упомянутой информации CCR в, по меньшей мере, одном запросе ССR на упомянутый узел OCS, когда он доступен.

Предпочтительно, модуль обработки может дополнительно быть выполнен с возможностью включать в упомянутый, по меньшей мере, один запрос ССR, содержащий буферизированную информацию, которая передается на упомянутый узел OCS, указание того, что информация, содержащаяся в нем, была буферизирована.

В соответствии с пятым аспектом настоящего изобретения, предусмотрено устройство, содержащее второй узел, выполненный с возможностью функционировать в качестве служебного блока тарификации в режиме реального времени (OCS), в сети подсистемы IP-мультимедиа (IMS). Устройство содержит приемный модуль для приема запросов CCR, передающий модуль для отправки ответных сообщений CCA, память и модуль обработки. Модуль обработки выполнен с возможностью обработки запросов CCR, относящиxся к SIP-сеансу, причем запрос CCR получен от узла CTF и содержит указание того, что включенная информация CCR была буферизирована упомянутым узлом CTF.

Предпочтительно, модуль обработки может дополнительно быть выполнен с возможностью передавать уведомление о недоступности в ответ на запрос CCR, полученный от CTF.

Более предпочтительно, модуль обработки может дополнительно быть выполнен с возможностью передавать уведомление о недоступности в ответ на запрос CCR, полученный от CTF, посредством ответного сообщения с ответом на запрос контроля кредита (CCA), которое содержит указание того, что запросы ССR, относящиеся к упомянутому SIP-сеансу, должны быть буферизированы.

Ответное сообщение ССА может предпочтительно содержать указание ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER).

Варианты осуществления настоящего изобретения позволяют уменьшить проблемы, возникшие при тарификации в режиме реального времени в системе на базе архитектуры IMS в случае, когда линия связи между CTF и OCS является ненадежной. Используя настоящее изобретение, операторы имеют возможность поддерживать доступность услуг без потери дохода. Операторы могут использовать интерфейс Ro как для абонентов с предоплатой, так и для абонентов с оплатой по факту, поскольку иx расходы могут быть рассчитаны задним числом.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 изображает сигнализацию, относящуюся к способу, в соответствии с вариантом осуществления настоящего изобретения.

Фиг. 2 изображает сигнализацию, относящуюся к способу, в соответствии с вариантом осуществления настоящего изобретения.

Фиг. 3 представляет собой блок-схему, иллюстрирующую этапы способа в соответствии с вариантом осуществления настоящего изобретения.

Фиг. 4 представляет собой блок-схему, иллюстрирующую этапы способа в соответствии с вариантом осуществления настоящего изобретения.

Фиг. 5 представляет собой блок-схему, иллюстрирующую этапы способа в соответствии с вариантом осуществления настоящего изобретения.

Фиг. 6 схематично иллюстрирует вариант осуществления устройства, реализующего узел CTF.

Фиг. 7 схематично иллюстрирует вариант осуществления устройства, реализующего узел OCS.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Как описано выше, в архитектуре IMS существует необходимость использования доступной инфраструктуры, относящейся к тарификации в режиме реального времени более эффективно. В настоящее время, если недоступно соединение между узлами CTF и OCS, реализованное посредством интерфейса Ro, то не существует никакого способа установления SIP-сеанса для абонента, даже если у абонента имеется кредитный баланс, который позволил бы установить такой сеанс. В соответствии с настоящим изобретением, эта проблема решается, например, за счет дополнения пары значений атрибутов (AVP) ′сбой обработки запроса кредитного контроля′ новым значением. Новое значение указывает на то, что CTF должен продолжать установление запрашиваемого сеанса и буферизировать любые запросы кредитного контроля (CCR) в отношении запрашиваемого сеанса для последующей обработки на OCS. В нижеследующем описании новое значение будет обозначаться как указание ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER).

Для того чтобы реализовать изобретение в соответствии с настоящим изобретением, CTF обеспечивается возможностью буферизации запросов ССR при получении уведомления ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER). Более того, CTF обеспечивается возможностью опустошения упомянутого буфера от информации CCR позднее, когда OCS снова становится доступен. CTF очищает буфер путем отправки ранее сгенерированных запросов ССR на OCS, включающих указание того, что они представляют собой буферизированные, а следовательно, не в реальном времени, запросы. OCS, кроме того, обеспечивается возможностью обрабатывать запросы ССR, которые не являются запросами в реальном времени и которые включают в себя предварительно буферизированную информацию CCR.

Последовательность событий обработки ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER) AVP указана на Фиг. 1.

Абонентское оборудование UE или сервер приложений AS запрашивает установление нового SIP-сеанса с вызываемой стороной. Соответствующий запрос SIP INVITE (ПРИГЛАШЕНИЕ) принимается CTF, возможно с помощью CSCF, который не показан на Фиг. 1. CTF генерирует первый CCR, обозначенный как CCR-1, который содержит идентификатор пользователя запрашивающей стороны, а также информацию об услуге, относящуюся к запрашиваемой услуге. CCR-1 передается через интерфейс Ro на OCS, который содержит кредитный баланс абонента.

Если OCS недоступен для предоставления услуг, например, потому что он перегружен, он отвечает CTF, используя новую пару значений атрибутов ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER). Помимо всего прочего, оператор может настроить CTF на использование значения ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER) в качестве значения по умолчанию всякий раз, когда OCS не отвечает. После того, как уведомление с указанием ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER) AVP будет доступнo на CTF, он сохраняет ранее отправленный CCR в памяти, которая выполнена с возможностью сохранять информацию CCR, относящуюся к запрашиваемому сеансу. Эта память называется буфером CCR.

Предполагая, что OCS предоставил соответствующий CCR, CTF направляет сообщение SIP INVITE (ПРИГЛАШЕНИЕ) вызываемой стороне, что хорошо известно в данной области техники. Если сеанс успешно установлен, с вызывающей стороны на CTF принимается подтверждение SIP 200 OK (успешно), и направляется с помощью CTF на вызывающий абонентское оборудование (UE) или AS. После установления сеанса CTF может, например, сгенерировать второе сообщение CCR, которое должно быть передано на OCS. CCR-2 содержит информацию, касающуюся установленного сеанса. Как только CTF узнает, что OCS недоступен, он сохраняет CCR-2 в буфере CCR.

Точно так же, как только SIP-сеанс прекращается запросом SIP BYE, CTF генерирует соответствующий запрос на прекращение (CCR-3) и сохраняет его в буфере CCR.

Последовательность событий для очистки буфера CCR на CTF и обработки буферизированных запросов ССR в OCS показана в Фиг. 2.

Буфер CCR на CTF в идеале настроен как FIFO-буфер («первым пришел - первым ушел»), так что поддерживается последовательность сгенерированных запросов ССR, принадлежащих одному и тому же сеансу. Сначала CTF отправляет первичный запрос CCR-1 на OCS. Предпочтительно, если все передаваемые запросы ССR включают в себя указание того, что передаваемая информация была буферизирована, и, следовательно, не являются запросами в реальном времени. OCS обрабатывает принятые запросы ССR и проверяет кредитный баланс абонента. Независимо от результата проверки баланса, ответное сообщение ССА, указывающее на одобрение запроса, передается в CTF.

Оператор может предпочтительно реализовать на OCS политику обновления кредитного баланса абонента задним числом в соответствии с принятыми буферизированными запросами ССR, которые отображают предыдущие услуги абонента и использование инфраструктуры. Такая политика делает возможным оператору восстановить по меньшей мере некоторые из его доходов, когда интерфейс Rо не работает, в то же время обеспечить доступность предложенных услуг. Могут быть применены другие политики для учета потребностей абонента.

CTF не предпринимает никаких действий с принятыми CCA, поскольку сеанс был уже предоставлен раньше. Остальная буферизированная информация CCR обрабатывается подобным же образом.

В предпочтительном варианте осуществления настоящего изобретения передача указания ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER) реализуется с использованием сообщения AVP ′сбой обработки кредитного контроля′ (код AVP 427), как определено в RFC 4006. AVP возвращается в CTF в CCA, отправленном с CCS, и представляет собой данные перечислимого типа, принимающие следующие возможные значения:

- ПРЕКРАТИТЬ (TERMINATE) 0;

- ПРОДОЛЖИТЬ (CONTINUE) 1;

- ПОВТОРИТЬ И ПРЕКРАТИТЬ (RETRY_AND_TERMINATE) 2;

- ПРОДОЛЖИТЬ БУФЕРИЗАЦИЮ (CONTINUE_BUFFER) 3.

В альтернативном варианте осуществления настоящего изобретения передача указания CONTINUE_BUFFER реализуется с использованием опытного кода AVP (Experimental-Code-AVP), определенного в RFC 3588. Аналогично, значение AVP ′запрос CCR не в реальном времени′ может быть добавлено для того, чтобы передать указание того, что запросы CCR, передаваемые от CTF на OCS, были предварительно буферизированы, и представляют информацию ССR не в реальном времени.

Фиг. 3 иллюстрирует основные этапы способа в соответствии с настоящим изобретением в виде блок-схемы, соответствующей диаграмме последовательности действий на Фиг. 1 и 2. Способ начинается на этапе 10. На этапе 11 узел CTF принимает SIP-запрос, относящийся к SIP-сеансу. На этапе 12 уведомление о том, что служебный узел OCS недоступен, поступает на узел CTF. На этапе 13 CTF проверяет, содержит ли уведомление указание того, что запросы ССR, относящиеся к SIP-сеансу, подлежат буферизации, и что соответствующие SIP-запросы должны быть обработаны при допущении того, что были предоставлены соответствующие запросы CCR. Eсли такое указание присутствует, то CTF сохраняет информацию CCR, относящуюся к упомянутому SIP-сеансу, в буфере памяти на этапе 14. На этапе 15 узел CTF обрабатывает SIP-запросы, которые относятся к SIP-сеансу, при допущении того, что были предоставлены соответствующие запросы CCR. Как только служебный узел OCS становится доступным снова, на этапе 16 узел CTF передает буферизированную информацию ССR на OCS. В конце концов, на этапе 17 узел OCS обрабатывает предварительно буферизированную информацию CCR, которая была принята от CTF.

Фиг. 4 иллюстрирует основные этапы способа, реализованного в одном варианте осуществления с помощью узла CTF, подобного узлу CTF, изображенному на Фиг. 1 и 2. Способ начинается на этапе 20. На этапе 21 узел CTF принимает SIP-запрос, относящийся к SIP-сеансу. На этапе 22 уведомление о том, что служебный узел OCS недоступен, поступает на узел CTF. На этапе 23 CTF проверяет, содержит ли уведомление указание того, что запросы ССR, относящиеся к SIP-сеансу, подлежат буферизации, и что соответствующие SIP-запросы должны быть обработаны при допущении того, что были предоставлены соответствующие запросы CCR. Eсли такое указание присутствует, то CTF сохраняет информацию CCR, относящуюся к упомянутому SIP-сеансу, в буфере памяти на этапе 24. На этапе 25 узел CTF обрабатывает SIP-запросы, которые относятся к SIP-сеансу, при допущении того, что были предоставлены соответствующие запросы CCR. Как только служебный узел OCS становится доступен снова, узел CTF передает на этапе 26 буферизированную информацию ССR на OCS.

Фиг. 5 иллюстрирует основные этапы способа, реализованного в одном варианте осуществления с помощью узла OCS, подобного узлу OCS, изображенному на Фиг. 1 и 2. Способ начинается на этапе 30. На этапе 31 узел OCS принимает запрос CCR, содержащий информацию ССR, которая была предварительно буферизирована на CTF. На этапе 32 узел OCS обрабатывает предварительно буферизированную информацию CCR, которая была принята от CTF.

Фиг. 6 схематично иллюстрирует вариант осуществления узла 100 IMS в соответствии с настоящим изобретением. Узел выполнен с возможностью функционировать в качестве функционального блока инициирования тарификации (CTF). Это обеспечивает функциональность узла CTF на Фиг. 1 и 2. Узел 100 содержит, по меньшей мере, первый приемный модуль 110 для приема SIP-пакетов от S-CSCF, абонентского оборудования UE или AS, и первый передающий модуль 111 для отправки SIP-пакетов. Узел 100 дополнительно содержит, по меньшей мере, второй приемный модуль 120 для приема ответных сообщений CCA по протоколу DIAMETER от узла OCS, и второй передающий модуль 121 для отправки запросов ССR по протоколу DIAMETER на узел OCS. Узел 100 дополнительно содержит модуль 130 обработки и память 140, причем модуль 130 обработки выполнен с возможностью генерации информации ССR, соответствующей принятому SIP-запросу и относящейся к SIP-сеансу. Mодуль обработки дополнительно выполнен с возможностью проверки того, доступно ли уведомление на узле 100 о том, что узел OCS недоступен, и указывающее на то, что запросы ССR, относящиеся к SIP-сеансу, которые должны были быть переданы на упомянутый OCS, вместо этого должны буферизироваться в область 150 буфера упомянутой памяти. Модуль 130 обработки дополнительно выполнен с возможностью соxранять сгенерированный запрос 122 CCR в буфере памяти 150, при условии поступления упомянутого оповещения. Модуль 130 обработки обрабатывает входящие SIP-запросы, относящиеся к SIP-сеансу, при допущении того, предоставлены соответствующие запросы ССR. Кроме того, модуль 130 обработки выполнен с возможностью считывать буферизированную информацию 122 запроса CCR из памяти 150 буфера и передавать ее в, по меньшей мере, одном запросе CCR на узел OCS, как только он становится доступным. Предпочтительно, модуль обработки указывает в исходящем запросе CCR, что содержащаяся в запросе CCR информация была буферизирована.

Фиг. 7 схематично иллюстрирует вариант осуществления узла 200 IMS в соответствии с настоящим изобретением. Узел 200 выполнен с возможностью функционировать в качестве служебного блока тарификации в режиме реального времени (OCS). Это обеспечивает функциональные возможности узла OCS на Фиг. 1 и 2. Узел 200 содержит, по меньшей мере, приемный модуль 220 для приема запросов ССR по протоколу DIAMETER от узла CTF и второй передающий модуль 221 для отправки ответов CCA по протоколу DIAMETER на узел CTF. Узел 200 дополнительно содержит модуль 230 обработки и память 240, причем модуль обработки выполнен с возможностью обработки информации ССR, которая получена в запросе CCR, содержащем информацию CCR не в реальном времени, которая была предварительно буферизирована. Преимущественно, модуль обработки выполнен с возможностью генерации ответного сообщения ССА, которое информирует узел CTF о том, что узел OCS недоступен, и что узел CTF должен буферизировать запросы ССR.

Модули 140, 240 памяти сохраняют команды для обработки соответствующими модулями 130, 230 обработки. Каждый узел 100, 200 может рассматриваться как компьютер, выполненный с возможностью выступать в качестве описанного путем обработки соответствующих сохраненных команд.

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