СПОСОБ УПРАВЛЕНИЯ КАЧЕСТВОМ ОБСЛУЖИВАНИЯ, СЕРВЕР ПРИЛОЖЕНИЯ И ОКОНЕЧНОЕ УСТРОЙСТВО Российский патент 2017 года по МПК H04W72/08 H04W28/24 

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

Настоящее изобретение относится к области связи и, в частности, к способу управления качеством обслуживания, серверу приложения и оконечному устройству.

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

Мобильный оконечное устройство сначала передает IP пакетные данные в беспроводную базовую станцию посредством беспроводного соединения; беспроводная базовая станция передает IP пакетные данные в шлюз эволюционной системной архитектуры (Шлюз эволюционной системной архитектуры, SAE GW); SAE GW маршрутизирует IP пакетные данные в сервер приложений. Сервер приложений предоставляет соответствующую пакетную услугу, и сервер приложений, главным образом предоставляет пакетные услуги, такие как просмотр веб-страниц, FTP загрузку и коммуникацию в режиме реального времени. SAE GW также реализует функции, такие как выполнение политики и выставление счетов, например, подсчет абонентского трафика данных, так что система выставления счетов беспрепятственно удерживает плату за пользование. Узел выставления счетов абонентам (Узел выставления счетов абонентам, PCRF), в основном, выполняет функцию управления политикой, например, предоставляя различное качество обслуживания (качество услуг, QoS) или политики тарификации для различных услуг и доставки политики в SAE GW для исполнения. Многие обычные мобильные приложения используют модель клиент-сервер (клиент-сервер, CS). Например, QQ или программное обеспечение MSN должно быть установлено таким образом, чтобы иметь возможность работать в режиме сетевого диалога с другим человеком. В модели CS, требуется установить независимое клиентское программное обеспечение для каждого приложения. Тем не менее, посредством разработки и усовершенствования стандарта 5 гипертекстового языка описания документов (Гипертекстовый язык описания документов, HTML) может быть предоставлено больше услуг с помощью модели браузер-сервер (Браузер-сервер, BS) в будущем, то есть, представляются все услуги пользователю с помощью браузера без установки дополнительного программного обеспечения, кроме браузера. Например, веб-игры украсть овощи на http://www.kaixin001.com и т.п. все относятся к модели BS.

В модели BS, оконечное устройство осуществляет синтактический анализ HTML страницы, файла каскадной таблицы стилей (Каскадная таблица стилей, CSS) и java-скрипта, которые соответствуют услуге, с тем, чтобы предоставлять различные услуги для оконечного устройства. Нет необходимости устанавливать дополнительно клиентское программное обеспечение для каждого приложения, до тех пока браузер установлен на оконечном устройстве. Следует отметить, что различные приложения имеют различные требования для мобильной сетевой передачи. Например, для обеспечения коммуникаций в реальном времени, онлайн-игр и т.п. существует строгое требование относительно задержки передачи; если задержка слишком велика, то коммуникации в реальном времени или онлайн-игры не могут быть осуществлены. В качестве другого примера, онлайн-видео по требованию имеет конкретные требования к пропускной способности; может возникнуть пауза, когда пропускная способность сети довольно низкая и, следовательно, непрерывный просмотр не может быть достигнут. Чтобы удовлетворить требования QoS различных приложений, стандарт 3GPP определяет следующие решения политики управления:

Оконечное устройство запрашивает услугу, например, при просмотре файла видео высокой четкости, используя браузер, с сервера приложений. В связи с тем, что для передачи видео необходимо иметь относительно высокую пропускную способность, сервер приложений запрашивает улучшение QoS, и информации о потоке услуги и запрашиваемой полосе пропускания получается из узла управления QoS мобильного оператора. Узел управления QoS может быть PCRF сетевым элементом мобильной полосы пропускания сети, и также может быть самостоятельной открытой платформой. Узел управления QoS формирует политику обслуживания и доставляет политику в SAE GW. SAE GW инициирует установление выделенного канала или процедуру изменения и инструктирует беспроводную базовую станцию зарезервировать ресурс беспроводной связи для канала. Установление выделенного канала или процедуры изменения будет завершено. SAE GW возвращает сообщение подтверждения в узел управления QoS. Узел управления QoS возвращает на сервер приложений информацию, указывающую, что улучшение QoS успешно выполнено. После того, как улучшение QoS завершено, мобильная сеть устанавливает канал передачи с гарантией QoS от UE к SAE GW для передачи услуги, таким образом, выполняется требование приложения к длительности задержки при передаче в сети и пропускной способности.

В предшествующем уровне техники, могут быть удовлетворены требования различных приложений для передачи QoS сети; однако, так как услуга, предоставляемая сервером приложений, не ограничивается пользователем конкретной мобильной сети, сервер приложений должен взаимодействовать с узлами управления QoS различных операторов мобильной связи, что усложняет реализацию сервера приложений, и также усложняет воплощение узла управления QoS. Сеть China Mobile используется в качестве примера. Например, для использования онлайн-игр необходимо обеспечить улучшение QoS для удовлетворения требований относительно задержки, и затем необходимо отделить взаимодействие с соответствующими узлами управления QoS China Mobile, China Unicom и China Telecom. Открытые интерфейсы всех функциональных узлов управления QoS могут быть разными, и сервер приложений должен быть в состоянии взаимодействовать с учетом наличия данного различия. Кроме того, для функционального узла управления QoS оператора сети необходимо обеспечить взаимодействие с различными серверами приложений. Эта техническая задача, как правило, называется открытой фрагментацией, которая является одной из сдерживающих причин популяризации использования сетевых возможностей.

В предшествующем уровне техники есть еще один недостаток: для обеспечения возможности управления QoS, предоставляемой оператором, особенно улучшения QoS, как правило, требуется оплата, так как резервируется дополнительный беспроводной ресурс. Если сервер приложений производит оплату, то этот недостаток в предшествующем уровне техники нивелируется. Тем не менее, если пользователь производит оплату, то требуется дополнительный механизм взаимодействия между сервером приложений и пользователем в предшествующем уровне техники, чтобы гарантировать, что пользователь готов платить за улучшение качества обслуживания, что также повышает сложность реализации приложения.

Раскрытие изобретения

Технические задачи, решаемые с помощью изобретения

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

Решения технической задачи

В соответствии с первым аспектом, способ управления качеством обслуживания включает в себя:

прием сервером приложений запроса HTML-страницы от оконечного устройства;

вставку указателя управления качеством обслуживания QoS в HTML-страницу гипертекстового языка описания документов; и

возврат HTML-страницы, включающей в себя указатель управления качеством обслуживания QoS, на оконечное устройство так, что оконечное устройство запрашивает QoS управление от функционального узла управления QoS оператора в соответствии с указанием управления QoS на HTML-странице, при этом управление QoS включает в себя QoS статус запросов и/или QoS улучшения.

Со ссылкой на первый аспект, в первом возможном варианте реализации способа согласно первому аспекту, указатель управления QoS является Java-скриптом, вновь определенным HTML-тегом или HTML-тегом вновь добавленного атрибута.

