RU2745773C2 - Реализация адаптивного качества обслуживания - Google Patents

Abstract

Изобретение относится к области изменения текущих настроек качества обслуживания (QoS, Quality of Service) в сети мобильной связи между устройством пользователя (UE, User Equipment) и базовой станцией. Техническим результатом является более эффективное обслуживание устройства пользователя. Способ включает в себя определение первых настроек качества обслуживания для первого приложения, содержащих минимальные требования к обслуживанию; определение способности первого приложения извлечь пользу из настроек более высокого качества обслуживания и сохранение этой информации в случае положительного результата; и после инициирования второго приложения в устройстве пользователя, требующего вторых настроек качества обслуживания, более высоких, чем первые настройки качества обслуживания, изменение первых настроек качества обслуживания для первого приложения с целью обеспечения их по меньшей мере частичного соответствия настройкам более высокого качества обслуживания, если определено, что первое приложение способно извлечь пользу из настроек более высокого качества обслуживания. 4 н. и 13 з.п. ф-лы, 6 ил.

Description

Область техники

Настоящее изобретение относится к способу изменения текущих настроек качества обслуживания (QoS, Quality of Service) в сети мобильной связи между устройством пользователя (UE, User Equipment) и базовой станцией.

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

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

Архитектура мобильной сети для систем 2G/3G описана в документе 3GPP TS 23.060, а архитектура системы 4G - в документе 3GPP TS 23.401. Эти системы обеспечивают обмен данными между устройством UE и сетью передачи данных на основе логических соединений между устройством UE и соответствующим шлюзом (PDN-соединений; PDN, Packet Data Network - сеть пакетной передачи данных). Большинство из таких соединений основано на протоколе IP (Internet Protocol), поэтому для устройства UE соответствующий шлюз выделяет IP-адрес в сети передачи данных, который действителен для соответствующего PDN-соединения в течение всего времени существования этого соединения. Устройство UE может иметь с сетью передачи данных несколько PDN-соединений с одним IP-адресом, используемым устройством UE. Устройство UE может иметь с несколькими сетями передачи данных несколько соединений с различными IP-адресами (например, Интернет, службы MMS и IMS).

В PDN-соединениях передача данных может происходить в различных потоках данных услуги (SDF, Service Data Flow). Эти потоки обеспечивают наименьшую гранулярность дифференцированной обработки пересылаемых данных, т.е. данные в одном потоке SDF обрабатываются с одинаковым качеством обслуживания и приоритетом и доставляются, в основном, упорядоченно, а данные в разных потоках могут иметь разный приоритет и могут по-разному обрабатываться в сети, например, обработка пакетов с более высоким приоритетом намеренно приводит к неупорядоченной доставке.

В системе 3G/UMTS концепция качества обслуживания (QoS) описана в техническом стандарте 23.107, причем одно из технических требований к качеству QoS состоит в том, что характеристики качества QoS должны быть динамическими, с возможностью изменения атрибутов качества QoS во время активной сессии. Существует четыре класса качества QoS с разными атрибутами. Администратор обслуживания координирует функции плоскости управления для запуска, изменения и поддержания обслуживания, за которое он ответственен. Изменение качества QoS реализуется путем отправки сообщения «Запрос на изменение контекста PDP» (Modify PDP (Packet Data Protocol) Context Request), содержащего указание на новое качество QoS (см. 3GPP TS 24.008).

Для мобильной сети следующего поколения (5G или NG, Next Generation) архитектура будет иметь большую гибкость, позволяя операторам адаптировать к реальным потребностям обслуживание, предлагаемое для устройства UE. Отдельно взятое соединение между устройством UE и сетью передачи данных обозначается как PDU-сессия (PDU, Packet Data Unit - блок пакетных данных). Она характеризуется высокой гибкостью при запуске и поддержании. Может существовать более одной PDU-сессии в одной и той же сети передачи данных для отдельно взятого устройства UE, например, с другим IP-адресом (так называемая множественная адресация (multi-homing)) и/или с другим качеством обслуживания (QoS). В пределах одной PDU-сессии могут существовать потоки PDU, обеспечивающие, подобно потокам SDF в традиционной опорной сети, наименьшую гранулярность при изменении качества QoS. Таким образом, несколько потоков PDU с (немного) различными настройками качества QoS (например, с различными приоритетами) могут сосуществовать в течение одной PDU-сессии. В одной сети передачи данных могут существовать несколько PDU-сессий с более значительными различиями в настройках качества QoS, например, с различными настройками сохранения IP-адресов (и, как следствие, с разными режимами мобильности) или с разными IP-адресами.

