Установка политики маршрутизации на основе приложений в многорежимном оконечном устройстве

Установка политики маршрутизации на основе приложений в многорежимном оконечном устройстве

Иллюстрации

Показать все

Реферат

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

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

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

В сетях радиосвязи, обслуживаемых провайдерами, таких как сети связи, работающие в соответствии с разработанными группой 3GPP (проект партнерства 3-го поколения) стандартами «Долговременная эволюция/Усовершенствованная долговременная эволюция» (Long Term Evolution/Long Term Evolution-Advanced (LTE/LTE-A)), применяются механизмы для помощи в обнаружении (раскрытии) и управлении политикой сети связи. В сетях связи согласно стандартам LTE/LTE-A один из таких способов содержит использование правил и политики функции поиска сети доступа (Access Network Discover Function (ANDSF)) в развитом ядре пакетной сети (evolved packet core (ЕРС)) архитектуры системы согласно стандартам LTE/LTE-A. Например, правила и политика функции ANDSF могут быть определены для абонентского оконечного устройства (UE), имеющего несколько режимов работы, с целью поиска и обнаружения сетей доступа, не соответствующих стандартам группы 3GPP, для помощи UE, имеющим несколько режимов работы, в установлении соединения с локальной сетью радиосвязи (wireless local area network (WLAN)) согласно стандарту Wi-Fi (например, сетью связи, работающей в соответствии со стандартом IEEE 802.11) или с глобальной сетью радиосвязи согласно стандарту WiMax (например, сетью связи, работающей в соответствии со стандартом IEEE 802.16)). Однако существующие политики не рассматривают требования, специфичные для приложений, или возможности, специфичные для устройств.

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

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

Фиг. 2 иллюстрирует операции с данными с использованием абонентского устройства со смешанным режимом работы согласно описываемому далее примеру.

Фиг. 3 иллюстрирует объект управления функции ANDSF, содержащий подобъект конфигурации профиля абонента, согласно описываемому далее примеру.

Фиг. 4А иллюстрирует узел политики ISRP на потоковой основе в составе объекта управления функции ANDSF, имеющий определенную для приложения конфигурацию, согласно описываемому далее примеру.

Фиг. 4В иллюстрирует узел политики ISRP на основе небесшовной выгрузки в составе объекта управления функции ANDSF, имеющий определенную для приложения конфигурацию, согласно описываемому далее примеру.

Фиг. 5 иллюстрирует профиль абонента в составе объекта управления функции ANDSF согласно описываемому далее примеру.

Фиг. 6 иллюстрирует логическую схему примера способа для установления и применения идентифицирующей приложение политики функции ANDSF согласно описываемому далее примеру.

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

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

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

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

Разнообразные способы и конфигурации, предложенные здесь, позволяют создать и эксплуатировать политику на основе функции ANDSF (функция поиска и выбора сети доступа), которая может быть применена при решении конкретных задач по реализации устройств/сетей связи и в случае выгрузки трафика. Информация, используемая в политике на основе функции ANDSF (далее ANDSF-политика), может содержать конфигурации, определенные для приложений и для устройства, включая тип устройства, версию аппаратуры, тип и версию операционной системы, тип и версию прикладного программного обеспечения и другие подробности конфигурации UE. Эти подробности конфигурации устройства LIE могут быть использованы для установления и применения конкретной политики межсистемной маршрутизации (inter-system routing policy (ISRP)) для управления маршрутизацией трафика и мобильностью для приложений, инсталлированных в устройстве.

В рамках конфигурации системы согласно стандартам LTE/LTE-A сервер функции ANDSF (далее ANDSF-сервер) может предоставить: политику межсистемной мобильности, используемую в качестве помощи при принятии решений о переключении связи; политику ISRP для маршрутизации трафика по Интернет-протоколу (далее IP-трафика) через множество интерфейсов радио доступа одновременно; и поисковую информацию для идентификации сетей доступа, которые не соответствуют стандартам группы 3GPP (далее не-3GPP-сети) и которые могут быть доступны поблизости от UE, с целью помочь UE установить соединение с такими сетями. Несколько разных политик могут быть заданы в качестве части политики ISRP для способов выгрузки IP-потоков в системе мобильной связи (IP Flow Mobility).