Со ссылкой на первый возможный вариант реализации способа по первому аспекту, в соответствии со вторым возможным вариантом осуществления способа согласно первому аспекту, когда указание управления QoS представляет собой Java-скрипт:

java-скрипт запрашивает оконечное устройство инициировать QoS запрос API, и если задержка, указанная посредством возвращенного значения QoS запроса API больше, чем заданное временное значение, то оконечное устройство инициирует QoS запрос API для запроса того, что задержка передачи является меньше, чем заданное значение задержки.

Со ссылкой на первый возможный вариант осуществления по первому аспекту, в третьем возможном варианте реализации способа по первому аспекту, когда указание управления QoS является вновь определенным HTML-тегом:

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

Со ссылкой на первый возможный вариант реализации способа по первому аспекту, в четвертом возможном варианте реализации способа по первому аспекту, когда указание управления QoS является HTML-тегом вновь добавленного атрибута, а именно:

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

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

вставку сервером приложений сертификата сервера приложений в HTML-страницу;

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

В соответствии со вторым аспектом способ управления качеством обслуживания включает в себя:

синтаксический разбор с помощью оконечного устройства указателя управления QoS на HTML-странице, и запрос управления QoS из функционального узла управления QoS оператора; и

прием результата запроса, возвращенного функциональным узлом управления QoS, и выполнение обработки в соответствии с результатом запроса.

Со ссылкой на второй аспект, в первом возможном варианте реализации способа согласно второму аспекту, синтаксический разбор оконечного устройства указания управления QoS на HTML-странице и запрос управления QoS из функционального узла управления QoS оператора включает в себя:

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

Со ссылкой на второй аспект, во втором возможном варианте реализации способа согласно второму аспекту, синтаксический разбор с помощью оконечного устройства указания управления QoS на HTML-странице, и запрос управления QoS из функционального узла управления QoS оператора включает в себя:

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

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

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

приглашение пользователя отправить запрос управления QoS включает в себя следующее:

отображается оконное приглашение или информация приглашения добавляется в существующее окно.

В соответствии с третьим аспектом, сервер приложений включает в себя:

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

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

Со ссылкой на третий аспект, в первом из возможных вариантов реализаций способа согласно третьему аспекту, указание управления QoS является Java-скриптом, вновь определенным HTML-тегом или HTML-тегом из вновь добавленного атрибута.

Со ссылкой на первый возможный вариант реализации способа согласно третьему аспекту, в соответствии со вторым возможным вариантом осуществления способа согласно третьему аспекту, блок вставки специально выполнен с возможностью:

вставлять java-скрипт в HTML-страницу, где java-скрипт запрашивает оконечное устройство инициировать запрос QoS API и, если значение возвращенного запроса QoS API больше, чем заданное значение задержки, то оконечное устройство инициирует запрос QoS API, что задержка передачи является меньше, чем заданное значение задержки.

Со ссылкой на первый возможный вариант реализации способа согласно третьему аспекту, в третьем возможном варианте реализации способа согласно третьему аспекту, блок вставки специально выполнен с возможностью:

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

Со ссылкой на первый возможный вариант реализации способа согласно третьему аспекту, в четвертом возможном варианте реализации способа согласно третьему аспекту, блок вставки специально выполнен с возможностью:

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

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

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

В соответствии с четвертым аспектом, оконечное устройство включает в себя:

блок синтаксического разбора, выполненный с возможностью осуществления синтаксического разбора указания управления QoS на HTML-странице;

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

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

Со ссылкой на четвертый аспект, в первом возможном варианте реализации способа по четвертому аспекту, блок синтаксического разбора специально выполнен с возможностью:

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

Со ссылкой на четвертый аспект, во втором возможном варианте реализации способа согласно четвертому аспекту, блок синтаксического разбора специально выполнен с возможностью:

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

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

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

приглашение пользователя отправить запрос на управление QoS включает в себя следующее:

отображение оконного приглашения, или информация приглашения добавляется в существующее окно.

Полезные эффекты изобретения

По сравнению с предшествующим уровнем техники, варианты осуществления настоящего изобретения описывают способ управления качеством обслуживания. В способе, сервер приложений вставляет указание управления QoS в HTML-страницу, так что оконечное устройство осуществляет синтаксический разбор указания управления QoS на HTML-странице, и запрашивает управление QoS из функционального узла управления QoS оператора. Таким образом, возможности управления QoS обеспечивают следующее: взаимодействие между сервером приложений и сетевым оператором изменяется на взаимодействие между оконечным устройством и оператором сети, и взаимодействие между сервером приложений и соответствующим функциональным узлом управления QoS оператора сети не требуется, тем самым упрощая обработку сервером приложений. Кроме того, функциональный узел управления QoS оператора сети должен взаимодействовать только с плагином браузера, установленным на оконечном устройстве оператором сети или с открытой платформой универсальных возможностей, и взаимодействие с различными серверами приложений не осуществляется, тем самым упрощая функционирование функционального узла управления QoS и решая техническую задачу открытой фрагментации возможностей.

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

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

Фиг. 1 является блок-схемой алгоритма способа управления качеством обслуживания согласно варианту 1 осуществления настоящего изобретения;

Фиг. 2 является схематическим представлением способа управления качеством обслуживания в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 3 является схематическим представлением способа управления качеством обслуживания в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 4 представляет собой схематическое изображение способа управления качеством обслуживания в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 5 является блок-схемой алгоритма способа управления качеством обслуживания согласно варианту 2 осуществления настоящего изобретения;

Фиг. 6 представляет собой блок-схему сервера приложений согласно варианту 3 осуществления настоящего изобретения;

Фиг. 7 представляет собой блок-схему оконечного устройства в соответствии с вариантом 4 осуществления настоящего изобретения;

Фиг. 8 представляет собой блок-схему сервера приложений согласно варианту 5 осуществления настоящего изобретения; и

Фиг. 9 представляет собой блок-схему оконечного устройства в соответствии с вариантом 6 осуществления настоящего изобретения.

Осуществление изобретения

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

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

Вариант 1 осуществления

Обращаясь к фиг. 1, где фиг. 1 является блок-схемой алгоритма способа управления качеством обслуживания согласно варианту 1 осуществления настоящего изобретения. Как показано на фиг. 1, способ включает в себя следующие этапы:

Этап 101: сервер приложений принимает запрос HTML-страницы оконечного устройства.

Этап 102: Вставка указания управления качеством обслуживания QoS в HTML-страницу гипертекстового языка описания документов.

Указание управления QoS является Java-скриптом, вновь определенным HTML-тегои или HTML-тегом вновь добавленного атрибута.

Возможно, сервер приложений вставляет указание управления QoS в HTML-страницу, где указание управления QoS является Java-скриптом, а именно:

вставка сервером приложений Java-скрипта в HTML-страницу, где Java-скрипт запрашивает оконечное устройство инициировать запрос QoS API, и если возвращенное значение запроса QoS API больше, чем заданное значение задержки, запрос QoS API инициирует запроса, что задержка передачи меньше, чем заданное значение задержки.