В рабочем документе 5G-архитектуры 3GPP TR 23.799 на рисунке 7.6.2-1 представлена предполагаемая архитектура 5G-сети без роуминга для нескольких устройств UE, одновременно осуществляющих доступ к локальной сети передачи данных и к центральной сети передачи данных с использованием нескольких PDU-сессий.

Устройство UE подключается к сети (радио)доступа следующего поколения (NG (R)AN, Next Generation (Radio) Access Network), которая через функцию плоскости пользователя (UP, User-Plane) опорной сети следующего поколения соединена с сетью передачи данных (DN, Data Network). По существу, функция UP представляет собой сетевой маршрутизатор и/или шлюз, который может быть каскадно задействован несколько раз за одну PDU-сессию между одним устройством UE и конкретной сетью передачи данных. Одиночная UP-функция, формирующая оконечную точку сети оператора в направлении сети передачи данных (такой как, Интернет или FMS), называется оконечной функцией плоскости пользователя (TUPF, Terminating User Plane Function), поскольку она завершает все PDU-сессии между устройством UE и сетью передачи данных. В опорной сети LTE оконечная функция обозначается как «пакетный шлюз» (PGW, Packet GateWay), а другая (не оконечная) функция плоскости пользователя обозначается как «обслуживающий шлюз» (SGW, Serving GateWay). В более гибкой архитектуре 5G обе эти функции заменены функцией (T)UPF.

Устройство UE и базовая станция подключены к функции управления мобильностью (MMF, Mobility Management Function) следующего поколения, которая управляет регистрацией и мобильностью устройства UE и направляет к функции управления сессией (SMF, Session Management Function) управляющие сообщения, относящиеся к PDU-сессиям (запуск новых PDU-сессий, их изменение, завершение и т.д.). Функция SMF связывается с функцией управления политиками плоскости управления и с функцией приложения, которая находится, например, на стороннем сервере приложений.

Показан лишь один экземпляр каждой функции. Фактически, устройство UE может быть подключено через средства множественного доступа (например, сети радиосвязи NG и LTE) и иметь разные PDU-сессии, которые маршрутизируются через разные UP-функции в различные или в те же сети передачи данных. Для каждой PDU-сессии вида IP (это типичный случай) для устройства UE выделяется IP-адрес. Устройство UE также может связываться с несколькими функциями управления сессией, каждая из которых используется для некоторых из PDU-сессий устройства UE. Тем не менее, за каждое устройство UE ответственна одна функция управления мобильностью (MMF). Это единственная точка входа для устройства UE в плоскость управления опорной сети.

В документе TR 23.799 в нескольких вариантах описаны потенциально возможные процедуры мобильности для системы 5G, определяющие требования мобильности (mobility requirements) для устройства UE и его PDU-сессии. Например, для системы 5G могут быть определены различные режимы 1, 2 и 3 так называемой «непрерывности сессии и обслуживания» (SSC, Session and Service Continuity). Для каждой PDU-сессии устройства UE применим один из этих режимов. Режим описывает, может ли быть (и если может, то как) в результате мобильности устройства UE заменена функция TUPF, то есть шлюз в направлении к сети передачи данных. Под мобильностью здесь подразумевается либо мобильность внутри одной технологии радиодоступа, либо мобильность между технологиями радиодоступа, что приводит к необходимости замены функции TUPF. Устройство UE при перемещении из одной соты в другую может покинуть область, которую способна эффективно обслуживать функция TUPF, или устройство UE при переходе с сети 5G на беспроводную локальную сеть (WLAN) или на сеть фиксированного доступа (fixed access) может быть вынуждено перейти на ту функцию TUPF, которая способна обслуживать фиксированные соединения.

При замене функции TUPF IP-адрес, выделенный устройству UE для некоторой сети передачи данных, обычно изменяется, а режим SSC определяет приемлемость и способ выполнения этого изменения. В соответствии с текущей версией документа TR 23.799, для конкретной PDU-сессии существуют следующие варианты:

