Method for enabling a mobile communication device to communicate with a user device via a short-range radio interface connection

Abstract

The present invention provides a method for enabling a mobile communication device to communicate with a user device via a short-range radio interface connection, wherein the mobile communication device acts as a relay node for enabling the user device to connect to a core network, the method comprising exchanging communication status messages to connect the user device to the mobile communication device and using the mobile communication device as a relay node to operate the user device.

Description

[0001] This case is a divisional application of a patent application with an application date of November 3, 2017, application number 201780068181.3, and invention name “Message Exchange for Wearable Devices”. Technical Field

[0002] The present invention relates to message transmission performed between a wearable device and a mobile communication device (usually referred to as user equipment, UE: User Equipment). Background Art

[0003] The mobile communication terminal can select, reselect and connect to a mobile relay node that provides access to the core network of the mobile network operator (MNO). The air interface between the mobile communication terminal and the mobile relay node can be based on LTE or some short-range technologies such as Bluetooth, BT (BlueTooth) or WiFi.

[0004] It is known that relay nodes are controlled to form and manage device-to-device (D2D) clusters in an opportunistic manner, for example within the scope of the ProSe (Proximity Services) feature of 3GPP. Many of these principles can be reused to connect wearable devices to mobile phones acting as mobile relay nodes.

[0005] For example, US 9,380,625 B2 describes a communication device with D2D capability, which is signaled to a base station. US 2016 / 0150373 A1 describes the use of proximity services to form a relay when a user equipment UE is not within the range of a group communication service. The second UE acts as a relay UE for group communication. US 2012 / 0238208 A1 describes a UE with a short-range wireless transceiver that can be used to form an opportunistic network. US 2012 / 0250601 A1 describes the use of a non-access layer NAS, a bearer, and a NAS bearer for exchanging data between a remote device and a core network using a short-range radio connection. US 8,682,243 B2 describes the use of a network selection device to decide whether an opportunistic network or a direct connection should be used to establish a connection. US 2013 / 0137469 A1 describes a method for transmitting an opportunistic network message.

[0006] US 2016 / 0295622 A1 describes a technique for connecting a first wireless device such as a laptop to a network via a second wireless device such as a mobile phone. Local connection information such as data rate, RSSI or bit error rate can be broadcast so that other nearby devices can compare the connection quality with their own connection quality.

[0007] US 2015 / 0245186 A1 describes wireless pairing between a first and a second electronic device. Once a connection is established, information such as capability exchange can be performed.

[0008] A widely implemented short-range wireless connection is a connection according to the BT standard. Many products such as phones, tablets, media players, laptops, console gaming devices, healthcare devices and watches contain such BT functionality. The technology is useful when information is transmitted between two or more devices that are close to each other in low bandwidth situations. The protocol defined for BT simplifies the discovery and setup of services between two devices. BT devices can advertise the services they provide. This makes it easier to use the service because more of the security, network address and permission configuration can be automated compared to many other network types.

[0009] The BT protocol stack is divided into two parts: a "controller stack" containing the timing-critical radio interface and a "host stack" that handles high-level data. Between these two parts of the protocol stack, the host controller interface (HCI) can be deployed. The controller stack is typically implemented in a low-cost silicon device that contains the BT radio and a microprocessor. The host stack is typically implemented as part of the operating system or as an installable package on top of the operating system. For integrated devices such as BT headsets, the host stack and controller stack can be executed on the same microprocessor (i.e., no HCI is required) to reduce mass production costs; this is called a "host-less" system.

[0010] An important protocol is the Service Discovery Protocol (SDR). It allows devices to discover services provided by other devices and their associated parameters. For example, a mobile phone is used with a BT headset. The phone uses SDR to determine which BT profiles the headset supports (e.g., Headset Profile, Hands-Free Profile, Advanced Audio Distribution Profile (A2DP), etc.) and the protocol multiplexer settings required for the phone to connect to the headset using each profile. Each service is identified by a Universally Unique IDentifier (UUID), and official services (i.e., BT profiles) are assigned short-format UUIDs (16 bits instead of the full 128 bits). In the protocol stack, SDR is usually bound to (or integrated in) L2CAP.

[0011] Data is exchanged between two (or more) BT devices via so-called BT profiles, which are defined (in terms of parameters and behavior) to support certain services. These BT profiles reside in higher layers of the protocol stack (e.g., the application layer) and must be implemented on both peer devices in order to support a certain service. Typically, compliance with the profile saves some time for retransmission of parameters before a bidirectional link becomes valid. There are a wide range of BT profiles describing many different types of applications or use cases for BT devices. For example, one of the most commonly used BT profiles to be used with a cellular phone, the headset profile, can request the establishment of an audio channel (relying on a synchronous connection-oriented (SCO) link for audio encoded at 64kbit / s CVSD or PCM) plus some control channels for exchanging minimal control commands (supporting a subset of AT commands from GSM 07.07), including the ability to ring, answer a call, hang up, and adjust the volume. A very important and mandatory BT profile is the Generic Access Profile (GAP). It provides the basis for all other profiles. GAP defines how two BT units can discover and establish a connection with each other.

[0012] Another BT profile related to the present invention is the BT Network Encapsulation Protocol (BNEP). It is used to transmit data of another protocol stack via the L2CAP channel. Its main purpose is to transmit IP packets in the Personal Area Network profile. BNEP performs a function similar to the SubNetwork Access Protocol (SNAP) in wireless LANs. In wireless LANs, a SNAP field can be added to the data packet at the transmitting node to allow the receiving node to pass each received frame to the appropriate device driver that understands the given protocol.

[0013] Further related to the present invention is the 3GPP LTE mobile communication standard. The LTE air interface (also referred to as the Uu interface) is logically divided into three protocol layers. The entities that ensure and provide the functions of the corresponding protocol layers are implemented in the mobile terminal and the base station. The bottom layer is the physical layer (PHY: Physical Layer), which represents protocol layer 1 (L1) according to the OSI (Open System Interconnection: Open System Interconnection) reference model. The protocol layer arranged above the PHY is the data link layer, which represents protocol layer 2 (L2) according to the OSI reference model. In the LTE communication system, L2 includes multiple sublayers, namely the medium access control (MAC: Medium Access Control) sublayer, the radio link control (RLC: Radio Link Control) sublayer and the packet data convergence protocol (PDCP: Packet Data Convergence Protocol) sublayer. The top layer of the Uu air interface is the network layer, which is the protocol layer 3 (L3) according to the OSI reference model and consists of the radio resource control (RRC: Radio Resource Control) layer on the C plane. On the C-plane, there is also a NAS (Non-Access Stratum) protocol layer.

[0014] Each protocol layer provides its services to the protocol layer above it via defined service access points (SAPs). In order to better understand the protocol layer architecture, clear names are assigned to the SAPs: PHY provides its services to the MAC layer via transport channels, the MAC layer provides its services to the RLC layer via logical channels, and the RLC layer provides its services to the PDCP layer as a data transmission function of the RLC mode, namely TM (Transparent Mode), UM (Unacknowledged Mode) and AM (Acknowledged Mode). In addition, the PDCP layer provides its services to the RRC layer and the upper layers of the U-plane via radio bearers, specifically providing its services to the RRC as signaling radio bearers (SRBs) and providing its services to the upper layers of the U-plane as data radio bearers (DRBs). According to LTE, a maximum of 3 SRBs and 8 DRBs are currently supported.

[0015] The radio protocol architecture is not only divided horizontally into the above-mentioned protocol layers; it is also divided vertically into a "control plane" (C-plane) and a "user plane" (U-plane). The entities of the control plane are used to handle the exchange of signaling data between the mobile terminal and the base station, which are required to establish, reconfigure and release physical channels, transport channels, logical channels, signaling radio bearers and data radio bearers, while the entities of the user plane are used to handle the exchange of user data between the mobile terminal and the base station.

[0016] According to LTE, each protocol layer has specific prescribed functions:

[0017] The PHY layer is mainly responsible for i) error detection on the transport channel; ii) channel coding / decoding of the transport channel; iii) hybrid ARQ soft combining; iv) mapping the coded transport channel to the physical channel; and v) modulation and demodulation of the physical channel.

[0018] The MAC layer is mainly responsible for i) mapping between logical channels and transport channels; ii) error correction through HARQ; iii) logical channel priority; iv) transport format selection.

[0019] The RLC layer is mainly responsible for i) error correction through ARQ, ii) concatenation, segmentation and reassembly of RLC SDU (Service Data Unit); iii) re-segmentation and reordering of RLC data PDU (Protocol Data Unit). In addition, the RLC layer is modeled so that there is an independent RLC entity for each radio bearer (data or signaling).

[0020] The PDCP layer is mainly responsible for the header compression and decompression of the IP (Internet Protocol) data stream, the encryption and decryption of the user plane data and the control plane data, and the integrity protection and integrity verification of the control plane data. The PDCP layer is modeled so that each RB (i.e., DRB and SRB, except SRB0) is associated with a PDCP entity. Each PDCP entity is associated with one or two RLC entities according to the RB characteristics (i.e., unidirectional or bidirectional) and the RLC mode.

[0021] The RRC layer is mainly responsible for control plane signaling between mobile terminals and base stations and performs the following functions: i) broadcasting system information, ii) paging, iii) establishing, reconfiguring and releasing physical channels, transport channels, logical channels, signaling radio bearers and data radio bearers. Signaling radio bearers are used to exchange RRC messages between mobile terminals and base stations.

[0022] According to E-UTRA (LTE) technology, the difference between C-plane (control plane) and U-plane (user plane) is Figure 1A and 1B The RRC protocol and all lower layer protocols (PDCP, RLC, MAC, and PHY) terminate at the eNB, while the NAS protocol layer terminates at the MME residing in the EPC. The interface between the UE and the eNB is the LTE air interface (called the Uu reference point), and the interface between the eNB and the MME is called S1. Figure 1A The lower layers of the S1 interface are not shown.

[0023] Future wearable communication devices may or may not come with NAS functionality. If future wearable devices do not come with NAS functionality and should be controllable and / or known to the core network (i.e. have a subscription with the MNO), it may be desirable to adapt the NAS entity in the UE to serve both the UE (operating as a relay node in this scenario) and the wearable device, or even to implement more than one NAS entity in the UE; one NAS entity for the UE itself and one or more additional NAS entities for various wearable devices, as explained in US 2013 / 0137469 A1.

[0024] Current BT technology does not provide adequate methods to connect a wearable communication device (with or without NAS functionality, denoted herein as a "wearable device") to a cellular communication device (without, one or more than one NAS entity dedicated to the wearable device, denoted herein as a "UE") that can be configured to relay transmissions to the MNO's core network in the uplink direction and / or to relay transmissions from the MNO's core network in the downlink direction.

[0025] The NAS layer that directly controls the communication with the cellular mobile core network of the wearable device can reside in the wearable device itself or in the connected UE. If only one of the respective devices, UE or wearable device, has a NAS layer implementation, then the NAS layer will control the wearable device. If both devices have a NAS implementation, the actual control must be negotiated.

[0026] As such, before the wearable device can register in the network, an exchange of NAS layer capabilities and potential negotiation between the wearable device and the UE regarding control of the wearable device must occur.

[0027] If the UE has multiple NAS layer implementations that may provide services to multiple connected wearable devices, it associates the corresponding NAS layer entity with the specific wearable device and the corresponding BT link. Summary of the invention

[0028] In one aspect, the present invention provides a method for enabling a mobile communication device to communicate with a user device via a short-range radio interface connection, the mobile communication device acting as a relay node for enabling the user device to connect to a core network, the method comprising transmitting a message via the short-range radio interface connection using a message exchange profile, the message comprising at least one of: a mutual non-access stratum capability exchange, wherein the non-access stratum capabilities of the user device and the mobile communication device for connecting the user device to the core network are exchanged; an indication of user preferences and user settings to the user device; a request for the mobile communication device to maintain a connection with the core network; a message for the user device to release the connection with the core network through the mobile communication device; and a request for the mobile communication device to terminate the connection between the core network and the user device.

[0029] The messages may be transmitted over a short-range radio interface connection using a message exchange profile that defines procedures and standardized behaviors for message exchanges between two devices.

[0030] In another aspect, the present invention provides a method for enabling a mobile communication device to communicate with a user device via a short-range radio interface connection, the mobile communication device acting as a relay node for enabling the user device to connect to a core network, the method comprising negotiating NAS capabilities to connect the user device to the mobile communication device and operating the user device using the mobile communication device as a relay node.

[0031] The message exchange framework for wearable devices, which may be implemented as a new BT profile, for example, provides the following benefits. Future wearable devices (with and without NAS functionality) can register and deregister in the MNO's core network via a relay UE. This allows the wearable device to be controlled and / or known by the core network (i.e., the wearable device can subscribe with the MNO without having a cellular modem).

[0032] The described process includes switching the capabilities of the device over a short-range interface and configuring relay functionality based on user preferences, individual user settings, and overall network policy. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0034] Figure 1A shows the protocol termination points in the control plane;

[0035] Figure 1B shows the protocol termination points in the user plane;

[0036] Figure 2 shows a schematic connection of a user device or a wearable device to a core network via a user equipment device, a UE and a base station, wherein the user device uses a NAS entity in the UE;

[0037] Figure 3 Shows Figure 2 a variation of the arrangement of wherein the user device uses its own NAS entity;

[0038] Figure 4 A schematic diagram showing the inter-core network exchange of NAS-specific information;

[0039] Figure 5A A schematic diagram showing the intra-core network and inter-MME exchange of NAS-specific information;

[0040] Figure 5B A schematic diagram showing the intra-core network and inter-functional slice exchange of NAS-specific information;

[0041] Fig. 6AA schematic diagram showing the intra-MME exchange of NAS-specific information;

[0042] Figure 6B A schematic diagram showing intra-functional slice exchange of NAS-specific information;

[0043] Figure 7 is a schematic diagram of the interaction between the user equipment, the core network and the NAS entity in the UE;

[0044] Figure 8 shows a bidirectional capability exchange between a wearable device and a UE initiated by the wearable device;

[0045] Fig. 9 A message pair is shown for a negotiation proposal that may be used between a wearable device and a UE, the negotiation proposal being used to negotiate which NAS entity and / or USIM application to use if more than one option exists, where: initiated by the wearable device;

[0046] Fig.10 A message pair for status indication is shown, which can be used to indicate a communication status change, where: an event trigger;

[0047] Fig.11 shows a message pair for a registration request which may be used to trigger a UE to set up a cellular connection with a core network;

[0048] Fig.12 A message pair for a keep request is shown, which can be used to request the UE to maintain a cellular connection with a core network;

[0049] Fig.13 A message pair is shown for an early release indication which may be used to indicate in advance an upcoming connection release;

[0050] Fig.14 A message pair for a release indication is shown, which can be used to notify a wearable device about a released network connection;

[0051] Fig.15 shows a message pair for a release request which may be used to request a wearable device to perform a release of a network connection;

[0052] Fig.16 A message pair for a release query is shown, which may be used by a wearable device to request a UE to perform a release of a network connection; and

[0053] Fig.17 A message pair is shown for a release indication, which may be used to notify a UE about a release of a network connection performed by a wearable device. DETAILED DESCRIPTION

[0054] The present invention relates to the definition of message exchange profiles for deployment over a short-range air interface (e.g., BT) between a wearable device ("wearable device") (e.g., smart watch, fitness tracker, etc.) and a cellular communication device ("UE") (e.g., mobile phone) acting as a relay node.

[0055] The profile may include procedures and standardized information exchange between two devices to achieve (at least one of) the following:

[0056] Mutual NAS capability exchange;

[0057] indicating user preferences and user settings to the wearable device;

[0058] Notifying the wearable device about the current communication status of the UE;

[0059] Requesting the UE to set up a network connection for the wearable device;

[0060] Request the UE to maintain cellular connection;

[0061] releasing, by the UE, a network connection for the wearable device; and

[0062] Request the UE to terminate the network connection for the wearable device.

[0063] Mutual Capability Exchange

[0064] Before the wearable device can exchange user data with the core network of the MNO via the cellular communication device acting as a relay UE, the two devices need to exchange their NAS capabilities regarding connecting the wearable device to the cellular network. Specifically, the following information may be relevant:

[0065] The wearable device needs to be enabled to indicate to the UE that it is a wearable device, and the UE needs to be enabled to indicate to the wearable device that it has relay capabilities. To this end, two new device classes are proposed to be introduced and used in the novel message exchange profile during the initial phase of signaling:

[0066] Wearables can signal: “I am a wearable” and

[0067] The UE can signal: "I am a UE with relay capability".

[0068] In some scenarios, finer segmentation makes sense. For example, the category “wearables” could be broken down into “glasses,” “fitness trackers,” “watches,” “jewelry,” etc.

[0069] Furthermore, in certain scenarios it seems beneficial to let the UE announce whether it has a "standby" subscription left, i.e. an unused USIM application dedicated to serving the wearable device. The USIM application may be e.g.

[0070] Resides on a removable USIM card inserted into the UE, or

[0071] Inseparably installed on the circuit of the UE.

[0072] The wearable device may announce its cellular control capabilities, ie whether the wearable device has an implemented NAS entity and / or an included (either embedded or removable, ie inserted into a slot) USIM application.

[0073] Furthermore, the UE may inform the wearable device whether other devices are connected to the UE and whether these devices may communicate with the wearable device and how to, for example, enable establishment of a Personal Area Network (PAN).

[0074] If more than one NAS entity (or USIM application) is available and suitable for serving a given wearable device, only one NAS entity (or USIM application) is selected (i.e., according to the present invention, the actual use / activation of the NAS entity and / or USIM application is negotiated between the wearable device and the UE over the short-range air interface).

[0075] The "mutual NAS capabilities exchange" process may include the following steps:

[0076] Option 1

[0077] Precondition: The wearable device contacts the UE for the first time.

[0078] Either device transmits a message containing its capabilities, possibly the wearable device first, then the UE following (based on previously received capabilities of the wearable device to propose some parameters for negotiation).

[0079] To complete the negotiation, the wearable device confirms the final parameters.

[0080] Post-condition: Both devices set up the service according to the exchanged capabilities and parameters.

[0081] Option 2

[0082] Prerequisite: Both UE and wearable device are connected.

[0083] The capability set changes (for example, the user has disabled mobile roaming).

[0084] The device (in case of changes) sends a capability update; this is then acknowledged by the peer device.

[0085] If the capabilities at the peer device have also changed, confirmation is completed with a return capability update.

[0086] If the capability update contains parameters to be negotiated, the update is confirmed with the negotiation result.

[0087] A detailed example message sequence chart is discussed below.

[0088] Indicating user preferences and user settings to wearable devices

[0089] For the initial phase of signaling, it may also be relevant whether the user and / or his subscription allows / does not allow or prefers / rejects certain (types of) wearable devices (or services) to connect to the UE. Specifically, the following information may be relevant.

[0090] Information about user preferences (e.g., set on the UE), general network policies, or individual contract settings (e.g., read from a core network database) can be sent from the UE to the wearable device about the types of remote devices that are allowed (or preferred) / not allowed (not preferred) to connect to a given UE. In some scenarios, it may even make sense to indicate that the maximum number of wearable devices has been met, or to signal a maximum number of additional wearable devices that can still be connected to the UE in question (note: regarding the maximum number of connected wearable devices, this may also be a UE capability rather than a user preference).

[0091] Notify the wearable device about the current communication status of the UE

[0092] Generally, the communication status between the UE and the corresponding cellular mobile communication network (e.g., a cellular communication network operating according to 3GPP LTE or LTE-Advanced) will affect the (potential) communication of the wearable device. Therefore, further information is proposed to be exchanged between the UE and the wearable device as part of a novel message exchange profile, for example during an initial phase of signaling.

[0093] Since the communication state of the UE may change over time, it is also proposed to enable the exchange of such layer 3 information (if required) during an ongoing short-range connection. Therefore, in order to maintain a satisfactory connection of the wearable device, periodic or event-based updates (indications of state changes) may be required. Specifically, the following layer 3 information may be relevant:

[0094] The currently registered PLMN. This can be important because if the UE is not registered with the correct cellular communications network for any reason then it will not be able to submit any messages (other than its own initial registration).

[0095] RRC connected, RRC suspended and RRC IDLE operating modes.

[0096] data rates that can be provided to

[0097] A single wearable device; or

[0098] a wearable device subcategory; or

[0099] A set of wearable devices.

[0100] Out of coverage indicator,

[0101] etc.

[0102] Furthermore, it may be beneficial to inform the wearable device about upcoming (i.e., soon to occur) changes on the cellular link over a short-range interface, in order to allow the wearable device to perform data transfers in a more efficient manner. For example, coordinated (i.e., synchronized) transmission of keep-alive messages to various application servers on the Internet would reduce the need for the UE to continuously (re)connect to the cellular network (i.e., continuously perform state transitions) for small data packets. Therefore, it is proposed that means of exchanging a scheduled schedule for data transfers be sent as part of a novel message exchange profile to improve the efficiency of connecting a wearable device to a UE. There are different options to achieve this goal:

[0103] When a good opportunity for data exchange comes (for example, when the RRC state changes from IDLE to

[0104] The UE indicates this to the wearable device when the RRC state transitions from CONNECTED to IDLE, or when the UE enters a DRX on period. Similarly, when the opportunity to exchange data has passed (e.g., when the RRC state transitions from CONNECTED to IDLE, or when the UE enters a DRX off period), the UE indicates this to the wearable device. Since any given DRX mode is typically configured for a specific period, it may make sense to signal the UE's DRX configuration mode and validity to the wearable device.

[0105] Note: DRX = Discontinuous Reception, a sleep state introduced in LTE to save power. In this state, the UE does not need to monitor the PDCCH in each subframe to check whether there is available downlink data.

[0106] Alternatively, the wearable device simply sends the data via the short-range interface whenever a new data packet becomes available. The UE buffers all incoming data packets until there is an opportunity to relay the data over the cellular interface. In addition, the wearable device may mark its data with a "time-critical" flag or a "delay-tolerant" flag. As long as only "delay-tolerant" data is received, the UE buffers it for future uplink transmissions. When "time-critical" data is received from the wearable device, the UE may choose to deviate from its original mode and attempt to relay the data immediately over the cellular interface. The latter behavior may imply an RRC state transition, for example, from IDLE to CONNECTED.

[0107] Alternatively, the UE indicates to the wearable device the time remaining until an opportunity for data exchange becomes available (eg, for a tracking area update).

[0108] Request UE to set up network connection for wearable device

[0109] The wearable device may be enabled to send a special request message to the UE using a novel message exchange profile, thereby triggering the UE to set up a cellular connection with the core network. In one embodiment (i.e., when it is decided during the mutual capability exchange that the NAS entity in the UE should be used for the wearable device), the request message may be simultaneously triggered by the UE to register the wearable device in the core network (either by using the same NAS connection as the core network or by using a separate NAS connection dedicated to the wearable device).

[0110] Request UE to maintain cellular connection

[0111] During an ongoing connection over a short-range interface, it may be desirable for the wearable device to indicate to the UE

[0112] Can we expect more UL data from wearable devices soon?

[0113] Whether the wearable device is expecting downlink data (eg, contents of a web page, a reply to a keep-alive message, etc.) in response to a previously sent uplink message (eg, HTTP GET request, keep-alive message, etc.).

[0114] At this point, the UE may choose to maintain the cellular connection for a short period of time (e.g., a predefined or predicted amount of time), thereby potentially alleviating the need for frequent transitions of the RRC state from CONNECTED to IDLE and back to CONNECTED again. The "wait time" may be calculated by the UE based on previous transmission characteristics (e.g., taking into account earlier responses from the same or similar content servers, application peers, etc.).

[0115] Release network connection for wearable device via UE

[0116] When an ongoing connection over a cellular air interface (e.g., LTE Uu) draws to a close, it is desirable to terminate both connections (the connection over the cellular link and the connection over the short-range air interface) in a coordinated manner. This is not possible in all cases (e.g., in the case where the UE experiences a sudden radio link failure over the cellular air interface), but it is definitely advisable whenever possible. Depending on where the NAS functionality of the wearable device resides, there are two different options for the coordination approach. In both cases, the UE must inform the wearable device over the short-range interface about the impending termination of the cellular connection, and the wearable device may react as follows:

[0117] The NAS entity for the wearable device resides in the UE: an appropriate reaction of the wearable device may be to stop application layer activity and connections to relevant servers. Another appropriate reaction of the wearable device may be to request the UE to avoid terminating the cellular connection between the UE and the infrastructure so that the NAS connection of the wearable device can remain active. Alternatively, the wearable device may request the UE to postpone the termination procedure. Such a request may include a favorable time span or information about the motivation for the request that may cause the UE to not proceed. A possible motivation may be that the wearable device finds another suitable UE to connect to during the indicated time span. In some cases, it is also desirable for the wearable device to indicate when it is (approximately or actually) ready for the UE to terminate the connection over the cellular air interface.

[0118] The wearable device implements its own NAS entity: In this case, the wearable device itself communicates with the relevant MME in the core network of the mobile network operator to deregister at the NAS layer. Once this is done, the wearable device can indicate to the UE that it has successfully released its registration so that the connection over the short-range air interface (lower layers) and the connection over the cellular air interface (at the NAS layer from the UE's perspective as well as the lower layers) can be terminated.

[0119] Request the UE to terminate the network connection for the wearable device

[0120] When the wearable device actively terminates an ongoing connection, there are also two different signaling options, depending on where the wearable device's NAS entity resides:

[0121] The NAS entity for the wearable device resides in the UE: the wearable device simply indicates to the UE over the short range interface that it requests the release of its registration at the MME, so that the UE can then generate and transmit a registration release request to the MME on behalf of the wearable device. In theory, the UE can use any of its NAS layers to achieve this, preferably the one that is allocated to and used on behalf of the wearable device. If the UE uses its own NAS connection for this, some inter-core network or intra-core network information exchange will be required (details will be discussed below).

[0122] The wearable device implements its own NAS entity: the wearable device directly requests release from the relevant MME through its own NAS connection. Once the procedure is successfully completed, the wearable device simply informs the UE about this result over the short-range air interface.

[0123] Figure 2 and 3 Examples of two different implementation options are shown: Figure 2 In the NAS entity for wearable devices, it resides in the UE; in Figure 3 In the wearable device, the wearable device implements its own NAS entity.

[0124] exist Figure 3 In an example implementation of the wearable device, the wearable device also has its own USIM application. In one embodiment, this can be an embedded USIM (eUSIM) that is inseparably mounted to the circuit of the wearable device.

[0125] Figure 2 and 3 Two NAS entities are shown residing in the same core network domain. This need not be the case in all deployment scenarios: the two NAS entities may be located in different core network domains, in different MMEs, or even in different functional network slices (see Figure 4 to 6).

[0126] In certain deployment scenarios, it may make sense to allow information to be exchanged between two NAS entities on the core network side, regardless of whether they are located in the same or different core network domains, MMEs or functional network slices.

[0127] For example, if the wearable device has its own NAS entity ("NAS1", e.g. Figure 3) and triggers certain actions at its own NAS layer, the two NAS entities on the network side can coordinate themselves in such a way that NAS1 notifies (or talks to) the NAS entity assigned to the UE ("NAS2"), and vice versa. Therefore, according to the present invention, data related to an action triggered by the first device using the first NAS connection (e.g., a registration release command sent by the wearable device, step 1) can be submitted to the second device via the second NAS connection (e.g., indicating to the UE that the wearable device has successfully terminated its connection at the NAS layer, step 3), and vice versa, as shown in FIG. Figure 7 Step 2 depicts the inventive exchange of NAS specific data between the two NAS entities involved on the network side.

[0128] Mutual capability exchange and user preferences and user settings

[0129] According to one aspect of the present invention, a one-way or two-way capability exchange may be performed whenever the wearable device attempts to re-register with the UE. For example, when requesting information from the UE in order to find out whether the UE is providing any relay services, the wearable device may let the UE know:

[0130] It is a "watch" type wearable device.

[0131] It implements the NAS entity.

[0132] It inserts the USIM which verifies the user's identity.

[0133] For example, in response to a request received from the wearable device, the UE may indicate to the wearable device:

[0134] It is a UE type device.

[0135] It provides wearable devices with the core network relay capabilities of mobile network operators.

[0136] It implements an alternate NAS entity for use by wearable devices.

[0137] It has a backup USIM application for use with wearable devices.

[0138] Both devices (UE and wearable device) are currently controlled / operated by the same user.

[0139] It can support the establishment of a Personal Area Network (PAN).

[0140] It can connect to up to three different wearable devices.

[0141] In addition, the UE may transmit the following information related to user preferences and / or user settings and / or network policies to the wearable device, either in the same response message or in a subsequent (pair of) messages:

[0142] The user consent is given to establish a personal area network (PAN).

[0143] The network policy grants connectivity to a maximum of two wearable devices.

[0144] The user profile only allows wearable devices of the subcategories "watches" and "jewelry" to connect to the UE.

[0145] Figure 8 An exemplary message sequence diagram between a wearable device and a UE for mutual capability exchange is shown in Tables 1 and 2 below. Figure 8 Table 1 shows an example of a capability request message, and Table 2 shows an example of a capability response message.

[0146] Table 1

[0147]

[0148]

[0149] Table 2

[0150]

[0151]

[0152]

[0153] If more than one NAS entity (or USIM application) is available and suitable for serving a given wearable device, only one NAS entity (or USIM application) needs to be selected. To do this, the wearable device and the UE will have to negotiate over the short-range air interface which NAS entity and / or USIM application is actually used. Fig. 9 An exemplary message sequence diagram between the wearable device and the UE for the negotiation process is shown. Multiple iterations may be required. It is also possible that the counter-proposal is part of the negotiation response message. Here, the negotiation process is initiated by the wearable device. Alternatively, the process may be initiated by the UE. For brevity, the following sections will be skipped. Fig. 9 A possible message structure for negotiating an offer / response pair.

[0154] One aspect of the present invention is that the wearable device and the UE providing relay functionality to the core network of the MNO can first exchange their capabilities with each other and then establish, terminate or suspend a (logical) connection for the wearable device to access the core network of the MNO. User preferences, individual user settings and general network policies can also be considered within the scope of the disclosed message exchange framework.

[0155] Notify the wearable device about the current communication status of the UE

[0156] Generally, the communication status between the UE and a corresponding cellular mobile communication network (eg, a cellular communication network operating according to 3GPP LTE or LTE-Advanced) will affect the (potential) communication of the wearable device.

[0157] "Status indication" messages may be exchanged from the UE to the wearable device as part of a message exchange profile at least during the initial phase of signaling.

[0158] Since the communication state of the UE may change over time, this exchange of information may also be implemented during an ongoing short-range connection (if necessary). Therefore, in order to maintain a satisfactory connection of the wearable device, periodic or event-based updates (state changes) may be required.

[0159] Fig.10 An exemplary message sequence diagram between a UE and a wearable device initiated by the UE is shown to notify the wearable device of recent changes in the communication state of the UE. Here, the transmission of a "status indication" message is triggered when an event is detected. Possible events may include the loss of a cellular link (e.g., a "radio link failure" in a LIE), a reduction or increase in the data rate through the cellular link, an RRC state transition in the UE, or the like. Alternatively or additionally, the UE may also be configured to periodically send a "status indication" message.

[0160] Specifically, the following information may be relevant:

[0161] The currently registered PLMN. This may be important when the wearable device is bound to a subscription, because if the UE is not registered with the correct cellular communication network for any reason, it will not be able to submit any messages on behalf of the wearable device.

[0162] RRC CONNECTED, RRC SUSPENDED and RRC IDLE operating modes.

[0163] Data rates can be provided to

[0164] A single wearable device; or

[0165] a wearable device subcategory; or

[0166] A set of wearable devices.

[0167] Roaming indicator.

[0168] Indicator for (de)activation of the "Mobile Data" option in the UE.

[0169] Out of coverage indicator.

[0170] etc.

[0171] In another embodiment of the present invention, the wearable device can be notified via a short-range interface about upcoming (i.e., soon-to-occur) changes on the cellular link to allow the wearable device to perform data transfers in a more efficient manner. For example, the coordinated (i.e., synchronized) transmission of keep-alive messages to various application servers on the Internet will reduce the need for the UE to continuously reconnect to the cellular network (i.e., continuously perform state transitions) due to small data packets. Therefore, a schedule for data transfer can be sent as part of a message exchange profile to improve the efficiency of connecting the wearable device to the UE. There are different options to achieve this goal:

[0172] When a good opportunity for data exchange arrives (e.g., when the RRC state transitions from IDLE to CONNECTED, or when the UE enters a DRX on period), the UE indicates this to the wearable device. Similarly, when the opportunity to exchange data has passed (when the RRC state transitions from CONNECTED to IDLE, or when the UE enters a DRX off period), the UE indicates this to the wearable device. Since any given DRX mode is typically configured to be valid for a specific period, it may make sense to send the UE's DRX configuration mode and validity signal to the wearable device.

[0173] Note: DRX = Discontinuous Reception, a sleep state introduced in LTE to save power. In this state, the UE does not need to monitor the PDCCH in each subframe to check whether there is available downlink data.

[0174] Alternatively, the wearable device simply sends the data over the short range interface whenever a new data packet is available. The UE buffers all incoming data packets until there is an opportunity to relay the data over the cellular interface. In addition, the wearable device can mark its data with a "time-critical" flag or a "delay-tolerant" flag. As long as only "delay-tolerant" data is received, the UE buffers it for future uplink transmissions. When "time-critical" data is received from the wearable device, the UE may choose to deviate from its original mode and attempt to relay the data immediately over the cellular interface. The latter behavior may imply an RRC state transition, for example, from IDLE to CONNECTED.

[0175] Alternatively, the UE indicates to the wearable device the time remaining until an opportunity for data exchange becomes available (eg, for a tracking area update).

[0176] The following Tables 3 and 4 give the Fig.10 Table 3 is an example of a status indication message, and Table 4 is an example of a confirmation message.

[0177] Table 3

[0178]

[0179]

[0180]

[0181] Table 4

[0182]

[0183]

[0184] Another optional aspect of the present invention is to notify the wearable device of current and future communication status changes regarding the UE's connection to the network.

[0185] Another optional aspect of the present invention is to provide per-packet priority and / or delay tolerance from the wearable device to the UE in order to efficiently transmit data to the network.

[0186] Request UE to set up network connection for wearable device (according to D)

[0187] The wearable device may trigger the UE to perform registration of the wearable device at the cellular network. The trigger may also be implicit, for example, registration of the wearable device at the UE may automatically trigger the UE to register the wearable device at the core network.

[0188] A specific registration request message may be provided to the UE, including

[0189] The ID of the wearable device to use in the registration.

[0190] In addition, wearable devices can also provide alternative IDs, such as providing a temporary identification (GUTI)

[0191] and unique identity (IMSI) so that the UE can first register with a temporary ID and use the IMSI when requested by the NW without requesting this information again.

[0192] Information about the IP connectivity of the wearable device, such as the packet data network (PDN) to which the wearable device needs to connect, is usually identified by an access point name (APN).

[0193] If the UE generates NAS messages on behalf of the wearable device when the wearable device has a SIM or USIM, then information related to authentication can be exchanged. The simplest (and least disruptive) method is to use the BT SIM Access Profile (SAP), but it is also possible to exchange them together with the NAS information exchange discussed in this article. The wearable device can also provide the UE with the information required to access the SIM or USIM of the wearable device using the BT SIM Access Profile at the UE.

[0194] The UE and the wearable device may also negotiate whether the UL data transmission from the wearable device to the UE must wait for the connection to be established or whether the wearable device can transmit the data immediately. The latter will have the advantage of utilizing LTE and exceeding the UL transmission speed from the UE to the NW, while the wearable device is limited to BT speeds, on the other hand, it requires buffering in the UE for a few seconds and carries the risk of wasting power if the wearable device is rejected by the NW.

[0195] If the UE has full control of the NAS entity for the wearable device, it will create and transmit a registration message via the cellular connection to the network it is currently using, taking into account the information received from the wearable device and filling in information related to the UE and its currently established network connection.

[0196] Alternatively, the wearable device implements the NAS entity itself and generates a registration message, which is then provided to the UE containing the above information. The UE may fill in the missing information in the message and transmit the message via the cellular air interface.

[0197] In one embodiment of the present invention, the wearable device can send a "Registration Request" message to the UE via a novel message exchange profile, thereby triggering the UE to set up a cellular connection with the core network (eg, a wireless connection according to 3GPP LTE or LTE-Advanced). Fig.11 An example message pair is shown.

[0198] In this regard, the following details are relevant:

[0199] A “wearable device ID” that will be used in the core networks of mobile network operators.

[0200] The "PLMN" to be registered (verified by the UE before starting the registration process of the wearable device).

[0201] Tables 5 and 6 below give the Fig.11 Table 5 is an example of a registration request message, and Table 6 is an example of a registration confirmation message.

[0202] Table 5

[0203]

[0204]

[0205] Table 6

[0206]

[0207]

[0208] Another optional aspect of the present invention is that the wearable device can trigger the UE to set up a (logical) connection between the wearable device and the network.

[0209] Request UE to maintain cellular connection

[0210] To mitigate frequent transitions of the RRC state from the connected state to the idle state and back to the connected state again, for example when the wearable device continuously generates small data packets, the wearable device may send a "keep request" message to the UE via a novel message exchange profile. Once the UE receives the message, the UE is expected to maintain the current cellular connection with the core network of the mobile network operator (e.g., a wireless connection according to 3GPP LTE or LTE-Advanced) for a little longer on behalf of the wearable device. Fig.12 An example message pair is shown.

[0211] During an ongoing connection over a short-range interface, it may be desirable for the wearable device to indicate to the UE

[0212] Can we expect more UL data from wearable devices soon?

[0213] Whether the wearable device expects downlink data (eg, contents of a web page, a reply to a keep-alive message, etc.) in response to a previously sent uplink message (eg, an HTTP GET request, a keep-alive message, etc.).

[0214] Tables 7 and 8 below give the Fig.12 Table 7 is an example of a hold request message, and Table 8 is an example of a hold response message.

[0215] Table 7

[0216]

[0217]

[0218] Table 8

[0219]

[0220]

[0221] Another optional aspect of the present invention is that the wearable device may request the UE to maintain the (logical) connection of the wearable device to the network for a little longer, either because there may be more data available in the wearable device uplink buffer to be sent via the relay UE, or because the wearable device is expecting a reply from the peer entity (in the form of downlink data arriving).

[0222] UE releases network connection for wearable device

[0223] Fig.13 , 14 15 show some example message flows between the UE and the wearable device for releasing a network connection for the wearable device.

[0224] Fig.13 Some optional messages that can be used to implement the Early Release Indication procedure are shown. First, the UE notifies the wearable device about the planned (or upcoming) release of the connection (message type: "Early Release Indication"). If the wearable device is not satisfied with what the UE proposes, the wearable device can generate a different release proposal, which is sent back (message type: "Early Release Response") and evaluated by the UE and / or the core network.

[0225] An early indication of a planned release of a network connection (as described above) may be desirable as it allows the wearable device to find an alternative relay device to register with so that the connection can be easily restored later. Since this is more like a connection suspension than a connection release operation (from the network's perspective), it may be beneficial to save the wearable device's context in the core network to quickly reactivate the (logical) connection at a later point in time. For this variant, the detailed message structure is not shown for brevity.

[0226] exist Fig.14 In the embodiment, the UE of the NAS entity hosting the wearable device may (in one embodiment) notify the wearable device about the successful release of the network connection of the wearable device (message type: "Release Indication"). The wearable device simply acknowledges this message (message type: "Ack"). For this variant, the detailed message structure is also not shown.

[0227] Fig.14 The message flow can be followed by Fig.13 After the message flow; and Fig.13 The "Proposal Assessment" may result in (or be combined with) Fig.14 of "Release Execution".

[0228] When Fig.13 When a delay is requested by the wearable device in an Early Release Response message and granted by the UE and / or the core network in a subsequent Proposal Evaluation, Fig.14 The messages shown in may alternatively be exchanged at a later point in time.

[0229] In one embodiment, Fig.15 Can be used as Fig.13 An alternative to Fig.15 In the embodiment, the wearable device, which may (in another embodiment) host its own NAS entity, is requested by the UE to release its network connection (message type: "Release Request"). The wearable device may then release its network connection and confirm the successful connection release (message type: "Release Confirm").

[0230] In another embodiment, Fig.15 Can be used as Fig.14 In this case, Fig.15 The message shown in can be followed by Fig.13 Therefore, Fig.15 The "Release Request" message in may contain Fig.13 Parameters calculated or determined during the Proposal Evaluation.

[0231] Tables 9 and 10 show the Fig.15Table 9 is an example of a release request message, and Table 10 is an example of a release response message.

[0232] Table 9

[0233]

[0234]

[0235] Table 10

[0236]

[0237]

[0238] In another embodiment of the present invention, the early indication may be part of the above-mentioned "communication status indication" and / or "schedule exchange" from the UE to the wearable device.

[0239] Another aspect of the present invention is that the UE initiates the release process of the (logical) connection of the wearable device to the network. The wearable device can be notified in advance about the planned release of the (logical) connection of the wearable device to the network, and can either perform the release operation itself (for example, if the relevant NAS entity resides in the wearable device) or respond to the UE with a release suspension proposal (for example, if the relevant NAS entity resides in the UE). After the UE successfully terminates the (logical) connection of the wearable device to the network, the UE can notify the wearable device. In addition, if applicable, the UE can notify the wearable device about the details of the connection suspension time (=context storage time in the core network).

[0240] Alternatively, if the release of the (logical) network connection of the wearable device is initiated by the NAS entity residing in the wearable device without previously receiving a trigger from the UE, the message flow will be similar to Fig.17 Here, the wearable device notifies the UE about the termination of the connection to the core network of the MNO (i.e., about the release of the already executed logical connection at the NAS layer and the release of its network registration at the MME). For this variant, the detailed message structure is not shown for the sake of brevity.

[0241] Request the UE to terminate the network connection for the wearable device

[0242] As mentioned above, the wearable device may also proactively terminate an ongoing connection. Fig.16 An example message flow between a wearable device and a UE regarding requesting the UE to terminate a network connection for the wearable device is shown.

[0243] If the NAS entity for the wearable device resides in the UE, the wearable device simply requests from the UE over the short-range interface to release its network registration at the MME (message type "Release Query"), so that the UE can then generate and transmit a registration release request ("Release Execute") to the MME on behalf of the wearable device. The UE can inform the wearable device about the result of this effort by means of a "Release Response" message. Tables 11 and 12 give Fig.16 Table 11 is an example of a release query message, and Table 12 is an example of a release response message.

[0244] Table 11

[0245]

[0246]

[0247] Table 12

[0248]

[0249]

[0250] Another optional aspect of the invention is that the wearable device requests the UE to release the (logical) connection of the wearable device to the network. The wearable device may be informed of the result of the requested release operation (including detailed information about the connection suspension time (=context storage time in the core network), if applicable).

[0251] In the case where the context of the wearable device is stored on the network side for future reactivation of a suspended logical connection (e.g., at the NAS layer), it is advantageous to provide the wearable device with a context ID via the first relay UE (e.g., as described within the scope of the "Release Request" message according to Table 9 and the "Release Response" message according to Table 12). This context ID can be used by the wearable device when reactivating the suspended connection later. Doing so allows for faster reactivation of the suspended connection when the wearable device is changing (or replacing) a UE with relay capabilities.

[0252] With regard to the above description of the preferred embodiments of the present invention, the following should be noted.

[0253] The NAS functionality may be divided between the UE and the wearable device. Thus, a "NAS in a wearable device" setup may mean that the wearable device performs session management, registration and security, while the UE always performs mobility (and some other things). Therefore, it may make sense to implement a finer subdivision for the various NAS functions in the process of the present invention, for example, when it comes to capability exchange ("Where does the NAS reside?" => "Where does the instance of the NAS function reside?") and capability negotiation ("Which NAS entity to use?" => "Which instance of a specific NAS sub-function to use? - the one in the UE, or the one in the wearable device?").

[0254] The names of messages, events, and information elements should be understood to be used as examples only. There are many other options for obtaining information over the short-range air interface. The present invention is in no way limited to the coding examples and message flows we disclose here.

[0255] In addition, the various information elements described in conjunction with the various messages may be grouped in other ways, such as by arranging them in a new or existing hierarchical structure, or by combining them with other information elements, such as in the form of a list or container.

[0256] About the basis Figure 2 and 3 In theory, there is also a third implementation option in which the USIM1 (either removable or inseparable) is located in the wearable device and the NAS1 entity resides in the UE. For the sake of brevity, this rare setting is deliberately excluded. The definition of messages, message flows, events and information elements covering this third implementation option can be completed in a manner similar to that disclosed in detail in the present invention.

[0257] The LTE terminology used here for different RRC states (connected vs. suspended vs. idle) should not be understood to limit the present invention to the LTE environment. For other radio access technologies, other UE states may be defined. For example, for LTE successor radio access technologies defined within the 5G range, UE implementations may define and support the same, similar, or other RRC states.

[0258] Although BT may represent a preferred embodiment of the present invention, wireless short-range technologies supported by the wearable device and the cellular communication device for the message exchange as described herein (see Figure 2 and 3 The short-range air interface of BT is not necessarily (based on) BT in all cases. Other wireless short-range technologies, such as WiFi, may also be suitable for supporting the spirit of the method described in this document and are explicitly included in the scope of the present invention.

[0259] In one embodiment, the wearable device itself may implement (at least one) cellular modem, so it may take the form of a cellular communication device. The radio access technologies supported by the cellular modem of the wearable device and the cellular modem of the cellular communication device may be the same or different. Therefore, the term "wearable device" should not be understood as a general limitation. In some embodiments, the wearable device defined within the scope of the present invention may also be a cellular communication terminal (in the form of), commonly referred to as a mobile communication device, such as a mobile phone.

Claims

1. A method for enabling a mobile communication device to communicate with a user device via a short-range radio interface connection, the mobile communication device acting as a relay node for enabling the user device to connect to a core network, the method comprising exchanging communication status messages to connect the user device to the mobile communication device and operating the user device using the mobile communication device as a relay node, The method comprises: The mobile communication device notifies the user device of a current communication status between the mobile communication device and the core network by exchanging a status indication message between the mobile communication device and the user device, wherein the status indication message provides a currently registered public land mobile network of the mobile communication device, The user device sends a registration request to the mobile communication device to establish a connection between the user device and the core network via the mobile communication device, the registration request includes information identifying the user device in the core network and indicating one or more public land mobile networks to which the user device can be connected, and if the public land mobile network currently registered by the mobile communication device corresponds to a public land wireless network to which the user device can be connected, the registration request triggers the mobile communication device to establish a connection to the core network.

2. The method according to claim 1, wherein: The user device and the mobile communication device exchange their NAS capabilities with each other, and then establish a connection between the user device and the core network.

3. The method according to claim 1 or 2, wherein: The short range radio connection is a sidelink connection.

4. The method according to claim 1 or 2, wherein: The user device provides delay tolerance information to the mobile communication device.

5. The method according to claim 1 or 2, wherein: The user device transmits a message to the mobile communication device, requesting the mobile communication device to maintain the connection between the user device and the core network.

6. The method according to claim 5, wherein: When the user device has data stored in a buffer waiting to be sent or is waiting for downlink data, a message is transmitted requesting the mobile communication device to maintain the connection of the user device with the core network.

7. The method according to claim 1 or 2, wherein: During the process of releasing the connection between the user device and the core network, the mobile communication device triggers the core network to keep at least one user device context active.

8. The method according to claim 7, wherein: The mobile communication device provides a context identifier to the user device, which can be stored in the user device for later use.

9. The method according to claim 7, wherein: When the user device attempts to reactivate a connection with the core network via another mobile communication device, the user device uses the stored context identifier.

10. The method according to claim 8, wherein: When the user device attempts to reactivate a connection with the core network via another mobile communication device, the user device uses the stored context identifier.

11. The method according to claim 3, wherein: The short range radio connection is one of a PC5, Bluetooth and a wireless LAN connection.

Images