Wap-шлюз и способ осуществления управления биллингом для абонентов тарифа с предоплатой
Изобретение относится к системам связи. WAP-шлюз и способ осуществления управления биллингом для абонентов тарифа с предоплатой включают в себя следующие этапы: WAP-шлюз протокола беспроводных приложений обменивается соответствующей информацией с системой биллинга согласно различным запросам на обслуживание абонента тарифа с предоплатой, а также собирает и контролирует соответствующие платежи согласно информации, полученной в результате обмена. Способ позволяет эффективно реализовать биллинг в реальном времени и четко конфигурировать стратегию биллинга, чтобы реализовать гибкий биллинг на основе различных тарифов платежей и удовлетворить необходимые условия гибкого биллинга компаний-поставщиков коммуникационных услуг. Способ также гарантирует высокую эффективность и надежность биллинга путем сохранения сеансов биллинга в шлюзе в течение определенного периода времени. В случае загрузки большого файла при предварительном списании трафика и недовольстве абонента содержательной услугой вследствие различных отклонений от нормы способ позволяет отменить списание трафика. 3 н. и 16 з.п. ф-лы, 4 ил.
По настоящей заявке испрашивается приоритет по заявке на патент Китая № 200510132469.1, поданной 20 декабря 2005, под названием "WAP-шлюз и способ осуществления управления биллингом для абонентов тарифа с предоплатой", переданной в общее пользование и включенной в данное описание в качестве ссылки.
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение касается связи, в частности WAP-шлюза и способа осуществления управления биллингом для абонентов тарифа с предоплатой.
УРОВЕНЬ ТЕХНИКИ
С развитием услуг передачи данных с использованием мобильной связи типа услуги обмена мультимедийными сообщениями (ММS), услуги определения местоположения (LCS), услуги по совершению платежей и просмотра сети и ресурсов с использованием протокола беспроводных приложений (WAP) возникла необходимость в разрешении проблем биллинга, связанных с платежами за связь и платежами за контент.
Платежи за связь - это платежи, которые компания-поставщик коммуникационных услуг начисляет абоненту за использование сети в случае, когда абоненты используют сеть, созданную этой компанией-поставщиком коммуникационных услуг. Платежи за связь обычно начисляются на основе трафика или длительности или начисляются помесячно.
Платежи за контент - это то, что поставщик контента начисляет абонентам за контент, использованный пользователями. Компания-поставщик коммуникационных услуг собирает платежи за контент для поставщиков контента. Обычно платежи за контент начисляются на основе порций, трафика или длительности контента или начисляются помесячно. Режим биллинга и расценки за контент определяются договором между компанией-поставщиком коммуникационных услуг и поставщиками контента.
Для существующих сетей 2G/2.5G/3G платежи за связь собираются на SGSN/GGSN/PDSN/NAS, которые в дальнейшем определены как система удаленного доступа (RAS), и равномерно перечисляются через систему поддержки эксплуатации сетей связи (OSS).
Техническая схема прототипа настоящего изобретения будет рассмотрена со ссылками на фиг. 1, на которой представлен схематичный структурный вид обычной сети для биллинга. Как показано на фиг. 1, сеть включает в себя базовую приемопередающую станцию (BTS), контроллер базовых станций (BSC), центр коммутации мобильной связи (MSC), сервер аутентификации, авторизации и аудита (AAA), RAS, WAP-шлюз (WAP GW), систему биллинга (billing SYS) и SP/CP.
WAP GW выполняет преобразование протоколов и прокси-функции для WAP-услуг. Не-WAP-услуги не обрабатываются WAP GW и непосредственно подключаются к SP/CP через RAS. Billing SYS, которая может быть реализована с помощью многочисленных устройств типа SCP/DSMP/OSS, выполняет функции биллинга для платежей за связь и платежей за контент для абонентов тарифа с предоплатой, обеспечивает аутентификацию SP/CP и абонентов и реализует биллинг и тарификацию контента.
Для реализации биллинга платежей за связь информация о платежах абонента за связь собирается в RAS. Эта информация включает в себя трафик, длительность, роуминг и сетевую информацию о сетевом доступе абонента типа адреса RAS и кодов доступа. Затем согласно собранной информации выполняется биллинг платежей абонента за связь.
Для реализации биллинга платежей за контент WAP GW или SP/CP получает IP-адрес абонента из пакетов данных, запрашивает и получает международный номер мобильной станции цифровой сети комплексного обслуживания (MSISDN) вызывающего абонента, соответствующей IP-адресу абонента, из пакета биллинга, направляемого сервером AAA на основе протокола удаленной аутентификациии пользователей, устанавливающих соединение по телефонным линиям (RADIUS), и затем пересылает MSISDN к SP/CP. SP/CP затем выполняет биллинг платежей за контент согласно записям о посещениях абонента, соответствующего MSISDN.
Кроме того, биллинг платежей за контент может быть выполнен согласно унифицированному указателю ресурсов (URL) или характеристическим величинам типа идентификатора услуги (SERVERID) и идентификатора SP (SPID), передаваемых с использованием URL на основе записей о посещениях абонента.
SERVERID может быть добавлен к URL через SP/CP или может быть добавлен через PORTAL. В случае, когда SERVERID добавляется через PORTAL, сначала необходимо получить доступ к PORTAL, а характеристические величины переносятся в URL в ссылке, возвращенной PORTAL.
Техническая схема прототипа показывает, что RAS прототипа собирает трафик сетевого уровня, а не трафик прикладного уровня. Поэтому в прототипе невозможно начисление трафиков различных приложений при различных тарифах и невозможно осуществление биллинга в реальном времени. Кроме того, точки сбора для различных режимов биллинга являются различными. Например, в случае принятия биллинга на основе трафика трафик собирается в RAS, но обычно в случае принятия биллинга на основе контента и генерации трафика GPRS для пересылки ММS сбор осуществляется в шлюзе CP. В настоящее время выполнение биллинга на основе трафика согласно различным услугам является затруднительным, и перекрестный биллинг может осуществляться в случае, если один режим биллинга принят для одной части услуг, а другие режимы биллинга приняты для других услуг.
При одновременном принятии биллинга на основе трафика и биллинга на основе контента прототип не может реализовать биллинг для различных ситуаций, а может только поддерживать некоторые простые режимы биллинга типа помесячных платежей на основе контента и помесячных платежей на основе трафика. Поэтому прототип характеризуется недостаточной гибкостью и не может гарантировать эффективный и достоверный биллинг.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Согласно настоящему изобретению предложен WAP-шлюз и способ осуществления управления биллингом для абонентов тарифа с предоплатой, который реализуют биллинг в реальном времени и перекрестный биллинг на основе трафика и контента для абонентов тарифа с предоплатой.
Настоящее изобретение осуществляется посредством описываемой ниже технической схемы.
Предложен способ осуществления управления биллингом для абонентов тарифа с предоплатой. Способ включает в себя следующие этапы.
WAP-шлюз обменивается соответствующей информацией с системой биллинга согласно различным запросам на обслуживание абонента тарифа с предоплатой, а также собирает и контролирует соответствующие платежи согласно информации, полученной в результате обмена.
Система биллинга осуществляет предварительное списание соответствующих платежей за приложения со счета абонента согласно запросу на тарификацию и аутентификацию.
Предложен способ осуществления управления биллингом для абонентов тарифа с предоплатой с использованием WAP-шлюза. Способ включает в себя следующие этапы.
WAP-шлюз собирает и контролирует информацию о платежах для биллинга на основе, по меньшей мере, одного из: трафика и контента для абонента тарифа с предоплатой согласно конфигурированной стратегии биллинга и различным запросам на обслуживание абонента тарифа с предоплатой.
Предложен WAP-шлюз. WAP-шлюз включает в себя первый блок для конфигурирования стратегии биллинга и второй блок для сбора и контроля информации о платежах для биллинга на основе, по меньшей мере, одного из: трафика и контента согласно конфигурированной стратегии биллинга.
Предложена система для осуществления управление биллингом на абонентах тарифа с предоплатой. Система включает в себя WAP-шлюз для приема запроса на обслуживание от абонента и установление соединения между поставщиком услуг (SP), системой биллинга и абонентом, а также систему биллинга для взаимодействия с WAP-шлюзом и возврата ответного сообщения о предварительном списании и резервировании.
Техническая схема настоящего изобретения показывает, что WAP-шлюз используется для сбора и контроля информации о режиме биллинга по трафику и режиме биллинга по контенту, позволяющей реализовать многочисленные режимы биллинга и реализовать перекрестный биллинг на основе трафика и контента. Кроме того, WAP-шлюз сохраняет сеанс биллинга в течение определенного периода времени, что гарантирует эффективность и надежность биллинга и позволяет реализовать биллинг абонента тарифа с предоплатой в реальном времени. Более того, в случае загрузки большого файла при предварительном списании трафика и недовольстве абонента содержательными услугами настоящее изобретение позволяет отменить списание трафика.
Кроме того, настоящее изобретение позволяет конфигурировать различные тарифы биллинга на шлюзе, чтобы реализовать гибкий биллинг при различных тарифах биллинга и удовлетворить требованиям по гибкому биллингу со стороны компании-поставщика коммуникационных услуг.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг. 1 - схематичный вид структуры сети с биллингом согласно прототипу;
Фиг. 2 - схематичный вид организации сети согласно примеру осуществления настоящего изобретения;
Фиг. 3 - временная диаграмма биллинга исключительно на основе трафика, реализованная на основе WAP-шлюза, согласно примеру осуществления настоящего изобретения; и
Фиг. 4 - временная диаграмма перекрестного биллинга на основе трафика и контента, реализованная на основе WAP-шлюза, согласно примеру осуществления настоящего изобретения.
ПОДРОБНОЕ ОПИСАНИЕ
Согласно рассматриваемому в примерах осуществления настоящего изобретения способу осуществления управления биллингом для абонентов тарифа с предоплатой шлюз протокола беспроводных приложений (WAP) обменивается соответствующей информацией с системой биллинга согласно различным запросам на обслуживание абонента тарифа с предоплатой, а также собирает и контролирует соответствующие платежи согласно информации, полученной в результате обмена.
На фиг. 2 представлена структура организации сети согласно настоящему изобретению, включающая в себя систему RAS, WAP-шлюз (WAP GW), систему биллинга (Billing SYS), сервер AAA и беспроводную сеть. WAP GW соединен с системой RAS, взаимодействует с SP через беспроводную сеть и обменивается информацией с системой биллинга посредством IP-протокола.
Система RAS соединяет устройства беспроводного доступа и беспроводную сеть с компьютерной сетью.
Система Billing SYS выполняет биллинг платежей за связь и платежей за контент абонента тарифа с предоплатой, а также осуществляет аутентификацию SP/CP и абонента и выполняет биллинг и тарификацию контента.
WAP GW преобразует протоколы, собирает платежи за связь или платежи за контент, генерирует счет и представляет отчет абоненту тарифа с предоплатой в реальном времени.
Сервер AAA осуществляет аутентификацию абонента и направляет на него пакеты биллинга.
На основе описанной выше организации сети в первом примере осуществления настоящего изобретения на базисе WAP-шлюза реализуется биллинг исключительно на основе трафика. Временная диаграмма согласно этому примеру осуществления представлена на фиг. 3.
Перед выполнением биллинга на основе трафика в шлюзе осуществляется конфигурирование различных стратегий биллинга, например способ выполнения биллинга на основе трафика в случае неуспешной попытки получения доступа со стороны абонента. После этого абонент устанавливает соединение с WAP-шлюзом, а затем - с SP. После установления соединения абонент выполняет аутентификацию и начинает представлять отчеты о биллинге через MS. Ниже приводится подробное описание этого процесса.
На этапе 1 MS запрашивает RAS об активации соединения.
На этапе 2 RAS пересылает запрос на основе протокола RADIUS на сервер AAA, а сервер AAA после успешной аутентификации запроса пересылает ответное сообщение об аутентификации в RAS.
На этапе 3 RAS пересылает запрос на начало биллинга на основе протокола RADIUS в WAP GW через сервер AAA. Сервер AAA направляет соответствующий запрос в WAP GW. В случае успешной аутентификации WAP GW пересылает ответное сообщение о начале биллинга в RAS через сервер AAA. После приема ответного сообщения о начале биллинга RAS пересылают ответ об установлении соединения на MS.
После проведения указанных выше этапов абонент соединяется с WAP GW. Затем WAP GW представляет отчет о биллинге на основе трафика согласно запросу абонента, и подробное описание этого процесса приводится ниже.
На этапе 4 абонент пересылает первый HTTP-запрос в WAP GW через MS.
На этапе 5 WAP-шлюз направляет HTTP-запрос абонента к SP.
На этапе 6 SP возвращает соответствующее ответное сообщение в WAP-шлюз согласно принятому HTTP-запросу.
На этапе 7 при приеме ответного сообщения от SP WAP-шлюз обрабатывает ответное сообщение и получает суммарный трафик, генерированный по запросу абонента.
В случае, когда абонент инициирует запрос на обслуживание с небольшим объемом данных, шлюз получает полный ответный контент от SP и затем доставляет ответный контент. Прежде всего, шлюз регистрирует ответный контент и получает суммарный трафик, генерированный по запросу абонента, согласно информации о контенте в ответном сообщении.
В случае, когда абонент инициирует услугу с большим объемом данных, ограниченным пространством системы, шлюз вместо получения полного ответного контент от SP и последующей доставки контента осуществляет доставку данных на терминал одновременно с получением данных. Ниже приводится описание способа обработки, выполняемой шлюзом для разрешения указанной выше проблемы.
После получения ответного сообщения от SP WAP-шлюз определяет, возможно ли отделение длины ответного контента от заголовка ответного сообщения.
В случае, когда определяется, что длина ответного контента может быть отделена от заголовка ответного сообщения, суммарный трафик, генерированный по запросу абонента, рассчитывается согласно длине ответного контента.
В случае, когда определяется, что длина ответного контента (например, кода чанка) не может быть отделена от заголовка ответного сообщения, шлюз отделяет метку конца ответного сообщения и рассчитывает длину ответного контента согласно метке конца. Затем согласно длине ответного контента осуществляется расчет суммарного трафика, генерированного по запросу абонента.
Небольшой объем данных и большой объем данных могут быть предварительно определены согласно действующим условиям работы сети. Например, услуга с определенным диапазоном трафика определяется как услуга с небольшим объемом данных, а услуга с трафиком, превышающим этот диапазон, определяется как услуга с большим объемом данных.
После осуществления нижеследующих этапов шлюз получает суммарный трафик, генерированный по запросу абонента, согласно ответному сообщению, возвращенному от SP. Далее шлюз управляет биллингом по трафику для абонента тарифа с предоплатой согласно суммарному трафику. Подробная реализация этого процесса включает в себя следующие две ситуации.
Первая ситуация состоит в том, что шлюз обнаруживает отсутствие резервирования размера трафика для абонента, что включает в себя следующие этапы.
На этапе 8 шлюз обращается к системе биллинга с просьбой об организации сеанса биллинга по трафику посредством сообщения с запросом на биллинг по трафику и запрашивает систему биллинга о резервировании трафика.
На этапе 9 система биллинга возвращает информацию о размере резервированного трафика согласно сообщению о биллинге по трафику, отчет о котором представляется шлюзом в реальном времени.
На этапе 10 после приема сообщения, возвращенного из системы биллинга, шлюз записывает информацию о резервировании, доставляет контент, запрошенный абонентом, этому абоненту и накапливает трафик.
Вторая ситуация состоит в том, что шлюз обнаруживает резервирование размера трафика для абонента, что обычно применяется в случае второго HTTP-запроса, пересылаемого абонентом в шлюз, и включает в себя следующие этапы.
На этапе 8' шлюз определяет, является ли резервированный доступный трафик меньше, чем суммарный трафик, генерированный по запросу абонента. В случае положительного решения выполняется этап 9'; в противном случае выполняется этап 11'.
На этапе 9' отчет о накопленном суммарном трафике представляется в систему биллинга в реальном времени посредством сообщения о биллинге по трафику, и шлюз обращается с повторной просьбой о резервировании трафика к системе биллинга, и затем выполняется этап 10'.
На этапе 10' система биллинга возвращает информацию о размере резервированного трафика согласно сообщению о биллинге по трафику, отчет о котором представляется шлюзом в реальном времени.
На этапе 11' после приема сообщения, возвращенного из системы биллинга, шлюз записывает информацию о резервировании, доставляет ответный контент, запрошенный абонентом, этому абоненту и накапливает трафик.
В описанных выше двух ситуациях шлюз может расширить информацию о биллинге по трафику и осуществить активное обращение к системе биллинга с просьбой о резервировании заданного размера трафика. Этот процесс применяется в случае, когда трафик, генерированный по запросу абонента, является очень большим. Посредством резервированного трафика абонент может резервировать достаточный трафик для этого запроса в одном сеансе взаимодействия.
Подробное описание операции, выполняемой на этапе 8, при обращении WAP-шлюза с просьбой об организации сеанса биллинга по трафику приводится ниже.
1. В случае, когда частота переключения тарифов платежей для запросов на обслуживание, инициируемых абонентом, превышает заданный порог, для каждого из запросов на обслуживание с различными тарифами платежей шлюз организует сеанс биллинга по тарифу с системой биллинга и сохраняет сеанс биллинга в течение определенного периода времени. Если обнаруживается, что ни один из сеансов биллинга не генерирует трафик в течение определенного периода времени, то сеанс биллинга завершается.
Абонент может получать доступ к интересующему контенту в ходе просмотра сети и ресурсов и может переходить между различными SP в любое время, поэтому частота переключения тарифов платежей обычно бывает высокой. Шлюз организует сеанс биллинга для каждого тарифа платежей и сохраняет сеанс биллинга в течение определенного периода времени. Если сеанс биллинга не генерирует никакого трафика в течение определенного периода времени, то сеанс биллинга завершается и, таким образом, ненужная трата денег предотвращается. Поэтому, даже в случае высокой частоты переключения тарифов платежей при доступе абонента к контенту, шлюзу не требуется организовывать новые сеансы биллинга с системой биллинга, что, таким образом, обеспечивает повышение скорости ответа.
2. В случае, когда абонент инициирует запрос на обслуживание с большим объемом данных, шлюз организует сеанс биллинга по выделенному трафику с системой биллинга посредством сообщения о биллинге по трафику согласно запросу на обслуживание с большим объемом данных, инициированному абонентом.
3. В случае, когда многочисленные запросы на обслуживание, инициированные абонентом, имеют один и тот же тариф платежей, шлюз организует сеанс биллинга по трафику согласно многочисленным запросам на обслуживание с одним и тем же тарифом платежей абонента.
Описанная выше ситуация основана на параллельных запросах. В это время терминал может устанавливать многочисленные соединения со шлюзом в одно и то же время, и шлюз обрабатывает соединения одновременно. Если эти многочисленные соединения получают доступ к страницам с одним и тем же тарифом платежей, то шлюзу не требуется организовывать сеанс биллинга для каждого соединения, а можно использовать один и тот же сеанс биллинга. Однако проблема, обусловленная параллельной обработкой, заключается в невозможности отмены списания объявленного трафика, что, таким образом, приводит к необходимости достижения баланса между точностью и эффективностью биллинга. Поэтому шлюзу требуется иметь специальный вид обработки для услуг с большим трафиком, чтобы контролировать ошибки биллинга по трафику в пределах определенного диапазона.
После выполнения указанных выше этапов WAP-шлюз может осуществлять управление биллингом для абонента тарифа с предоплатой в реальном времени. В случае, когда MS запрашивает деактивацию, согласно настоящему изобретению выполняется процесс представления отчета об окончании биллинга, и ниже приводится подробное описание этого процесса.
На этапе 11 MS запрашивает деактивацию.
На этапе 12 RAS пересылает запрос на окончание биллинга в WAP GW через сервер AAA.
На этапе 13 WAP GW собирает информацию о чистом трафике. Если это информация об абоненте тарифа с предоплатой, то WAP GW представляет отчет о собранной информации о трафике в систему биллинга.
На этапе 14 система биллинга возвращает ответное сообщение согласно представленной информации.
На этапе 15 шлюз обрабатывает принятое ответное сообщение и генерирует счет биллинга по трафику.
На этапе 16 шлюз деактивирует MS и процесс заканчивается.
На основе организации сети, представленной на фиг. 2, в другом примере осуществления настоящего изобретения на основе WAP-шлюза реализуется биллинг исключительно на основе контента. Перед биллингом в шлюзе выполняется конфигурирование различных стратегий биллинга. Затем абонент устанавливает соединение с SP, т.е. абонент выполняет идентификацию и начинает представлять отчеты о биллинге через MS. Этот процесс аналогичен описанному в первом примере осуществления, и его подробное описание повторно не приводится.
После установления соединения абонента с SP выполняется описываемый ниже процесс осуществления биллинга на основе контента на базисе WAP-шлюза.
На этапе 101 абонент инициирует запрос на обслуживание.
На этапе 102 шлюз анализирует этот запрос. В случае, когда определяется, что услуга, запрошенная абонентом, является контент-услугой, шлюз инициирует запрос на тарификацию и аутентификацию к системе биллинга.
На этапе 103 система биллинга осуществляет предварительное списание соответствующих платежей за приложение со счета абонента согласно запросу на тарификацию и аутентификацию.
В случае успешного предварительного списания система биллинга пересылает ответное сообщение с указанием на успешное предварительное списание назад в шлюз, и выполняется этап 104.
В случае неуспешной попытки предварительного списания система биллинга пересылает ответное сообщение с указанием на неуспешную попытку предварительного списания назад в шлюз, и согласно этому сообщению шлюз запрещает абоненту получать доступ к услуге.
На этапе 104 после приема ответного сообщения с указанием на успешное предварительное списание шлюз доставляет контент, запрошенный абонентом, этому абоненту. После выполнения указанных выше этапов WAP-шлюз может осуществлять управление биллингом для абонента тарифа с предоплатой в реальном времени. В случае, когда MS запрашивает деактивацию, согласно настоящему изобретению выполняется процесс представления отчета об окончании биллинга. Этот процесс аналогичен описанному в первом примере осуществления, и его подробное описание повторно не приводится.
На основе организации сети, представленной на фиг. 2, в другом примере осуществления настоящего изобретения на основе WAP-шлюза реализуется биллинг на основе трафика и контента. Перед биллингом в шлюзе выполняется конфигурирование различных стратегий биллинга. Затем абонент устанавливает соединение с SP, т.е. абонент выполняет идентификацию и начинает представлять отчеты о биллинге через MS. Этот процесс аналогичен описанному в первом примере осуществления, и его подробное описание повторно не приводится.
После установления соединения абонента с SP выполняется описываемый ниже процесс осуществления биллинга на основе контента на базисе WAP-шлюза.
На этапе 201 абонент инициирует запрос на обслуживание.
На этапе 202 шлюз анализирует этот запрос. В случае, когда определяется, что услуга, запрошенная абонентом, является контент-услугой, шлюз инициирует запрос на тарификацию и аутентификацию к системе биллинга.
На этапе 203 система биллинга осуществляет предварительное списание соответствующих платежей за приложение со счета абонента согласно запросу на тарификацию и аутентификацию. В случае успешного предварительного списания система биллинга пересылает ответное сообщение с указанием на успешное предварительное списание назад в шлюз, и выполняется этап 204. В случае неуспешной попытки предварительного списания система биллинга пересылает ответное сообщение с указанием на неуспешную попытку предварительного списания назад в шлюз, и после приема сообщения с указанием на неуспешную попытку списания шлюз запрещает абоненту получать доступ к услуге.
На этапе 204 после приема ответного сообщения с указанием на успешное предварительное списание, посланного назад системой биллинга, шлюз направляет HHTP-запрос на обслуживание абонента к SP.
На этапе 205 SP возвращает соответствующее ответное сообщение в WAP-шлюз согласно принятому HTTP-запросу.
На этапе 206 после приема ответного сообщения от SP WAP-шлюз обрабатывает ответное сообщение и получает информацию о суммарном трафике, генерированном по запросу абонента.
На этапе 207 шлюз управляет биллингом на основе трафика и биллингом на основе контента для абонента тарифа с предоплатой. Подробная реализация этого процесса включает в себя следующие две ситуации.
Первая ситуация состоит в том, что шлюз обнаруживает отсутствие резервирования размера трафика для абонента, что включает в себя следующие этапы.
На этапе I WAP-шлюз обращается к системе биллинга с просьбой об организации сеанса биллинга посредством сообщения с запросом на биллинг по трафику и запрашивает систему биллинга о резервировании трафика.
На этапе II система биллинга резервирует трафик согласно сообщению с запросом на биллинг по трафику. В случае успешного резервирования трафика информация о размере резервированного трафика возвращается, и выполняется этап III; в противном случае в шлюз пересылается ответное сообщение с указанием на неуспешную попытку резервирования, и выполняется этап IV.
На этапе III шлюз доставляет информацию о контенте, к которому абонент может получить доступ, и информацию о суммарном трафике абоненту согласно информации, возвращенной из системы биллинга. В случае успешной доставки шлюз пересылает сообщение с подтверждением биллинга по контенту (в состоянии успешной доставки) в систему биллинга и накапливает трафик. В случае неуспешной попытки доставки шлюз пересылает сообщение с подтверждением биллинга по контенту (в состоянии неуспешной попытки доставки) в систему биллинга, отменяет списание трафика, накопленного в запросе, и запрещает абоненту получать доступ к услуге.
На этапе IV шлюз запрашивает систему биллинга об отмене списания в биллинге по трафику посредством сообщения с подтверждением биллинга по трафику и запрещает абоненту получать доступ к услуге.
Вторая ситуация состоит в том, что шлюз обнаруживает резервирование размера трафика для абонента, что включает в себя следующие этапы.
На этапе I шлюз определяет, является ли резервированный доступный трафик меньше, чем суммарный трафик, генерированный по запросу абонента. В случае положительного решения выполняется этап II; в противном случае выполняется этап IV.
На этапе III отчет о генерированном суммарном трафике представляется в систему биллинга в реальном времени посредством сообщения о биллинге по трафику, и шлюз обращается с повторной просьбой о резервировании трафика к системе биллинга, и затем выполняется этап III.
На этапе III система биллинга резервирует трафик согласно сообщению с запросом на биллинг по трафику. В случае успешного резервирования информация о размере резервированного трафика возвращается, и выполняется этап IV; в противном случае в шлюз пересылается ответное сообщение с указанием на неуспешную попытку резервирования, и выполняется этап V.
На этапе IV шлюз доставляет ответный контент, запрошенный абонентом, этому абоненту. В случае успешной доставки шлюз пересылает сообщение с подтверждением биллинга по контенту (в состоянии успешной доставки) в систему биллинга и накапливает трафик. В случае неуспешной попытки доставки шлюз пересылает сообщение с подтверждением биллинга по контенту (в состоянии неуспешной попытки доставки) в систему биллинга, отменяет списание трафика, накопленного в запросе, и запрещает абоненту получать доступ к услуге.
На этапе V шлюз запрашивает систему биллинга об отмене списания в биллинге по трафику посредством сообщения с подтверждением биллинга по трафику и запрещает абоненту получать доступ к услуге.
После выполнения описанных выше этапов WAP-шлюз может осуществлять управление биллингом для абонента тарифа с предоплатой в реальном времени. В случае, когда MS запрашивает деактивацию, согласно настоящему изобретению выполняется процесс представления отчета об окончании биллинга. Этот процесс аналогичен описанному в первом примере осуществления, и его подробное описание повторно не приводится.
В итоге в настоящем изобретении WAP-шлюз используется для сбора и контроля платежей в биллинге на основе трафика и биллинге на основе, который реализует многочисленные режимы биллинга и реализует перекрестный биллинг на основе трафика и контента. Кроме того, WAP-шлюз сохраняет сеанс биллинга в течение определенного периода времени, что позволяет повысить эффективность и надежность биллинга и реализовать биллинг в реальном времени абонента тарифа с предоплатой. Более того, в случае загрузки большого файла при предварительном списании трафика и недовольстве абонента содержательными услугами настоящее изобретение позволяет отменить списание трафика. Кроме того, настоящее изобретение позволяет конфигурировать различные тарифы биллинга в шлюзе, чтобы реализовать гибкий биллинг при различных тарифах биллинга и удовлетворить требованиям по гибкому биллингу со стороны компании-поставщика коммуникационных услуг.
Выше настоящее изобретение описано на предпочтительных примерах осуществления, однако оно не ограничивается этими примерами. Любой специалист в данной области техники может внести некоторые изменения и дополнения, не выходящие за пределы объема настоящего изобретения. Поэтому объем защиты настоящего изобретения определяется прилагаемой формулой изобретения и ее эквивалентами.
1. Способ осуществления управления биллингом для абонентов тарифа с предоплатой, содержащий этапы:
приема шлюзом протокола беспроводных приложений (WAP) различных запросов на обслуживание абонентов тарифа с предоплатой;
направления шлюзом WAP запроса на обслуживание абонента к поставщику услуг (SP);
приема ответного сообщения от SP и получения суммарного трафика, сгенерированного по этому запросу абонента;
взаимодействия шлюза WAP с системой биллинга согласно суммарному трафику;
сбора шлюзом WAP информации платежей в соответствии с информацией взаимодействия с системой биллинга;
контроля шлюзом WAP разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом WAP.
2. Способ по п.1, содержащий также этап
установления соединения между SP, системой биллинга и абонентом после приема запроса на обслуживание абонента.
3. Способ по п.1, в котором WAP-шлюз обменивается соответствующей информацией с системой биллинга согласно конфигурированной стратегии биллинга.
4. Способ по п.3, в котором в случае инициирования абонентом запроса на обслуживание в пределах предварительно заданного небольшого объема данных процедура получения суммарного трафика, сгенерированного по этому запросу абонента, содержит этапы:
получения ответного сообщения от SP и
получения суммарного трафика, сгенерированного по этому запросу абонента согласно информации о контенте в ответном сообщении.
5. Способ по п.3, в котором в случае инициирования абонентом запроса на обслуживание в пределах предварительно заданного большого объема данных процедура получения суммарного трафика, сгенерированного по этому запросу абонента, содержит этапы:
расчета и получения суммарного трафика, сгенерированного по этому запросу абонента, согласно длине ответного контента в случае определения возможности отделения длины ответного контента от заголовка ответного сообщения от SP; а также отделения метки конца ответного сообщения, расчета и получения длины ответного контента согласно метке конца, а также расчета и получения суммарного трафика, сгенерированного по этому запросу абонента, согласно длине ответного контента в случае определения невозможности отделения длины ответного контента от заголовка ответного сообщения от SP.
6. Способ по п.3, в котором процедура взаимодействия с системой биллинга согласно суммарному трафику, а также сбора информации платежей в соответствии с информацией взаимодействия с системой биллинга и контроля разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом, содержит этапы:
обращения к системе биллинга с просьбой об организации сеанса биллинга по трафику посредством сообщения о биллинге по трафику и запрашивания системы биллинга о резервировании трафика согласно полученному суммарному трафику в случае обнаружения отсутствия резервирования доступного трафика для абонента;
приема информации о размере резервированного трафика, возвращенной из системы биллинга; а также
доставки соответствующего ответного контента абоненту согласно информации, возвращенной из системы биллинга, и накапливания трафика.
7. Способ по п.3, в котором процедура взаимодействия с системой биллинга согласно суммарному трафику, а также сбора информации платежей в соответствии с информацией взаимодействия с системой биллинга и контроля разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом, содержит этапы:
представления отчетов о накопленном суммарном трафике в систему биллинга в реальном времени, запрашивания системы биллинга о повторном резервировании трафика, приема информации о размере резервированного трафика, возвращенной из системы биллинга, доставки ответного контента по этому запросу абонента и накапливания трафика в случае обнаружения резервирования доступного трафика для абонента и определения того, что резервированный доступный трафик меньше, чем полученный суммарный трафик; а также доставки ответного контента по этому запросу абонента и накапливания трафика в случае обнаружения резервирования доступного трафика для абонента и обнаружения того, что резервированный доступный трафик больше или равен полученному суммарному трафику.
8. Способ по п.3, в котором в случае обработки перекрестного биллинга на основе трафика и контента способ дополнительно содержит этапы:
анализа запроса на обслуживание абонента и пересылки запроса на тарификацию и аутентификацию в систему биллинга в случае определения, что услуга, запрошенная абонентом, включает в себя контент-услугу;
приема ответного сообщения о предварительном списании, возвращенного из системы биллинга; и
запрета на получение абонентом доступа к услуге в случае приема ответного сообщения о предварительном списании с указанием на неуспешную попытку предварительного списания; причем процедура направления запроса на обслуживание абонента к SP содержит этап направления запроса на обслуживание абонента для просмотра HTTP к SP в случае приема ответного сообщения о предварительном списании с указанием на успешную попытку предварительного списания.
9. Способ по п.8, в котором в случае отсутствия резервирования размера трафика для абонента процедура взаимодействия с системой биллинга согласно суммарному трафику, сбора информации платежей в соответствии с информацией взаимодействия с системой биллинга и контроля разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом WAP, содержит этапы:
обращения к системе биллинга с просьбой об организации сеанса биллинга посредством сообщения о биллинге по трафику и запрашивания о резервировании трафика согласно полученному суммарному трафику;
приема информации о размере резервированного трафика, возвращенной из системы биллинга; а также доставки соответствующего ответного контента абоненту и накапливания трафика; или запрашивания системы биллинга об отмене списания в биллинге по трафику посредством подтверждающего сообщения с запросом на биллинг по трафику в случае приема ответного сообщения с указанием на неуспешную попытку резервирования трафика.
10. Способ по п.9, содержащий также этапы:
доставки соответствующего ответного контента, запрошенного абонентом, этому абоненту в случае приема ответного сообщения с указанием на успешное резервирование; и пересылки подтверждающего ответного сообщения на биллинг по контенту в систему биллинга и накапливания трафика в случае успешной доставки; или пересылки сообщения с отменой списания на биллинг по контенту в систему биллинга в случае неуспешной попытки доставки.
11. Способ по п.8, в котором в случае резервирования размера трафика для абонента процедура взаимодействия с системой биллинга согласно суммарному графику, сбора информации платежей в соответствии с информацией взаимодействия с системой биллинга и контроля разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом WAP, содержит этапы:
представления отчетов о накопленном суммарном трафике в систему биллинга в реальном времени, запрашивания системы биллинга о повторном резервировании трафика, приема информации о размере резервированного трафика, возвращенной из системы биллинга, доставки ответного контента по этому запросу абонента и накапливания трафика в случае обнаружения того, что резервированный доступный трафик меньше, чем полученный суммарный трафик; или доставки ответного контента по этому запросу абоненту и накапливания трафика при определении того, что резервированный доступный трафик больше или равен полученному суммарному трафику.
12. Способ по п.11, содержащий также этап запрашивания системы биллинга об отмене списания в биллинге по трафику посредством подтверждающего сообщения с запросом на биллинг по трафику в случае приема ответного сообщения с указанием на неуспешную попытку резервирования трафика.
13. Способ по п.11 или 12, в котором процедура доставки ответного контента по этому запросу абоненту и накапливания трафика содержит этапы:
доставки ответного контента, запрошенного абонентом, этому абоненту; пересылки подтверждающего сообщения о биллинге по контенту в состоянии успешной доставки в систему биллинга и накапливания трафика в случае успешной доставки; а также пересылки подтверждающего сообщения о биллинге по контенту в состоянии неуспешной попытки доставки в систему биллинга в случае неуспешной попытки доставки; и запрета на получение абонентом доступа к услуге.
14. Способ по п.6 или 9, в котором в случае превышения заданного порога частоты переключения тарифов платежей для запросов на обслуживание, инициируемых абонентом, процедура обращения к системе биллинга с просьбой об организации сеансов биллинга по трафику содержит этапы:
организации соответствующих сеансов биллинга по трафику с системой биллинга посредством сообщения о биллинге по трафику согласно запросам абонента для различных тарифов платежей и сохранения сеансов биллинга в течение определенного периода времени; а также завершения сеанса биллинга в случае обнаружения отсутствия генерации какого-либо трафика в течение определенного периода времени.
15. Способ по п.6 или 9, в котором в случае инициирования абонентом запроса на обслуживание в пределах предварительно заданного большого объема данных процедура обращения к системе биллинга с просьбой об организации сеансов биллинга по трафику содержит этап организации сеанса биллинга по выделенному трафику с системой биллинга посредством сообщения о биллинге по трафику согласно запросу на обслуживание с большим объемом данных, инициированному абонентом.
16. Способ по п.6 или 9, в котором в случае наличия одного и того же тарифа у многочисленных запросов на обслуживание, инициированных одним и тем же абонентом, процедура обращения к системе биллинга с просьбой об организации сеансов биллинга по тарифу содержит этап организации одного и того же сеанса биллинга по тарифу с системой биллинга согласно многочисленным запросам абонента на обслуживание, имеющим один и тот же тариф платежей.
17. Шлюз протокола беспроводных приложений (WAP), содержащий: первый блок, адаптированный к конфигурированию стратегии биллинга; и второй блок, адаптированный к приему различных запросов на обслуживание абонентов тарифа с предоплатой, направлению запроса на обслуживание абонента к поставщику услуг (SP), приему ответного сообщения от SP, получению суммарного трафика, сгенерированного по этому запросу абонента, взаимодействию с системой биллинга согласно суммарному трафику, сбору информации платежей в соответствии с информацией взаимодействия с системой биллинга и контролю разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом WAP, и сконфигурированной стратегии биллинга.
18. WAP-шлюз по п.17, в котором в случае необходимости перекрестного биллинга на основе трафика и контента второй блок также адаптирован к инициированию запроса на тарификацию и аутентификацию к системе биллинга, приему ответного сообщения о предварительном списании, возвращенному из системы биллинга, запрету на доступ абонента к услуге при приеме ответного сообщения с указанием о неуспешной попытке предварительного списания или направлению запроса на обслуживание абонента для просмотра HTTP к SP, приему ответного сообщения от SP, получению информации о суммарном трафике, генерированном по этому запросу абонента, и управлению биллингом на основе трафика и контента согласно информации о контенте, к которому абонент может получить доступ, и полученной информации о суммарном трафике, генерированном по этому запросу абонента, в случае приема ответного сообщения о предварительном списании с указанием на успешное предварительное списание.
19. Система для осуществления управления биллингом для абонентов тарифа с предоплатой, содержащая:
шлюз протокола беспроводных приложений (WAP), адаптированный к конфигурированию стратегии биллинга, приему различных запросов на обслуживание абонентов тарифа с предоплатой, направлению запроса на обслуживание абонента к поставщику услуг (SP), приему ответного сообщения от SP, получению суммарного трафика, сгенерированного по этому запросу абонента, взаимодействию с системой биллинга согласно суммарному трафику, сбору информации платежей в соответствии с информацией взаимодействия с системой биллинга и контролю разрешения абоненту доступа к запрошенному обслуживанию в соответствии с информацией платежей, собранной шлюзом WAP, и сконфигурированной стратегии биллинга; и
систему биллинга, адаптированную к взаимодействию с WAP-шлюзом и возврату ответного сообщения о предварительном списании и резервировании.
