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

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

Иллюстрации

Показать все

Реферат

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

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

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

Мобильный оконечное устройство сначала передает 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 требует дополнительной оплаты, открытая платформа универсальных возможностей