Patent Application
20190281127
The present invention relates to messaging performed between a wearable device and a mobile communication device, commonly referred to as a user equipment, UE.
Mobile communication terminals can select, reselect, and connect to a mobile relaying node offering connectivity into a Mobile Network Operator's (MNO's) core network. An air interface between the mobile communication terminal and the mobile relaying node may be based on LTE or some short range technology, such as Bluetooth®, BT, or WiFi.
It is known for a relaying node to be controlled to form and administer device-to-device, D2D, clusters in an opportunistic fashion, for example in scope of 3GPP's ProSe (Proximity Services) feature. Many of these principles could be re-used for connecting wearables to a cell phone acting as a mobile relaying node.
For example, U.S. Pat. No. 9,380,625 B2 describes a communication device having D2D capability, with this capability being signalled to a base station. US 2016/0150373 A1 describes forming a relay using a proximity service when a user equipment, UE, is not in range of a group communication service. A second UE acts as a relay UE for the group communication. US 2012/0238208 A1 describes a UE having a short range wireless transceiver which may be used to form an opportunistic network. US 2012/0250601 A1 describes the establishment of a non-access stratum, NAS, bearer between a UE and a core network and the use of the NAS bearer for exchanging data between a remote device and the core network using a short range radio connection. U.S. Pat. No. 8,682,243 B2 describes using a network selection device for deciding whether a connection should be established using an opportunistic network or a direct connection. US 2013/0137469 A1 describes a method for transmitting an opportunistic network message.
US 2016/0295622 A1 describes a technique for connecting a first wireless device such as a laptop computer to a network via a second wireless device such as a mobile phone. Local connection information such as a data rate, RSSI or bit error rate may be broadcast such that other proximal devices may compare a connection quality with their own connection quality.
US 2015/0245186 A1 describes a wireless pairing between a first and a second electronic device. Once a connection has been established, information such as a capability exchange may be performed.
A widely implemented short range wireless connection is one according to the BT standard. Many products such as telephones, tablets, media players, laptops, console gaming equipment, health devices, and watches incorporate such a BT functionality. The technology is useful when information is to be transferred between two or more devices that are near each other in low-bandwidth situations. The protocols defined for BT simplify the discovery and setup of services between two devices. BT devices can advertise the services they provide. This makes using services easier, because more of the security, network address and permission configuration can be automated than with many other network types.
The BT protocol stack is split in two parts: a “controller stack” containing a timing critical radio interface, and a “host stack” dealing with high level data. In between these two parts of the protocol stack a host controller interface (HCI) may be deployed. The controller stack is generally implemented in a low cost silicon device containing the BT radio and a microprocessor. The host stack is generally implemented as part of an operating system, or as an installable package on top of an 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 known as a “host less” system.
An important protocol is the service discovery protocol (SDP). It allows a device to discover services offered by other devices, and their associated parameters. For example, a mobile phone is used with a BT headset, the phone uses SDP to determine which BT profiles the headset supports (for example, headset profile, hands free profile, advanced audio distribution profile (A2DP), etc.) and the protocol multiplexer settings needed for the phone to connect to the headset using each of them. Each service is identified by a universally unique identifier (UUID), with official services (i.e. BT profiles) assigned a short form UUID (16 bits rather than the full 128 bits). In the protocol stack, the SDP is often bound to (or integrated in) the L2CAP.
Data is exchanged between two (or more) BT devices via so-called BT profiles that were defined (in terms of parameters and behaviour) 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. Generally, adherence to profiles saves some time for transmitting parameters anew before a bi-directional link becomes effective. There is a wide range of BT profiles that describe many different types of applications or use cases for BT devices. For instance, one of the most commonly used BT profiles, namely the headset profile, to be used with a cellular phone can request establishment of an audio channel (relying on a synchronous connection-oriented (SCO) link for audio encoded in 64 kbit/s CVSD or PCM) plus some control channels for the exchange of 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 discover and establish a connection with each other.
Another BT profile relevant for the present invention is the BT network encapsulation protocol (BNEP). It is used for transferring another protocol stack's data via an L2CAP channel. Its main purpose is the transmission of IP packets in the personal area networking profile. BNEP performs a function similar to the subnetwork access protocol (SNAP) in Wireless LAN. In Wireless LAN, SNAP fields may be added to packets at the transmitting node in order to allow the receiving node to pass each received frame to an appropriate device driver which understands the given protocol.
Of further relevance to the present invention is the 3GPP LTE mobile communication standard. The LTE air interface (also referred to as Uu interface) is logically divided into three protocol layers. The entities ensuring and providing the functionality of the respective protocol layers are implemented both in the mobile terminal and the base station. The bottommost layer is the physical layer (PHY), which represents the protocol layer 1 (L1) according to the OSI (Open System Interconnection) reference model. The protocol layer arranged above PHY is the data link layer, which represents the protocol layer 2 (L2) according to the OSI reference model. In an LTE communication system, L2 consists of a plurality of sublayers, namely the Medium Access Control (MAC) sublayer, the Radio Link Control (RLC) sublayer and the Packet Data Convergence Protocol (PDCP) sublayer. The topmost 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) layer on the C-Plane. On the C-Plane, there is further the NAS (Non-Access Stratum) protocol layer.
Each protocol layer provides the protocol layer above it with its services via defined service access points (SAPs). To provide a better understanding of the protocol layer architecture, the SAPs were assigned unambiguous names: The 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 transfer function of the RLC mode, i.e. TM (Transparent Mode), UM (Unacknowledged Mode) and AM (Acknowledged Mode). Further, the PDCP layer provides its services to the RRC layer and the U-Plane upper layers via radio bearers, specifically as Signalling Radio Bearers (SRB) to the RRC and as Data Radio Bearers (DRB) to the U-Plane upper layers. According to LTE a maximum of 3 SRBs and 8 DRBs is currently supported.
The radio protocol architecture is not just split horizontally into the above-described protocol layers; it is also split vertically into the “control plane” (C-Plane) and the “user plane” (U-Plane). The entities of the control plane are used to handle the exchange of signalling data between the mobile terminal and the base station, which are required among others for the establishment, reconfiguration and release of physical channels, transport channels, logical channels, signalling radio bearers and data radio bearers, whereas the entities of the user plane are used to handle the exchange of user data between the mobile terminal and the base station.
According to LTE, each protocol layer has particular prescribed functions: The PHY layer is primarily responsible for i) error detection on the transport channel; ii) channel encoding/decoding of the transport channel; iii) Hybrid ARQ soft combining; iv) mapping of the coded transport channel onto physical channels; v) modulation and demodulation of physical channels.
The MAC layer is primarily responsible for i) mapping between logical channels and transport channels; ii) error correction through HARQ; iii) logical channel prioritization; iv) transport format selection.
The RLC layer is primarily responsible for i) error correction through ARQ, ii) concatenation, segmentation and reassembly of RLC SDUs (Service Data Unit); iii) re-segmentation and reordering of RLC data PDUs (Protocol Data Unit). Further, the RLC layer is modelled such that there is an independent RLC entity for each radio bearer (data or signalling).
The PDCP layer is primarily responsible for header compression and decompression of IP (Internet Protocol) data flows, ciphering and deciphering of user plane data and control plane data, and integrity protection and integrity verification of control plane data. The PDCP layer is modelled such that each RB (i.e. DRB and SRB, except for SRB0) is associated with one PDCP entity. Each PDCP entity is associated with one or two RLC entities depending on the RB characteristic (i.e. uni-directional or bi-directional) and RLC mode.
The RRC layer is primarily responsible for the control plane signalling between the mobile terminal and the base station and performs among other the following functions: i) broadcast of system information, ii) paging, iii) establishment, reconfiguration and release of physical channels, transport channels, logical channels, signalling radio bearers and data radio bearers. Signalling radio bearers are used for the exchange of RRC messages between the mobile terminal and the base station.
The differences between the C-Plane (control plane) and the U-Plane (user plane) according to E-UTRA (LTE) technology are depicted in
Future wearable communication devices may come with or without NAS functionality. If future wearable devices come without NAS functionality and should be controllable by and/or known to the core network (i.e. have a subscription with the MNO) nevertheless, it may be desirable to adapt the NAS entity in a UE in order to serve both, the UE (which is operating in this scenario as a relaying node) and the wearable device, or even implement more than one NAS entity in the UE; one NAS entity for the UE itself and one or more further NAS entities for the various wearable devices as explained in US 2013/0137469 A1.
Current BT technology doesn't offer sufficient means to connect a wearable communication device (with or without NAS functionality, here denoted as “Wearable”) to a cellular communication device (with none, one or more NAS entities dedicated to wearables, here denoted as “UE”) that may be configured to relay traffic into an MNO's core network in uplink direction, and/or to relay traffic stemming from an MNO's core network in downlink direction.
The NAS layer that controls directly the communication with the cellular mobile core network for a Wearable may reside in the Wearable itself or in the connected UE. If only one of the respective devices, the UE or the Wearable, has a NAS layer implementation, this NAS layer will take control for the Wearable. If both devices have a NAS implementation, the actual control has to be negotiated.
As a result, an exchange of NAS layer capability and a potential negotiation among Wearable and UE regarding control of the Wearable device has to take place before the Wearable device can be registered in the network.
If the UE has multiple NAS layer implementations potentially serving multiple connected Wearables, it will associate the respective NAS layer entity with a specific Wearable device and the respective BT link.
In one aspect, the present invention provides a method for a mobile communication device to communicate with a user device over a short range radio interface connection, the mobile communication device acting as a relaying node for enabling a connection of the user device to a core network, the method comprising transmitting messages over the short range radio interface connection using a message exchange profile, the messages comprising at least one of a mutual non-access stratum capability exchange in which 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 subscriber settings to the user device; a request for the mobile communication device to maintain the connection to the core network; a message to release the connection to the core network for the user device by the mobile communication device; and a request for the mobile communication device to terminate the core network connection for the user device.
The messages may be transmitted over the short range radio interface connection using a message exchange profile, the message exchange profile defining procedures and a standardized behaviour for information exchange between the two devices.
In a further aspect, the present invention provides a method for a mobile communication device to communicate with a user device over a short range radio interface connection, the mobile communication device acting as a relaying node for enabling a connection of the user device to a core network, the method comprising negotiating NAS capabilities for connecting the user device to the mobile communication device and for operating the user device using the mobile communication device as the relaying node.
The message exchange framework for Wearables, that may be realized for example as a new BT Profile, offers the following benefits. Future wearable devices (with and without NAS functionality) may be registered and de-registered in an MNO's core network via a relaying UE. This makes Wearables controllable by and/or known to the core network (i.e. Wearables may have a subscription with the MNO without the need to have a cellular modem).
The procedures described comprise the exchange of the devices' capabilities as well as configuration of the relaying function over the short range interface based on user preferences, individual subscriber settings, and general network policies.
Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:
The invention is directed to the definition of a message exchange profile for deployment on a short range air interface (such as BT) between a wearable device (“Wearable”) (such as a smart watch, fitness tracker, and alike) and a cellular communication device (“UE”) (such as a mobile phone) serving as a relaying node.
The profile may consist of procedures and standardized information exchange between the two devices to achieve (at least one of) the following:
Before a Wearable can exchange user data with the MNO's core network via a cellular communication device acting as a relaying UE the two devices need to exchange their NAS capabilities regarding connecting the Wearable to the cellular network. In detail the following information may be relevant:
In case more than one NAS entity (or USIM application) is available and suited to serve a given Wearable, only one NAS entity (or USIM application) is selected (i.e. according to this invention the actual use/activation of the NAS entity and/or USIM application is negotiated among the Wearable and the UE over the short range air interface).
The “mutual NAS capability exchange” procedure may contain the following steps:
Option 1
Pre-Condition: The Wearable contacts the UE for the first time.
Post-Condition: Both devices setup the service according to the capabilities and parameters exchanged.
Option 2
Pre-conditions: Both the UE and the Wearable are already connected.
A detailed example message sequence chart is discussed below.
Indication of User Preferences and Subscriber Settings to the Wearable
For the initial phase of signalling it may also be relevant whether the user and/or his subscription allows/disallows or prefers/declines certain (types of) Wearables (or services) to connect to the UE. In detail the following information may be relevant.
(Information about) User Preferences (e.g., set on the UE), general network policies, or individual contract settings (e.g., read from a core network data base) could be sent from the UE to the Wearable regarding the type of remote devices that are allowed (or preferred)/disallowed (not preferred) to connect to the given UE. In some scenarios it may even make sense to indicate that a maximum number of Wearables is already met, or to signal the maximum number of additional Wearables that can still connect to the UE in question (Note: Regarding the maximum numbers of connected Wearables, this may also be a UE capability rather than a user preference).
Inform the Wearable about the UE's Current Communication Status
In general, the status of the communication between UE and the corresponding cellular mobile communication network (e.g., a cellular communication network operating according to 3GPP LTE or LTE-Advanced) will influence the (potential) communication of the Wearable. Thus, further pieces of information are proposed to be exchanges between the UE and the Wearable as part of the novel message exchange profile, for example during the initial phase of signalling.
As the UE's communication status may change over time, it is also proposed to enable exchange of such layer 3 information (if needed) during an ongoing short range connection as well. So, in order to keep the connection for the Wearable satisfactory, regular or event based updates (indications of status changes) may be required. In detail the following layer 3 information may be relevant:
In addition, it may be beneficial to inform the Wearable over the short range interface about upcoming (i.e. imminent) changes on the cellular link in order to allow the Wearable to perform data transmissions in a more efficient way. For example, a coordinated (i.e. synchronized) transmission of keep-alive message to various application servers on the internet will reduce the need for the UE to continuously (re-) connect to the cellular network (i.e., to continuously perform state transitions) for small data packets. Therefore, means to exchange schedules for data transmissions are proposed to be sent as part of the novel message exchange profile to increase efficiency of connecting a Wearable to a UE. There are different options to achieve this:
The Wearable may be enabled to send a special request message to the UE using the novel message exchange profile thereby triggering the UE to set-up a cellular connection to the core network. In one embodiment (namely, when it was decided during the mutual capability exchange that a NAS entity in the UE is supposed to be used for the Wearable) this request message may trigger at the same time the registration of the Wearable in the core network by the UE (either by using the same NAS connection into the core network or a separate one, which is dedicated to the Wearable).
During an ongoing connection over the short range interface, it may be desirable to let the Wearable indicate to the UE
The UE may then choose to keep up the cellular connection for a little while longer (e.g., for a predefined or predicted amount of time), thereby possibly mitigating the need for frequent RRC state transitions from CONNECTED to IDLE and back to CONNECTED again. Said “waiting time” may be calculated by the UE based on previous traffic characteristics (e.g., taking into consideration earlier responses coming in from the same or similar content servers, application peers, and so on).
When an ongoing connection over the cellular air interface (e.g., LTE Uu) is drawing to a close, it is desirable to terminate the two connections (the one over the cellular link and the one over the short range air interface) in a coordinated manner. This may not be possible in all cases (for example, in case the UE experiences an abrupt radio link failure on the cellular air interface), but it is definitively desirable whenever possible. Depending on where the NAS functionality of the Wearable resides, there are two different options for a coordinated approach. In both cases, the UE has to inform the Wearable over the short range interface about the imminent termination of the cellular connection and the Wearable may react as follows:
When the Wearable takes the initiative to terminate an ongoing connection, also two different signalling options exist, depending on where the NAS entity for the Wearable resides:
In the example implementation of
In some deployment scenarios, it may be sensible to allow for exchange of information between the 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.
For example, in case the Wearable has its own NAS entity (“NAS1” as in
Mutual Capability Exchange & User Preferences & Subscriber Settings
According to one aspect of the present invention a uni-directional or bi-directional capability exchange may take place whenever a Wearable is trying to newly register with a UE. For instance, while requesting information from the UE in order to find out, whether the UE is offering any relaying services, the Wearable may let the UE know that:
For instance, as a response to the request received from the Wearable the UE may indicate to the Wearable that:
Furthermore, the UE could transmit the following information related to user preferences and/or subscriber settings and/or network policies to the Wearable either in the same response message or in a subsequent (pair of) message(s):
In case more than one NAS entity (or USIM application) is available and suited to serve a given Wearable, only one NAS entity (or USIM application) needs to be selected. For this, the Wearable and the UE would have to negotiate over the short range air interface which of the NAS entities and/or USIM applications is actually to be used.
One aspect of the present invention is that a Wearable and a UE that is offering a relaying function into an MNO's core network are first enabled to mutually exchange their capabilities and then to establish, terminate or suspend a (logical) connection for the Wearable into an MNO's core network. User preferences, individual subscriber settings, and general network policies can also be take into account in scope of the message exchange framework disclosed.
Informing the Wearable about the UE's Current Communication Status
In general, the status of the communication between UE and the corresponding cellular mobile communication network (e.g., a cellular communication network operating according to 3GPP LTE or LTE-Advanced) will influence the (potential) communication of the Wearable.
“Status Indication” messages may be exchanged from the UE to the Wearable as part of the message exchange profile at least during the initial phase of signalling.
As the UE's communication status may change over time, exchange of such information (if needed) may be enabled during an ongoing short range connection as well. So, in order to keep the connection for the Wearable satisfactory, regular or event based updates (status changes) may be required.
In detail the following information may be relevant:
In a further embodiment of this invention, the Wearable may be informed over the short range interface about upcoming (i.e. imminent) changes on the cellular link in order to allow the Wearable to perform data transmissions in a more efficient way. For example, a coordinated (i.e. synchronized) transmission of keep-alive message to various application servers on the internet will reduce the need for the UE to continuously reconnect to the cellular network (i.e., to continuously perform state transitions) for small data packets. Therefore, schedules for data transmissions may be sent as part of the message exchange profile to increase efficiency of connecting a Wearable to a UE. There are different options to achieve this:
Possible message structures for the Status Indication/Acknowledgement pair of messages according to
A further optional aspect of the present invention is to inform the Wearable about current and future communication state changes of the UE's connection to the network.
Another optional aspect of the present invention is to provide per packet priority and/or delay tolerance from the Wearable to the UE for efficient data transfer to the network.
The Wearable can trigger the UE to perform a registration of the Wearable at the cellular network. The trigger may also be implicit, e.g. the registration of the Wearable at the UE may automatically trigger the UE to register the Wearable at the core network.
A specific registration request message may be provided to the UE containing
If the UE has full control of the NAS entity for the Wearable, it will create and transmit a registration message via the cellular connection to the network it currently uses taking into account the information received from the Wearable and filling-in information related to the UE and its currently established network connection.
Alternatively, the Wearable has a NAS entity implemented on its own and generates the registration message that is then provided to the UE containing above information. The UE may fill-in information missing in the message and transmit the message via the cellular air interface.
In one embodiment of the present invention the Wearable is enabled to send a “Registration Request” message to the UE via the novel message exchange profile thereby triggering the UE to set-up a cellular connection (for instance, a wireless connection according to 3GPP LTE or LTE-Advanced) to the core network.
In this context, the following details are of relevance:
Tables 5 and 6 below are giving possible message structures for the Registration Request/Registration Confirmation pair of messages according to
A further optional aspect of this invention is that the Wearable can trigger the UE to set-up the Wearable's (logical) connection to the network.
In order to mitigate frequent RRC state transitions from CONNECTED to IDLE and back to CONNECTED again, for example when a Wearable is constantly generating small packets of data, the Wearable may be enabled to send a “Keep Up Request” message to the UE via the novel message exchange profile. Once this message is received by the UE, the UE is expected to keep the current cellular connection into the Mobile Network Operator's core network (for instance, a wireless connection according to 3GPP LTE or LTE-Advanced) alive a little bit longer on behalf of the Wearable.
During an ongoing connection over the short range interface, it may be desirable to let the Wearable indicate to the UE
Tables 7 and 8 below give possible message structures for the Keep Up Request/Keep Up Response pair of messages according to
A further optional aspect of the present invention is that the Wearable can ask the UE to keep up the Wearable's (logical) connection to the network a little while longer, as there may be more data available in the Wearables uplink buffer to be sent via the relaying UE, or as the Wearable is expecting an answer (in form of downlink data arriving) from a peer entity.
An early indication of a planned release of the network connection (as described above) may be desirable, as it allows the Wearable to look for an alternative relaying device to register with, so that it can easily resume the connection later on. As this is more like a connection suspend rather than a connection release operation (looking at it from the network's point of view), it may be beneficial to hold the Wearable's context in the core network for a quick re-activation of the (logical) connection at a later point in time. For this variant no detailed message structures are shown for the sake of brevity.
In
The message flow of
When a delay has been requested by the Wearable in the “Early Release Response” message of
In one embodiment
In another embodiment
Some exemplary detailed message structures for the example message flow of
In a further embodiment of the present invention the early indication can be part of the above-mentioned “communication status indication” and/or “schedule exchange” from the UE to the Wearable.
A further aspect of this invention is that the UE initiates the release process of the Wearable's (logical) connection to the network. The Wearable may be informed in advance about a planned release of the Wearable's (logical) connection to the network and may either execute the release operation itself (e.g., if the relevant NAS entity is residing inside the Wearable), or respond to the UE with a release suspension proposal (e.g., if the relevant NAS entity is residing inside the UE). The UE may inform the Wearable after the UE has successfully terminated the Wearable's (logical) connection to the network. Also, the UE may inform the Wearable about details of a connection suspension time (=context storage time in the core network), if applicable.
Alternatively, if the release of the Wearable's (logical) network connection is initiated by a NAS entity residing in the Wearable without previous reception of a trigger from the UE, the message flow would look like the one given in
As discussed above, the Wearable may also take the initiative to terminate an ongoing connection.
If the NAS entity for the Wearable resides in the UE, the Wearable 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 may then generate and transmit a registration release request to the MME on behalf of the Wearable (“Release Execution”). The UE may inform the Wearable about the outcome of this effort by means of the “Release Response” message. Some detailed message structures for the example message flow of
A further optional aspect of the present invention is that the Wearable asks the UE to release the Wearable's (logical) connection to the network. And the Wearable may be informed about the outcome of the requested release operation (incl. details about the connection suspension time (=context storage time in the core network), if applicable).
In case a Wearable's context is stored on the network side for a future re-activation of a suspended logical connection (e.g., at NAS layer), it is advantageous to provide the Wearable via a first relaying UE with a Context ID (as described for instance within the scope of the “Release Request” message according to Table 9 and the “Release Response” message according to Table 12). This Context ID may be used by the Wearable at a later point in time when it re-activates the suspended connection. Doing so allows faster re-activation of a suspended connection when the Wearable is changing (or substituting) a UE with relaying capabilities.
With regard to the above description of preferred embodiments of the invention, the following is to be noted.
A split of NAS functionality among UE and Wearable is possible. Consequently, a “NAS in the Wearable” setup could mean that the Wearable performs Session Management, Registration, and Security while the UE always performs Mobility (and some other things). Thus, it may make sense to enable a finer granularity for the various NAS functions in course of the present invention, e.g. when it comes to capability exchange (“Where does the NAS reside?”=>“Where does what instance of NAS functionality reside?”) and capability negotiation (“Which NAS entity is to be used?”=>“Which instance of a particular NAS sub function is to be used?—The one in the UE, or the one in the Wearable?”).
The names of the messages, events, and information elements shall be understood to merely serve as examples. There are many other options to get the information across the short range air interface. This invention is by no means restricted to the encoding examples and message flows we disclose here.
Furthermore, the various information elements described in connection with the various messages may be grouped in other ways. For example, they may be collated in a new or already existing hierarchical structure, or grouped together with other information elements, for instance in form of a list or a container.
Regarding the possible implementation options according to
The LTE terminology used here for the different RRC states (CONNECTED vs. SUSPENDED vs. IDLE) shall not be understood as restricting this invention to an LTE environment. For other radio access technologies, other UE states may be defined. For example, for the LTE successor radio access technology defined within the scope of 5G, the same, similar, or other RRC states may be defined and supported by UE implementations.
While BT may represent a preferred embodiment of the present invention, the wireless short range technology supported by the wearable device and the cellular communication device for the exchange of messages as described herein (cf. short range air interface according to
In one embodiment, the wearable device itself may have implemented a(t least one) cellular modem, so it may take on the form of a cellular communication device. The radio access technologies supported by the cellular modem(s) of the wearable device and the cellular modem(s) of the cellular communication device may be the same or different. Consequently, the term “Wearable” shall not be understood as a general restriction. In some embodiments a wearable device as defined within the scope of this invention may also be a (form of) cellular communication terminal, generally referred to as a mobile communication device, such as a mobile phone.
| Number | Date | Country | Kind |
|---|---|---|---|
| 16197097.5 | Nov 2016 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2017/078199 | 11/3/2017 | WO | 00 |
