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

Авторы патента:


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

 


Владельцы патента RU 2634917:

ХУАВЕЙ ТЕКНОЛОДЖИЗ КО., ЛТД. (CN)

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

 

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

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

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

Мобильный оконечное устройство сначала передает 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 включает в себя следующее:

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

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

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-тегом вновь добавленного атрибута.



 

Похожие патенты:

Изобретение относится к области радиосвязи. Техническим результатом является управление перегрузкой сети в секции радиосвязи.

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

Изобретение относится к беспроводной связи. Технический результат заключается в обеспечении усиления при кодировании посредством HARQ (гибридный автоматический запрос повторной передачи) для все DL (нисходящая линия связи) HARQ-процессов, когда UL-DL конфигурация отличается для множества компонентных несущих.

Изобретение относится к беспроводной связи. Техническим результатом является освобождение ресурсов сети сотовой связи для других UE.

Изобретение относится к системе мобильной связи, в которой терминал может быть одновременно подключен к множеству служебных сетей. Техническим результатом является эффективное и легкое выполнение переключения туннелей GTP (протокол туннелирования GPRS), связанного с перемещением терминала в системе мобильной связи.

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

Изобретение относится к мобильной связи. При передаче обслуживания между сотами eNB источник определяет, согласно RSRP восходящей линии связи UE в обслуживающей соте и целевой соте, передать ли обслуживание UE из обслуживающей соты в целевую соту; и если результат является положительным, получает параметры UE, включая ТА UE в целевой соте, и передает данные UE и параметры UE к целевому eNB, где ТА используется для синхронизации восходящей линии связи между целевым eNB и UE.

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

Изобретение относится к беспроводной связи. Способ передачи отчета обратной связи по информации состояния канала (CSI) на обслуживающую соту содержит конфигурирование процесса апериодической CSI опорным ресурсом CSI, заданным единичным подкадром нисходящей линии связи n-nCQI_ref, где nCQI_ref – задается на основании субкадра нисходящей линии связи, связанного с форматом DCI восходящей линии связи.

Изобретение относится к способам связи, выполняемым в пользовательском оборудовании (UE) и в узле радиосвязи. Технический результат заключается в обеспечении возможности для UE применять цикл прерывистого режима (DRX) в течение периода времени, когда UE переходит из ждущего режима в присоединенный.

Изобретение относится к области связи. Технический результат заключается в возможности устранять перегрузку на центральной частоте ресурсов передачи данных, в которых устройства передачи данных с минимальными возможностями по полосе пропускания должны принимать ресурсы передачи данных для приема сигналов нисходящего канала передачи. Сеть мобильной передачи данных включает в себя один или больше сетевых элементов, предоставляющих интерфейс беспроводного доступа для устройства передачи данных. Интерфейс беспроводного доступа предоставляет множество элементов ресурса передачи данных в пределах полосы частот хост-устройства, и включает в себя, в пределах полосы частот хост-устройства, первый блок элементов ресурса передачи данных в пределах первой полосы частот для выделения, предпочтительно, для устройств с пониженными возможностями, для приема сигналов, представляющих данные, переданные модулем передатчика в пределах первой полосы пропускания, формирующей первую виртуальную несущую, каждое устройство с пониженными возможностями имеет полосу пропускания приемника, которая больше чем или равна первой полосе частот, но меньше, чем полоса частот хост-устройства. Устройство передачи данных выполнено с возможностью передавать в сеть мобильной передачи данных относительную возможность устройства передачи данных для приема данных через интерфейс беспроводного доступа, относительная возможность, содержащая, по меньшей мере, показатель относительной полосы пропускания модуля приемника для приема сигналов в пределах диапазона частот хост-устройства, большего чем или равного первой полосе пропускания, и принимать выделение элементов ресурса передачи данных, которые включают в себя элементы ресурса передачи данных, которые находятся за пределами первой виртуальной несущей, но в пределах полосы пропускания устройства передачи данных, в ответ на показатель относительной возможности устройства передачи данных. 2 н. и 16 з.п. ф-лы, 16 ил.