- режим SSC1: функция TUPF не меняется в течение всей PDU-сессии, независимо от радиосети;

- режим SSC2: функция TUPF меняется, когда устройство UE покидает область обслуживания функции TUPF. Эта область может содержать несколько сот с одинаковыми или разными технологиями доступа (или с технологиями, не основанными на сотах, например, технологиями фиксированного доступа). Сеть завершает текущую PDU-сессию и запрашивает инициирование новой PDU-сессии устройством UE. Новая функция TUPF может быть подготовлена сетью так, чтобы новая сессия имела подходящие настройки;

- режим SSC3: решение о смене функции TUPF PDU-сессии может принимать сеть. Устройство UE либо инициирует запуск новой PDU-сессии и переключает приложения на эту новую сессию, после чего старая сессия завершается, либо существующая PDU-сессия передается новой функции TUPF. Для последнего решения на короткое время могут быть одновременно назначены два IP-адреса (т.н. множественная адресация).

При запросе PDU-сессии устройство UE может указать запрашиваемый режим SSC в виде части передаваемых в сеть настроек PDU-сессии. Устройство UE может определить требуемый режим SSC, как указано в проекте IETF (draft-ietf-dmm-ondemand-mobility), в котором описано расширение интерфейса прикладного программирования (API, Application Programming Interface) для приложений, которые запрашивают сокет и, тем самым, запрашивают переходящий, устойчивый или фиксированный IP-адрес. Это соответствует режиму SSC2 (переходящий) или режимам SSC1 или SSC3 (устойчивый или фиксированный).

Типичными примерами приложений, требующих режима SSC1, являются браузерные приложения, обращающиеся к веб-серверу за обслуживанием, поскольку они обычно не справляются с изменением IP-адреса. Режим SSC3 обычно используется голосовыми приложениями (Skype или основанными на протоколе SIP (Session Initiation Protocol)), имеющими встроенные средства для преодоления последствий эпизодических изменений IP-адреса. Режим SSC2 используется только для услуг с короткими сессиями связи, таких как мессенджеры (приложения обмена сообщениями) или клиенты службы DNS. На них изменения IP-адреса не оказывают существенного влияния.

Другое описание, альтернативное режимам SSC, содержится в том же документе TR 23.799. Оно определяет категории сессий (Session Classes) для конкретной PDU-сессии устройства UE. Эти категории также определены для случаев проявления мобильности и, как следствие, для изменения функции плоскости пользователя (UPF). Они различают, определены ресурсы PDU-сессии, подлежащие изменению на целевые ресурсы, до фактической замены функции TUPF (это т.н. преднастройка сессии, аналогичная выполняемой при хэндовере в сети LTE) или после смены функции TUPF (постнастройка сессии). В основном, эти две категории описывают различия весьма похоже на режим SSC2 (постнастройка сессии) и режим SSC3 (преднастройка сессии).

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

Эта недостижимая ранее гибкость мобильной сети следующего поколения в отношении количества и характера PDU-сессий между устройством UE и сетью передачи данных и в отношении количества IP-адресов, выделяемых устройству UE со стороны сети передачи данных (при формальном ограничении одним IP-адресом), приводит к множеству PDU-сессий, имеющих настройки с параметрами, очень точно адаптированными к услугам и приложениям, которые их используют.

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

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

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

Средства, позволяющие приложению информировать о его строгих требованиях к обслуживанию, а также о том, что оно способно получить пользу из лучшего обслуживания, не известны. Между тем, это позволило бы сети предоставлять обслуживание в соответствии со строгими требованиями, при этом сеть могла бы экономить ресурсы. Когда дополнительно запрашивается другая услуга со строгими требованиями для обеспечения лучшего обслуживания (например, в отношении меньшего времени перерыва в связи или в отношении сохранения IP-адреса), то предоставляя такую услугу, сеть меняет обслуживание также и для первого приложения. В результате, как указано, и первое приложение может извлечь пользу, и сеть может извлечь пользу за счет ресурсов, не являющихся необходимыми для ограниченного обслуживания в соответствии со строгими требованиями первого приложения.