В частности, со ссылкой к этап 202 на фиг. 2, веб-сайт игры в режиме онлайн имеет специфическое требование к задержке передачи, и сервер приложений вставляет следующий Java-скрипт в HTML-страницу:

Navigator.QoScontrol.getCurrentQoS (информация QoS);

если QoS information.delay > 100 мс,

затем Navigator.QoScontrol.UpdatetQoS (100 мс);

Значение скрипта заключается в том, что браузер сначала должен вызывать QoS API запрос, и если задержка, указанная возвращаемым значением запроса QoS API, больше чем 100 мс, запрос QoS API инициируется для запроса того, что задержка передачи по сети менее 100 мс.

Возможно, сервер приложений вставляет указание управления QoS в HTML-страницу, где указание управления QoS является вновь определенным HTML-тегом, а именно:

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

В частности, со ссылкой на этап 303 на фиг. 3, видео файлы с различными разрешениями одного и того же фильма, которые обеспечиваются видео веб-сайтом, соответствуют высокой четкости, стандартной четкости и т.п. отдельно, и HTML-страница, возвращаемая сервером приложений, включает в себя следующий контент:

<video id = "movie">

<source src = "XXX.mp4" type = "video/mp4; требуемая пропускная способность = 512 Kbit/s />

<source src = " YYY.mp4" type = "video/mp4; требуемая пропускная способность = 1 Mbits /s />

</ video>

Часть источника src указывает на видеофайлы с различным разрешением. Например, "XXX.mp4" тип указывает на файл стандартной четкости, и "YYY.mp4" тип указывает на файл высокой четкости. Часть требуемой пропускной способности указывает на минимальные значения полосы пропускания, требуемые для видеофайлов с различным разрешением, которые могут быть реализованы посредством добавления атрибута в существующий HTML-тег (видео).

Возможно, сервер приложений вставляет указание управления QoS в HTML-страницу, где указание управления QoS является HTML-тегом вновь добавленного атрибута, а именно:

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

В частности, со ссылкой на этап 402 на фиг. 4, поскольку для осуществления коммуникации требуется специфическое требование к задержке передачи и полосы пропускания, вновь добавленный QoS тег может быть вставлен в HTML-страницу:

<QoS>

<гарантированная полоса пропускания = 512 Kbit/s />

<гарантированная задержка <=100 ms>

</ QoS>

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

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

вставку сервером приложений сертификата сервера приложений в HTML-страницу;

доставку с помощью оконечного устройства сертификата сервера приложений при отправке запроса в узел управления QoS оператора; и определение с помощью функционального узла управления QoS, используя сертификат сервера приложений, что управление QoS инициируется приложением и тарификацией приложения.

В частности, со ссылкой на этап 403 и этап 404 на фиг. 4, оконечное устройство осуществляет синтаксический разбор HTML-страницы; после обнаружения вновь добавленного QoS-тега, инициируется улучшение QoS API из открытой платформы универсальной способности, когда информация сертификата приложения дополнительно включается в состав в дополнение к идентификатору пользователя, требованию QoS и идентификатору потока службы. Открытая платформа универсальных возможностей удерживает плату с соответствующего счета в сервере приложений в соответствии с информацией сертификата приложения, в котором открыт счет, например, данные кредитной карты, предоставляемые сервером приложений, может быть предоставленной открытой платформой универсальных возможностей сервером приложений заранее.

Этап 103: возврат HTML-страницы, включающей в себя указание управления качеством обслуживания QoS, в оконечное устройство, так что оконечное устройство запрашивает управление QoS из узла управления QoS оператора в соответствии с указанием управления QoS на HTML-странице, где управление QoS включает в себя запрос QoS статуса и/или QoS улучшения.

Этот вариант осуществления настоящего изобретения описывает способ управления качеством обслуживания. В способе, сервер приложений вставляет указание управления QoS в HTML-страницу, так что оконечное устройство осуществляет синтаксический разбор указания управления QoS на HTML-странице, и запрашивает управление QoS из узла управления QoS оператора. Таким образом, с точки зрения возможности управления QoS, взаимодействие между сервером приложений и сетевым оператором изменяется на взаимодействие между оконечным устройством и оператором сети, и взаимодействие между сервером приложений и соответствующим сетевым узлом управления QoS оператора не требуется, тем самым упрощая обработку сервером приложений. Кроме того, узел управления QoS оператора сети должен обеспечить взаимодействие только с плагином браузера, установленного на оконечном устройстве, оператором сети или с открытой платформой универсальных возможностей, и взаимодействие с различными серверами приложений не осуществляется, таким образом, упрощая реализацию функционального узла управления QoS и решая техническую задачу, связанную с открытой фрагментацией возможностей.

Вариант 2 осуществления

Обращаясь к фиг. 5, фиг. 5 является блок-схемой алгоритма способа управления качеством обслуживания согласно варианту 2 осуществления настоящего изобретения. Как показано на фиг. 5, способ включает в себя следующие этапы:

Этап 501: Оконечное устройство осуществляет синтаксический разбор указателя управления QoS на HTML-странице и запрашивает управление QoS из узла управления QoS оператора.

Возможно, оконечное устройство осуществляет синтаксический разбор указателя управления QoS на HTML-странице и запрашивает управление QoS из узла управления QoS оператора включает в себя:

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

В частности, со ссылкой на этап 304 на фиг. 3, оконечное устройство осуществляет синтаксический разбор тега на HTML-странице; после обнаружения указания управления QoS на HTML-странице оконечное устройство вызывает плагин браузера, установленный на оконечном устройстве. Плагин браузера отправляет сообщение с запросом QoS в функциональный узел управления QoS оператора сети или инициирует запрос QoS интерфейса прикладного программирования (интерфейс прикладного программирования, API), где сообщение с запросом QoS или запроса QoS API может передаваться в HTTPS для обеспечения безопасности.

Возможно, оконечное устройство осуществляет синтаксический разбор указания управления QoS на HTML-странице и запрашивает управление QoS из функционального узла управления QoS оператора включает в себя:

синтаксический разбор, с помощью оконечного устройства, указания управления QoS на HTML-странице, вызывая интерфейс API прикладного программирования из открытой платформы универсальных возможностей и, отправку запроса управления QoS в узел управления QoS оператора, используя открытую платформу универсальных возможностей

В частности, со ссылкой на этап 203 на фиг. 2, оконечное устройство осуществляет синтаксический разбор Java-скрипта на HTML-странице; после обнаружения указания управления QoS на HTML-странице, оконечное устройство напрямую инициирует запрос QoS API из открытой платформы универсальных возможностей для запроса текущей задержки передачи по сети. Открытая платформа универсальных возможностей может быть связана с оконечным устройством. Например, браузер IE Майкрософт может инициировать запрос QoS API из открытой платформы возможностей Microsoft и chrome браузер Google может инициировать запрос QoS API из открытой платформы возможностей Google. Открытая платформа возможностей может быть также не связана с браузером и предоставлена третьей стороной, и любой браузер может инициировать запрос QoS API из открытой платформы возможностей. Независимо от того, связана ли открытая платформа возможностей с оконечным устройством, при инициировании запроса QoS API из открытой платформы возможностей, оконечное устройство должно взаимодействовать с оператором сети, к которому принадлежит оконечное устройство пользователя.