Изобретение относится к беспроводной связи. Оконечное устройство (106) с функциональными возможностями промежуточного узла соединено с базовой станцией (101) системы (100) беспроводной связи. Функциональные возможности промежуточного узла обеспечивают возможность направления передаваемых данных, принимаемых от базовой станции (101), на дополнительное оконечное устройство (107) и направления передаваемых данных, принимаемых от дополнительного оконечного устройства (107), на базовую станцию (101). Технический результат заключается в обеспечении динамического увеличения покрытия радиосоты системы беспроводной связи. 4 н. и 8 з.п. ф-лы, 7 ил.

Изобретение относится к технике связи и может использоваться для контроля качества канала линии радиосвязи между вторичным развитым узлом В (SeNB) и устройством пользователя (UE) в сети беспроводной связи. Технический результат состоит в повышении эффективности управления системой. Для этого устройство сконфигурировано для двойного подключения. В вариантах осуществления настоящего изобретения UE может генерировать одно или более указаний качества канала линии радиосвязи SeNB-UE и направлять указание на SeNB. На основании указания UE может принимать сообщение управления радиоресурсами (RRC) от главного eNB (MeNB), относящегося к линии радиосвязи SeNB-UE. 3 н. и 19 з.п. ф-лы, 6 ил.

Изобретение относится к определению параметра нисходящей линии. Технический результат – повышение спектральной эффективности передач нисходящей линии. Для этого предусмотрено: прием информации о категории и информации о модуляции, сообщаемой терминалом UE, где информация о категории содержит указание категории терминала UE, а информация о модуляции содержит указание схемы модуляции наивысшего порядка, поддерживаемого терминалом UE; и определение, в качестве параметра нисходящей линии для терминала UE, параметра нисходящей линии, соответствующего категории терминала UE и схеме модуляции наивысшего порядка, поддерживаемого терминалом UE, где параметр нисходящей линии для терминала UE определяют согласно соответствию между категорией терминала UE и схемой модуляции наивысшего порядка, поддерживаемого этим терминалом UE, с одной стороны, и параметром нисходящей линии для этого терминала UE, с другой стороны, равно как и согласно категории терминала UE и схеме модуляции наивысшего порядка, поддерживаемого терминалом UE. Согласно чему модуляционные возможности терминала UE могут быть полностью использованы в процессе связи в нисходящей линии. 4 н. и 11 з.п. ф-лы, 12 ил., 24 табл.

Изобретение относится к устройству беспроводной связи, монтируемому на мобильном объекте. Технический результат изобретения заключается в предотвращении использования устройства беспроводной связи вне мобильного объекта (автомобиля). Устройство беспроводной связи, монтируемое на мобильном объекте, при этом мобильный объект включает в себя: блок мобильной связи, который способен подключаться к мобильной сети связи; и блок подключения к беспроводной сети, который предоставляет услугу подключения к беспроводной сети на основе сети мобильной связи, подключенный посредством блока мобильной связи. Устройство беспроводной связи включает в себя: блок спутникового позиционирования на устройстве беспроводной связи, конфигурируемый для получения информации о местоположении на основе системы спутникового позиционирования; и блок управления, конфигурируемый для управления характеристиками подключения услуги подключения к беспроводной сети на основе информации о местоположении, полученной блоком спутникового позиционирования. 5 н. и 15 з.п. ф-лы, 9 ил.

Изобретение относится к способам и устройствам для передачи и приема сообщений обнаружения и персонального вызова. Технический результат заключается в сокращении потребления электроэнергии при вводе устройства связи в среду связи. Способ беспроводной связи, выполняемый устройством связи, содержит: прием индикации первого момента начала для первого интервала обнаружения из множества интервалов обнаружения, первой продолжительности для первого интервала обнаружения, второго момента начала для первого интервала персонального вызова из множества интервалов персонального вызова и второй продолжительности для первого интервала персонального вызова; передачу пакета обнаружения в течение первого интервала обнаружения из множества интервалов обнаружения, при этом пакет обнаружения афиширует услугу, обеспеченную в сети беспроводной связи, а множество интервалов обнаружения содержит повторяющиеся временные интервалы, когда множество устройств связи выполнено с возможностью передавать и принимать пакеты обнаружения, при этом множество устройств связи знает о первом моменте начала и первой продолжительности; и прием пакета персонального вызова от первого устройства связи в течение первого интервала персонального вызова из множества интервалов персонального вызова, при этом пакет персонального вызова показывает интерес к услуге, множество интервалов персонального вызова содержит повторяющиеся временные интервалы, когда множество устройств связи выполнено с возможностью передавать и принимать пакеты персонального вызова, при этом множество устройств связи знает о втором моменте начала и второй продолжительности, множество интервалов персонального вызова не перекрывается с множеством интервалов обнаружения. 8 н. и 58 з.п. ф-лы, 30 ил.