В патентном документе US 20080132268 А1 описано техническое решение, состоящее в запуске первого приложения с первыми настройками качества QoS и, в случае изменения контекста PDP, в обновлении настроек качества QoS.

В патентном документе US 20140162676 А1 описана настройка нового канала в ответ на запрос на новую услугу с более высоким качеством обслуживания.

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

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

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

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

Изобретение дополнительно реализует сеть, способную предоставлять первую услугу в соответствии с первым уровнем качества, а по запросу - вторую услугу со вторым (более высоким) уровнем качества. Сеть предоставляет первую услугу, позволяющую извлечь пользу из лучшего обслуживания, и вторую услугу в соответствии со вторым уровнем качества. Сеть может продолжать предоставлять с первым уровнем качества первую услугу, не позволяющую извлечь пользу из лучшего обслуживания.

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

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

Далее лишь в качестве примера описаны предпочтительные варианты осуществления изобретения со ссылками на приложенные чертежи.

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

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

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

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

На фиг. 5 представлена блок-схема последовательности событий с точки зрения устройства UE.

На фиг. 6 представлена блок-схема последовательности событий с точки зрения сети.

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

На фиг. 1 схематично изображено мобильное устройство в виде устройства UE 10 с интерфейсом 12 связи. Этот интерфейс может состоять из сотового модема, способного осуществлять связь в соответствии со стандартом сотовой связи пятого поколения, LTE и UMTS. Интерфейс связи может также поддерживать WLAN (WiFi) и другие технологии связи.

На фиг. 1 в качестве примера показаны три приложения 14 (для краткости обозначенные «Пр»), которые могут быть использованы в устройстве. В устройстве может присутствовать гораздо больше приложений, например, являющихся частью его операционной системы (OS) или загруженных в устройство по запросу его пользователя.

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

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

Запрос также может включать в себя дополнительную информацию о качестве обслуживания, представляющую собой информацию об альтернативном качестве обслуживания, при котором приложение может оказывать услугу таким образом, который является предпочтительным для пользователя, устройства и/или сети. Эта информация может быть очень простой, например, в виде флагов для трех указанных выше показателей качества QoS, указывающих «может извлечь пользу из лучшего обслуживания» или «не может извлечь пользу из лучшего обслуживания». Информация также может быть более сложной, например, в виде параметра, величина которого указывает уровень пользы, известный устройству UE и/или сети (иными словами, величины которых стандартизированы). В качестве примеров, значения таких величин могут быть следующими.

В отношении сохранения IP-адреса:

4: «сохранение IP-адреса экономит существенную часть клиент-серверного взаимодействия и предотвращает кратковременное прерывание обслуживания»;

3: «сохранение IP-адреса экономит малую часть клиент-серверного взаимодействия и предотвращает кратковременное прерывание обслуживания»;

2: «сохранение IP-адреса предотвращает незначительное прерывание обслуживания»;

1: «сохранение IP-адреса не оказывает положительного влияния на обслуживание».

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

х: <Целое число в интервале 1-256> «только перерывы в связи длительностью меньше <х> мс гарантированно не будут замечены пользователем».

В отношении потери данных:

х: <Целое число в интервале 1-256> «потеря <х> последовательных пакетов приведет к ухудшению обслуживания, но без прекращения обслуживания», или

х: < Целое число в интервале 1-32> «потеря 2^<х> последовательных байтов приведет к ухудшению обслуживания, но без прекращения обслуживания».

Строгие требования приложения, т.е. информация о качестве обслуживания, и дополнительная информация о качестве обслуживания могут быть переданы вместе, например, в виде диапазона значений. В частности, приложение может запросить услугу доступа к Интернету пропускной способностью 20-100 Мбайт/с и с возможным изменением IP-адреса от «эпизодически» до «ни одного раза». Нижний предел соответствующего диапазона значений может интерпретироваться приложением как строгие или минимальные требования, в данном случае это 20 Мбайт/с и эпизодические изменения IP-адреса, а все значения выше этих значений, вплоть до верхнего предела, могут быть предпочтительными.

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

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

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

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

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