В качестве возможного варианта осуществления способ дополнительно включает в себя:

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

запрос пользователя отправить запрос на управление QoS включает в себя следующее:

отображение оконного приглашения или информация приглашения добавляется в существующее окно.

В частности, со ссылкой на этап 207 на фиг. 2, когда задержка передачи превышает 100 мс, требование для реализации онлайн игры не удовлетворено; следовательно, необходимо инициировать улучшение API QoS в соответствии с определяющей логики скрипта. Потому, возможно, потребуется зарезервировать больше ресурсов беспроводной связи для улучшения API QoS, сетевой оператор взимает плату за API. Информация приглашения может отображаться для пользователя, прежде чем оконечное устройство вызывает API, и оконечное устройство вызывает улучшение QoS API только после того, как пользователь направляет подтверждение. Конкретные способы приглашения пользователя включают в себя, что отображается оконное приглашение или информация приглашения добавляется в существующем окне.

Кроме того, оконечное устройство может конфигурировать управление QoS APIs, для пользователей, которые необходимо приглашение. Например, для запроса QoS API пользователь не должен быть приглашен; или оконечное устройство может также непосредственно вызывать улучшение QoS API из открытой платформы возможностей. После обнаружения того, что улучшение QoS требует дополнительной оплаты, открытая платформа универсальных возможностей может направить команду управления в ответном сообщении улучшения QoS API браузеру пригласить пользователя и запросить улучшение QoS API снова, после того, как пользователь делает подтверждение.

Этап 502: Прием результата запроса, возвращенного функциональным узлом управления QoS, и также выполнять обработку в соответствии с результатом запроса.

Например, оконечное устройство представляет услуги, относящиеся к управлению QoS, пользователю в соответствии с результатом запроса, возвращаемого функциональным узлом управления QoS.

Этот вариант осуществления настоящего изобретения описывает способ управления качеством обслуживания. В способе, сервер приложений вставляет указание управления QoS в HTML-страницу, так что оконечное устройство осуществляет синтаксический разбор указания управления QoS на HTML-странице, и запрашивает управление QoS из узла управления QoS оператора. Таким образом, с точки зрения возможности управления QoS, взаимодействие между сервером приложений и сетевым оператором изменяется на взаимодействие между оконечным устройством и оператором сети, и взаимодействие между сервером приложений и соответствующим сетевым узлом управления QoS оператора не требуется, тем самым упрощая обработку сервером приложений. Кроме того, узел управления QoS оператора сети должен обеспечить взаимодействие только с плагином браузера, установленного на оконечном устройстве, оператором сети или с открытой платформой универсальных возможностей, и взаимодействие с различными серверами приложений не осуществляется, таким образом, упрощая реализацию функционального узла управления QoS и решая техническую задачу, связанную с открытой фрагментацией возможностей.

Способ взаимодействия между сервером приложений и оконечным устройством в варианте 1 выполнения и в варианте 2 осуществления дополнительно далее описывается со ссылками на фиг. 2, фиг. 3 и фиг. 4, в качестве примеров. Последовательность этапов на фиг. 2, фиг. 3 и фиг. 4 не ограничивается, и только один из этих способов используется в качестве примера для описания.

Обращаясь к фиг. 2, фиг. 2 является схематическим представлением способа управления качеством обслуживания в соответствии с вариантом осуществления настоящего изобретения.

В этом варианте осуществления, сервер приложений обеспечивает услугу онлайн-игры. Поскольку онлайн игра имеет высокое требование к задержке, то должна быть запрошена текущая сетевая задержка, указанная услугой. После того, как задержка не может удовлетворить запросу услуги, требуется инициирование запроса на улучшение QoS API, чтобы уменьшить задержку передачи в сети, и тем самым удовлетворить запрос услуги. Как показано на фиг. 2:

Этап 201: Оконечное устройство посылает запрос HTTP в сервер приложений, чтобы запросить страницу онлайн-игры.

Этап 202: Так как веб-сайт онлайн игры имеет специфическое требование к задержке передачи в этом примере, сервер приложений может вставить следующий скрипт в HTML страницу:

Navigator.QoScontrol.getCurrentQoS (информация QoS);

если QoS information.delay > 100 мс,

затем Navigator.QoScontrol.UpdatetQoS (100 мс);

Значение скрипта заключается в том, что браузер сначала запрашивает инициирование запроса QoS API, а если задержка, указанная возвращаемым значением запроса QoS API, больше чем 100 мс, то инициируется запрос QoS API, так что задержка передачи по сети менее 100 мс.

Этап 203: Оконечное устройство осуществляет синтетический разбор Java-скрипт на HTML-странице; после обнаружения изложенного выше описания, оконечное устройство, прежде всего, инициирует запрос QoS API для запроса текущей задержки передачи по сети. Браузер напрямую инициирует запрос QoS API из открытой платформы универсальных возможностей, и открытая платформа универсальных возможностей может быть связана с браузером. Например, браузер IE Майкрософт может вызвать запрос QoS API из открытой платформы возможностей Microsoft, и chrome браузер Google может вызывать запрос QoS API из открытой платформы возможностей Google. Открытая платформа возможностей может быть не связана с браузером и предоставлена третьей стороной, и любой браузер может вызывать запрос QoS API из открытой платформы возможностей. Независимо от того, связана ли открытая платформа возможностей с браузером, при вызове запроса QoS API из открытой платформы возможностей, браузер не должен взаимодействовать с оператором сети, к которой принадлежит пользователь.

Этап 204: Открытая платформа универсальных возможностей определяет, в соответствии с ID пользователя, включенным в состав запроса QoS API, например, номер телефона, оператор сети, к которой принадлежит пользователь, и отправляет сообщение с запросом на запрос QoS или запрос QoS API в узел управления QoS оператора.

Этап 205: Узел управления QoS оператора сети возвращает текущий статус QoS пользователя.

Этап 206: Открытая платформа возможностей возвращает текущий статус QoS в браузер.

Этап 207: В этом варианте осуществления, текущая задержка передачи превышает 100 мс, и запрос на интернет-игру не выполняется; таким образом, должно быть применено улучшение QoS API в соответствии с определяющей логикой скрипта. В связи с тем, что могут потребоваться больше ресурсов беспроводной связи, которые зарезервированы для улучшения QoS API, сетевой оператором взимает плату за пользование этого API. Информация приглашения может отображаться для пользователя, прежде чем браузер вызывает API, и браузер вызывает улучшение QoS API только после того, как пользователь делает подтверждение. Конкретные способы приглашения пользователя включают в себя отображение оконного приглашения или информация приглашения добавляется в существующее окно.

