Обмен сообщениями для носимых устройств

Изобретение относится к области связи устройства мобильной связи с носимым устройством через соединение радиоинтерфейса ближней связи, при этом устройство мобильной связи выполняет функцию ретрансляционного узла, обеспечивающего возможность соединения носимого устройства с опорной сетью. Техническим результатом является обеспечение возможности, при которой носимые устройства с функциональностью слоя NAS или без нее могут быть зарегистрированы и сняты с регистрации в опорной сети оператора MNO через ретранслирующее устройство UE, что делает носимые устройства управляемыми и/или известными опорной сети, т.е. носимые устройства могут иметь подписку у оператора MNO без необходимости иметь сотовый модем. Для этого при осуществлении связи устройства мобильной связи с носимым устройством через соединение радиоинтерфейса ближней связи, в котором устройство мобильной связи выполняет функцию ретрансляционного узла, обеспечивающего возможность соединения носимого устройства с опорной сетью производят согласование возможностей слоя NAS для соединения носимого устройства с устройством мобильной связи и для функционирования носимого устройства с использованием устройства мобильной связи в качестве ретрансляционного узла. 2 н. и 27 з.п. ф-лы, 20 ил.

 

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

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

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

Терминалы мобильной связи могут выбирать, повторно выбирать и подключаться к мобильному ретрансляционному узлу, обеспечивающему соединение с опорной сетью оператора мобильной сети (MNO, Mobile Network Operator). Радиоинтерфейс между терминалом мобильной связи и мобильным ретрансляционным узлом может быть основан на технологии LTE или на некоторой технологии ближней связи, такой как BT (Bluetooth®) или WiFi.

Известно, что ретрансляционным узлом необходимо управлять для адаптивного формирования и администрирования кластеров связи вида устройство-устройство (D2D, Device-to-Device), например, в рамках предусмотренной стандартом 3GPP возможности услуг на основе географической близости (ProSe, Proximity Services). Многие из используемых при этом принципов могут найти применение для подключения носимых устройств к сотовому телефону, который в этом случае действует как мобильный ретрансляционный узел.

Например, в патентном документе US9380625B2 описано устройство связи с возможностями связи D2D, причем об этих функциональных возможностях сообщается базовой станции. В патентном документе US20160150373A1 описана реализация ретранслятора с использованием услуг на основе географической близости в том случае, когда устройство пользователя (UE, User Equipment) находится вне зоны действия обслуживания групповой связи. Второе устройство UE действует как ретранслятор для групповой связи. В патентном документе US20120238208A1 описано устройство UE с беспроводным трансивером ближней связи, которое может быть использовано для формирования адаптивной сети. В патентном документе US20120250601A1 описано установление канала связи между устройством UE и опорной сетью в слое, не связанном с предоставлением доступа (NAS, Non-Access Stratum), а также применение канала в слое NAS для обмена данными между удаленным устройством и опорной сетью с использованием соединения по радиоканалу ближней связи. В патентном документе US8682243B2 описано использование устройства выбора сети для принятия решения о том, как устанавливать соединение - напрямую или с использованием адаптивной сети. В патентном документе US20130137469A1 описан способ передачи сообщения в адаптивной сети.