В качестве примера маршрутизации трафика и мобильности некоторые приложения, способные осуществлять связь через множество интерфейсов сетей радиосвязи в аппаратуре с множеством режимов работы (такими как сеть WLAN или сеть сотовой связи), могут выбрать маршрутизацию всего трафика через один интерфейс (WLAN), а не через другой. Разные ANDSF-политики находятся под управлением оператора основной сети передачи данных и предназначены для соответствия таким сценариям с управлением выгрузкой трафика из сети на основе правил. Такие механизмы на основе функции ANDSF (далее ANDSF-механизмы) могут быть использованы для предоставления UE политик и информации о политиках от имени операторов по самым разнообразным причинам и в разнообразных ситуациях, таких как управление выгрузкой и доступом в сеть в какие-то определенные периоды суток, в каких-то определенных областях и для каких-то конкретных потоков данных.

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

В одном из примеров предложены различные поля идентификации данных для использования с объектом управления (МО) ANDSF-политики, включая добавление различных идентификаторов приложений на ANDSF-сервере, чтобы позволить политике ISRP поддерживать идентификацию трафика на основе идентификаторов приложений. Современные обновления политики ISRP позволяют увеличить степень использования идентификатора приложения в качестве идентификатора IP-трафика. Информация, используемая для определения подходящего идентификатора приложения, содержит не только указание конкретной версии приложения или конфигурации приложения, но и соответствующие поля, указывающие версию UE, конфигурацию платформы и аппаратуры этого UE, операционную систему UE и другие подобные характеристики. Описываемые здесь конфигурации данных и механизмы обмена данными позволяют передавать подробные идентификаторы приложений и связанные с ними политики и процедуры работы с данными.

Фиг. 1 представляет иллюстрацию примера конфигурации архитектуры 100 сети связи со смешанным режимом работы. В рамках сетевой архитектуры 100 система 102 основной сети передачи данных (например, развитый Узел В (evolved NodeB (eNodeB)), организующий сеть сотовой связи), осуществляющая связь с мобильными устройствами (UE) 104А, 104В, имеющими множество режимов работы, создает основную сеть передачи данных (например, сеть сотовой связи LTE/LTE-A, работающую в соответствии с одним из стандартов семейства стандартов, разработанных группой 3GPP). Система 106 локальной сети связи (например, сети WiFi, работающей в соответствии с одним из стандартов из семейства стандартов IEEE 802.11) может быть создана посредством аппаратуры локальной сети связи, содержащей маршрутизатор или точку доступа WiFi. Основная сеть передачи данных содержит сетевые соединения 108А, 108В с мобильными устройствами 104А, 104В, соответственно, а локальная сеть связи содержит сетевые соединения 110А, 110В с этими мобильными устройствами 104А, 104В, соответственно. Мобильные устройства 104А, 104В изображены в соответствии с различными форм-факторами, включая смартфон (мобильное устройство 104А) и персональный компьютер (мобильное устройство 104В), имеющие встроенное или внешнее устройство радиосвязи, хотя должно быть понятно, что здесь можно использовать одинаковые или разные форм-факторы.

Сетевые соединения 108А, 108В, 110А, 110В радиосвязи с различными мобильными устройствами 104А, 104В могут быть осуществлены с использованием системы 102 основной сети передачи данных или системы 106 локальной сети связи в сочетании с применением разнообразных политик выгрузки и предпочтений. Эти политики выгрузки и предпочтения могут быть сообщены с использование одной или более ANDSF-политик 120, передаваемых от ANDSF-сервера 114 через систему 102 основной сети передачи данных (и сетевые соединения 108А, 108B).