На фиг. 2 представлен запуск новой PDU-сессии, инициированной приложением в устройстве UE. Показаны различные элементы или функции, задействованные в процедуре запуска PDU-сессии. На этой фигуре показано устройство UE 20, содержащее два приложения (Пр1 и Пр2) и коммуникационный интерфейс (КИ). Устройство UE может напрямую общаться с сетью доступа (AN, Access Network), которая может быть сетью радиодоступа, осуществляющей связь с устройством UE через антенны. Сеть AN также может быть фиксированной сетью или гибридной сетью (сочетанием фиксированной сети и сети WiFi).

Сеть AN соединена с опорной сетью (CN, Core Network), содержащей разные функции. Большинство из этих функций показано только один раз, но потенциально они могут быть представлены в опорной сети многократно. Сеть AN содержит функцию управления мобильностью (MMF, Mobility Management Function), функцию управления сессией (SMF, Session Management Function), функцию управления политиками (PCF, Policy Control Function), а также две или более функции плоскости пользователя (UPF, User Plane Function). Новые функции UPF (Нов. UPF) не показаны. Опорная сеть CN также содержит базу данных (DB, Database). Обмен данными может выполняться между опорной сетью и одной или несколькими сетями передачи данных (DN, Data Networks).

Как показано на фиг. 2, в целях описания запуска PDU-сессии предполагается, что устройство UE зарегистрировано в сети и, следовательно, существует контекст управления мобильностью. Действия для достижения этого представлены на шаге 0 «Установление контекста управления мобильностью» (MM Context Establishment), который может состоять из обмена несколькими сообщениями.

Когда приложение, например, приложение Пр1, запрашивает услугу передачи данных от сети DN, как показано на шаге 1, например, через интерфейс API, интерфейс связи в устройстве UE проверяет, имеется ли PDU-сессия устройства UE с этой сетью DN и, если да, то применима ли эта PDU-сессия для дополнительной передачи запрошенной услуги. Приложение Пр1 может включать в свой запрос параметры качества QoS, описывающие качество обслуживания, требуемое для оказания этой услуги. Например, приложение Пр1 может указывать, что для этого приложения эпизодическое изменение IP-адреса является приемлемым. Приложение Пр1 может также указывать дополнительные параметры качества обслуживания addQoS, которые приложение способно использовать. Например, приложение Пр1 может указывать информацию о том, что сохранение IP-адреса позволяет сэкономить значительную часть сигнализации управления уровня приложения. В качестве альтернативы, дополнительные параметры качества обслуживания могут быть получены из внутренней базы данных устройства UE на необязательном шаге 1а.

Предполагая, что в отсутствие PDU-сессии для соответствующей сети DN может потребоваться новая PDU-сессия, устройство UE запрашивает запуск PDU-сессии от функции MMF через сеть AN, как показано как шаге 2. Этот запрос может содержать описание качества QoS, полученное от приложения, включая дополнительное описание качества QoS. Функция MMF выбирает подходящую функцию SMF и перенаправляет запрос, включая качество QoS и дополнительное качество QoS, на шаге 3. Функция SMF основывает последующую процедуру запуска PDU-сессии исключительно на требованиях приложения к качеству QoS. Кроме того, функция SMF может сохранять дополнительные параметры качества QoS (шаг 4), чтобы они могли быть использованы в случае, если будущие PDU-сессии будут способны обеспечить дополнительное качество QoS и соответствующее обслуживание для приложения Пр1. Функция SMF может аутентифицировать и авторизовать устройство UE и параметры сессии в сети DN (шаг 5), получать информацию о политике от функции PCF (шаг 6) и выбирать соответствующую функцию UPF или несколько функций UPF, если для обслуживания требуется более одной функции UPF. На опциональном шаге 7 функция SMF может принимать информацию о качестве QoS для конкретного приложения из какой-либо базы данных в опорной сети или из сети DN, особенно, если такая информация не была получена на шагах 1 и 1а. Определение ресурса PDU-сессии инициируется на основе параметров качества QoS, разрешенных сетью DN и политикой оператора. Определение ресурсов PDU-сессии выполняется с помощью сети AN (шаг 8) и соответствующей функции UPF (шаг 9). Оконечный шлюз (TUPF) владеет информацией фильтра, управляющей соответствующими данными DL, предназначенными для передачи с использованием этой вновь начатой PDU-сессии. Устройство UE информируется о завершении запуска PDU-сессии на шаге 10, включая информацию фильтра, управляющую соответствующими данными UL приложения Пр1, предназначенными для передачи с использованием этой новой PDU-сессии. На шаге 11 приложение может быть проинформировано о том, что запрашиваемая услуга доступна, что может быть выполнено посредством дополнительной информации о качестве QoS, фактически обеспечиваемом сетью.