В патентном документе US20160295622A1 описан способ соединения первого беспроводного устройства, такого как портативный компьютер, с сетью через второе беспроводное устройство, такое как мобильный телефон. Информация о локальном соединении (например, скорость передачи данных, индикатор уровня принимаемого сигнала (RSSI, Received Signal Strength Indicator) или интенсивность битовых ошибок может передаваться в режиме широкого вещания, так что другие устройства поблизости могут сравнивать качество соединения с их собственным качеством соединения.

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

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

Стек протокола BT разделен на две части: «стек контроллера», содержащий критичный ко времени радиоинтерфейс, и «стек хоста», работающий с данными высокого уровня. Между этими двумя частями стека протокола может быть реализован интерфейс хост-контроллера (HCI, Host Controller Interface). Стек контроллера обычно реализуется в недорогом устройстве, содержащем BT-приемопередатчик и микропроцессор. Стек хоста, как правило, реализуется как часть операционной системы или в виде программного пакета, устанавливаемого поверх операционной системы. Для интегрированных устройств, таких как BT-гарнитуры, стек хоста и стек контроллера могут быть реализованы в одном и том же микропроцессоре. Интерфейс HCI при этом не требуется, что снижает затраты при массовом производстве. Такое решение называется системой «без хоста».

Важен протокол обнаружения обслуживания (SDP, Service Discovery Protocol). Он позволяет устройству обнаруживать предлагаемые другими устройствами возможности обслуживания и определять их параметры. Например, мобильный телефон, используемый с гарнитурой BT, применяет протокол SDP, чтобы определить, какие BT-профили поддерживаются этой гарнитурой. Это может быть, например, профиль гарнитуры, профиль устройства громкой связи, расширенный профиль распространения звука (A2DP, Advanced Audio Distribution Profile) и т.п. Кроме того, мобильный телефон определяет настройки протокола мультиплексора, необходимые для подключения телефона к гарнитуре. Каждое обслуживание идентифицируется универсальным уникальным идентификатором (UUID, Universally Unique Identifier), причем официальным услугам (то есть BT-профилям) назначается короткий (16-битный вместо 128-битного) идентификатор UUID. В стеке протоколов протокол SDP часто бывает связан с протоколом L2CAP (Logical Link Control and Adaptation Protocol) или интегрирован в него.

Обмен данными между двумя или большим количеством BT-устройств осуществляется через так называемые BT-профили, которые были определены (с точки зрения параметров и схемы поведения) для поддержки определенных услуг. Эти BT-профили находятся на более высоких уровнях стека протоколов (например, на уровне приложений) и для поддержания определенных услуг должны быть реализованы на обоих взаимодействующих устройствах. Как правило, применение профилей экономит время за счет того, что отпадает необходимость в передаче параметров заново, обычно выполняемой перед тем, как двунаправленный радиоканал начинает работу. Существует большое количество BT-профилей, описывающих множество различных видов приложений или сценариев использования BT-устройств. Например, один из наиболее часто используемых BT-профилей, используемых с сотовым телефоном - профиль гарнитуры - способен запрашивать установление аудиоканала, а также нескольких каналов управления. Аудиоканал использует синхронный ориентированный (SCO, Synchronous Connection Oriented) канал для аудио потока со скоростью 64 Кбит/с, кодированного с применением дельта-модуляции с непрерывно изменяемой крутизной наклона (CVSD, Continuously Variable Slope Delta Modulation) или импульсно-кодовой модуляции (PCM, Pulse Code Modulation), а каналы управления предназначены для обмена минимальными командами управления из подмножества AT-команд GSM 07.07, куда входит возможность подавать вызывной сигнал, отвечать на вызов, разрывать соединение и регулировать громкость. Весьма важным и обязательным BT-профилем является профиль общего доступа (GAP, Generic Access Profile). Он представляет собой основу для всех других профилей. Профиль GAP определяет то, как два BT-устройства обнаруживают друг друга и устанавливают соединение друг с другом.

Другой BT-профиль, имеющий отношение к настоящему изобретению - протокол инкапсуляции BT-сети (BNEP, Bluetooth Network Encapsulation Protocol). Он используется для передачи данных другого стека протоколов по каналу L2CAP. Его основное назначение - передача IP пакетов в профиле персональной сети. Протокол BNEP выполняет функцию, аналогичную протоколу доступа к подсети (SNAP, Subnetwork Access Protocol) в беспроводной локальной сети (WLAN, Wireless Local Area Network). В сети WLAN на стороне передающего узла к пакетам могут быть добавлены поля SNAP, что дает возможность принимающему узлу перенаправлять каждый принятый кадр к тому драйверу устройства, который понимает этот протокол.

К настоящему изобретению имеет отношение также коммуникационный стандарт 3GPP LTE. Радиоинтерфейс LTE (также называемый интерфейсом Uu) логически разделен на три протокольных уровня. Объекты, обеспечивающие и предоставляющие функции соответствующих протокольных уровней, реализованы как в мобильном терминале, так и в базовой станции. Самым нижним уровнем является физический уровень (PHY, Physical Layer), представляющий собой протокольный уровень 1 (L1) в соответствии с эталонной моделью взаимодействия открытых систем (OSI, Open System Interconnection). Протокольный уровень, расположенный выше уровня PHY, является уровнем канала передачи данных и представляет собой протокольный уровень 2 (L2) в соответствии с моделью OSI. В системе связи LTE уровень L2 состоит из множества подуровней, а именно подуровня управления доступом к среде (MAC, Medium Access Control), подуровня управления радиоканалом (RLC, Radio Link Control) и подуровня протокола конвергенции пакетных данных (PDCP, Packet Data Convergence Protocol). Самым верхним уровнем радиоинтерфейса Uu является сетевой уровень, который, в соответствии с моделью OSI, представляет собой протокольный уровень 3 (L3) и состоит из уровня управления радиоресурсами (RRC, Radio Resource Control) в плоскости управления (C-Plane). В плоскости управления, кроме того, существует протокольный уровень слоя NAS.

Каждый протокольный уровень обеспечивает обслуживание более высокого протокольного уровня через определенные точки доступа к обслуживанию (SAP, Service Access Points). Для лучшего понимания архитектуры протокольного уровня точкам SAP присвоены понятные имена: уровень PHY обслуживает уровень MAC через транспортные каналы, уровень MAC обслуживает уровень RLC через логические каналы, а уровень RLC обслуживает уровень PDCP в качестве функции передачи данных RLC-режима: прозрачного режима (TM, Transparent Mode), режима без подтверждения (UM, Unacknowledged Mode) и режима с подтверждением (AM, Acknowledged Mode). Кроме того, уровень PDCP обеспечивает обслуживание уровня RRC и верхних уровней плоскости пользователя через радиоканалы, в частности, радиоканалы сигнализации (SRB, Signalling Radio Bearers) для уровня RRC и радиоканалы данных (DRB, Data Radio Bearers) для верхних уровней плоскости пользователя. Согласно технологии LTE, в настоящее время поддерживается максимум 3 канала SRB и 8 каналов DRB.

Помимо разделения по горизонтали на вышеописанные протокольные уровни, архитектура протокола радиосвязи также разделена по вертикали на «плоскость управления» (C-Plane, Control Plane) и «плоскость пользователя» (U-Plane, User Plane). Объекты плоскости управления используются для управления обменом данными сигнализации между мобильным терминалом и базовой станцией. Они необходимы, среди прочего, для установления, реконфигурирования и высвобождения физических каналов, транспортных каналов, логических каналов, радиоканалов сигнализации и радиоканалов данных. Объекты плоскости пользователя используются для управления обменом пользовательскими данными между мобильным терминалом и базовой станцией.

Согласно технологии LTE, каждый протокольный уровень имеет особые предписанные ему функции.

Уровень PHY в первую очередь отвечает а) за обнаружение ошибок в транспортном канале, б) за кодирование и декодирование в транспортном канале, в) за «мягкое комбинирование» при модифицированном автоматическом запросе на повторную передачу (HARQ, Hybrid Automatic Repeat reQuest), г) за отображение кодированного транспортного канала в физические каналы, д) за модуляцию и демодуляцию физических каналов.

Уровень MAC в первую очередь отвечает а) за отображение между логическими каналами и транспортными каналами, б) за исправление ошибок путем запросов HARQ, в) за определение приоритета логического канала, г) за выбор транспортного формата.

Уровень RLC в первую очередь отвечает а) за исправление ошибок посредством схемы ARQ, б) за объединение, сегментирование и повторную сборку блоков данных обслуживания (SDU, Service Data Unit) уровня RLC, в) за повторное сегментирование и переупорядочивание данных уровня RLC в протокольном блоке данных (PDU, Protocol Data Unit). Кроме того, уровень RLC моделируется таким образом, чтобы обеспечить независимый RLC-объект для каждого радиоканала сигнализации или радиоканала данных.

Уровень PDCP в первую очередь отвечает за упаковку и распаковку заголовков потоков данных Интернет-протокола (IP, Internet Protocol), за шифрование и дешифрование данных плоскости пользователя и данных плоскости управления, а также за обеспечение целостности и проверку целостности данных плоскости управления. Уровень PDCP моделируется таким образом, чтобы каждый канал RB (то есть каналы DRB и SRB, за исключением канала SRB0) был связан с одним PDCP-объектом. Каждый PDCP-объект связан с одним или двумя RLC-объектами, в зависимости от особенностей канала RB (т.е. его одно- или двусторонней направленности) и от RLC-режима.

Уровень RRC в первую очередь отвечает за сигнализацию в плоскости управления между мобильным терминалом и базовой станцией. Он выполняет, среди прочего, следующие функции: а) широковещательную передачу системной информации, б) вызов абонента (пейджинг), в) установление, реконфигурирование и высвобождение физических каналов, транспортных каналов, логических каналов, радиоканалов сигнализации и радиоканалов данных. Радиоканалы сигнализации используются для обмена сообщениями уровня RRC между мобильным терминалом и базовой станцией.