Указанный ANDSF-сервер 114 может располагаться в сети 112 провайдера услуг связи в основной сети передачи данных. Сеть 112 провайдера может содержать различные компоненты развитого ядра пакетной сети (ЕРС) и другие компоненты сети LTE/LTE-A группы 3GPP, включая различные сервисы 118 и шлюз P-GW (шлюз сети передачи пакетов данных (Packet Data Network (PDN) Gateway)) 116. Трафик данных, выгруженный в сетевую систему 106 на основе локальной сети связи, может быть передан назад в сеть 112 провайдера через соединение со шлюзом P-GW 116. Таким образом, сообщения сети радиосвязи, выгруженные в другую сетевую архитектуру (соединения 110А, 110В с сетью радиосвязи) могут быть использованы для доступа к функциональным возможностям сети 112 провайдера.

Фиг. 2 представляет иллюстрацию примера операций 200 с данными с использованием абонентского оконечного устройства, имеющего смешанный режим работы, (мобильное устройство 104С), осуществляемых в соединении с архитектурой 100 сети связи со смешанным режимом работы, показанной на фиг. 1. Как показано на фиг. 2, мобильное устройство 104С конфигурировано для осуществления передачи данных 206 сети связи согласно стандарту 3GPP от системы 102 основной сети передачи данных во внешнюю сеть 122 связи (такую как Интернет); а также мобильное устройство 104С конфигурировано для передачи данных 208 не-3GPP-сети связи от системы 106 локальной сети связи во внешнюю сеть 122 связи.

Показано, что мобильное устройство 104С обменивается данными с использованием первого программного приложения "Арр 1" для данных 206 3GPP-сети и с использованием второго приложения "Арр 2" для данных 208 не-3GPP-сети. Передача данных от различных программных приложений в соответствующую сеть осуществляется в соединении с политикой ISRP 204, включая одну или более политик 204А приложений, поступающих от ANDSF-сервера 114. Мобильное устройство 104С конфигурировано для реализации политики ISRP 204 с целью определения мобильных приложений с IP-потоками на основе идентификаторов приложений (таких как индикация Арр 1 или Арр 2).

Конкретные идентификаторы приложений и группу прикладных политик 204А в рамках политики ISRP 204 сообщают мобильному устройству 104С в составе объекта управления ANDSF МО от ANDSF-сервера, а устройство принимает эту информацию через невыгруженную сеть связи (например, сеть 3GPP LTE/LTE-A). Объект ANDSF МО может быть структурирован в формате расширяемого языка разметки (extensible Markup Language (XML)) и может быть запрошен от или передан мобильному устройству 104С. Для определения подходящих прикладных политик с целью применения в рамках политики ISRP 204 ANDSF-серверу 114 может быть передана информация о UE и соответствующих приложениях. В одном из примеров ANDSF-серверу 114 также в составе объекта ANDSF МО сообщают профиль 202 UE, содержащий подходящую информацию 202А о UE и приложениях.

Применение прикладных политик 204А в составе применяемой политики ISRP 204 может направлено на решение вопросов использования сети связи для приложения UE. Такие прикладные политики 204А могут быть определены для самых разнообразных случаев и сценариев использования сети связи и могут содержать правила для осуществления конкретного доступа или группы обращений и доступов от идентифицированного приложения в выбранную сеть связи или к сетям связи выбранного типа. Например, рассмотрим воспроизведение программы видеокодеком в рамках приложения воспроизведения мультимедиа. В некоторых вариантах UE может воспроизводить видео низкого качества, которое имеет предпочтение для скачивания из сети доступа согласно стандарту 3GPP. Если нужно высококачественное воспроизведение в формате высокой четкости или с повышенным разрешением, может быть задано предпочтение, чтобы приложение использовало сеть Wi-Fi или другую вторичную сеть радиосвязи. Прикладные политики 204А могут быть использованы для однозначной идентификации приложения и ассоциирования этого приложения с правилами типа доступа на основе требований и предпочтений основной сети передачи данных.