Кроме того, браузер можно конфигурировать управление QoS API для приглашаемых пользователей. Например, для запроса QoS API пользователь не должен быть приглашен; браузер может также непосредственно вызывать улучшение QoS API из открытой платформы возможностей. После обнаружения того, что требуется оплатить за улучшение QoS, открытая платформа универсальных возможностей может направить команду управления в ответном сообщении на улучшение QoS API, в браузер пригласить пользователя, и запрашивает улучшение QoS API снова после того, как пользователь делает подтверждение.

Этап 208: Браузер вызывает улучшение QoS API из открытой платформы универсальных возможностей, где идентификатор пользователя, QoS затребованное услугой, включено в состав, то есть, задержка составляет менее 100 мс в этом примере, и информация потока услуг потока услуг обозначает услугу онлайн-игры, и конкретный формат может быть 1Р-пять.

Этап 209: Открытая платформа универсальных возможностей определяет, в соответствии с ID пользователя, включенного в состав улучшения QoS API, оператора сети, к которой принадлежит пользователь, и отправляет сообщение с запросом на улучшение качества обслуживания или улучшение QoS API в функциональный узел управления QoS оператора.

Этап 210: Так как функциональный узел управления QoS оператора сети является независимым элементом сети в этом примере, независимый элемент сети может дать команду, используя интерфейс Rx, который уже был определен в существующем стандарте, PCRF удовлетворить требование QoS потока услуг.

Этап 211: PCRF генерирует политику обслуживания и доставляет политику в SAE шлюз.

Этап 212: SAE шлюз инициирует установление выделенного канала или процедуру модификации, и инструктирует базовую станцию беспроводной связи, чтобы зарезервировать ресурс беспроводной связи для канала, чтобы гарантировать QoS услуги.

Этап 213: Завершение установления выделенного канала или процедуры модификации.

Этап 214: SAE шлюз возвращает сообщение с подтверждением в PCRF.

Этап 215: PCRF возвращает сообщение с подтверждением в независимый функциональный узел управления QoS.

Этап 216: Функциональный узел управления QoS возвращает результат улучшения QoS в открытую платформу универсальных возможностей.

Этап 217: Открытая платформа универсальных возможностей возвращает результат улучшения QoS в браузер, и браузер взаимодействует с сервером приложений, чтобы обеспечить онлайн-игру. Так как задержка уже менее 100 мс посредством улучшения QoS, пользователь может воспроизводить онлайн-игру без зависаний.

Как видно из этого варианта осуществления для сервера приложений, только один java-скрипт должны быть вставлен в существующий тег, и нет необходимости в реализации взаимодействия между сервером приложений и соответствующим функциональным узлом управления QoS сетевого оператора, тем самым, упрощая обработку сервером приложений. Для функционального узла управления QoS оператора сети требуется только взаимодействие с универсальной открытой платформой возможностей, и не требуется осуществление отдельного взаимодействия с каждым сервером приложений, таким образом, также упрощает реализацию функционального узла управления QoS. Для браузера, требуется только взаимодействие с универсальной открытой платформой возможностей, и открытая платформа возможностей осуществляет выбор соответствующего оператора сети и завершает соответствующую операцию управления QoS.

Обращаясь к фиг. 3, фиг. 3 является схематическим представлением способа управления качеством обслуживания в соответствии с вариантом осуществления настоящего изобретения.

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

Как показано на фиг. 3, способ включает в себя следующие этапы:

Этап 301: Установление соединения протокола управления передачей (протокол управления передачей, TCP) между оконечным устройством и сервером приложений.

Этап 302: Оконечное устройство посылает запрос протокола передачи гипертекста (Протокол передачи гипертекста, HTTP), чтобы запросить страницу видео сайта.

Этап 303: В связи с тем, что видео-файлы с различным разрешением одного и того же фильма, которые предоставлены видео веб-сайта, соответствуют высокой четкости, видео стандартной четкости и т.п., в этом примере, сервер приложений возвращает HTML-страницу, которая включает в себя следующее содержание:

<video id = "movie">

<source src = "XXX.mp4" type = "video/mp4; требуемая пропускная способность = 512 Kbit/s />

<source src = "YYY.mp4" type = "video/mp4; требуемая пропускная способность = 1 Mbits /s/>

</video>

Часть source src указывает на видеофайлы с различными разрешениями. Например, "XXX.mp4" указывает тип файла стандартной четкости и тип "YYY.mp4" указывает файл высокой четкости. Часть требуемой пропускной способности указывает минимальные значения полосы пропускания, требуемые для видео файлов с различным разрешением, которые реализуются посредством добавления атрибута в существующий HTML-тег (video) в этом варианте осуществления.

Этап 304: Браузер выполняет синтаксический разбор тега на HTML-странице; после обнаружения вновь добавленного атрибута, браузер вызывает плагин браузера, установленного на оконечном устройстве; плагин браузера отправляет сообщение с запросом QoS в функциональный узел управления QoS оператора сети или вызывает запрос QoS API, где сообщение с запросом QoS или запрос QoS API может быть передан в HTTPS для обеспечения безопасности. Возможно, сообщение с запросом может включать в себя информацию о текущем местоположении оконечного устройства, например, информацию о соте беспроводной связи, где оконечное устройство находится в данный момент. Следует отметить, что плагин браузера в данном документе установлен посредством сетевого оператора, к которому принадлежит оконечное устройство пользователя. Например, оконечное устройство пользователя А принадлежит мобильному оператору X, затем устанавливается плагин браузера мобильного оператора X, и плагин отвечает за взаимодействие с функциональным узлом управления QoS сетевого оператора X. Аналогичным образом, когда оконечное устройство пользователя В принадлежит мобильному оператору Y, то устанавливается плагин браузера мобильного оператора Y, и плагин отвечает за взаимодействие с функциональным узлом управления QoS сетевого оператора Y.

Этап 305: Функциональный узел управления QoS оператора сети запрашивает информацию о текущем состоянии QoS пользователя из соответствующей базовой станции беспроводной связи в соответствии с информацией о местоположении в сообщении, после приема сообщения с запросом QoS или приема вызова запроса QoS API.

Функциональный узел управления качеством обслуживания может быть независимой открытой платформой возможностей оператора сети, и также может быть сетевым элементом выставления счетов абонентам (узел политики и правил тарификации, PCRP), определенным в существующем стандарте.

Этап 306: Базовая станция беспроводной связи возвращает текущий статус QoS пользователя в соответствии с действующим использованием беспроводного ресурса, где текущее состояние QoS включает в себя доступную максимальную полосу пропускания, текущую максимальную задержку передачи, перегружена ли сеть в данный момент и тому подобное.

Этап 307: Функциональный узел управления QoS возвращает доступную информацию QoS в плагин браузера.

Этап 308: Браузер получает информацию о доступности QoS в соответствии с плагином браузера, и выбирает видеофайл с соответствующим разрешением. В этом примере доступная максимальная полоса пропускания для пользователя, возвращаемая функциональным узлом управления QoS, равна 600 кбит/с, и браузер выбирает для загрузки XXX.mp4 видео файл (соответствующий видео со стандартным разрешением) в соответствии с этим результатом и представляет это пользователю.