Различия между C-плоскостью (плоскостью управления) и U-плоскостью (плоскостью пользователя) в соответствии с технологией E-UTRA (LTE) изображены на фиг. 1A и фиг. 1Б. Протокол уровня RRC и все протоколы более низких уровней (PDCP, RLC, MAC и PHY) реализованы в базовой станции eNB, а протокольный уровень NAS реализован в узле управления мобильностью (MME, Mobility Management Entity), находящемся в усовершенствованном пакетном ядре (EPC, Evolved Packet Core). Интерфейсом между устройством UE и базовой станцией eNB является LTE-радиоинтерфейс (известный как опорная точка Uu), а интерфейс между станцией eNB и узлом MME называется S1. Нижние уровни интерфейса S1 не показаны с целью упрощения фиг. 1А.

В будущем носимые устройства связи смогут иметь функциональность слоя NAS или не иметь ее. В случае, если будущие носимые устройства не имеют функциональности слоя NAS, но при этом должны управляться опорной сетью и/или должны быть ей известны, т.е. иметь подписку у оператора мобильной сети (MNO), то может быть желательно модифицировать имеющийся объект слоя NAS в устройстве UE так, чтобы обслуживать как само это устройство UE (которое работает в этом сценарии в качестве ретрансляционного узла), так и носимое устройство. Может быть желательно реализовать даже более одного объекта слоя NAS в устройстве UE, т.е. один объект слоя NAS для самого этого устройства UE и один или несколько дополнительных объектов слоя NAS для различных носимых устройств, как это описано в патентном документе US20130137469A1.

Существующие технологии BT не предлагают достаточных средств для подключения носимого устройства связи с функциональностью слоя NAS или без нее (здесь - «носимые устройства»), к устройству сотовой связи (здесь - «устройство UE»), которое не содержит ни одного либо содержит один или несколько объектов слоя NAS, выделенных для носимых устройств. При этом устройство UE может быть способным ретранслировать трафик в опорную сеть оператора MNO, т.е. в восходящем направлении, и/или ретранслировать трафик, исходящий из опорной сети оператора MNO, т.е. в нисходящем направлении.

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

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

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

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

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

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

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

Эта концепция обмена сообщениями для носимых устройств, которая может быть реализована, например, в виде нового BT-профиля, дает следующие преимущества. Будущие носимые устройства с функциональностью слоя NAS или без нее, могут быть зарегистрированы и сняты с регистрации в опорной сети оператора MNO через ретранслирующее устройство UE. Это делает носимые устройства управляемыми и/или известными опорной сети, т.е. носимые устройства могут иметь подписку у оператора MNO без необходимости иметь сотовый модем.

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

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

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

На фиг. 1A показаны крайние точки протокола в плоскости управления.

На фиг. 1Б показаны крайние точки протокола в плоскости пользователя.

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

На фиг. 3 показан вариант конфигурации согласно фиг. 2, в котором носимое устройство использует собственный объект слоя NAS.

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

На фиг. 5A показана схема обмена информацией, относящейся к слою NAS, между узлами MME внутри опорной сети.

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

На фиг. 6A показана схема обмена информацией, относящейся к слою NAS, внутри узла MME.

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

На фиг. 7 показана схема взаимодействия между объектами слоя NAS в носимом устройстве, в опорной сети и в устройстве UE.

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

На фиг. 9 показана пара сообщений, относящихся к предложению о согласовании, которая может быть использована носимым устройством и устройством UE для согласования того, какой объект слоя NAS и/или приложение универсального модуля идентификации подписчика (USIM, Universal Subscriber Identity Module) следует использовать, если существует более одного варианта; здесь процедура инициирована носимым устройством.

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

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

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

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

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

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

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

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

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

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

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

- взаимный обмен информацией о возможностях слоя NAS;

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

- информирование носимого устройства о текущем состояния связи устройства UE;

- запрос к устройству UE на установление сетевого соединения для носимого устройства;

- запрос к устройству UE на удержание сотового соединения;

- разрыв устройством UE сетевого соединения для носимого устройства; и

- запрос к устройству UE на завершение сетевого соединения для носимого устройства.

Взаимный обмен информацией о возможностях

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

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

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

Кроме того, в некоторых сценариях представляется целесообразным позволить устройству UE объявлять, имеется ли у него «запасная» подписка, то есть неиспользуемое USIM-приложение, предназначенное для обслуживания носимых устройств. Например, такое USIM-приложение может находиться на подключенной к устройству UE съемном модуле USIM или может быть встроено в устройство UE на схемном уровне.

Носимое устройство может объявить о своих возможностях управления сотовой связью, т.е. о том, реализован ли в этом носимом устройстве объект слоя NAS и/или имеется ли в этом носимом устройстве USIM-приложение, которое может быть встроенным или съемным (то есть вставленным в слот).

Кроме того, устройство UE может информировать носимое устройство о том, соединены ли с устройством UE другие устройства, может ли носимое устройство установить с ними контакт и, например, каким образом возможно построение персональной сети (PAN, Personal Area Network).

Если доступны и подходят для обслуживания данного носимого устройства более одного объекта слоя NAS (или USIM-приложения), то выбирается только один объект слоя NAS (или USIM-приложение). Таким образом, согласно данному изобретению, фактическое использование или подключение объекта слоя NAS и/или USIM-приложения согласовывается между носимым устройством и устройством UE по радиоинтерфейсу ближней связи.

Процедура взаимного обмена информацией о возможностях слоя NAS может содержать следующие шаги.

Вариант 1

Начальная ситуация: носимое устройство устанавливает контакт с устройством UE в первый раз.

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

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

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

Вариант 2

Начальная ситуация: устройство UE и носимое устройство уже соединены.

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

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

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

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

Далее обсуждается подробный пример диаграммы последовательности сообщений.

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

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

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

Информирование носимого устройства о текущем состояния связи устройства UE

В целом, состояние связи между устройством UE и соответствующей сотовой сетью мобильной связи (например, сетью сотовой связи, работающей в соответствии с 3GPP LTE или LTE-Advanced) будет влиять на потенциальную связь носимого устройства. Поэтому в качестве части нового профиля обмена сообщениями предполагается обмен дополнительными фрагментами информации между устройством UE и носимым устройством, например, во время начальной фазы сигнализации.

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