Фиг, 3 показывает иллюстрацию 300 примера форматированного структурированного узлового объекта ANDSF МО 302, имеющего ряд структурированных подобъектов, включая подобъект конфигурации профиля абонента. Структурированные подобъекты в составе структурированного узлового объекта 302 могут быть определены для соответствия конкретным спецификациям (например, спецификациям 3GPP LTE/LTE-А) и могут содержать: подобъект 304 узла политики, определяющий дерево 304А узла политики; подобъект 306 узла поисковой информации (DiscoveryInformation), определяющий дерево 306А узла поисковой информации 306А; подобъект 308 узла местонахождения оконечного устройства (UE_Location), определяющий дерево 308А узла местонахождения абонентского оконечного устройства; подобъект 310 узла политики ISRP, определяющий дерево 310А узла политики ISRP; подобъект 312 узла профиля оконечного устройства (UE_Profile) определяющий дерево 312А узла профиля UE (дополнительно показано на фиг. 5); и подобъект 314 внешнего узла (Ext), предоставляющий потенциальное определение для информации, определенной для поставщика.

Модификация объекта ANDSF МО с целью задания и применения политик маршрутизации на основе приложений может быть проведена в связи с двумя аспектами: во-первых, определением в дереве 312А узла профиля оконечного устройства (UE_Profile), содержащем конфигурацию аппаратуры конкретного UE, информации об операционной системе и версии операционной системы, а также другой операционной информации UE; и, во-вторых, определением «листка» (вторичной «ветки» дерева) идентификатора приложения (Applicationld) для применения в дереве 31 OA узла политики ISRP, как это будет далее описано здесь (и проиллюстрировано в узловых деревьях 400, 450 на фиг. 4А и 4В, соответственно).

Определение в дереве 312А узла профиля оконечного устройства (UE_Profile) может быть использовано для сообщения общей операционной информации UE и приложений через объект ANDSF МО, как это иллюстрирует профиль 202 UE, показанный на фиг. 2. Узел, задающий идентификатор Applicationld для конкретных политик приложения, используется в объекте ANDSF МО, применяемом в политике ISRP для обоих - потокового механизма и небесшовного механизма выгрузки данных в сеть связи WLAN.

Фиг. 4А и 4В представляют примеры иллюстраций структур узла политики ISRP для объекта управления функции ANDSF для потокового дерева 400 узла политики и для дерева 450 узла политики с небесшовной выгрузкой, соответственно. Группа правил политики ISRP может содержать один или несколько контейнеров распределения потоков, включая узел 402 ForFlowBased для сервиса мобильности на уровне IP-потоков и бесшовной выгрузки (IP Flow Mobility and Seamless Offload (IFOM)), как показано на фиг. 4А, и узел 452 ForNonSeamiessOffload для сервиса небесшовной выгрузки (Non-seamless Offload), как показано на фиг. 4В.

Ветви узла политики ISRP задают механизм идентификации трафика, генерируемого конкретным приложением. Контейнер распределения потоков может иметь одно или несколько правил распределения потоков. В узле ForFlowBased 402 для сервиса IFOM, как показано на фиг. 4А, совокупность этих правил распределения содержит правила распределения трафика для UE в соединении с механизмом IFOM выгрузки. В узле ForNonSeamiessOffload 452 для небесшовной выгрузки, как показано на фиг. 4В, совокупность этих правил распределения содержит правила распределения трафика для UE в соединении с механизмом небесшовной выгрузки.

В одном из примеров узлы политики ISRP определены для использования под узлом ForFlowBased 402, в сочетании с определениями для узла 404 идентификатора приложения (App-ID), узла 406 платформы (Platform), узла 408 приложений платформы (PlatformApps) и узла 410 специфичного для платформы идентификатора приложения (Platform_specificAppID). Определения для этих узлов могут быть даны следующим образом:

Этот внутренний узел действует как заполнитель для механизма идентификации потока IPFlow через идентификатор приложения. Отсутствие этого узла может быть использовано для индикации, что идентификатор приложения не исследуется при сопоставлении пакетов с описанием IP-потока согласно рассматриваемому правилу.

- Проявление: ZeroOrOne

- Формат: узел

- Типы доступа: Get, Replace

Этот внутренний узел действует как заполнитель для одной или нескольких конфигураций платформы, поддерживаемых UE, на основе информации, содержащейся в узле UE_Profile.

- Проявление: OneOrMore

- Формат: узел

- Типы доступа: Get, Replace

Листок Платформа (Platform) обозначает платформу, ассоциированную с идентификатором приложения, содержащимся в соответствующем листке Platformspecific AppID.

- Проявление: One

- Формат: chr

- Типы доступа: Get, Replace

- Значения: <Platform>

Значение идентификатора «Платформа» (Platform) представляет собой строку, задающую операционную систему или среду выполнения вместе с информацией о соответствующей версии и об архитектуре аппаратуры UE. Для формата и значений этого идентификатора Платформа (Platform) могут быть даны и другие определения.

Этот внутренний узел действует как заполнитель для одного или нескольких листков Platform_specificAppID.

- Проявление: One

- Формат: узел

- Типы доступа: Get, Replace

Этот внутренний узел действует как заполнитель для одного или нескольких листков Platform_specificAppID.

- Проявление: OneOrMore

- Формат: узел

- Типы доступа: Get, Replace

Листок Platform_specificAppID указывает определенный для платформы идентификатор приложения, ассоциированный с описанием IP-потока (IP Flow).

- Проявление: One

- Формат: chr

- Типы доступа: Get, Replace

- Значения: <AppID>

Значение идентификатора AppID представляет собой символьную строку, ассоциированную с рассматриваемым приложением. Определенный для платформы идентификатор приложения однозначно идентифицирует приложение в пределах UE для рассматриваемой платформы. В качестве примера, идентификатор приложения может иметь форму

com.organization.app-name.

В другом примере узлы политики ISRP определены для использования под узлом ForNonSeamiessOffload 452 в сочетании с определениями для узла идентификатора AppID 454, узла Платформы (Platform) 456, узла PlatformApps 458 и узла Platform_specificAppID 460. Определения для этих узлов могут иметь следующий вид:

Этот внутренний узел действует как заполнитель для идентификации потока IPFlow через идентификатор appiicationID. Отсутствие этого узла может быть использовано для индикации, что идентификатор приложения не исследуется при сопоставлении пакетов с описанием ГР-потока согласно рассматриваемому правилу.

- Проявление: ZeroOrOne

- Формат: узел

- Типы доступа: Get, Replace

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

- Проявление: OneOrMore

- Формат: узел

- Типы доступа: Get, Replace

Листок Platform указывает платформу, ассоциированную с идентификатором приложения, содержащимся в соответствующем листке Platform_specificAppID.

- Проявление: One

- Формат: chr

- Типы доступа: Get, Replace

- Значения: <Platform>

Значение идентификатора «Платформа» (Platform) представляет собой строку, задающую операционную систему или среду выполнения вместе с информацией о соответствующей версии и об архитектуре аппаратуры UE. Для формата и значений этого идентификатора Платформа (Platform) могут быть даны и другие определения.

Этот внутренний узел действует как заполнитель для одного или более листков Platform_specific AppID.

- Проявление: One

- Формат: узел

- Типы доступа: Get, Replace

Этот внутренний узел действует как заполнитель для одного или более листков Platform_specific AppID.

- Проявление: OneOrMore

- Формат: узел

- Типы доступа: Get, Replace

Листок Platform_specificAppID указывает определенный для платформы идентификатор приложения, ассоциированный с описанием IP-потока (IP Flow).

- Проявление: One

- Формат: chr

- Типы доступа: Get, Replace

- Значения: <AppID>