Этап 309: Браузер посылает второй запрос HTTP в сервер приложений на загрузку видео файла стандартного разрешения.

Этап 310: Сервер приложений возвращает соответствующий видеофайл.

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

Обращаясь к фиг. 4, фиг. 4 представляет собой схематическое изображение способа управления качеством обслуживания согласно варианту осуществления настоящего изобретения. Аналогично фиг. 2, на фиг. 4 показано, что улучшение QoS необходимо запросить из сети; различие от фиг. 2 заключается в том, в этом варианте осуществления улучшение QoS API оплачивается сервером приложений, а не пользователем.

Этап 401: Оконечное устройство посылает запрос HTTP для запроса веб-сервиса в режиме реального времени, например, услуги видео-чата.

Этап 402: В связи с тем, что для осуществления коммуникации необходимо удовлетворить специфическое требование к задержке передачи и пропускной способности, в этом примере, сервер приложений может вставить вновь добавленный QoS тег в HTML-страницу.

<QoS>

<гарантированная полоса пропускания = 512 Кбит = /с/>

<гарантированная задержка <=100 мс>

</ QoS>

Поскольку приложение платит за запрос QoS в этом варианте осуществления, информация, такая как сертификат приложения, может быть вставлен в HTML-страницу для идентификации приложения.

Этап 403: Браузер осуществляет синтаксический разбор HTML-страницы; после обнаружения QoS тега, браузер вызывает улучшение QoS API из универсальной открытой платформы возможностей, где улучшение QoS API дополнительно содержит информацию о сертификате приложения в дополнение к идентификатору пользователя, запрос QoS и идентификатор потока службы.

Этап 404: Универсальная открытая платформа возможностей удерживает плату с соответствующего счета в сервере приложений в соответствии с информацией сертификата приложения, в котором открыт счет, например, данные кредитной карты предоставляются сервером приложений, которые могут быть предоставлены универсальной открытой платформе возможностей сервером приложений заранее.

Этап 405: Универсальная открытая платформа возможностей определяет, в соответствии с ГО пользователя, включенного в состав улучшения QoS API, сетевого оператора, к которому принадлежит пользователь, и отправляет сообщение с запросом на улучшение качества обслуживания или улучшение QoS API в узел управления QoS. Следует отметить, что функциональный узел управления QoS интегрирован в PCRF существующей мобильной сети в этом варианте осуществления, и взаимодействие между универсальной открытой платформой возможности и функциональным узлом управления QoS может быть реализовано с помощью интерфейса Rx, который уже определен в стандарте, а также может быть реализовано с помощью открытого API функционального узла управления QoS.

Этап 406: Функциональный узел управления QoS формирует политику и правило управления тарификацией (Политика и управление тарификацией, РСС), где сообщение также включает в себя тарификацию ID универсальной открытой платформы возможностей.

Этап 407: Шлюз выполняет политику и инициирует установку выделенного канала.

Этап 408: Успешно установлен выделенный канал.

Этап 409: Шлюз возвращает ответное сообщение в функциональный узел управления QoS; в тоже время, шлюз взаимодействует с системой тарификации оператора сети мобильной связи для оплаты потока услуги. В процессе взаимодействия, шлюз направляет в систему оплаты ID оплаты универсальной открытой платформы возможностей, доставленный посредством функционального узла управления QoS, и оператор мобильной связи списывает оплату со счета универсальной открытой платформы возможностей.

Этап 410: Функциональный узел управления QoS возвращает сообщение с подтверждением улучшения качества обслуживания в открытую платформу возможностей.

Этап 411: Универсальная открытая платформа возможностей возвращает результат улучшения QoS в браузер, и браузер взаимодействует с сервером приложений, чтобы обеспечить веб-услугу в режиме реального времени. Поскольку полоса пропускания и задержка обеспечены, пользователь имеет высокий уровень обслуживания.

В этом варианте осуществления, универсальная открытая платформа возможности используется не только для выбора функционального узла управления QoS, соответствующего оператору сети, но также функции, такие как достоверность оплаты: с одной стороны, универсальная открытая платформа возможностей осуществляет оплату оператору сети; с другой стороны, универсальная открытая платформа возможностей взимает оплату за конкретное приложение на сервере приложений.

Этот вариант осуществления настоящего изобретения описывает способ управления качеством обслуживания. В способе, сервер приложений вставляет указание управления QoS в сообщение HTML-страницы, так что оконечное устройство осуществляет синтаксический разбор указания управления QoS на HTML-странице, и запрашивает управление QoS из функционального узла управления QoS оператора. Таким образом, для управления QoS возможности, взаимодействие между сервером приложений и сетевым оператором изменяется на взаимодействие между оконечным устройством и оператором сети, и взаимодействие между сервером приложений и соответствующим функциональным узлом управления QoS оператора сети не требуется, тем самым, упрощая обработку сервером приложений. Кроме того, функциональный узел управления QoS оператора сети должен взаимодействовать только с плагином, установленным в оконечном устройстве браузера оператором сети, или с универсальной открытой платформой возможности, и взаимодействие с различными серверами приложений не осуществляется, тем самым, упрощая реализацию функционального узла управления QoS и решает техническую задачу открытой фрагментации возможностей.

Вариант 3 осуществления

Обращаясь к фиг. 6, фиг. 6 представляет собой блок-схему сервера приложений согласно варианту 3 осуществления настоящего изобретения. Как показано на фиг. 6, сервер приложений включает в себя следующие блоки: блок 601 вставки и приемный блок 602.

Блок 601 вставки выполнен с возможностью вставлять указание управления QoS в HTML-страницу гипертекстового языка описания документов.

Указание управления QoS является java-скриптом, вновь определенным HTML-тегом или HTML-тегом вновь добавленного атрибута.

Возможно, блок 601 вставки специально выполнен с возможностью:

вставлять java-скрипт в HTML страницу, где java-скрипт запрашивает оконечное устройство инициировать запрос QoS API, и если возвращенное значение запроса QoS API больше, чем заданное временное значение, то оконечное устройство инициирует QoS API запрос, где задержка передачи меньше, чем заданное значение задержки.

В частности, со ссылкой на этап 202 на фиг. 2, веб-сайт онлайн игры имеет специфическое требование к задержке передачи в этом примере, сервер приложений может вставить следующий скрипт в HTML страницу:

Navigator.QoScontrol.getCurrentQoS (информация QoS);

если QoS information.delay > 100 мс,

затем Navigator.QoScontrol.UpdatetQoS (100 мс);

Значение скрипта заключается в том, что браузер сначала запрашивает инициирование запроса QoS API, а если задержка, указанная возвращаемым значением запроса QoS API, больше чем 100 мс, то инициируется запрос QoS API, так что задержка передачи по сети менее 100 мс.

Возможно, блок 601 вставки специально выполнен с возможностью:

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

В частности, со ссылкой на этапе 303 на фиг. 3, видео-файлы с различным разрешением одного и того же фильма, которые предоставлены видео веб-сайта, соответствуют высокой четкости, видео стандартной четкости и т.п., в этом примере, сервер приложений возвращает HTML-страницу, которая включает в себя следующее содержание:

<video id = "movie">

<source src = "XXX.mp4" type = "video/mp4; требуемая пропускная способность = 512 Kbit/s />

<source src = "YYY.mp4" type = "video/mp4; требуемая пропускная способность = 1 Mbits/s />

</video>

Запрашиваемая часть полосы пропускания указывает минимальные значения полосы пропускания, требуемые для видео файлов с различным разрешением, которые могут быть реализованы посредством добавления атрибута в существующий HTML тег (видео).

Возможно, блок 601 вставки специально выполнен с возможностью:

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

В частности, со ссылкой на этап 402 на фиг. 4, в связи с тем, что для осуществления коммуникации необходимо удовлетворить специфическое требование к задержке передачи и пропускной способности, сервер приложений может вставить вновь добавленный QoS тег в HTML-страницу.

<QoS>

<гарантированная полоса пропускания = 512 Кбит = /с/>

<гарантированная задержка <=100 мс>

</ QoS>

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

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

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

В частности, со ссылкой на этап 403 и этап 404 на фиг. 4, оконечное устройство осуществляет синтаксический разбор HTML-страницы; после обнаружения вновь добавленного QoS тега, оконечное устройство вызывает улучшение QoS API из универсальной открытой платформы возможностей, где улучшение QoS API дополнительно содержит информацию о сертификате приложения в дополнение к идентификатору пользователя, запрос QoS и идентификатор потока службы. Универсальная открытая платформа возможностей удерживает плату с соответствующего счета в сервере приложений в соответствии с информацией сертификата приложения, в котором открыт счет, например, данные кредитной карты предоставляются сервером приложений, которые могут быть предоставлены универсальной открытой платформе возможностей сервером приложений заранее.

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

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

Вариант 4 осуществления

Обращаясь к фиг. 7, фиг. 7 представляет собой блок-схему оконечного устройства в соответствии с вариантом 4 осуществления настоящего изобретения. Как показано на фиг. 7, оконечное устройство включает в себя следующие блоки: блок 701 разбора, блок 702 передачи и блок 703 представления.

Блок 701 разбора выполнен с возможностью осуществлять синтаксический разбор указания управления QoS на HTML-странице.

Блок 702 передачи выполнен с возможностью направлять запрос управления QoS в функциональный узел управления QoS оператора.

Возможно, блок 701 разбора специально выполнен с возможностью:

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

В частности, со ссылкой на этап 304 на фиг. 3, оконечное устройство выполняет синтаксический разбор тега на HTML-странице; после обнаружения указания управления QoS на HTML-странице, оконечное устройство вызывает плагин браузера, установленного на оконечном устройстве. Плагин браузера отправляет сообщение с запросом QoS в функциональный узел управления QoS оператора сети или инициировать запрос QoS интерфейс прикладного программирования (API), где сообщение с запросом QoS или запрос QoS API может быть передан в HTTPS для обеспечения безопасности.

Возможно, блок 701 разбора специально выполнен с возможностью:

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

В частности, со ссылкой на этап 203 на фиг. 2, оконечное устройство осуществляет синтетический разбор Java-скрипт на HTML-странице; после обнаружения указания управления QoS на HTML-странице, оконечное устройство непосредственно инициирует запрос QoS API из универсальной открытой платформы возможностей для запроса текущей задержки передачи по сети. Универсальная открытая платформа возможностей может быть связана с оконечным устройством. Например, браузер IE Microsoft может вызвать запрос QoS API из открытой платформы возможностей Microsoft, и chrome браузер Google может вызывать запрос QoS API из открытой платформы возможностей Google. Открытая платформа возможностей может быть не связана с браузером и предоставлена третьей стороной, и любой браузер может вызывать запрос QoS API из открытой платформы возможностей. Независимо от того, связана ли открытая платформа возможностей с оконечным устройством, при вызове запроса QoS API из открытой платформы возможностей, оконечное устройство не должно взаимодействовать с оператором сети, к которой принадлежит пользователь.

Блок 703 представления выполнен с возможностью осуществлять обработку в соответствии с результатом запроса, возвращаемого функциональным узлом управления QoS.

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

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

приглашение пользователя отправить запрос на управление QoS включает в себя следующее:

отображение оконного приглашения, или информация приглашения добавляется в существующее окно.

В частности, со ссылкой на этап 207 на фиг. 2, когда задержка передачи превышает 100 мс, и запрос на интернет-игру не выполняется; таким образом, должно быть применено улучшение QoS API в соответствии с определяющей логикой скрипта. В связи с тем, что могут потребоваться больше ресурсов беспроводной связи, которые зарезервированы для улучшения QoS API, сетевой оператор взимает плату за пользование этого API. Информация приглашения может отображаться для пользователя, прежде чем браузер вызывает API, и браузер вызывает улучшение QoS API только после того, как пользователь делает подтверждение. Конкретные способы приглашения пользователя включают в себя отображение оконного приглашения или информация приглашения добавляется в существующее окно.

Кроме того, оконечное устройство может конфигурировать управление QoS APIs для приглашаемых пользователей. Например, для запроса QoS API пользователь не должен быть приглашен; или оконечное устройство может также непосредственно вызывать улучшение QoS API из открытой платформы возможностей. После обнаружения того, что требуется оплатить за улучшение QoS, открытая платформа универсальных возможностей может направить команду управления в ответном сообщении на улучшение QoS API, в браузер пригласить пользователя, и запрашивает улучшение QoS API снова после того, как пользователь делает подтверждение.

Этот вариант осуществления настоящего изобретения описывает оконечное устройство. Оконечное устройство осуществляет синтаксический разбор указания управления QoS, которое вставляется сервером приложений в HTML страницу, и запрашивает управление QoS из функционального узла управления QoS оператора. Таким образом, для возможности управления QoS, взаимодействие между сервером приложений и сетевым оператором изменяется на взаимодействие между оконечным устройством и оператором сети, и взаимодействие между сервером приложений и соответствующим функциональным узлом управления QoS оператора сети не требуется, тем самым, упрощая обработку сервером приложений. Кроме того, функциональный узел управления QoS оператора сети должен взаимодействовать только с плагином браузера, установленного в оконечном устройстве оператором сети или с универсальной открытой платформы возможностей, и взаимодействие с различными серверами приложений не осуществляется, тем самым, упрощая реализацию функционального узла управления QoS, и решает техническую задачу открытой фрагментации возможностей.

Вариант 5 осуществления

Обращаясь к фиг. 8, фиг. 8 представляет собой блок-схему сервера приложений согласно варианту 5 осуществления настоящего изобретения. Ссылаясь на фиг. 8, фиг. 8 показывает сервер 800 приложений в соответствии с этим вариантом осуществления настоящего изобретения. Конкретный вариант реализации сервера приложений не ограничивается в конкретном варианте осуществления настоящего изобретения. Сервер 800 приложений включает в себя:

процессор (процессор) 801, интерфейс 802 связи (интерфейс связи), память (память) 803 и шину 804.