Затем между приложением Пр1 и сетью DN может происходить передача данных через сеть AN и выбранную функцию UPF с качеством QoS, согласно требованиям приложения.

Согласно фиг. 2, дополнительная информация о качестве QoS передается в сеть в запросе на обслуживание и/или в запросе на запуск PDU-сессии от приложения через интерфейс связи и сохраняется в опорной сети, например, в функции SMF. В качестве альтернативы, дополнительная информация о качестве QoS принимается из баз данных устройства UE или опорной сети.

Далее описано использование новых параметров и их преимущества.

На фиг. 3 представлен запуск дополнительной PDU-сессии для второго приложения. Как показано на шаге 0 фиг. 3, в качестве предварительного условия предполагается, что первая PDU-сессия начата согласно фиг. 2, как описано выше. Как показано, передача данных между приложением Пр1 и сетью DN может происходить через сеть AN и выбранную функцию UPF (или несколько функций UPF).

Приложение Пр2 может запрашивать услугу доставки данных от средства связи с требуемым для этого приложения качеством QoS. Например, приложение Пр2 может запросить обслуживание, включающее сохранение IP-адреса во время соединения. Качество QoS приложения Пр2 может быть получено от приложения, из внутренней базы данных устройства UE или из базы данных опорной сети (см. фиг. 2). Альтернативные варианты не показаны на дальнейших фигурах; их следует понимать как общие альтернативы, применимые ко всем примерам в этом описании.

В этом примере предполагается, что качество QoS для приложения Пр2 таково, что текущих начатых PDU-сессий недостаточно для предоставления обслуживания приложению Пр2. Предполагая, что запрашиваемое качество QoS требует сохранения IP-адреса, сеть оператора может предположить соответствующее обслуживание, при этом IP-адрес выбирается из диапазона адресов, отличного от диапазона адресов приложения Пр1. Другая возможная стратегия сети оператора может заключаться в сохранении IP-адресов для разных шлюзов (TUPF), поскольку выбранный шлюз требует другой поддержки мобильности.

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

Возможны разные сетевые стратегии, приводящие к началу другой PDU-сессии в результате запроса приложением Пр2 услуги доставки данных. На фиг. 3 представлен процесс запуска PDU-сессии, весьма сходный с изображенным на фиг. 2. Приложение Пр 2 запрашивает услугу доставки данных с качеством QoS (шаг 1), что инициирует запрос новой PDU-сессии интерфейсом связи устройства UE (шаг 2). На шаге 3 соответствующий запрос направляется соответствующей функции SMF, при этом устройство UE и новая PDU-сессия могут быть аутентифицированы и авторизованы в сети DN на шаге 4. После получения политик от функции PCF (шаг 5), функция SMF имеет все параметры для запуска PDU-сессии.

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