Изобретение относится к мобильной связи. Способ предоставления отчета измерения терминала, при котором установлена первичная ячейка, содержит: этап для добавления вторичной ячейки; этап для выявления, применима ли вторичная ячейка к связанному измерению; и этап выявления, включена ли вторичная ячейка в cellsTriggeredList, при этом когда вторичная ячейка не применима к связанному измерению и вторичная ячейка включена в cellsTriggeredList, то вторичная ячейка удаляется из cellsTriggeredList. Технический результат заключается в исключении ненужной передачи отчета об измерении, что экономит потребление энегрии батареи терминала. 2 н. и 10 з.п. ф-лы, 17 ил., 5 табл.

Изобретение относится к области связи. Технический результат заключается в сообщении пользовательскому оборудованию сконфигурированной максимальной выходной мощности, которой обслуживающая сота соответствует, даже если имеется неадаптивная повторная передача по восходящей линии связи в обслуживающей соте, или базовая станция планирует только информацию о состоянии канала, таким образом, решая проблему, существующую в предшествующем уровне техники. Способ включает в себя этапы, на которых: оценивают последовательно, посредством пользовательского оборудования, имеется ли неадаптивная повторная передача данных восходящей линии связи в каждой из обслуживающих сот, или оценивают, планирует ли базовая станция только информацию о состоянии канала в каждой из обслуживающих сот и не выделяет грант восходящей линии связи для передачи данных совместно используемого канала восходящей линии связи, когда пользовательское оборудование инициирует сообщение о запасе мощности в текущем подкадре, причем базовая станция выделяет грант восходящей линии связи пользовательскому оборудованию для передачи новых данных по совместно используемому каналу восходящей линии связи, и причем грант восходящей линии связи выполнен с возможностью содержать сообщение о запасе мощности; получают, если результат оценки положителен, посредством пользовательского оборудования, сконфигурированную максимальную выходную мощность, соответствующую обслуживающей соте; и сообщают полученную сконфигурированную максимальную выходную мощность базовой станции. 4 н. и 6 з.п. ф-лы, 8 ил.

Изобретение относится к беспроводной связи. Для недопущения слежения при перемещении по сети точек беспроводного доступа (WAP) устройство беспроводной связи меняет МАС-адрес. Устройство рандомизирует некоторые или все разряды в МАС-адресе или выбирает МАС-адрес из группы МАС-адресов, назначенных устройству производителем устройства. Устройство может использовать МАС-адреса совместно с другими устройствами и проводить проверку, чтобы, прежде чем выбрать и использовать МАС-адрес, удостовериться, что отсутствует активное совместное использование МАС-адреса. Технический результат заключается в повышении степени анонимности пользователя в сети. 3 н. и 12 з.п. ф-лы, 7 ил.

Изобретение относится к области связи. Техническим результатом является гарантия того, что устройство базовой станции эффективно принимает результат измерения апериодического состояния канала, который посылается пользовательским оборудованием, для набора подкадров нисходящей линии связи. Раскрыты устройство базовой станции, пользовательское оборудование и способ для передачи отчета информации о состоянии канала. Устройство базовой станции содержит: приемный блок, сконфигурированный для приема по меньшей мере одной порции апериодической информации о состоянии канала, CSI, посланной пользовательским оборудованием, где по меньшей мере одна порция апериодической CSI соответствует результату измерения апериодической CSI в первом опорном подкадре, где результат измерения апериодической CSI в первом опорном подкадре является результатом измерения апериодической CSI для первого набора подкадров нисходящей линии связи и первый опорный подкадр является подкадром в первом наборе подкадров нисходящей линии связи. Дополнительно раскрыты соответствующее пользовательское оборудование и соответствующий способ передачи отчета информации о состоянии канала. 4 н. и 4 з.п. ф-лы, 1 табл., 20 ил.
Наверх