Значение идентификатора AppID может быть определено в виде символьной строки, ассоциированной с рассматриваемым приложением. Определенный для платформы идентификатор приложения однозначно идентифицирует приложение в пределах UE для рассматриваемой платформы. В качестве примера, идентификатор приложения может иметь форму

com.organization.app-name.

Фиг. 5 представляет иллюстрацию примера структуры 500 узла профиля абонента (например, узла UE_Profile 312), переданной ANDSF-серверу 114 с использованием объекта ANDSF МО. Структура 500 узла UE_Profile может быть построена, чтобы содержать информацию, характеризующую конфигурацию платформы UE, которая может быть использована ANDSF-сервером 114 для предоставления информации. UE обновляет структуру 500 узла UE Profile в подходящее время, например, после включения питания или перед установлением соединения с сетью. Указанный ANDSF-сервер 114 выбирает информацию из структуры 500 узла UE_Profile после того, как UE (например, мобильное устройство 104С) установит соединение с этим ANDSF-сервером 114. Обновление информации, содержащейся в этих узлах, не обязательно предполагает, однако, какое-либо взаимодействие с ANDSF-сервером.

Структура 500 узла UE_Profile используется, чтобы определить конфигурацию UE и чтобы позволить UE обозначить свою конфигурацию для сети связи. Для удовлетворения требования поддержки множества операционных систем ANDSF-сервер 114 предоставляет UE политики, содержащие идентификатор ID приложения для соответствующей операционной системы, работающей в аппаратуре UE, и для типа аппаратной платформы, чтобы правильно идентифицировать приложения. Посредством структуры 500 узла UE_Profile UE сообщает ANDSF-серверу информацию о поддерживаемой им операционной системе и о конфигурации аппаратуры, чтобы проинформировать этот ANDSF-сервер с целью получения или скачивания политик с идентификатором application-ID приложения, используемого поддерживаемой платформой, и, таким образом, идентификации приложения, к которому относится соответствующая политика.

UE может поддерживать множество конфигураций платформы. Конфигурация платформы, переданная ANDSF-серверу 114, может указывать применимую операционную систему или среду выполнения вместе с информацией о соответствующей версии. В одном из примеров ANDSF-сервер использует информацию о профиле абонента, получаемую из структуры 500 узла UE_Profile, для установления и передачи конкретной политики ISRP (например, политики ISRP, специализированной для дерева 400 узла политики на потоковой основе или для дерева 450 узла политики на основе небесшовной выгрузки) с целью классификации трафика приложения. Политику ISRP используют только для тех приложений, которые поддерживаются конфигурацией платформы UE, на основе информации, заданной в структуре 500 узла UE_Profile.

UE обновляет узлы в структуре 500 узла UE_Profile, так что ANDSF-сервер 114 может прочитать эту информацию при взаимодействии с UE. Информация из структуры 500 узла UE Profile может быть вызвана ANDSF-сервером 114 в ходе обмена данными согласно стандартам управления устройствами Открытого сообщества производителей мобильной связи (Open Mobile Alliance Device Management (OMA-DM)), когда сервер считывает объект МО для UE, например.

Как показано на фиг. 3, объект МО имеет узел (узел UE_Profile 312), указывающий конфигурацию UE и содержащий структуру 500 узла UE_Profile. Эта структура 500 узла UE_Profile задает подробности аппаратной платформы UE и операционной системы или среды выполнения, используемой этим UE или доступной для него. Обновление информации, содержащейся в этих узлах, необязательно предполагает какое-либо взаимодействие с ANDSF-сервером 114. Однако объект МО позволяет ANDSF-серверу 114 быть информированным о конфигурации аппаратуры UE, операционной системе и версии операционной системы, инсталлированной в этом UE, а также иметь другую относящуюся к профилю UE информацию. На основе этой информации ANDSF-сервер 114 может генерировать и предоставлять специфичные идентификаторы приложений, соответствующие конфигурации UE, (и тем самым специализировать конкретные политики ISRP применительно к этим специфичным идентификаторам приложений).