В этом примере функция SMF может обнаружить, что приложение Пр1 способно извлечь пользу из сохранения IP-адреса. В результате функция SMF, в дополнение к запуску PDU-сессии, переключает поток пакетов приложения Пр1 с первой PDU-сессии, запущенной согласно фиг. 2, на новую PDU-сессию, которая должна быть запущена (шаг 6 на фиг. 3, обобщенно обозначенный как «реакция на addQoS» (React on addQoS).

В этом примере представлена новая PDU-сессия, которая должна быть запущена с помощью другой функции UPF, обозначенной как «Нов. UPF», и способная обеспечить вновь запрошенное качество QoS, относящееся к непрерывности сессии и/или к сохранению IP-адреса.

Ресурсы PDU-сессии устанавливаются с помощью сети AN (шаг 7) и выбранных функций UPF (шаг 8), потенциально принимая во внимание ресурсы, необходимые для обслуживания потока пакетов приложения Пр2 и приложения Пр1. На шаге 8 информация фильтра может содержать новые фильтры, обеспечивающие прием новыми функциями UPF данных DL приложения Пр1 и их передачу в новой PDU-сессии.

Когда на шаге 9 в устройство UE передается подтверждение начала PDU-сессии, оно содержит фильтры, управляющие трафиком приложения Пр2, подлежащего передаче в новой PDU-сессии. Шаг 9 также может содержать изменения фильтров, касающиеся данных приложения Пр1, перенаправляемых в новую PDU-сессию.

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

Далее может выполняться передача данных между сетью DN и приложением Пр1 и приложением Пр2, соответственно, через сеть AN и вновь выбранную функцию UPF (или несколько функций UPF).

Возможны также альтернативные варианты реализации изобретения.

В качестве первого варианта следует отметить, что на фиг. 2 на шаге 4 показана функция SMF для сохранения дополнительной информации о качестве QoS, которая должна быть принята во внимание, когда позже потребуется запустить другую PDU-сессию с лучшим обслуживанием. В качестве альтернативы, сохранять эту информацию после получения запроса на запуск PDU-сессии (PDU Session Establishment Request) на шаге 2 может функция MMF. Кроме того, информация может храниться в базе данных, внешней по отношению к функциям MMF или SMF, например, в базе данных, доступной различным функциям SMF. Эти два варианта позволяют применять изобретение в случаях, когда функция MMF выбирает другую функцию SMF для новой PDU-сессии. При этом фиг. 3 и описание могут быть изменены соответственно, так что реагировать на сохранение дополнительного качества QoS может функция MMF или другая функция SMF, извлекающая информацию из базы данных и реагирующая на нее.

В качестве второго варианта, шаги изменения качества QoS также могут быть инициированы устройством UE. Устройство UE может хранить информацию о дополнительном качестве QoS для приложения Пр1 и предоставлять соответствующую информацию при запуске PDU-сессии для приложения Пр2 (фиг. 3, шаг 2). Эта информация может быть специально адаптирована к качеству QoS, запрошенному приложением Пр2, то есть она может содержать только те части дополнительного качества QoS приложения Пр1, которые запрошены приложением Пр2, чтобы инициировать переключение сетью соответствующего PDU-потока на новую PDU сессию.

Что касается третьего варианта, в приведенном выше описании предполагается, что для реализации нового оконечного шлюза (TUPF) для новой PDU-сессии выбрана новая функция UPF. Это предположение может оправдаться или не оправдаться. Принципы изобретения и описание, приведенное выше и ниже, в равной степени действительны, и если новая PDU-сессия устанавливается для одного оконечного шлюза (TUPF), обеспечивающего PDU-сессию с сохранением или без сохранения IP-адреса, или в общем случае обеспечивающего PDU-сессиям как качество QoS, так и дополнительное качество QoS, предусмотренное приложением Пр1.

В отношении четвертого варианта следует отметить, что процедура, описанная выше и представленная на фиг. 3, определяет на шаге 6 в функции SMF, что существует поток, который может извлечь пользу из изменения качества QoS. Эта процедура предлагает немедленную реакцию и запуск PDU-сессии, чтобы приложение Пр1 было перенаправлено на новую PDU-сессию. Это может привести к дополнительному изменению потока данных в приложении Пр1, которое само по себе может нарушить услугу передачи данных приложения Пр1. В случае, если сохранение IP-адреса изначально не применялось, путем переключения приложения Пр1 на новую PDU-сессию сохранение IP-адреса может быть реализовано за счет переключения на новый IP-адрес новой PDU-сессии.

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

Этот вариант представлен на фиг. 4. Шаги 2, 3, 4 и 5 с фиг. 3, по существу идентичные в этом варианте, для удобства чтения обобщенно изображены на фиг. 4 как шаг 2. После запроса PDU-сессии функция MMF или функция SMF может определить, что поток пакетов приложения Пр1 (обозначенный как «поток 1») может быть переключен на новую PDU-сессию, которая должна быть запущена. В отличие от описания, приведенного выше со ссылкой на фиг. 3, такое переключение не выполняется, но эта возможность для потока 1 сохраняется, т.е. поток помечается как потенциально переключаемый. Альтернативно, в этот момент времени определение может не выполняться (поэтому шаг 3 на фиг. 4 показан штриховой рамкой).

Подобно описанному выше, шаги 7, 8 и 9 с фиг. 3 объединены на фиг. 4 и обозначены как шаг 4. Разница в том, что запуск PDU-сессии выполняется с определением ресурсов для потока пакетов приложения Пр2, а не приложения Пр1. На шаге 5 приложение Пр2 информируется о доступности запрашиваемой услуги передачи данных.

В некоторый последующий момент времени возникает необходимость изменить IP-адрес первой PDU-сессии (то есть PDU-сессии потока 1), что обнаруживается на шаге 6 либо функцией MMF, либо функцией SMF, либо ими обеими. Это может быть связано с мобильностью устройства UE, при этом другая функция TUPF становится эффективнее текущей функции TUPF из-за изменения доступных для устройства UE технологий доступа или по другим причинам. Из-за флага, установленного на шаге 3, функция MMF или любая функция SMF может принять решение переключить поток 1 с первой PDU-сессии на новую PDU-сессию. Если шаг 3 был пропущен, шаг 7 также может включать в себя проверку функцией MMF или функцией SMF всех потоков первой PDU-сессии на наличие дополнительных параметров качества QoS, показывающих, что переключение на новую PDU-сессию является полезным.

На шагах 8 и 9 ресурсы PDU-сессии изменяются, чтобы дополнительно обслуживать поток 1 сетью AN, а также в новыми функциями UPF. На шаге 10 устройство UE информируется об измененной PDU-сессии, включая измененные фильтры, управляющие потоком 1, предназначенным для передачи в новой PDU-сессии. Указание приложению Пр1, информирующее это приложение о новом качестве QoS, может быть реализовано в устройстве UE. Если поток 1 был единственным потоком пакетов в первой PDU-сессии, первая PDU-сессия может быть завершена после описанной процедуры (не показано).

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

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

Изобретение особенно полезно, когда настройки качества QoS связаны с режимом непрерывности сессии и обслуживания (SSC), как описано выше.

Claims (30)

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

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

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

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

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

3. Способ по п. 1, отличающийся тем, что указанная информация хранится в сетевом объекте.

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

5. Способ по любому из пп. 1-3, отличающийся тем, что указанная информация включает в себя по меньшей мере один параметр для связи.

6. Способ по п. 5, отличающийся тем, что по меньшей мере один параметр выбран из перечня, содержащего уровень сохранения IP-адреса, уровень непрерывности обслуживания и уровень потери данных.

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

8. Способ по любому из пп. 1-6, отличающийся тем, что первые настройки качества обслуживания изменяются устройством пользователя.

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

10. Способ по любому из пп. 1-8, отличающийся тем, что указанная информация передается в базовую станцию во время запроса на запуск PDU-сессии.

11. Способ по п. 1, отличающийся тем, что первые настройки качества обслуживания связаны с первым режимом непрерывности сессии и обслуживания (SSC), а вторые настройки качества обслуживания связаны со вторым режимом SSC, отличным от первого режима SSC, при этом первый и второй режимы SSC отличаются следующим: может ли измениться сетевой адрес, используемый для обслуживания, и/или может ли услуга подключения быть прекращена сетью, и/или запускается ли новая услуга подключения для приложения перед прекращением услуги подключения для этого приложения.

12. Устройство пользователя, выполненное с возможностью:

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

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

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

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

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

14. Устройство пользователя по п. 12, отличающееся тем, что указанная информация включает в себя по меньшей мере один параметр для связи с базовой станцией.

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

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

- приема информации о способности первого приложения извлечь пользу из настроек более высокого качества обслуживания и сохранения этой информации в случае положительного результата;

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

16. Сетевое устройство по п. 15, отличающееся тем, что указанная информация включает в себя по меньшей мере один параметр для связи между базовой станцией и устройством пользователя.

17. Способ обеспечения непрерывного обслуживания для первого приложения, работающего в устройстве пользователя, в котором непрерывное обслуживание имеет режим непрерывности сессии и обслуживания (SSC), определяющий следующее: может ли измениться сетевой адрес, используемый для непрерывного обслуживания, и/или может ли услуга подключения быть прекращена сетью, и/или запускается ли новая услуга подключения для приложения перед прекращением услуги подключения для этого приложения, включающий в себя:

- определение первого режима SSC для первого приложения, включающего в себя минимальный режим SSC для первого приложения;

- определение способности первого приложения извлечь пользу из другого режима SSC; и

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

Images