Процессор 801, интерфейс 802 связи и память 803 взаимодействуют друг с другом с помощью шины 804.

Интерфейс 802 связи выполнен с возможностью устанавливать связь с оконечным устройством.

Процессор 801 выполнен с возможностью реализовать программу.

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

Процессор 801 может представлять собой центральный процессор CPU, специализированную интегральную схему ASIC (специализированная интегральная схема) или одну или более интегральную схему, выполненную с возможностью осуществлять этот вариант осуществления настоящего изобретения.

Память 803 выполнена с возможностью хранить программу. Память 803 может включать в себя высокоскоростную оперативную память RAM, и также может включать в себя энергонезависимую память (энергонезависимая память). Программа может быть специально выполнена с возможностью:

вставлять указание управления качеством обслуживания QoS в HTML-страницу гипертекстового языка описания документов; и

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

Указание управления QoS является java-скриптом, вновь определяемым HTML-тегом или HTML-тегом вновь добавленного атрибута.

Программа вставляет указание управления QoS в HTML страницу, где указание управления QoS является java-скриптом, а именно:

вставку сервером приложений java-скрипта в HTML страницу, где java-скрипт запрашивает оконечное устройство инициировать запрос QoS API, и если задержка, указанная возвращаемым значением запроса QoS API, больше, чем заданное временное значение, оконечное устройство инициирует запрос API QoS о том, что задержка передачи меньше, чем заданное значение задержки.

Когда указание управления QoS является вновь определенным HTML тегом:

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

Когда указание управления QoS является HTML-тегом вновь добавленного атрибута, а именно:

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

Программа дополнительно включает в себя:

вставку сертификата сервера приложений в HTML-страницу; когда принятый запрос HTML-страницы оконечного устройства имеет сертификат сервера приложений, определение с помощью сертификата сервера приложений, что управление QoS инициирует приложение и выставляет счет за использование приложения.

Вариант 6 осуществления

Обращаясь к фиг. 9, фиг. 9 представляет собой блок-схему оконечного устройства в соответствии с вариантом 6 осуществления настоящего изобретения. Ссылаясь на фиг. 9, фиг. 9 показывает оконечное устройство 900 согласно этому варианту осуществления настоящего изобретения. Конкретный вариант реализации оконечного устройства не ограничивается в конкретном варианте осуществления настоящего изобретения. Оконечное устройство 900 включает в себя:

процессор (процессор) 901, интерфейс 902 связи (интерфейс связи), память (память) 903 И шину 904.

Процессор 901, интерфейс 902 связи и память 903 взаимодействует друг с другом с помощью шины 904.

Интерфейс 902 связи выполнен с возможностью устанавливать связь с сервером приложений.

Процессор 901 выполнен с возможностью реализовать программу.

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

Процессор 901 может представлять собой центральный процессор CPU, специализированную интегральную схему ASIC (специализированная интегральная схема) или одну или более интегральную схему, выполненную с возможностью осуществлять этот вариант осуществления настоящего изобретения.

Память 903 выполнена с возможностью хранить программу. Память 903 может включать в себя высокоскоростную оперативную память RAM, и также может включать в себя энергонезависимую память (энергонезависимая память). Программа может быть специально выполнена с возможностью:

осуществлять синтаксический разбор указания управления QoS на HTML-странице, и направлять запрос управления QoS в функциональный узел управления QoS оператора; и

выполнять обработку в соответствии с результатом запроса, возвращаемого функциональным узлом управления QoS.

Программа может быть специально выполнена с возможностью осуществлять синтаксический разбор указания управления QoS на HTML-странице, и направляет запрос управления QoS в функциональный узел управления QoS оператора, что включает в себя:

осуществление синтаксического разбора указания управления QoS на HTML-странице, и запрос управления QoS функционального узла управления QoS оператора, используя плагин браузера, где плагин браузера обеспечивается оператором, к которому принадлежит оконечное устройство.

Программа может быть специально выполнена с возможностью осуществлять синтаксический разбор указания управления QoS на HTML-странице, и направляет запрос управления QoS в функциональный узел управления QoS оператора, что включает в себя:

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

Способ дополнительно включает в себя:

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

приглашение пользователя отправить запрос управления QoS включает в себя следующее:

отображается оконное приглашение или информация приглашения добавляется в существующее окно.

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

Изобретение относится к области управления качеством обслуживания. Техническим результатом является в упрощении системы предоставления услуг при дополнительной тарификации каналов беспроводной связи выделяемых для улучшения качества обслуживания. Для этого принимают с помощью сервера приложений запрос HTML-страницы от оконечного устройства, вставляют указание управления качеством обслуживания QoS в страницу гипертекстового языка описания документов (HTML) и возвращают HTML-страницу, включающую в себя указание управления качеством обслуживания QoS, на оконечное устройство так, что оконечное устройство выполнено с возможностью запроса управления QoS из функционального узла управления QoS оператора в соответствии с указанием управления QoS на HTML-странице, в котором управление QoS содержит запрос статуса QoS и/или улучшение QoS. При этом осуществляют вставку с помощью сервера приложений сертификата сервера приложений в HTML-страницу и передают с помощью оконечного устройства сертификат сервера приложений в функциональный узел управления QoS оператора; и определяют с помощью функционального узла управления QoS с использованием сертификата сервера приложений, что управление QoS инициируется приложением и тарификацией приложения. 2 н. и 2 з.п. ф-лы, 9 ил.

1. Способ управления качеством обслуживания, содержащий этапы, на которых:

принимают с помощью сервера приложений запрос HTML-страницы от оконечного устройства;

вставляют указание управления качеством обслуживания QoS в страницу гипертекстового языка описания документов (HTML) и

возвращают HTML-страницу, включающую в себя указание управления качеством обслуживания QoS, на оконечное устройство так, что оконечное устройство выполнено с возможностью запроса управления QoS из функционального узла управления QoS оператора в соответствии с указанием управления QoS на HTML-странице, в котором управление QoS содержит запрос статуса QoS и/или улучшение QoS;

осуществляют вставку с помощью сервера приложений сертификата сервера приложений в HTML-страницу;

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

2. Способ по п. 1, в котором указание управления QoS представляет собой java-скрипт, вновь определенный HTML-тег или HTML-тег вновь добавленного атрибута.

3. Сервер приложений, содержащий:

блок вставки, выполненный с возможностью вставки указания управления качеством обслуживания QoS в страницу гипертекстового языка описания документов HTML;

блок приема, выполненный с возможностью приема запроса на HTML-страницу от оконечного устройства и возврата HTML-страницы, включающей в себя указание управления качеством обслуживания QoS, на оконечное устройство, так что оконечное устройство выполнено с возможностью запроса управления QoS от функционального узла управления QoS оператора согласно указанию управления QoS на HTML-странице, при этом управление QoS содержит запрос статуса QoS и/или улучшения QoS, и

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

4. Сервер приложений по п. 3, в котором указание управления QoS является java-скриптом, вновь определенным HTML-тегом или HTML-тегом вновь добавленного атрибута.