В качестве конкретного примера реализации могут быть предложены следующие узлы и «листковые» объекты узла UE_Profile 312 и дерева 312А узла UE Profile под форматированным структурированным узловым объектом 302 ANDSF МО:

Узел UE_Profile действует в качестве заполнителя для описания информации о конфигурации платформы UE и используется для идентификации приложений и сред приложений для конкретного UE.

- Проявление: ZeroOrOne

- Формат: узел

- Типы доступа: Get

Этот внутренний узел действует как заполнитель для одной или множество конфигураций платформы UE.

- Проявление: OneOrMore

- Формат: узел

- Типы доступа: Get

Листок Платформа (Platform) указывает конфигурацию платформы, поддерживаемую UE

- Проявление: ZeroOrOne

- Формат: chr

- Типы доступа: Get

- Значения: <Platform>

Значение идентификатора «Платформа» (Platform) представляет собой строку, задающую операционную систему или среду выполнения вместе с информацией о соответствующей версии и об архитектуре аппаратуры UE. Для формата и значений этого идентификатора Платформа (Platform) могут быть даны и другие определения для указания информации об архитектуры аппаратуры и операционной системе или среде выполнения с целью однозначно идентифицировать подходящие приложения для UE.

Другие спецификации для формата узла UE_Profile или идентификатора платформы (Platform) могут определять конкретные конфигурации аппаратуры, операционной системы или программного обеспечения. В качестве примера идентификатор платформы (Platform) может задавать одно из следующих значений:

- система Android для процессоров х86 или процессоров на основе х86

- система Android для процессоров ARM или процессоров на основе х86

- система Windows 8 для процессоров на основе х86

- система Windows 8 для процессоров на основе ARM

- система iOS для процессоров на основе ARM

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

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

Листок «Политика обновления» (UpdatePolicy) указывает политику обновления для политики ISRP. Значение UpdatePolicy может быть использовано UE для принятия решения, следует ли запросить обновление для своей политики ISRP, если этот UE больше не считает соответствующее правило действительным. Если этот листок не задан, применяется значение по умолчанию 0.

- Проявление: ZeroOrOne

- Формат: bool

- Типы доступа: Get, Replace

- Значения: 0, 1 (0 указывает, что от UE не требуется запрашивать обновление правил; 1 означает, что от UE требуется запросить обновление правил).

Фиг. 6 представляет пример логической схемы 600, иллюстрирующей способ установления и применения ANDSF-политики, идентифицирующей приложение. Как показано на чертеже, логическая схема 600 содержит сочетание действий, выполняемых ANDSF-сервером и UE. Однако должно быть очевидно, что изменения способа, обзор которого приведен далее, могут содержать соответствующие действия и методики, выполняемые исключительно ANDSF-сервером или UE.

Логическая схема 600 показывает операции, выполняемые для передачи и получения информации о профиле UE, включая передачу информации о профиле UE от этого UE указанному ANDSF-серверу (операция 602) и определение информации о конфигурации устройства на этом ANDSF-сервере на основе информации о профиле UE (операция 604). Информация профиля UE может быть сообщена серверу в составе объекта ANDSF МО или в составе других данных, предоставляемых ANDSF-серверу перед применением политики ISRP.

Далее, совокупность операций для определения параметров конкретной политики ISRP содержит обновление политики ISRP на основе информации конфигурации устройства (операция 606) и передачу политики ISRP от ANDSF-сервера UE (операция 608). Политика ISRP может быть передана в виде узла в составе объекта ANDSF МО, сообщаемого UE. Эта политика ISRP может быть передана или затребована от ANDSF-сервера или другого сервиса ядра ЕРС.

