способ и система предоставления отчета об объеме использования службы данных, медиапроцессор и медиаконтроллер
Классы МПК: | H04L12/04 коммутационные панели |
Автор(ы): | ЧЭНЬ Цян (US) |
Патентообладатель(и): | ХУАВЭЙ ТЕКНОЛОДЖИЗ КО., ЛТД. (CN) |
Приоритеты: |
подача заявки:
2009-03-27 публикация патента:
27.05.2012 |
Изобретение относится к области отслеживания объема использования службы данных. Техническим результатом является повышение эффективности отслеживания объема использования службы данных. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре включает этапы: медиапроцессор (МР) принимает квоту, доставленную от медиаконтроллера (МС); МР устанавливает квоту для прерывания в МР и собирает статистические данные об объеме использования службы данных прерывания; и предоставляет отчет о событии исчерпания квоты в МС в том случае, когда объем использования службы данных, потребляемый прерыванием, достигнет квоты. В вариантах осуществления настоящего изобретения, при взаимодействии между МС и МР в реальном масштабе времени, МР может контролировать объем использования службы данных в реальном масштабе времени и предоставлять отчет о статистической информации тогда, когда выполнены условия. Таким образом, информацию об объеме использования службы данных можно предоставлять проактивно в реальном масштабе времени. 4 н. и 15 з.п. ф-лы, 6 ил.
Формула изобретения
1. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре, содержащий этапы:
прием медиапроцессором (МР) квоты, доставленной посредством медиаконтроллера МС; и
установку в МР квоты для прерывания, и сбор информации об объеме использования службы данных прерыванием; и предоставление отчета в МС о событии исчерпания квоты в том случае, когда объем использования службы данных, потребляемый прерыванием, достигнет квоты.
2. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по п.1, дополнительно содержащий:
прием посредством МР периода достоверности, доставленного от МС; и
установление периода достоверности для прерывания, и предоставление отчета о событии истечения периода достоверности в том случае, когда квота не достигнута, но период достоверности истек, причем событие истечения периода достоверности содержит значение объема использования службы данных, потребляемого в течение периода достоверности.
3. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по п.1, в котором: после предоставления в МР отчета о событии исчерпания квоты, способ дополнительно содержит:
прием посредством МР новой квоты, указанной посредством МС; и
установление квоты для прерывания в соответствии с новой квотой, и получение статистических данных об объеме использования службы данных прерывания.
4. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по п.2, в котором: после предоставления в МР отчета о событии исчерпания квоты, или после того, как МР предоставляет отчет о событии истечения периода достоверности, способ дополнительно содержит:
завершение посредством МР прерывания, соответствующего сеансу, и предоставление отчета о последнем объеме использования службы данных прерывания после приема посредством МС от пользовательского оборудования (UE) запроса завершения сеанса, при этом последний объем использования не был сообщен до завершения сеанса;
в котором предоставление отчета о последнем объеме использования содержит:
вычисление накопленного значения объема использования службы данных, потребленного прерыванием, предоставление отчета в МС о накопленном значении с тем, чтобы МС мог получить последний объем использования в соответствии с накопленным значением за вычетом всех объемов использования, предоставленных ранее.
5. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по п.1, в котором: МР устанавливает квоту для прерывания следующим образом:
устанавливает соответствующую квоту для прерывания согласно идентификатору потока, соответствующему конкретному типу медиапотока прерывания.
6. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по п.1, в котором: после предоставления отчета о событии исчерпания квоты, способ дополнительно содержит:
предоставление посредством МС отчета о событии исчерпания квоты системе онлайн начисления оплаты (OCS); начисление оплаты посредством OCS для прерывания в соответствии с величиной квоты, содержащейся в событии исчерпания квоты.
7. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре в соответствии с пп.1-6, в которых: объем использования службы данных содержит:
трафик или количество службы данных, потребленное в направлении отправления в направлении приема, причем
трафик является общим трафиком или полезным трафиком.
8. Способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по п.7, в котором:
МС является контроллером функции ресурсов мультимедиа (MRFC), и МР является процессором функции ресурсов мультимедиа (MRFP).
9. Медиаконтроллер (МС), отличающийся тем, что МС содержит:
первый модуль управления, приспособленный для отправки квоты, заданной в индикации квоты, медиапроцессору (МР) после приема индикации квоты, и инструктирования МР установить квоту для прерывания; и
второй модуль управления, приспособленный для приема события исчерпания квоты, которое сообщается посредством МР в том случае, когда объем использования службы данных, потребляемый прерыванием, достигает квоты.
10. МС по п.9, дополнительно содержащий:
шестой модуль управления, приспособленный для инструктирования МР установить период достоверности для прерывания в том случае, когда период достоверности квоты принимается одновременно с приемом индикации квоты; и
седьмой модуль управления, приспособленный для приема события истечения периода достоверности, предоставленного в отчете посредством МР, в том случае, когда квота не достигнута, но период достоверности истек.
11. МС по п.9, дополнительно содержащий:
третий модуль управления, приспособленный для предоставления отчета о событии исчерпания квоты, принятом вторым модулем управления, к системе онлайн начисления оплаты (OCS), вследствие чего OCS осуществляет начисление оплаты для прерывания в соответствии с величиной квоты, содержащейся в событии исчерпания квоты.
12. МС по п.11, дополнительно содержащий:
четвертый модуль управления, приспособленный для инструктирования МР завершить прерывание, соответствующее сеансу, и предоставить отчет о последнем объеме использования службы данных прерыванием, перед завершением сеанса, при приеме запроса завершения сеанса от пользовательского оборудования (UE); и
пятый модуль управления, приспособленный для предоставления отчета в OCS о последнем объеме использования, вследствие чего OCS осуществляет начисление оплаты для прерывания в соответствии с последним объемом использования.
13. МС по п.12, дополнительно содержащий:
восьмой модуль управления, приспособленный для предоставления в OCS отчета о событии истечения периода достоверности, вследствие чего OCS осуществляет начисление оплаты для прерывания в соответствии с объемом использования службы данных, потребляемым в допустимом периоде, причем объем использования содержится в событии истечения периода достоверности.
14. Медиапроцессор (МР), отличающийся тем, что МР содержит:
первый модуль обработки, приспособленный для приема квоты, доставленной медиаконтроллером (МС), или приема квоты периода достоверности;
второй модуль обработки, приспособленный для установки квоты для прерывания и сбора статистических данных об объеме использования службы данных прерывания; и
третий модуль обработки, приспособленный для предоставления в МС отчета о событии исчерпания квоты в том случае, когда объем использования службы данных, потребляемый прерыванием, достигает квоты.
15. МР по п.14, дополнительно содержащий:
шестой модуль обработки, предназначенный для установки периода достоверности для прерывания; и
седьмой модуль обработки, предназначенный для предоставления отчета о событии истечения периода достоверности в том случае, когда квота не достигнута, но период достоверности истек.
16. МР по п.15, дополнительно содержащий:
четвертый модуль обработки, приспособленный для завершения прерывания, соответствующего сеансу, в том случае, когда МС принимает запрос завершения сеанса от пользовательского оборудования (UE); и
пятый модуль обработки, приспособленный для предоставления отчета о последнем объеме использования службы данных прерывания перед завершением сеанса после того, как четвертый модуль обработки завершает прерывание.
17. Система предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре, содержащая медиаконтроллер (МС) и медиапроцессор (МР), которые связаны телекоммуникационно, в которой:
МС приспособлен для передачи в МР квоты, заданной в индикации квоты, после приема индикации квоты; и
МР приспособлен для установки квоты для прерывания и сбора статистических данных об объеме использования службы данных прерывания; и предоставления отчета о событии исчерпания квоты в МС в том случае, когда объем использования службы данных, потребляемый прерыванием, достигнет квоты.
18. Система предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени по п.17, в которой:
МР дополнительно приспособлен для установления периода достоверности для прерывания и предоставления отчета о событии истечения периода достоверности в том случае, когда квота не достигнута, но период достоверности истек, причем событие истечения периода достоверности содержит объем использования службы данных, потребленный в течение периода достоверности.
19. Система предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени по п.18, в которой: система дополнительно содержит систему он-лайн начисления оплаты (OCS), которая связана телекоммуникационно с МС, и OCS содержит:
первый модуль начисления оплаты, приспособленный для передачи в МС квоты; и
второй модуль начисления оплаты, приспособленный для осуществления начисления оплаты в МР при прерывании в соответствии с величиной квоты, содержащейся в событии исчерпания квоты, предоставленном в отчете от МС, или в соответствии с объемом использования службы данных, потребляемым в периоде достоверности, причем объем использования содержится в событии истечения периода достоверности, предоставленном в отчете от МС, или в соответствии с последним объемом использования, предоставленным в отчете от МС.
Описание изобретения к патенту
ОБЛАСТЬ ИЗОБРЕТЕНИЯ
Настоящее изобретение относится к технологии предоставления отчета об объеме использования службы данных, и, более конкретно, к способу проактивного предоставления отчета об объеме использования службы данных в распределенной архитектуре, к медиапроцессору MP и медиаконтроллеру MC.
УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ
В сети с распределенной архитектурой услуга или управление отделены от несущей, и для осуществления связи и взаимодействия между объектами сети принят стандартный протокол. В существующей распределенной архитектуре объем использования службы данных получается путем выполнения запроса объема использования. А именно MC после завершения сеанса или в течение сеанса посылает в MP запрос на статистическую информацию, такую как количество и трафик. В ответ на этот запрос MP посылает ответное сообщение к MC. Ответное сообщение содержит статистическую информацию.
На известном уровне техники существуют недостатки: сеть распределенной архитектуры согласно уровню техники не в состоянии контролировать объем использования службы данных в реальном масштабе времени. В существующей сети распределенной архитектуры MC отделен от MP. Управление в реальном масштабе времени в отношении объема использования службы данных требует осуществляемого в реальном масштабе времени контроля количества и трафика услуги в режиме реального времени, и проактивного отчета об объеме использования в том случае, когда наблюдаемые количество или трафик достигают пороговой величины. Согласно уровню техники у MC нет сведений о том, когда количество или трафик службы данных достигнет пороговой величины, и нет сведений о времени осуществления запроса об объеме использования. Когда MP предоставляет отчет о статистических данных в MC, ответ МР о статистических данных по количеству или трафику службы данных является неясным. Таким образом, в уровне техники взаимодействие между MC и MP в реальном масштабе времени с целью осуществления управления объемом использования службы данных в реальном масштабе времени в сети с распределенной архитектурой не осуществляется.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Целью настоящего изобретения является отчет об объеме использования службы данных в реальном масштабе времени в сети распределенной архитектуры.
Для удовлетворения этой цели в варианте осуществления настоящего изобретения предоставлен способ проактивного отчета в реальном масштабе времени об объеме использования службы данных.
Способ включает:
посредством MP получение квоты, доставленной MC; и
установление квоты для прерывания (окончания), и сбор информации об объеме использования службы данных упомянутого прерывания, где прерывание создается посредством MP в том случае, когда пользовательское оборудование (UE) обращается к службе, и является логической сущностью, отображенной на UE; а также предоставление отчета к MC о событии исчерпания квоты в том случае, когда объем использования службы данных, потребляемый прерыванием, достигнет квоты.
MC, предоставленный в одном из вариантов осуществления настоящего изобретения, включает в себя:
первый модуль управления, предназначенный для: отправки квоты, заданной в индикации квоты, к MP после приема индикации квоты, и инструктирование MP установить квоту для прерывания; и
второй модуль управления, предназначенный для приема события исчерпания квоты, которое сообщается посредством MP в том случае, когда объем использования службы данных, потребляемый прерыванием, достигает квоты.
MP, предоставленный в одном из вариантов осуществления настоящего изобретения, включает:
первый модуль обработки, предназначенный для: приема квоты, отправленной MC, или приема квоты допустимого периода;
второй модуль обработки, предназначенный для: установки квоты для прерывания и сбора данных об объеме использования службы данных прерыванием; и
третий модуль обработки, предназначенный для предоставления отчета в MC о событии исчерпания квоты в том случае, когда объем использования службы данных, потребляемый прерыванием, достигает квоты.
В другом варианте осуществления настоящего изобретения система отчета в реальном масштабе времени проактивным образом об объеме использования службы данных в распределенной архитектуре включает в себя MC и MP, которые связаны телекоммуникационно.
MC выполнен с возможностью передачи к MP квоты, заданной в индикации квоты, после приема индикации квоты; и
MP выполнен с возможностью: установки квоты для прерывания и сбора данных об объеме использования службы данных прерыванием; и сообщения события исчерпания квоты в MC в том случае, когда объем использования службы данных, потребляемый прерыванием, достигнет квоты.
В вариантах осуществления настоящего изобретения, при взаимодействии между MC и MP в реальном масштабе времени, MP может отслеживать объем использования службы данных в реальном масштабе времени и предоставлять отчет о статистической информации тогда, когда выполнены условия. Таким образом, информацию об объеме использования службы данных можно предоставлять проактивно в реальном масштабе времени.
КРАТКОЕ ОПИСАНИЕ чертежей
Для более наглядной иллюстрации технического решения по вариантам осуществления настоящего изобретения или на современном уровне техники ниже схематически предоставлены прилагаемые чертежи. Понятно, что прилагаемые чертежи в следующем описании представляют собой только некоторые варианты осуществления настоящего изобретения, и специалисты в данной области из прилагаемых чертежей без творческих усилий могут получить другие чертежи.
Фиг.1 представляет собой блок-схему последовательности операций при сообщении отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по первому варианту осуществления настоящего изобретения.
Фиг.2 представляет собой блок-схему последовательности операций при сообщении отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по второму варианту осуществления настоящего изобретения.
На Фиг.3 представлена архитектура службы конференц-связи сообщений по одному из вариантов осуществления настоящего изобретения.
Фиг.4 представляет собой блок-схему последовательности операций процесса начисления в онлайн режиме в службе конференц-связи сообщений по одному из вариантов осуществления настоящего изобретения.
На Фиг.5 представлена структура системы сообщения отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по первому варианту осуществления настоящего изобретения; и
на Фиг.6 представлена структура системы сообщения отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре по второму варианту осуществления настоящего изобретения.
ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Следующее подробное описание относится к техническому решению по настоящему изобретению со ссылкой на прилагаемые чертежи. Однако описанные варианты осуществления представляет собой только часть, а не все варианты осуществления настоящего изобретения. Кроме того, в пределы объема настоящего изобретения попадают все другие варианты осуществления, которые специалисты в данной области могут получить без приложения каких-либо творческих усилий на основе вариантов осуществления, предоставленных в настоящем документе.
Первый вариант осуществления способа
Данный вариант осуществления предоставляет способ отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре. Как представлено на Фиг.1, способ включает:
Этап 101: MC получает индикацию квоты. Конкретно, в MC индикация квоты может быть доставлена системой онлайн начисления оплаты (OCS).
Индикация квоты содержит квоту, подлежащую дальнейшему уточнению. Квота является пороговой величиной объема использования службы данных, разрешенной для отправки или приема пользователем, например, количества или трафика сообщений в службе данных. Трафик относится к общему трафику или полезному трафику. Полезный трафик относится к фактическому эффективному трафику за исключением служебных сигналов.
Установка квоты в направлении отправки известна как квота в направлении отправки; а установка квоты в направлении приема известна как квота в направлении приема. Конкретно, для доставки квоты, усиления взаимодействия между MC и MP и сообщения об объеме использования службы данных проактивно в реальном масштабе времени может быть расширен пакет согласно протоколу H.248.
Этап 102: В соответствии с принятой индикацией квоты MC дает команду MP установить квоту для прерывания.
Прерывание осуществляется посредством MP в том случае, когда UE обращается к службе, и является логическим объектом, отображаемым на UE. Квота в направлении отправки может быть той же самой или отличаться от квоты в направлении приема. Например, как квоту в направлении отправки и квоту в направлении приема устанавливают в соответствии с трафиком, и величина квоты составляет 1024 байт.
Этап 103: После завершения установки квоты MP собирает данные об объеме использования службы данных прерывания; и сообщает MC о событии исчерпания квоты в том случае, когда объем использования службы данных, потребляемый прерыванием, достигнет квоты, а именно, когда достигается квота. Событие исчерпания квоты переносит сигнал о потребляемой квоте. Например, потребляемый трафик службы данных равен 1024 байта.
После приема сообщения о событии исчерпания квоты MC может предоставить отчет в OCS о событии исчерпания квоты, и OCS осуществляет начисление платы для прерывания в соответствии с величиной квоты, переносимой в событии исчерпания квоты. Таким образом, онлайновое начисление оплаты выполняется в реальном масштабе времени. В частности, OCS вычитает соответствующую сумму в счете, соответствующем UE.
Этап 104: После приема новой индикации квоты MC может повторить этапы 102-103. После принятого от UE запроса завершения сеанса MC выполняет этап 105.
На этом этапе процесс изменения квоты может возникнуть снова в зависимости от состояния использования UE службы данных, и измененная квота может остаться такой же или отличаться от прежней квоты.
Этап 105: В том случае, когда UE отправляет запрос завершения сеанса к MC, чтобы запросить завершение текущего сеанса, MC инструктирует MP освободить прерывание, соответствующее сеансу.
Конкретно, MP вычисляет накопленное значение объема использования прерыванием службы данных и возвращает накопленное значение в MC. В соответствии с накопленным значением MC вычисляет последнее значение объема использования, о котором от прерывания до завершения сеансу еще не предоставляли отчет. Например, если принятое накопленное значение составляет 2048 байта, и весь сообщенный ранее объем использования в сумме составлял 1536 байта, то последний объем использования прерывания вычисляется как 2048-1536=512 байт.
В противном случае MC может сообщать OCS о последнем объеме использования, и OCS производит начисление оплаты в соответствии с последним объемом использования.
Согласно способу описанного выше варианта осуществления MC взаимодействует с MP в реальном масштабе времени, и MP может отслеживать объем использования службы данных в реальном масштабе времени и предоставлять отчет о статистической информации в том случае, когда выполнены условия. Таким образом, объем использования службы данных можно предоставлять проактивно в реальном масштабе времени.
Второй вариант осуществления способа
Данный вариант осуществления является усовершенствованием первого варианта осуществления, и предоставляет способ предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре. Как представлено на Фиг.2, способ включает:
Этап 201 аналогичен этапу 101.
Этап 202: После приема индикации квоты MC инструктирует MP установить квоту и значение периода достоверности для прерывания. Например, период достоверности составляет 10 секунд, и квота 1024 байт.
Этап 203: После того, как квота и период достоверности установлены, собираются статистические данные об объеме использования службы данных прерывания. В том случае, если квота достигается, процесс переходит к этапу 210; в том случае, если квота не достигнута, но период достоверности истек, процесс переходит к этапу 220, где истечение периода достоверности может быть определено таймером.
Этап 210: MP предоставляет отчет в MC о событии исчерпания квоты. Событие исчерпания квоты переносит сигнал о потребленной квоте. Например, использованы сообщения в 1024 байта.
Этап 220: MP предоставляет отчет о событии истечения периода достоверности. Событие истечения периода достоверности переносит объем использования службы данных, потребляемый в течение периода достоверности, например 512 байт, которые меньше чем квота в 1024 байта.
MC также может предоставлять отчет в OCS о событии исчерпания квоты и о событии истечения периода достоверности, и OCS при прерывании осуществляет начисление оплаты в соответствии с величиной квоты, содержащейся в событии исчерпания квоты, и объемом использования службы данных, содержащимся в событии истечения периода достоверности.
Этап 230: После приема инструкции новой квоты MC может повторить этапы 202-203 и этапы 210-220 с целью управления прерыванием и предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени.
На этом этапе процесс изменения квоты может возникнуть снова в зависимости от состояния использования UE службы данных, и измененная квота может остаться такой же или отличаться от прежней квоты.
Затем, согласно этапу 106 и этапу 107 по первому варианту осуществления после завершения сеанса может быть сообщено последнее значение объема использования.
Согласно способу описанного выше варианта осуществления устанавливают период достоверности, благодаря чему MC получает объем использования службы данных прерывания периодически, а также избегают сбоя предоставления отчета о статистической информации в случае, когда объем использования службы данных не достигает заранее заданной квоты, из-за сбоев оборудования.
Взяв, например, оплату службы конференц-связи сообщений, нижеследующее усовершенствует сигнальный поток по способу отчета об объеме использования службы данных проактивно в реальном масштабе времени согласно способу вышеизложенным вариантам осуществления.
Служба конференц-связи сообщений позволяет пользователю посылать контент другим пользователям с целью создания конференц-связи сообщений в режиме онлайн. Контент сообщения в службе конференц-связи сообщений может представлять собой текст, Web-страницу, рисунок или любые другие файлы, включая песни и видеоклипы. На Фиг.3 представлена архитектура службы конференц-связи сообщений, основанная на мультимедийной подсистеме на базе протокола IP (IMS). Архитектура включает: UE, функцию управления сеансами вызова (CSCF), сервер приложений (AS) или контроллер функции ресурсов мультимедиа (MRFC), процессор функции ресурсов мультимедиа (MRFP), и домен выставления счетов.
UE, CSCF, AS/MRFC взаимодействуют друг с другом посредством протокола инициации сеанса (SIP); UE взаимодействует с MRFP посредством протокола трансляции сеанса сообщений (MSRP); MRFP взаимодействует с AS/MRFC посредством протокола H.248; и AS/MRFC взаимодействует с устройством начисления оплаты в домене выставления счетов посредством протокола Diameter. MRFC эквивалентен MC; и MRFP эквивалентен MP.
Фиг.4 представляет собой схему передачи сигналов онлайн процесса начисления оплаты службы конференц-связи сообщений. Процесс включает следующие этапы:
Этап 1: UE отправляет к AS/MRFC сообщение запроса создания сеанса, запрашивая создать сеанс. Конкретно, для создания сеанса UE может отправить сообщение INVITE по протоколу SIP. Соответствующий медиауровень не является звуковым или видео, а уровнем сообщений.
Этап 2: Запрашивая соответствующую квоту, AS/MRFC отправляет OCS сообщение с запросом установления кредитного управления в домене выставления счетов. OCS возвращает разрешенную квоту.
Этап 3: MRFC отправляет в MRFP сообщение запроса предоставления ресурса (ADD), инструктируя MRFP выделить ресурсы, такие как прерывание, и установить квоту, разрешенную для прерывания.
Предполагается, что начисление оплаты в направлении приема является основанным на трафике, и в направлении отправления начисления оплаты является основанным на качестве. На этом этапе предполагается, что квота в направлении отправления составляет 10 сообщений, квота в направлении приема составляет 2048 байт, и период достоверности составляет 5 минут. Сигнальной информацией может являться
"addReq{$,Events={qsr/sq(qu=number,qq=10),qsr/rq(qu=volume,qc=all,qq=2048),qsr/vt(t1=300)}}".
Этап 4: MRFP возвращает в MRFC ответ, чтобы подтвердить прием сообщения запроса предоставления ресурса. Сигнальной информацией ответа может являться "addReply{T1}".
Этап 5: AS/MRFC указывает, что UE успешно присоединился к конференции передачи сообщений. Сигнальной информацией может являться "OK".
Этап 6: Через основную сеть передаются медиапотоки конференции передачи сообщений.
Этап 7: Квота величиной в 10 сообщений закончилась.
Этап 8: MRFP предоставляет отчет о событии исчерпания квоты, который содержит такие параметры как израсходованная часть квоты, например, отправлено 10 сообщений, и принято 512 байт. Сигнальной информацией может являться "notifyReq{T1,ObservedEven ts={qsr/sq(sqq=10,rqq=512)}}".
Этап 9: MRFC возвращает в MRFP ответ, чтобы подтвердить прием события исчерпания квоты. Сигнальной информацией может являться "notifyReply{T1}".
Этап 10: MRFC предоставляет отчет в OCS о событии исчерпания квоты, и OCS осуществляет начисление оплаты прерывания соответствующего пользователя в MRFP в соответствии с величиной квоты, содержащейся в событии исчерпания квоты.
Этап 11: Запрашивая изменить квоту, AS/MRFC отправляет в OCS сообщение с запросом изменения кредитного управления. OCS возвращает новую разрешенную квоту.
Этап 12: MRFC инструктирует MRFP изменить квоту соответствующего прерывания. Предполагается, что измененная квота составляет: Квота в направлении приема составляет 20 сообщений, и квота в направлении приема составляет 2048 байт, и период достоверности составляет 5 минут. Сигнальной информацией может являться
"modReq{T1,Events={qsr/sq(qu=number,qq=20),qsr/rq(qu=volume,qc=all,qq=2048),qsr/vt(t1=300)}}".
Этап 13: MRFP возвращает в MRFC ответ, чтобы подтвердить прием измененной квоты. Сигнальной информацией может являться "modReply{T1}".
Этап 14: Через основную сеть передаются медиапотоки конференции передачи сообщений.
Этап 15: UE отправляет в AS/MRFC сообщение запроса завершения сеанса, запрашивая завершить сеанс. Сигнальной информацией может являться "BYE".
Этап 16: MRFC отправляет в MRFP сообщение с запросом высвобождения ресурса (SUBTRACT), отдавая указание MRFP высвободить ресурсы, такие как прерывание, и проверить значения статистических данных. Сигнальной информацией может являться "subReq{T1,audit{Statistics}}".
Этап 17: MRFP возвращает в AS/MRFC ответ. Ответ указывает, что накопленное количество отправленных сообщений составляет 15 и накопленный принятый трафик составляет 1024 байт. В соответствии с этими двумя значениями, AS/MRFC вычисляет последний объем использования. А именно с момента последнего отчета (Уведомления) до настоящего времени отправлено 5 сообщений и принято 512 байт, так как в предыдущем отчете количество отправленных сообщений составляет 10 и ранее принятый трафик составляет 512 байт. Сигнальной информацией может являться "subReply{T1,Statistics{qs r/sqaq=15,qsr/rqaq=1024}}".
Этап 18: AS/MRFC предоставляет отчет в OCS о последнем объеме использования, и OCS производит начисления оплаты в соответствии с последним объемом использования.
Этап 19: Запрашивая завершить кредит, AS/MRFC отправляет в OCS сообщение с запросом завершения кредитного управления. OCS возвращает ответ.
Этап 20: AS/MRFC указывает, что UE успешно покинуло конференцию передачи сообщений.
Заметим, что в службе (услуге) мультимедийных конференций одно прерывание может одновременно иметь множество медиапотоков, таких как аудиопотоки, видеопотоки и потоки сообщений. В том случае, если требуется собрать информацию об объеме использования однотипных медиапотоков, для квоты, которая должна быть доставлена, MC может установить идентификатор потока для каждого потока прерывания, и квота является специфической для медиапотока, соответствующего идентификатору потока. В том случае, когда MP устанавливает квоту, MP может установить соответствующую квоту для прерывания согласно идентификатору потока, соответствующего конкретному типу медиапотока прерывания.
Первый вариант осуществления системы
Данный вариант осуществления предоставляет систему предоставления отчета об объеме использования службы данных проактивно в реальном масштабе времени в распределенной архитектуре. Как представлено на Фиг.5, система включает в себя MC 10 и MP 20, которые связаны телекоммуникационно. Если требуется, чтобы система имела возможность производить начисление оплаты, система также включает в себя OCS 30, которая связана с MC 10 телекоммуникационно. Принципы работы системы следующие.
Первый модуль 31 начисления оплаты из OCS 30 передает в MC 10 индикацию квоты. Индикация квоты содержит заданную квоту. Заметим, что также в этом варианте осуществления индикация квоты доставляется посредством OCS 30, индикация квоты может доставляться к MC 10 в других режимах. Впоследствии, принимая квоту, доставленную посредством OCS 30, первый модуль управления MC 10 инструктирует MP 20 установить квоту для прерывания.
После того, как первый модуль обработки 21 из MP 20 принимает квоту от MC 10, второй модуль обработки 22 устанавливает квоту для прерывания и собирает данные об объеме использования службы данных прерывания; и третий модуль обработки 23 предоставляет отчет в MC о событии исчерпания квоты в том случае, когда объем использования службы данных, потребляемый прерыванием, достигает квоты. Событие исчерпания квоты переносит величину квоты. Таким образом, MP 20 проактивно предоставляет отчет о квоте.
Чтобы иметь возможность производить начисление оплаты, MC 10 может включать в себя третий модуль управления 13. В том случае, когда второй модуль управления 12 принимает событие исчерпания квоты, предоставленное в отчете от MP 20, третий модуль управления 13 предоставляет отчет в OCS 30 о событии исчерпания квоты, принятом вторым модулем управления 12. Второй модуль 32 начисления оплаты из OCS 30 осуществляет начисление оплаты для прерывания в соответствии с величиной квоты, содержащейся в событии исчерпания квоты.
В том случае, когда UE отправляет запрос завершения сеанса в MC 10, чтобы запросить завершение текущего сеанса, MC 10 может использовать четвертый модуль управления 14, с целью отдать указание MP 20 завершить прерывание, относящееся к сеансу, и предоставить отчет о последнем объеме использования службы данных, потребляемом прерыванием перед завершением сеанса. Четвертый модуль обработки 24 из MP 20 завершает (освобождает) прерывание, относящееся к сеансу, и после завершения прерывания пятый модуль обработки 25 предоставляет отчет в MC 10 о последнем объеме использования прерывания. Пятый модуль управления 15 из MC 10 предоставляет отчет в OCS 30 о последнем объеме использования, и второй модуль 32 начисления оплаты из OCS 30 осуществляет начисление оплаты для прерывания в соответствии с последним объемом использования.
В системе согласно описанному выше варианту осуществления MC 10 взаимодействует с MP 20 в реальном масштабе времени, и MP может контролировать объем использования службы данных, потребляемый пользователем, в реальном масштабе времени, и предоставлять отчет о статистической информации в том случае, когда выполнены условия. Таким образом, существует возможность осуществления начисления оплаты в режиме онлайн за службу данных.
Второй вариант осуществления системы
На основании первого варианта осуществления системы этот вариант осуществления предоставляет другую OCS для службы данных. Как представлено на Фиг.6, MC 10, кроме того, включает в себя: шестой модуль управления 16, седьмой модуль управления 17, и восьмой модуль управления 18; и MP 20, кроме того, включает в себя: шестой модуль обработки 16, и седьмой модуль обработки 17. Принципы работы системы следующие.
После того, как первый модуль управления 11 из MC 10 доставляет квоту в MP 20, шестой модуль управления 16 инструктирует MP 20 установить период достоверности для прерывания. Шестой модуль обработки 26 из MP 20 устанавливает период достоверности для прерывания. Более конкретно, перед тем, как второй модуль обработки 22 создаст статистические данные об объеме использования службы данных прерывания, запускается таймер в соответствии с периодом достоверности, и в том случае, когда квота не достигнута, но период достоверности истекает, седьмой модуль обработки 27 предоставляет отчет в MC 10 о событии истечения периода достоверности. После того, как седьмой модуль управления 17 из MC 10 принимает событие истечения периода достоверности, восьмой модуль управления 18 предоставляет отчет в OCS 30 о событии истечения периода достоверности. Второй модуль 32 начисления оплаты из OCS 30 осуществляет начисление оплаты для прерывания в соответствии с объемом использования службы данных, потребляемым в периоде достоверности, где объем использования содержится в событии истечения периода достоверности.
В системе согласно описанному выше варианту осуществления MC 10 периодически принимает информацию об объеме использования службы данных, потребляемом посредством UE, избегая сбоя предоставления отчета о статистической информации в случае, когда объем использования службы данных не достигает заранее заданной квоты из-за сбоев оборудования, и усовершенствован процесс начисления оплаты в режиме онлайн.
Специалистам в данной области следует понимать, что все или часть этапов способа в соответствии с вариантами осуществления настоящего изобретения могут быть реализованы программой, инструктирующей подходящее аппаратное обеспечение. Программа может храниться на считываемом компьютером носителе информации. В том случае, когда программа запущена, этапы способа выполняются в соответствии с вариантами осуществления настоящего изобретения. Носителем информации может являться магнитный диск, компакт диск (CD), постоянное запоминающее устройство (ROM), или оперативное запоминающее устройство (RAM).
В заключение следует отметить, что вышеприведенные варианты осуществления предоставлены только для пояснения технического решения по настоящему изобретению, но не предполагают ограничить настоящее изобретение. Очевидно, что специалисты в данной области могут реализовать различные модификации и изменения изобретения вне зависимости от объема изобретения. Настоящее изобретение предполагает распространение на предоставленные модификации и изменения, так как они попадают под объем правовой защиты, определяемой следующей формулой изобретения и ее эквивалентами.