Supporting Virtually Simultaneous Operation of Dual Wireless Protocols in a Single Device

Abstract

Appearance of simultaneous connections is provided to devices that support two wireless protocols which are not permitted to operation simultaneously. As an example the method and systems disclosed are applied to the communication between a phone and a smartwatch wherein Bluetooth (BT) classic protocol is used for e.g. voice commands and phone calls and Bluetooth low Energy (BLE) protocol is used for data notifications. In a first embodiment of the disclosure automatic mode switching between BT and BLE is provided. In a second embodiment a dual-ID device utilizes separate IDs for both protocols in time multiplexed connections. It operates as logically independent devices with individual ID's although physically it is a single device.

Claims

1. A system to provide appearance of simultaneous connections between two devices each supporting two different wireless communication protocols, which are not permitted to operate simultaneously, wherein the system comprises a first of the two devices utilizing dual separate communication protocol addresses for the two wireless communication protocols in time-multiplexed connection with a second of both devices, wherein the first device is configured to support both wireless protocols as a dual mode device, wherein the first device is configured to operate as two logical independent devices with independent addresses although it is a single physical device; and the second of the two devices configured as dual wireless protocol master.

2. The system of claim 1, wherein the first device is configured to support slave operations for both wireless protocols.

3. The system of claim 1, wherein the first device comprises individual instantiations of all blocks related to each of both protocol addresses

4. The system of claim 1, wherein the first device is a smartwatch and the second device is a phone.

5. The system of claim 1, wherein the first wireless protocol is Bluetooth Low Energy (BLE) communication protocol and the second wireless protocol is Bluetooth Classic (BT) protocol.

6. The system of claim 5, wherein BLE communication protocol is used for relative low power consuming operations.

7. The system of claim 6, wherein the relative low power operations comprise data notifications generated by apps comprising emails, messages and news.

8. The method of claim 5, wherein the BT protocol is used for voice applications.

9. The system of claim 8, wherein the voice applications comprise voice commands and phone calls.

10. The system of claim 9, wherein the first device is configured to receive an external wireless event and a user action-triggered mode switch.

11. The system of claim 10, wherein the user action-triggered mode switch is activated by pressing a button of the first device

12. The system of claim 10, wherein the external wireless event is an incoming phone call.

13. A first device providing an appearance of simultaneous connections between two devices each supporting two different wireless communication protocols, which are not permitted to operate simultaneously, wherein the system comprises the first device utilizing dual separate communication protocol addresses for the two wireless communication protocols, wherein said first device is capable of having a time-multiplexed connection with the second device, wherein the first device is configured to support both wireless protocols as a dual mode device, and wherein the first device is configured to operate as two logical independent devices with independent addresses although it is a single physical device, and wherein said first device is able to be connected to said second device when said second device is configured as a dual wireless protocol master.

14. The system of claim 13, wherein the first device is configured to support slave operations for both wireless protocols.

15. The system of claim 13, wherein the first device comprises individual instantiations of all blocks related to each of both protocol addresses

16. The system of claim 13, wherein the first device is a smartwatch.

17. The system of claim 13, wherein the first wireless protocol is Bluetooth Low Energy (BLE) communication protocol and the second wireless protocol is Bluetooth Classic (BT) protocol.

18. The system of claim 17, wherein BLE communication protocol is used for relative low power consuming operations.

19. The system of claim 18, wherein the relative low power operations comprise data notifications generated by apps comprising emails, messages and news.

20. The system of claim 17, wherein the BT protocol is used for voice applications.

21. The system of claim 20, wherein the voice applications comprise voice commands and phone calls.

22. The system of claim 13, wherein the first device is configured to receive an external wireless event and a user action-triggered mode switch.

23. The system of claim 22, wherein the user action-triggered mode switch is activated by pressing a button of the first device

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In the accompanying drawings forming a material part of this description, there is shown:

[0018] FIG. 1 prior art shows an example of two devices connected wirelessly over two different Bluetooth protocols.

[0019] FIG. 2 prior art shows an example of a phone supporting two protocols but being enabled to use only one protocol at any given time.

[0020] FIG. 3 shows the flow chart of a first embodiment of the Automatic Mode-Switching method, namely user action-triggered mode switching.