Политику ISRP обновляют с учетом конфигурации аппаратуры и программного обеспечения UE, однако могут быть предложены для применения множество типов параметров политики выгрузки трафика. Определение подходящего набора параметров политики ISRP может содержать определение, происходит ли бесшовная или небесшовная выгрузка трафика (операция 610). После выбора подходящего набора параметров политики ISRP из этой политики ISRP могут быть выделены параметры прикладной политики для выгрузки (операция 612) (например, из узла APP-ID в составе раздела политики ISRP, специфичного для бесшовной или для небесшовной выгрузки).

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

Как описано здесь, различные способы или методики, либо некоторые аспекты или части таких способов могут принимать форму программного кода (т.е. команд), записанного на материальном носителе, таком как флэш-память, CD/DVD-ROM, накопитель на жестком диске, портативные запоминающие устройства или другие компьютерные носители записи, так что когда программный код загружен в машину, такую как компьютер, и выполняется этим компьютером, такой компьютер становится устройством, осуществляющим различные способы. В случае выполнения программного кода на программируемых компьютерах такое компьютерное устройство может содержать процессор, читаемый этим процессором носитель записи (включая энергозависимую и энергонезависимую память и/или запоминающие элементы), по меньшей мере одно устройство ввода и по меньшей мере одно устройство вывода. Одна или более программ, которые способны реализовать или использовать различные описанные здесь способы, могут использовать интерфейс прикладных программ (API), многократно используемые органы управления и т.п.Такие программы могут быть написаны на процедурно-ориентированном или объектно-ориентированном языке программирования высокого уровня для связи с компьютерной системой. Однако, если нужно, эти программы могут быть написаны на ассемблере или на языке машинных команд. В любом случае, язык может быть компилируемым или интерпретируемым языком и сочетаться с аппаратной реализацией.

Фиг. 7 представляет иллюстрацию примера мобильного устройства 700, такого как абонентское оконечное устройство (UE), мобильная станция (MS), мобильное устройство радиосвязи, планшет, телефонная трубка или мобильное устройство радиосвязи другого типа. Мобильное устройство 700 может содержать одну или более антенн 708, конфигурированных для связи с базовой станцией (BS), узлом eNodeB или точкой доступа другого типа для глобальной сети радиосвязи (WWAN). Мобильное устройство 700 может быть конфигурировано для связи с использованием по меньшей мере одного стандарта радиосвязи, включая 3GPP LTE, WiMAX, высокоскоростной пакетный доступ (High Speed Packet Access (HSPA)), Bluetooth и Wi-Fi. Мобильное устройство 700 может осуществлять связь с использованием отдельных антенн для каждого стандарта радиосвязи или антенн, совместно используемых для множества стандартов радиосвязи. Мобильное устройство 700 может осуществлять связь в локальной сети радиосвязи (WLAN), персональной сети радиосвязи (wireless personal area network (WPAN)) и/или глобальной сети радиосвязи (WWAN).

На фиг. 7 показаны также микрофон 720 и один или более громкоговорителей, которые могут быть использованы для ввода и вывода звука из мобильного устройства 700. Экран 704 устройства отображения может представлять собой экран жидкокристаллического дисплея (LCD) или экран дисплея другого типа, такого как дисплей на органических светодиодах (OLED). Экран 704 дисплея может быть конфигурирован в виде сенсорного экрана. Сенсорный экран может использовать технологию емкостных, резистивных сенсорных экранов или сенсорных экранов другого типа. Процессор 714 приложений и графический процессор 718 могут быть связаны с внутренней памятью 716 для осуществления процессорных функций и функций управления дисплеем. Порт 710 энергонезависимой памяти может быть также использован для создания дополнительных возможностей ввода/вывода данных для абонента. Этот порт 710 энергонезависимой памяти может быть также использован для расширения возможностей памяти в мобильном устройстве 700. В мобильное устройство 700 может быть встроена или связана с ним по радио клавиатура для предоставления абоненту дополнительного устройства ввода. Сенсорный экран позволяет также создать виртуальную клавиатуру. На передней (где находится экран устройства) или на задней стороне мобильного устройства 700 может быть расположена видеокамера 722, встроенная в корпус этого мобильного устройства 700.

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