- регистрация в сети мобильной связи общего пользования (PLMN, Public Land Mobile Network). Это может быть важно, поскольку если устройство UE по какой-либо причине не зарегистрировано в соответствующей сети сотовой связи, оно не сможет отправлять какие-либо сообщения (кроме первоначальной регистрации самого себя);

- режим работы RRC CONNECTED, RRC SUSPENDED или RRC IDLE;

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

- индикатор нахождения вне зоны действия сети и т.д.

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

Устройство UE сообщает носимому устройству о благоприятной возможности для обмена данными (например, при переходе уровня RRC из состояния IDLE в состояние CONNECTED или в случае, когда устройство UE входит в активный период (On-Duration) режима прерывистого приема (DRX, discontinuous reception)). Подобным образом, устройство UE сообщает носимому устройству, что возможность для обмена данными исчерпана (например, при переходе уровня RRC из состояния CONNECTED в состояние IDLE или в случае, когда устройство UE входит в пассивный период (Off-Duration) режима DRX). Поскольку любой заданный шаблон режима DRX обычно конфигурируется для определенного отрезка времени, может иметь смысл сообщать носимому устройству шаблон конфигурации и валидность режима DRX устройства UE.

Следует отметить, что режим DRX означает «прерывистый прием», т.е. состояние ожидания в технологии LTE, введенное для энергосбережения, в котором устройству UE не требуется контролировать физический нисходящий канал управления (PDCCH, Physical Downlink Control Channel) в каждом субкадре, чтобы проверять наличие доступных нисходящих данных.

В качестве альтернативы, носимое устройство просто отправляет данные через интерфейс ближней связи всякий раз при появлении новых пакетов. Устройство UE буферизирует все входящие пакеты до тех пор, пока не появится благоприятная возможность ретранслировать эти данные через сотовый интерфейс. Кроме того, носимое устройство может помечать свои данные флагом «time-critical» («критичный по времени») или «delay-tolerant» («устойчивый к задержке»). Пока поступают только данные, помеченные как «устойчивые к задержке», устройство UE буферизирует их для будущей восходящей передачи. Когда от носимого устройства поступают данные, помеченные как «критичные по времени», устройство UE может выбрать изменение своего исходного режима и попытаться немедленно ретранслировать данные через сотовый интерфейс. Эта последняя схема поведения может означать переход между состояниями RRC, например, из состояния IDLE в состояние CONNECTED.

В качестве альтернативы, устройство UE указывает носимому устройству время, оставшееся до появления возможности для обмена данными, например, до коррекции зоны отслеживания (TAU, Tracking Area Update).

Запрос к устройству UE на установление сетевого соединения для носимого устройства

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

Запрос к устройству UE на удержание сотового соединения

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

- следует ли ожидать в скором времени появления большего количества восходящих данных (UL data, Up-Link data), поступающих от носимого устройства; или

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

Устройство UE может выбрать удержание сотового соединения на несколько более продолжительное время (например, на предварительно определенный или прогнозируемый период времени), тем самым, возможно, уменьшая необходимость частых переходов между состояниями RRC из CONNECTED в IDLE и обратно в CONNECTED. Упомянутое «время ожидания» устройство UE может рассчитать на основе предыдущих характеристик трафика, принимая во внимание, например, более ранние ответы, приходящие с тех же или аналогичных серверов контента, от абонентов приложений и т.д.

Разрыв устройством UE сетевого соединения для носимого устройства

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

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

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

Запрос к устройству UE на завершение сетевого соединения для носимого устройства

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

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

Если в носимом устройстве реализован собственный объект слоя NAS, то носимое устройство напрямую запрашивает разрыв соединения от соответствующего узла MME через свое собственное NAS-соединение. После успешного завершения этой процедуры носимое устройство просто информирует устройство UE о результате по радиоинтерфейсу ближней связи.

На фиг. 2 и 3 показаны примеры для двух разных вариантов реализации: на фиг. 2 объект слоя NAS, предназначенный для носимого устройства, расположен в устройстве UE, а на фиг. 3 в носимом устройстве реализован его собственный объект слоя NAS.

В примере реализации на фиг. 3 носимое устройство также имеет свое собственное USIM-приложение. В одном варианте осуществления это может быть встроенный модуль USIM (eUSIM), который неотделимо встроен в носимое устройство на схемном уровне.

На фиг. 2 и 3 показаны оба объекта слоя NAS, находящиеся в одном домене опорной сети. Это не обязательно во всех сценариях применения: оба объекта слоя NAS могут быть расположены в различных доменах опорной сети, в различных узлах MME или даже в различных функциональных зонах сети (ср. фиг. 4-6).

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

Например, если при наличии у носимого устройства собственного объекта слоя NAS (NAS₁ на фиг. 3) оно инициирует некоторые действия на своем уровне NAS, два объекта слоя NAS на стороне сети могут координировать свои действия таким образом, что NAS₁ информирует объект слоя NAS (или обменивается информацией с объектом слоя NAS), который назначен для устройства UE (NAS₂), и наоборот. Таким образом, в соответствии с изобретением, данные, относящиеся к действию (и к его результату), активированному первым устройством (например, команда отмены регистрации, отправленная носимым устройством, шаг 1) с использованием первого NAS-соединения, могут быть переданы во второе устройство через второе NAS-соединение. В частности, устройству UE может быть передано сообщение о том, что носимое устройство успешно завершило соединение на уровне NAS (шаг 3) и наоборот, как показано на фиг. 7. Шаг 2 изображает, согласно изобретению, обмен данными, относящимися к слою NAS, между двумя объектами слоя NAS, задействованными на стороне сети.

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

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

- это носимое устройство вида «часы»;

- в нем реализован собственный объект слоя NAS;

- в него вставлен модуль USIM, посредством которого удостоверен идентификатор пользователя.

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

- это устройство пользователя вида «устройство UE»;

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

- оно содержит запасной объект слоя NAS для использования носимыми устройствами;

- оно содержит запасное USIM-приложение для использования носимыми устройствами;

- оба устройства (устройство UE и носимое устройство) в настоящее время контролируются или управляются одним и тем же пользователем;

- оно способно поддерживать формирование персональной сети (PAN);

- оно способно подключать до трех различных носимых устройств.

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

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

- сетевые политики разрешают соединение до двух носимых устройств;

- данные о подписчике позволяют подключаться к этому устройству UE только носимым устройствам подкатегорий «часы» и «украшения».