[0021] FIG. 4 shows a flow chart of a second embodiment of the Automatic Mode-Switching method, namely an external event-triggered mode switching method.

[0022] FIG. 5 shows a block diagram of a smartwatch with BT and BLE functions that have independent BD_ADDR addresses and connect to the phone as two separate slave devices.

[0023] FIG. 6 shows the aspect of efficient hardware implementation disclosed within the Bluetooth core system architecture.

DESCRIPTION

[0024] The preferred embodiments of the present disclosure present methods and systems to provide appearance of simultaneous connections to devices that support two wireless communication protocols which are not permitted to operate simultaneously. The simultaneous operation is not permitted either by protocol definition, as in the case of BT and BLE, wherein the two devices are not permitted to operate simultaneously under some states for each device, or are not permitted due to functional limitation of the hardware for each device.

[0025] The methods are explained using, as a non-limiting example, a smartwatch supporting Bluetooth Classic (BT) and Bluetooth Low Energy (BLE) communication protocols. Both protocols are not permitted to simultaneous operation due to protocol definition.

[0026] It has to be understood that the methods and systems disclosed are applicable to any devices supporting any two wireless communication protocols, which are not permitted to operate simultaneously either by protocol definition, as in the case of BT and BLE, that the two devices are not permitted to operate simultaneously under some states for each device, or are not permitted due to functional limitation of the hardware for each device

[0027] 1. Automatic Mode-Switching:

[0028] The device, e.g. a smartwatch stays in BLE mode normally for low power operations, and switches mode automatically upon a user action or external event to perform operations supported only in BT mode, and upon completion of those functions, switches back automatically to BLE mode.

[0029] FIG. 3 shows the flow chart of a first embodiment of the Automatic Mode-Switching method, namely user action-triggered mode switching user action-triggered mode switching, for example due to a button press to activate voice-command functions. The smartwatch automatically disconnects from a phone as a BLE device and reconnects back to the phone immediately as a BT device, sends the messages corresponding to the user actions, and upon completion of which, disconnects as a BT device from the phone and reconnects back to the phone as a BLE device.

[0030] Step 30 of the method illustrated by FIG. 3 shows connecting the smartwatch to a phone using the Bluetooth BLE protocol. Steps 31/32/33 depict disconnecting the smartwatch from the BLE connection by a user action as e.g. pressing a button and connecting the smartwatch to the phone using the classic BT protocol.

[0031] It should be noted that at the press of the button, the BLE transceiver inside the Watch initiates the termination of the BLE connection between the Watch and the Phone by sending the required messages and follow the BLE protocol for connection termination. Upon completion of the termination process, the BT transceiver inside the Watch (which can be physically the same component as the BLE transceiver) initiates a BT connection to the phone by sending the required messages and following the BT protocol for connection setup. The action is complete when the BT connection is set up and the Watch communicates to the Phone via the BT protocol.

[0032] It should be also noted that steps 32 and 33 are performed upon the user action of step 31 and no additional user action is required for connecting the device to the phone via the classic BT protocol. Step 34 describes sending classic BT messages from the smartwatch to the phone corresponding to a user action. Step 35 illustrates receiving Bluetooth messages from the phone to the smartwatch corresponding to user action. Step 36 describes a waiting loop waiting for more actions. In case more user actions are to be performed the process flow goes back to step 34 in order to execute the desired action in steps 34 and 35.

[0033] After a Time-Out, i.e. a time span without a user action, the device automatically falls back to a BLE connection mode in order to save power.

[0034] FIG. 4 shows a flow chart of a second embodiment of the Automatic Mode-Switching method, namely an external event -triggered mode switching method such as by e.g. an incoming call. In this case the smartwatch may alert the user as e.g. in case of an incoming call, and immediately switches automatically from BLE to BT mode without waiting for any user response such as pushing a button to answer to call. The call can then be connected until the mode switch is complete and user has taken action to accept the call. The perceived delay due to mode-switching is minimized as the time for mode-switching overlaps the time for user response, as shown in FIG. 4. Finally at the completion of the operations such as the termination of a call by the user, the smartwatch switches back automatically into BLE mode.