На фиг. 8 показан пример диаграммы последовательности сообщений между носимым устройством и устройством UE для взаимного обмена информацией о возможностях. Далее в таблицах 1 и 2 приведены возможные структуры сообщений для пары запрос/ответ в соответствии с фиг. 8. В табл. 1 показан пример сообщения «Запрос о возможностях», а в табл. 2 показан пример сообщения «Ответ о возможностях».

Таблица 1

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Запрос о возможностях» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Класс устройства-отправителя	Указание вида передающего устройства, например, «носимое устройство».	Обязательно
Подкатегория класса устройства-отправителя	Подвид вышеуказанного, например: - часы; - очки; - фитнес-трекеры; - украшения и т.п.	Опционально
Контейнер возможностей
> Детали реализации слоя NAS	Указывает, реализован ли в устройстве-отправителе собственный объект слоя NAS, например: - истина; - ложь.	Обязательно
> Детали идентификации подписчика	Указывает, имеет ли устройство-отправитель вставляемый или встроенный универсальный модуль идентификации подписчика (USIM), например: - истина; - ложь.	Обязательно
…	…	…
Вспомогательная информация
> Идентификатор пользователя	Информация о пользователе.	Опционально
…	…	…

Таблица 2

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Ответ о возможностях» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства UE	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательный
Класс устройства-отправителя	Указание вида передающего устройства, например, «устройство UE».	Обязательно
Контейнер возможностей
> Ретрансляция	Указывает, поддерживает ли устройство-отправитель функцию ретрансляции для носимых устройств, например: - истина; - ложь.	Обязательно
> Детали реализации слоя NAS	Указывает, реализован ли в устройстве-отправителе запасной объект слоя NAS для носимых устройств, например: - истина; - ложь.	Обязательно
> Детали идентификации подписчика	Указывает, имеет ли устройство-отправитель запасной вставляемый или встроенный универсальный модуль идентификации подписчика (USIM) для носимых устройств, например: - истина; - ложь.	Обязательно
Вспомогательная информация
> Идентификатор пользователя	Указывает, управляются ли носимое устройство и устройство UE одним пользователем.	Опционально
…	…	…
Контейнер пользовательских предпочтений
> Создание персональной сети (PAN).	Например: - разрешено; - не разрешено.	Опционально
…	…	…
Контейнер сетевых политик
> Максимальное число носимых устройств	Например: - не более одного; - до двух; - до трех и т.п.	Опционально
…	…	…
Контейнер настроек подписчика
> Сетевые политики	Например, максимальная скорость передачи данных, которая может быть назначена для носимых устройств: 500 кбит/с, 1 Мбит/с, 2 Мбит/с и т.п.	Опционально
…	…	…

Если более одного объекта слоя NAS (или USIM-приложения) доступны и подходят для обслуживания данного носимого устройства, необходимо выбрать только один объект слоя NAS (или USIM-приложение). Для этого носимому устройству и устройству UE необходимо согласовать по радиоинтерфейсу ближней связи то, какие объекты слоя NAS и/или USIM-приложения должны фактически использоваться. На фиг. 9 показан пример диаграммы последовательности сообщений между носимым устройством и устройством UE для такого процесса согласования. При этом может потребоваться более одной итерации. Также возможно, что частью сообщения с ответом о согласовании является встречное предложение. Здесь процесс согласования инициируется носимым устройством. В другом варианте этот процесс может быть инициирован устройством UE. Для краткости на фиг. 9 пропущены возможные структуры сообщений для пары «Предложение о согласовании» и «Ответ о согласовании».

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

Информирование носимого устройства о текущем состояния связи устройства UE

В целом, состояние связи между устройством UE и соответствующей сотовой сетью мобильной связи (например, сетью сотовой связи, работающей в соответствии с 3GPP LTE или LTE-Advanced) будет влиять на (потенциальную) связь носимого устройства.

Сообщения «Индикация состояния» могут передаваться в направлении от устройства UE к носимому устройству по меньшей мере во время начальной фазы сигнализации как часть нового профиля обмена сообщениями.

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

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

В частности, может быть актуальной следующая информация:

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

- режим работы RRC CONNECTED, RRC SUSPENDED или RRC IDLE;

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

- индикатор роуминга;

- индикатор включения (отключения) опции «Мобильные данные» в устройстве UE;

- индикатор нахождения вне зоны действия сети и т.п.

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

Устройство UE сообщает носимому устройству о благоприятной возможности для обмена данными (например, при переходе уровня RRC из состояния IDLE в состояние CONNECTED или в случае, когда устройство UE входит в активный период (On-Duration) режима прерывистого приема (DRX, discontinuous reception)). Подобным образом, устройство UE сообщает носимому устройству, что возможность для обмена данными исчерпана (например, при переходе уровня RRC из состояния CONNECTED в состояние IDLE или в случае, когда устройство UE входит в пассивный период (Off-Duration) режима DRX). Поскольку любой заданный шаблон режима DRX обычно конфигурируется для определенного отрезка времени, может иметь смысл сообщать носимому устройству шаблон конфигурации и валидность режима DRX устройства UE.

Следует отметить, что режим DRX означает «прерывистый прием», т.е. состояние ожидания в технологии LTE, введенное для энергосбережения, в котором устройству UE не требуется контролировать физический нисходящий канал управления (PDCCH, Physical Downlink Control Channel) в каждом субкадре, чтобы проверять наличие доступных нисходящих данных.

В качестве альтернативы, носимое устройство просто отправляет данные через интерфейс ближней связи всякий раз при появлении новых пакетов. Устройство UE буферизирует все входящие пакеты до тех пор, пока не появится благоприятная возможность ретранслировать эти данные через сотовый интерфейс. Кроме того, носимое устройство может помечать свои данные флагом «time-critical» («критичный по времени») или «delay-tolerant» («устойчивый к задержке»). Пока поступают только данные, помеченные как «устойчивые к задержке», устройство UE буферизирует их для будущей восходящей передачи. Когда от носимого устройства поступают данные, помеченные как «критичные по времени», устройство UE может выбрать изменение своего исходного режима и попытаться немедленно ретранслировать данные через сотовый интерфейс. Эта последняя схема поведения может означать переход между состояниями RRC, например, из состояния IDLE в состояние CONNECTED.

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

В таблицах 3 и 4 приведены возможные структуры сообщений для пары сообщений «Индикация состояния» и «Подтверждение» в соответствии с фиг. 10. В табл. 3 показан пример сообщения «Индикация состояния», а в табл. 4 показан пример сообщения «Подтверждение».

Таблица 3

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Индикация состояния» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Вид индикации	Указание вида индикации, например, - первичная индикация; - корректировка на основе событий; - регулярная корректировка; - расписание RRC; - шаблон DRX.	Обязательно
Контейнер изменений
> Переходы между состояниями RRC	Указание направления переходов между состояниями уровня RRC в устройстве UE, например: - из IDLE в CONNECTED; - из SUSPENDED в CONNECTED; - из CONNECTED в IDLE; - из CONNECTED в SUSPENDED; - из SUSPENDED в IDLE; - из IDLE в SUSPENDED.	Опционально
> PLMN	Указание сети PLMN, в которой в настоящее время зарегистрировано устройство UE: - MCC + MNC (шесть разрядов); - отсутствует.	Опционально
> Скорость передачи данных (для всех носимых устройств)	Например, максимальная скорость передачи данных, которая может быть назначена для всех носимых устройств, соединенных с устройством UE: 500 кбит/с, 1 Мбит/с, 2 Мбит/с и т.п.	Опционально
> Роуминг	Указание того, находится ли устройство UE в роуминге, например: - истина; - ложь.	Опционально
> Поддержка мобильных данных	Указание текущего статуса опции «Мобильные данные» в устройстве UE, например: - включена; - отключена.	Опционально
> Вне зоны покрытия	Указание того, находится ли устройство UE вне зоны действия сети, например: - истина; - ложь.	Опционально
> Расписание включения и выключения	Указание деталей долгосрочного расписания переходов между состояниями уровня RRC в устройстве UE.	Опционально
> Шаблон DRX	Указание деталей долгосрочного шаблона режима DRX в устройстве UE.	Опционально
> Возможность TAU	Указание предоставляемой устройством UE возможности для коррекции зоны отслеживания (TAU) для носимого устройства.	Опционально
…	…	…

Таблица 4

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Подтверждение» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Контейнер обратной связи
> Подтверждение	Указание того, был ли соответствующий индикатор состояния успешно получен носимым устройством, например: - истина; - ложь.	Обязательно
> В ответ на	Возврат идентификатора предшествующего сообщения «Индикация состояния».	Обязательно

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

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

Запрос к устройству UE на установление сетевого соединения для носимого устройства.

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

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

Кроме того, носимое устройство может сообщить альтернативный идентификатор, например, временный идентификатор GUTI (Globally Unique Temporary UE Identity) и уникальный идентификатор IMSI (International Mobile Subscriber Identity), чтобы устройство UE могло сначала зарегистрироваться с этим временным идентификатором и использовать идентификатор IMSI в запросе к сети без повторного запроса этой информации.

Информация относительно IP-соединения носимого устройства, например, касающаяся сети пакетной передачи данных (PDN, Packet Data Network), к которой необходимо подключиться носимому устройству, обычно определяется по имени точки доступа (APN, Access Point Name).

Обмен информацией, связанной с аутентификацией, может выполняться, если устройство UE формирует NAS-сообщения от имени носимого устройства, а носимое устройство содержит SIM-карту или модуль USIM. Самым простым (и наименее деструктивным) способом является использование профиля доступа (SAP, SIM Access Profile) в BT SIM-карте, но также возможен обмен этой информацией одновременно с обсуждаемым здесь NAS-обменом. Носимое устройство может также сообщать устройству UE информацию, необходимую устройству UE для доступа к SIM-карте или к модулю USIM носимого устройства с помощью профиля доступа в BT SIM-карте.

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

Если устройство UE имеет полный контроль над объектом слоя NAS, предназначенным для носимого устройства, оно создает и передает сообщение регистрации через сотовое соединение в сеть, которую оно использует в настоящее время. При этом принимается во внимание информация, полученная от носимого устройства и заполняющая информация, относящаяся к устройству UE и к его текущему сетевому соединению.

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

В одном варианте осуществления настоящего изобретения носимое устройство может иметь возможность отправлять сообщение с запросом на регистрацию в устройство UE с применением нового профиля обмена сообщениями и тем самым инициировать установление устройством UE сотового соединения с опорной сетью. Это может быть, например, беспроводное соединение в соответствии с 3GPP LTE или LTE-Advanced. На фиг. 11 показан пример пары таких сообщений.

В этом контексте актуальны следующие детали:

- «Идентификатор носимого устройства» для использования в опорной сети оператора мобильной связи;

- сеть «PLMN», в которой должна быть выполнена регистрация. Эта сеть должна быть подтверждена устройством UE до начала процесса регистрации носимого устройства.

В таблицах 5 и 6 приведены возможные структуры сообщений для пары сообщений «Запрос на регистрацию» и «Подтверждение регистрации» в соответствии с фиг. 11. В табл. 5 показан пример сообщения «Запрос на регистрацию», а в табл. 6 показан пример сообщения «Подтверждение регистрации».

Таблица 5

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Запрос на регистрацию» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Идентификатор носимого устройства	Идентификация носимого устройства (например, в процессе регистрации и во время работы) в опорной сети.	Обязательно
Вспомогательные данные
> PLMN	Указание (списка) сетей PLMN, к которым разрешено подключение носимого устройства, например: MCC + MNC (шесть разрядов).	Опционально
> Альтернативный идентификатор	Альтернативный идентификатор для носимого устройства, например, временный идентификатор GUTI и/или уникальный идентификатор IMSI, чтобы устройство UE могло сначала зарегистрироваться с временным идентификатором и использовать IMSI в сетевом запросе без повторного запроса информации.	Опционально
> Информация о соединении	Информация, относящаяся к IP-соединению носимого устройства, например, касающаяся сети пакетной передачи данных (PDN), к которой необходимо подключиться носимому устройству. Обычно идентификация выполняется по имени точки доступа (APN).	Опционально
> Данные аутентификации	Информация, относящаяся к аутентификации, если устройство UE формирует NAS-сообщения от имени носимого устройства, а носимое устройство содержит SIM-карту или модуль USIM (как описано выше).	Опционально

Таблица 6

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Подтверждение регистрации» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Контейнер обратной связи
> Подтверждение	Указание того, был ли соответствующий запрос на регистрацию успешно получен устройством UE, например: - истина; - ложь.	Обязательно
> В ответ на	Возврат идентификатора предшествующего сообщения «Запрос на регистрацию».	Обязательно

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

Запрос к устройству UE на удержание сотового соединения

Для уменьшения частоты переходов между состояниями уровня RRC из CONNECTED в IDLE и обратно в CONNECTED, например, когда носимое устройство постоянно генерирует небольшие пакеты данных, носимые устройства могут иметь возможность отправлять устройству UE сообщение «Запрос на удержание» через новый профиль обмена сообщениями. Ожидается, что при получении этого сообщения устройство UE будет удерживать текущее сотовое соединение с опорной сетью оператора мобильной связи (например, беспроводное соединение в соответствии с 3GPP LTE или LTE-Advanced) от имени носимого устройства несколько дольше. На фиг. 12 показан пример пары таких сообщений.

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

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

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

В таблицах 7 и 8 приведены возможные структуры сообщений для пары сообщений «Запрос на удержание» и «Ответ об удержании» в соответствии с фиг. 12. В табл. 7 показан пример сообщения «Запрос на удержание», а в табл. 8 показан пример сообщения «Ответ об удержании».

Таблица 7

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Запрос на удержание» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Контейнер
> Прогнозируемый промежуток времени	Указание промежутка времени (рассчитанного или прогнозируемого) носимым устройством, например, 500 мс, 1 с, 2 с и т.д.	Опционально
> Направление трафика	Указание направления трафика, который ожидается от носимого устройства, например: - нисходящий; - восходящий; - оба направления.	Опционально

Таблица 8

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Ответ об удержании» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Контейнер обратной связи
> Подтверждение	Указание того, был ли соответствующий индикатор удержания запроса получен устройством UE, например: - истина; - ложь.	Обязательно
> В ответ на	Возврат идентификатора предшествующего сообщения «Запрос на удержание».	Обязательно
> Временной интервал	Указание промежутка времени определенного (или разрешенного) устройством UE, например, 500 мс, 1 с, 2 с и т.д.	Опционально

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

Разрыв устройством UE сетевого соединения для носимого устройства

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

На фиг. 13 показаны некоторые опциональные сообщения, которые могут быть использованы для выполнения процедуры ранней индикации разрыва соединения. Во-первых, устройство UE сообщает носимому устройству о запланированном (или неизбежном) разрыве соединения (вид сообщения: «Ранняя индикация разъединения»). Если носимое устройство не удовлетворено предложением устройства UE, носимое устройство может сформировать другое предложение относительно разрыва соединения, которое отправляется обратно (вид сообщения: «Ранний ответ о разъединении») и оценивается в устройстве UE и/или в опорной сети.

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

На фиг. 14 устройство UE, которое может (в одном варианте осуществления) содержать объект слоя NAS носимого устройства, информирует носимое устройство об успешном разрыве сетевого соединения носимого устройства (вид сообщения: «Индикация разъединения»). Носимое устройство просто подтверждает это сообщение (вид сообщения: «Подтверждение» («Ack»). Для этого варианта подробные структуры сообщений также не показаны.

Поток сообщений на фиг. 14 может следовать сразу после потока сообщений на фиг. 13. При этом результатом «Оценки предложения» на фиг. 13 может быть «Выполнение разъединения» на фиг. 14; эти действия также могут быть объединены.

Если носимое устройство запрашивает задержку в сообщении «Ранний ответ о разъединении» на фиг. 13 и она предоставляется устройством UE и/или опорной сетью при последующей «Оценке предложения», то сообщения, показанные на фиг. 14, могут поочередно отправляться в более поздний момент времени.

В одном варианте осуществления фиг. 15 может быть альтернативой фиг. 13. Носимое устройство на фиг. 15, которое может (в другом варианте осуществления) содержать собственный объект слоя NAS, запрашивается устройством UE относительно разрыва его сетевого соединения (вид сообщения: «Запрос на разъединение»). Затем носимое устройство может разорвать свое сетевое соединение и подтвердить успешный разрыв соединения (вид сообщения: «Подтверждение разъединения»).

В другом варианте осуществления фиг. 15 может служить альтернативой фиг. 14. В этом случае сообщения, показанные на фиг. 15, могут следовать сразу после потока сообщений на фиг. 13. Таким образом, сообщение «Запрос на разъединение» в соответствии с фиг. 15 может содержать параметры, рассчитанные или определенные в ходе «Оценки предложения» на фиг. 13.

В таблицах 9 и 10 приведены примеры подробных структур сообщений для примера потока сообщений на фиг. 15. В табл. 9 показан пример сообщения «Запрос на разъединение», а в табл. 10 показан пример сообщения «Подтверждение разъединения».

Таблица 9

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Запрос на разъединение» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Контейнер команды на разъединение
> Команда на разъединение	Указание вида команды на разъединение соединения, например: - немедленно; - отложено; - отменено.	Опционально
> Время задержки	Указание разрешенной длительности задержки (если такая задержка была запрошена носимым устройством), например, 500 мс, 1 с, 2 с и т.д.	Опционально
> Удержание контекста для возобновления	Указание того, будет ли контекст носимого устройства храниться в опорной сети (если ожидается, что носимое устройство будет искать другую возможность для ретрансляции), например: - истина; - ложь.	Опционально
> Идентификатор контекста	Идентификация контекста носимого устройства в опорной сети, например, длиной 8 байтов.	Опционально
> Длительность хранения контекста	Указание вышеупомянутой длительности, например, 500 мс, 1 с, 2 с и т.д.	Опционально

Таблица 10

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Подтверждение разъединения» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Контейнер подтверждения
> Подтверждение	Указание того, был ли соответствующий индикатор запроса на разъединение успешно получен носимым устройством, например: - истина; - ложь.	Обязательно
> Выполнение команды	Указание того, была ли выполнена полученная команда на разъединение, например: - истина; - ложь.	Опционально
> В ответ на	Возврат идентификатора предшествующего сообщения «Запрос на разъединение».	Обязательно

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

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

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

Запрос к устройству UE на завершение сетевого соединения для носимого устройства

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

Если объект слоя NAS для носимого устройства находится в устройстве UE, носимое устройство просто запрашивает у устройства UE через интерфейс ближней связи отмену своей сетевой регистрации в узле MME (вид сообщения «Заявка на разъединение»). Таким образом, устройство UE может затем создать и передать запрос на отмену регистрации в узел MME от имени носимого устройства («Выполнение разъединения»). Устройство UE может сообщить носимому устройству о результате этих усилий посредством сообщения «Ответ о разъединении». В таблицах 11 и 12 приведены подробные структуры сообщений для примера потока сообщений в соответствии с фиг. 16. В табл. 11 показан пример сообщения «Заявка на разъединение», а в табл. 12 показан пример сообщения «Ответ о разъединении».

Таблица 11

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Заявка на разъединение» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательно
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Контейнер команды на разъединение
> Команда на разъединение	Указание вида команды на разрыв соединения, например: - немедленно; - отложено.	Опционально
> Время задержки	Указание желательного времени задержки (если такая задержка была запрошена носимым устройством), например, 500 мс, 1 с, 2 с и т.д.	Опционально
> Удержание контекста для возобновления	Указание того, требует ли носимое устройство сохранить свой контекст в опорной сети (если носимое устройство начинает искать другую возможность для ретрансляции), например: - истина; - ложь.	Опционально
> Длительность хранения контекста	Указание вышеупомянутой длительности, например, 500 мс, 1 с, 2 с и т.д.	Опционально

Таблица 12

Информационный элемент	Описание	Наличие
Заголовок сообщения
Версия протокола	Идентификация используемой версии протокола.	Обязательно
Идентификатор сообщения	Уникальный идентификатор этого сообщения.	Обязательно
Вид сообщения	Идентификация этого сообщения как сообщения «Ответ о разъединении» (в рамках нового профиля радиоинтерфейса ближней связи).	Обязательный
Адрес отправителя ближней связи	Идентификация устройства-отправителя, например, идентификатор BT-устройства в составе устройства UE.	Обязательно
Адрес получателя ближней связи	Идентификация предполагаемого устройства-получателя, например, идентификатор BT-устройства в составе носимого устройства.	Обязательно
Контейнер подтверждения
> Подтверждение	Указание того, была ли соответствующая заявка на разъединение успешно получена устройством UE, например: - истина; - ложь.	Опционально
> Выполнение команды	Указание того, была ли выполнена полученная команда на разъединение, например: - истина; - ложь;	Опционально
> Удержание контекста для возобновления	Указание того, будет ли контекст носимого устройства сохранен в опорной сети, например: - истина; - ложь.	Опционально
> Идентификатор контекста	Идентификация контекста носимого устройства в опорной сети, например, длиной 8 байтов.	Опционально
> Длительность хранения контекста	Указание вышеупомянутой длительности, например, 500 мс, 1 с, 2 с и т.д.	Опционально
> В ответ на	Возврат идентификатора предшествующего сообщения «Заявка на разъединение».	Обязательно

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

Если контекст носимого устройства хранится на стороне сети для целей будущего возобновления приостановленного логического соединения (например, на уровне NAS), полезно предоставить носимому устройству (через первое ретранслирующее устройство UE) идентификатор контекста.
Это описано, например, в таблице 9 применительно к сообщению «Запрос на разъединение» и в таблице 12 применительно к сообщению «Ответ о разъединении». Этот идентификатор контекста может использоваться носимым устройством в более поздний момент времени при возобновлении приостановленного соединения. Это позволяет быстрее возобновлять приостановленное соединение при смене (или замене) носимым устройством устройства UE, обладающего возможностями ретрансляции.

В отношении приведенного выше описания предпочтительных вариантов осуществления изобретения следует отметить следующее.

Возможно разделение функций слоя NAS между устройством UE и носимым устройством. Следовательно, настройка «NAS в носимом устройстве» может означать, что носимое устройство ответственно за управление сеансом, регистрацию и безопасность, а устройство UE всегда обеспечивает мобильность (и выполняет некоторые другие функции). Таким образом, согласно изобретению, может иметь смысл обеспечивать меньшую гранулярность для различных функций слоя NAS, например, когда речь идет об обмене информацией о возможностях (информация «Где находится NAS?» может быть заменена на «Где находится экземпляр функциональности NAS?») и о согласовании возможностей (информация «Какой объект слоя NAS следует использовать?» может быть заменена на «Какой экземпляр определенной подфункции слоя NAS следует использовать - который находится в устройстве UE или который находится в носимом устройстве?»).

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

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

Что касается возможных вариантов реализации на фиг. 2 и 3, то теоретически существует также третий вариант реализации, в котором модуль USIM1 (съемный или несъемный) расположен в носимом устройстве, а объект NAS1 находится в устройстве UE. Для краткости этот редкий вариант конфигурации намеренно опущен. Сообщения, потоки сообщений, события и информационные элементы для рассмотрения этого третьего варианта реализации могут быть реализованы аналогично тому, что уже подробно описано в этом изобретении.

Терминология, принятая в LTE и использованная здесь для различных состояний уровня RRC (CONNECTED, SUSPENDED, IDLE), не должна пониматься как ограничивающая это изобретение средой LTE. Для других технологий радиодоступа могут быть определены другие состояния устройства UE. Например, для технологии радиодоступа 5G, являющейся преемником LTE, могут быть определены и аппаратно поддерживаться устройством UE те же, подобные или другие состояния уровня RRC.

Несмотря на то, что BT может представлять собой предпочтительный вариант осуществления настоящего изобретения, технология беспроводной ближней связи (радиоинтерфейс ближней связи согласно фиг. 2 и фиг. 3), поддерживаемая носимым устройством и устройством сотовой связи для обмена сообщениями, не обязательно должна быть во всех случаях технологией BT, или технологией, основанной на BT. Другие беспроводные технологии ближнего радиуса действия, такие как WiFi, также могут быть использованы в способах, описанных в этом документе, и они, как таковые, явно включены в объем настоящего изобретения.

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

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

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

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

- указание того, было ли дано согласие на создание персональной сети;

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

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

- запрос к устройству мобильной связи на поддержание соединения с опорной сетью;

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

- запрос к устройству мобильной связи на завершение соединения с опорной сетью для носимого устройства.

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

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

- указание того, было ли дано согласие на создание персональной сети;

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

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

- запрос к устройству мобильной связи на поддержание соединения с опорной сетью;

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

- запрос к устройству мобильной связи на завершение соединения с опорной сетью для носимого устройства.

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

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

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

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

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

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

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

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

11. Способ по п. 10, отличающийся тем, что носимое устройство информируется заранее о планируемом разрыве соединения носимого устройства с опорной сетью.

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

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

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

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

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

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

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

19. Способ по любому из пп. 16-18, отличающийся тем, что устройство мобильной связи информирует носимое устройство о текущих и будущих изменениях в состоянии связи для соединения устройства мобильной связи с опорной сетью.

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

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

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

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

24. Способ по любому из пп. 16-23, отличающийся тем, что устройство мобильной связи инициирует разрыв соединения носимого устройства с опорной сетью.

25. Способ по п. 24, отличающийся тем, что носимое устройство информируется заранее о планируемом разрыве соединения носимого устройства с опорной сетью.

26. Способ по любому из пп. 16-25, отличающийся тем, что носимое устройство передает устройству мобильной связи запрос на разрыв соединения с опорной сетью.

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

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

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