[0035] Identical steps of the flowcharts of FIGS. 3 and 4 are signified by the same step numbers.

[0036] The first step 30 of the flowchart of FIG. 4, namely connecting the smartwatch using the Bluetooth BLE protocol, is identical to the first step of the method of FIG. 3. In following steps 41/42 an external event, as e.g. man incoming call, happens and the smartwatch sends a corresponding notification to the user. The following steps 32/33 signify the time required for mode switching and depict disconnecting the smartwatch from the BLE connection activated by the external event of step 41 and connecting the smartwatch using the classic BT protocol. The next step 36 illustrates waiting for a user action corresponding to the external event until a time-out is activated if no action is taken. In case no action is taken the process flow goes to step 37 where the smartwatch is disconnected from the classic BT protocol and in the following step 38 the smart watch is connected as a BLE device. In case the user takes action in response to the alert sent in step 42 the correspondent action is taken in step 43 and the process flow is proceeds to step 37.

[0037] Steps 42, 32, 33 and 36 including the time out span of step 36 define the time available to the user to respond to the alert.

[0038] It should be noted that the flowcharts of FIGS. 3 and 4 describe two operations of the smartwatch, namely user action-triggered mode switch (FIG. 3) and external wireless triggered mode switch (FIG. 4). It is obvious that the smartwatch is configured to support both switching modes and that therefore the both flowcharts can be combined since in reality both switching modes can happen any time.

[0039] 2. Dual-ID (communication protocol addresses) device utilizing separate addresses (IDs)

[0040] The Dual-ID device utilizes separate IDs (i.e. Bluetooth addresses) for the two different modes in time-multiplexed connections: in case of using Bluetooth, the device (smartwatch) contains both BT and BLE as a dual mode device, but furthermore it operates as logically two independent devices with individual ID's being Bluetooth Addresses (BD_ADDR) although physically it is a single device. In this case the phone, being a dual- mode BT and BLE master, may connect to the smartwatch simultaneously in BT and BLE modes as logically two independent devices.

[0041] FIG. 5 shows a block diagram of a smartwatch 50 with BT and BLE functions that have independent BD_ADDR and connect to the phone as two separate slave 51/52 devices, wherein the BT classic slave 51 is hatched to the right side and the BLE slave 52 is hatched to the left side. As the phone 53 is a dual-mode Bluetooth master in this case, communication to the two slaves is naturally time-multiplexed as controlled by the master. The communication data blocks according to BT classic protocol are also hatched to the right and the communication data blocks according to BLE protocol are also hatched to the left, This means that the two slaves may share a lot of the hardware even though it is not the typical dual-mode controller that supports simultaneous BT and BLE as a master. This special case of dual-ID device that can connect as two separate slaves to the same master, in BT and BLE modes, lends itself to efficient hardware implementation as another major feature of this invention.

[0042] FIG. 6 shows the aspect of efficient hardware implementation disclosed within the Bluetooth core system architecture [Bluetooth Specification Version 4.0, Vol. 1, pp.31]. Compared to the typical dual-mode controller that can share all the controller blocks between BT and BLE, this dual-ID device would contain individual instantiations of all blocks related to the specific BD_ADDR, as shown by FIG. 6 wherein the blocks related to BT classic ADDR are signified by the label 60 and the blocks related to BLE ADDR are signified by the label 61.

[0043] Key advantages of the Dual-ID device disclosed utilizing separate Ids for two different modes are: [0044] 1. Seamless switching between BT and BLE modes with no user intervention, and minimizing perceived time latency for switching by carrying out other operations, such as alerting the user and waiting for user input, during the time of switching. [0045] 2. Dual-ID (Bluetooth addresses) BT and BLE device to support truly simultaneous voice and data connections between device and Bluetooth master. [0046] 3. Efficient implementation of the Dual-ID device with only small increase in complexity compare to typical dual-mode Bluetooth device.

[0047] It has to be noted that the methods and systems applying BT classic and BLE protocols shown above are non-limiting examples only. The systems and methods can be applied to any other dual protocol applications.

[0048] While the disclosure has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the spirit and scope of the disclosure.

[0049] What is claimed is: