Devices and methods for wireless communication

Abstract

The present disclosure relates to a method (210) of establishing a communication session, the method (210) including: detecting a user-triggered event (222) at a first communication device (200); generating, by the first communication device (200) and in response to the detection of the user-triggered event (222), a first message (232) according to the iBeacon communication protocol, wherein the first message (232) includes: identifier information (236) representative of the first communication device (200), random information (238), and event-related information (234) representative of the user-triggered event (222); transmitting, by the first communication device (200) and according to the iBeacon communication protocol, the first message (232) to a second communication device (242); and receiving, at the first communication device (200), a request to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device (200) and the second communication device (242).

Description

P97341DEVICES AND METHODS FOR WIRELESS COMMUNICATIONTechnical Field

[0001] The present disclosure is generally related to a method of establishing a communication session between two communication devices, and to communication devices configured to carry out the method to establish the communication session.Background

[0002] In general, various technologies and standards have been developed for wireless communication. A protocol that is widely adopted for short-range communication is Bluetooth (BT), which is based on the use of radio frequencies for transmission and reception at short distances. With the 4.0 version of the Bluetooth wireless networking standard, the Bluetooth Low Energy (BLE) was introduced, which is an adapted communication protocol that allows operating with reduced power consumption compared to the preceding Bluetooth versions. In the BLE-framework, the iBeacon technology has been developed as an advertising protocol for proximity sensing and location-based services. BLE and iBeacon are thus widely adopted in modern devices, so that improved strategies for wireless communication in the BLE- and iBeacon-context are of particular relevance for a variety of services and applications. US 2023 / 0217544 Al describes a rescue system used for search-and-rescue operation. In search-and-rescue scenarios, phones can emit low-power location signals. Rovers detect these signals while exploring dangerous terrain. The phones may use a battery-saving app that sends signals intermittently, and the rovers process the received data to support the rescue.US 9936466 Bl describes methods and systems for managing the emission of data from RF enabled tags.CN 104053155 A describes a data protection method and system for an iBeacon base station and a control device and a server for data protection of the iBeacon base station.Brief Description of the Drawings

[0003] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects of the invention are described with reference to the following drawings, in which:P97341FIG. l shows communication circuitry, in a schematic representation according to various aspects;FIG.2A and 2B show a communication device, in a schematic representation according to various aspects;FIG.3A and FIG.3B show an exemplary realization of the communication device, in a schematic representation according to various aspects;FIG.3C shows a switching operation of a switchable element of the communication device, in a schematic representation according to various aspects;FIG.4A shows event-related information representative of a user-triggered event, in a schematic representation according to various aspects;FIG.4B shows random information, in a schematic representation according to various aspects;FIG.4C shows identifier information representative of a communication device, in a schematic representation according to various aspects;FIG.5 A shows a communication device, in a schematic representation according to various aspects;FIG.5B shows the communication device including an installed application, in a schematic representation according to various aspects;FIG.6 A shows a schematic communication flow between a first communication device and a second communication device, according to various aspects; andFIG.6B shows a schematic communication flow between a portable safety button and an application, according to various aspects.Description

[0004] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects in which the invention may be practiced. These aspects are described in sufficient detail to enable those skilled in the art to practice the invention. Other aspects may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects are not necessarily mutually exclusive, as some aspects may be combined with one or more other aspects to form new aspects. Various aspects are described in connection with methods and various aspects are described in connection with devices (e.g., a first communication device, a second communication device, etc.). However, it is understood that aspects described in connection with methods may similarly apply to the devices, and vice versa.P97341

[0005] In general, Bluetooth (BT) is a well-established technology in the context of short-range communication and small area networks. BT enables communication without the need for connection to the internet, and provides a cost- and energy-efficient framework for exchange of data between devices that are in close proximity to one another. An evolution of the BT technology is the so-called Bluetooth Low Energy (BLE), also referred to as Bluetooth smart, introduced with the 4.0 version of the Bluetooth wireless networking standard and further developed in the later versions (e.g., 4.1, 4.2, 5.0, 5.1, 5.2, and 5.3).

[0006] The BLE protocol is designed to operate efficiently in power-constrained environments, typical of modern portable devices, which are usually battery-operated and for which a reduced power consumption is thus of particular relevance. BLE has two primary modes of communication, namely “broadcasting” and “connections”. In the (connectionless) broadcasting mode, a device (the broadcaster) transmits data to any nearby BLE-enabled devices (observers). Connections, on the other hand, involve bidirectional data transfer between two devices, with periodic transmissions occurring in both directions. Both broadcasting and connections are governed by the Generic Access Profile (GAP) specification.

[0007] In BLE connections, participating devices assume distinct roles. A first BLE-enabled device transmits advertisement packets to allow discovery and connection establishment with other BLE-enabled devices. A second BLE-enabled device perform scans of available communication channels to detect the advertisements packets and establish a connection upon finding a suitable packet. Following connection establishment, either BLE-enabled device may assume the roles of client or server. The client typically accesses resources on the server, and the server provides data to the client. Data exchange between clients and servers may generally occur via a request-response mechanism.

[0008] In the BLE-context, the iBeacon communication protocol has been developed as a technology for use in BLE-enabled devices. The iBeacon technology is an advertising protocol designed for proximity sensing and proximity-based services and applications. In brief, an iBeacon device (also referred to simply as “Beacon” or “iBeacon”) transmits a unique identifier, known as the Universally Unique Identifier (UUID), together with additional data such as a major identifier (major ID) and a minor identifier (minor ID), to nearby BLE-enabled devices (e.g., a smartphone, a tablet, etc.). A BLE-enabled device that receives the iBeacon advertising packet may use the UUID, major ID, and minor ID to identify specific iBeacon devices. The BLE-enabled device may then determine its proximity to the iBeacon device (based on the strength of received signal), and may carry out corresponding actions, such as showing a push-P97341 notification, alerting a user, launching an application, providing location-based information, and the like.

[0009] Although widely adopted, the use of BLE and iBeacon technology in modern applications presents certain limitations. For example, BLE-enabled devices, while efficient in connectivity, may be heavy on battery consumption and require a continuously running paired application, particularly on iOS platforms. This continuous operation can be impractical. On the other hand, iBeacon technology, although effective for proximity sensing and triggering actions, lacks feedback mechanisms and may be ignored by the operating system (OS) of the BLE-enabled device after repeated detections, diminishing its reliability.

[0010] The present disclosure is related to a strategy for establishing a communication session between two wireless communication devices that addresses the above-mentioned weaknesses by combining the strengths of both iBeacon and BLE technologies to create a dynamic and energy-efficient system that ensures reliable communication and feedback mechanisms. In particular, the present disclosure is based on the realization that rather than relying exclusively on one technology (i.e., only iBeacon, or only BLE), a hybrid approach may be provided in which the initial “discovery” exploits the iBeacon capabilities, and subsequently a communication session is carried out exploiting the BLE capabilities.

[0011] The hybrid communication combines thus the advantages of the iBeacon protocol, such as background detection, energy efficiency, and a simple configuration for the beacon, with the possibility of a feedback mechanism during the BLE communication session. The approach proposed herein introduces thus a dynamic configuration for a device or application that leverages iBeacon protocol and BLE connectivity. Illustratively, in the iBeacon protocol communication is generally unidirectional, with the iBeacon transmitting data to the BLE- enabled device but without receiving or collecting data therefrom. Aspects of the present disclosure are thus based on the realization that the strengths of the iBeacon protocol in relation to the establishment of the connection may be combined with the strengths of the BLE protocol for the communication session itself, in which a bidirectional data exchange is enabled.

[0012] In particular, the approach proposed herein is provided in the context of iBeacon devices capable of reacting to an action by a user, and reporting the occurrence of the action to a BLE-enabled device. Illustratively, the iBeacon device may recognize the occurrence of a user-triggered event at the iBeacon device, and may report the occurrence of the event by including event-related information in the initial iBeacon message (together with the identifier information), and then by further communicating with the BLE-enabled device during the BLE communication session. The proposed strategy allows making the BLE-enabled device awareP97341 of the user-triggered event in a rapid and efficient manner (using the iBeacon technology), while enabling a feedback mechanism between the iBeacon device and the BLE-enabled device in the BLE communication session.

[0013] Furthermore, according to the approach proposed herein, the iBeacon message that reports the user-triggered event includes, in addition to the identifier information and the event-related information, random information (illustratively, a random component that varies randomly among different iBeacon messages). The presence of random information prevents that the BLE-enabled device that receives the iBeacon message simply ignores it without taking an appropriate action. Illustratively, in the context of reporting user-triggered events, a common occurrence is that the OS of a BLE-enabled device does not react to an iBeacon message because previous messages from that iBeacon device did not contain any relevant information and did not report any event (because no event occurred at that time). The random component ensures that the BLE-enabled device processes each iBeacon message from the iBeacon device, thus enhancing the reliability of the communication and ensuring that the user-triggered event is suitably processed at the BLE-enabled device.

[0014] The configuration proposed herein may make use of the iBeacon protocol with the major identifier (major ID) as a primary identifier and the minor identifier (minor ID) for incorporating randomness and communication of events (e.g., click counts). This approach ensures continuous notification by the OS and allows for an immediate reaction from the paired application. Upon detection, the application may establish a BLE connection for feedback and further interaction.

[0015] According to various aspects, from the point of view of the iBeacon device, a method of establishing a communication session is provided, the method including: detecting a user-triggered event at a first communication device; generating, by the first communication device and in response to the detection of the user-triggered event, a first message according to the iBeacon communication protocol, wherein the first message includes: identifier information representative of the first communication device, random information, and event-related information representative of the user-triggered event; transmitting, by the first communication device and according to the iBeacon communication protocol, the first message to a second communication device; and receiving, at the first communication device, a request to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device and the second communication device.

[0016] A computer program product may be provided, the computer program product comprising instructions which, when the program is executed by a computer, cause theP97341 computer to carry out the method of establishing a communication session described in the preceding paragraph.

[0017] According to various aspects, a corresponding communication device configured for wireless communication (e.g., an iBeacon device) may be provided, the communication device including a processor configured to: detect a user-triggered event at the communication device; generate, in response to the detection of the user-triggered event, a first message according to the iBeacon communication protocol, wherein the first message includes: identifier information representative of the communication device, random information, and event-related information representative of the user-triggered event; cause a transmission, according to the iBeacon communication protocol, of the first message to a second communication device; and receive a request to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the communication device and the second communication device.

[0018] According to various aspects, from the point of view of the BLE-enabled device, a method of establishing a communication session is provided, the method including: receiving, at a second communication device, a first message according to the iBeacon communication protocol from a first communication device, wherein the first message includes: identifier information representative of the first communication device, random information, and event-related information representative of a user-triggered event at the first communication device; and issuing, by the second communication device and in response to the first message, a request to the first communication device to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device and the second communication device.

[0019] A computer program product may be provided, the computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of establishing a communication session described in the preceding paragraph.

[0020] According to various aspects, a corresponding communication device configured for wireless communication (e.g., a BLE-enabled device) may be provided, the communication device including a processor configured to: receive a first message according to the iBeacon communication protocol from a first communication device, wherein the first message includes: identifier information representative of the first communication device, random information, and event-related information representative of a user-triggered event at the first communication device; and issue, in response to the first message, a request to the firstP97341 communication device to establish a communication session according to the Bluetooth Low- Energy, BLE, protocol between the first communication device and the communication device.

[0021] In some aspects, the method from the point of view of the iBeacon device and the method from the point of view of the BLE-enabled device define together a method of establishing a communication session between the first communication device and the second communication device.

[0022] After the establishment of the communication session, the first communication device and the second communication device may be configured to communicate according to the BLE protocol. In this context, the second communication device may transmit feedback information to the first communication device during the BLE communication session, and the first communication device may receive the feedback information. The proposed approach allows thus a dynamic and adaptive mechanism that enables bidirectional communication and allows delivering information to the first communication device.

[0023] The communication strategy proposed herein is of particular relevance in the context of portable safety buttons. As generally known, a “portable safety button” is a small portable device (e.g., a wearable device) configured to allow a user to quickly call for help in case of an emergency. The user may push the safety button to trigger a response to a safety-relevant situation. For example, pushing the safety button may trigger a silent alert, initiate a call to an emergency service (e.g., to the police, to a hospital, to the fire department, to a private security firm, etc.), inform predefined emergency contacts, and / or the like. A “portable safety button” may also be referred to as “alarm button”, “action button”, “panic button”, “emergency button”, or “emergency alert device”.

[0024] In the context of the present disclosure, the portable safety button may be the first communication device that transmits the user-related information using the iBeacon message with the random component. In this regard, the user-triggered event may include an actuation of the safety button that is indicative of an emergency situation for the user. The approach proposed herein may thus ensure that the call for help is not ignored by the BLE-enabled device (e.g., a smartphone that includes an application configured to carry out a corresponding action) thanks to the random information contained in the iBeacon message, and the BLE communication session may allow the BLE-enabled device to inform the user regarding the actions taken (e.g., “alarm delivered”, “help is on the way”, “call to the police initiated”, etc.) via the feedback provided to the portable safety button.

[0025] Thus, in the following particular reference may be made to the scenario in which the communication device transmitting the iBeacon message is a portable safety button, andP97341 terminology may be used that pertains to the context of portable safety buttons. It is however understood that the communication strategy proposed herein is not limited to portable safety buttons, and that establishing a communication session according to the hybrid approach proposed herein may be for use with any suitable communication devices for which combining the properties of iBeacon and BLE may be beneficial.

[0026] The term “BLE-enabled” is used herein in relation to a device to describe that the device is configured to carry out communication according to the BLE communication protocol. Illustratively, a “BLE-enabled” device may include communication circuitry configured to enable transmission and / or reception of messages according to the BLE communication protocol (see also FIG.l), and configured to process messages according to the BLE communication protocol (e.g., configured to extract information from a BLE message, and / or to prepare a BLE message for transmission via the communication interface). A “BLE-enabled” device may thus be configured to carry out wireless communication according to Bluetooth technology (via radiofrequency waves), and may be configured to carry out communication according to the set of rules defined by the BLE protocol.

[0027] In this regard, references herein to entities configured according to Bluetooth Low Energy, e.g., a BLE-enabled device, a BLE communication session, a BLE message, etc., refer to entities configured according to the set of rules and instructions defined by any Bluetooth standard that supports BLE, both existing or not yet formulated. Examples of Bluetooth standard that support BLE include Bluetooth 4.0 Low Energy (2010), Bluetooth 4.1 (2013), Bluetooth 4.2 (2014), Bluetooth 5.0 (2016), Bluetooth 5.1 (2019), Bluetooth 5.2 (2020), Bluetooth 5.3 (2021), and Bluetooth 5.4 (2023).

[0028] The term “iBeacon” is used herein in relation to a device to describe that the device is configured to enable communication according to the iBeacon communication protocol. Illustratively, an “iBeacon” device may include communication circuitry configured to enable transmission and / or reception of messages according to the iBeacon communication protocol, and configured to process messages according to the iBeacon communication protocol (e.g., configured to extract information from an iBeacon message, and / or to prepare an iBeacon message for transmission via the communication interface). A “iBeacon” device may thus be configured to carry out wireless communication according to Bluetooth technology (via radiofrequency waves), and may be configured to carry out communication according to the set of rules defined by the iBeacon protocol.

[0029] In this regard, references herein to entities configured according to iBeacon, e.g., an iBeacon device, an iBeacon message, etc., refer to entities configured according to the set ofP97341 rules and instructions defined by any standard that supports iBeacon, both existing or not yet formulated. An example includes the document “Getting Started with iBeacon Version 1.0” dated June 2, 2014 and issued by Apple Inc.

[0030] In general, iBeacon is a development of BLE. Thus, communication circuitry configured to carry out communication according to the iBeacon communication protocol may also be capable of carrying out communication according to the BLE communication protocol. An iBeacon device may thus generally be considered to be a BLE-enabled device. In a corresponding manner, communication circuitry configured to carry out communication according to the BLE communication protocol may further be configured to carry out communication according to the iBeacon communication protocol. A BLE-enabled device may thus be further configured to carry out communication according to the iBeacon protocol.

[0031] Before describing the specific features of the adapted approach for establishing a communication session, the general aspects of communication circuitry for use in a communication device are discussed with reference to FIG.l, which shows communication circuitry 100 in a schematic representation according to various aspects. The representation of the communication circuitry 100 is simplified to discuss the general components to enable wireless communication (e.g., in the BLE-context and iBeacon context). The aspects discussed in relation to the communication circuitry 100 apply in general to circuitry for use in a (first) communication device configured to transmit an iBeacon message (see FIG.2A), as well as in a (second) communication device configured to receive the iBeacon message (see FIG.5A).

[0032] The communication circuitry 100 may be configured for wireless communication, and may include a communication portion 102 (also referred to herein as communication interface, or communication circuit) and a signal processing portion 104 (also referred to herein as processing portion, or processing circuit). It is understood that the communication circuitry 100 in FIG. l is exemplary, and in general communication circuitry for use in a communication device may include additional, fewer, or alternative components with respect to those shown.

[0033] The communication circuitry 100 may be configured to transmit and / or receive radiofrequency signals (illustratively, radiofrequency waves) via the communication portion 102. In this regard, the communication portion 102 may be configured to enable wireless communication, and may include one or more antennas 110, and a radiofrequency transceiver 112. For example, the communication portion 102 may include a single antenna 110, or a plurality of antennas 110 (e.g., an array of antennas 110). The one or more antennas 110 may be for example directional or omnidirectional antennas. The one or more antennas 110 may include any suitable type of antennas for transmitting / receiving radiofrequency signals, such asP97341 dipole antennas, loop antennas, microstrip antennas, patch antennas, and the like. As an example, considering the BLE / iBeacon-context, the one or more antennas 110 may be configured to enable transmission and reception of radiofrequency signals in the 2.4 GHz ISM spectrum band (e.g., from 2400 MHz to 2483.5 MHz), where ISM stands for “Industrial, Scientific, and Medical”.

[0034] As another example, the one or more antennas 110 may be configured to enable transmission and reception of radiofrequency signals in the frequency range above 2.4 GHz, for example from 3.1 GHz to 10.6 GHz (ultra-wideband), e.g., in a 500 MHz bandwidth within such range. As a further example, the one or more antennas 110 may be configured to enable transmission and reception of radiofrequency signals in a frequency range below 1 GHz, for example in a frequency range from 100 MHz to 500 MHz (narrowband), e.g., in the frequency range from 150 MHz to 174 MHz and / or 421 MHz to 470 MHz, e.g., in a 25 kHz bandwidth within such ranges. As a further example, the one or more antennas 110 may be configured according to Long Range (LoRa) technology, and enable transmission and reception of radiofrequency signals in the sub-gigahertz radiofrequency bands EU868 (863 MHz to 870 / 873 MHz), AU915 / AS923-1 (915 MHz to 928 MHz), US915 (902 MHz to 928 MHz), IN865 (865 MHz to 867 MHz), and / or AS923 (915 MHz to 928 MHz).

[0035] In some aspects, the communication circuitry 100 may include antennas configured to operate in different frequency ranges, e.g., the communication circuitry may include a plurality of subsets of antennas, each dedicated to transmission / reception of radiofrequency signals in a respective frequency range.

[0036] The radiofrequency transceiver 112 may include a receiver circuit 114 (illustratively, a receive path), and a transmitter circuit 116 (illustratively, a transmit path). In this regard, the radiofrequency transceiver 112 may include analog and digital components for processing radiofrequency signals, such as amplifiers, filters, up-converters, down-converters, signal modulators, quadrature couplers, analog-to-digital converters (ADCs), digital-to-analog converters (DACs), and the like.

[0037] Considering the receive path 114, the radiofrequency transceiver 112 may be configured to receive analog radiofrequency signals from the one or more antennas 110, and perform analog and digital front-end processing on the analog radiofrequency signals to obtain digital baseband signals. In the transmit path 116, the radiofrequency transceiver 110 may be configured to receive digital baseband signals from the signal processing portion 104, and perform analog and digital front-end processing on the digital baseband signals to obtain analog radiofrequency signals to be transmitted via the one or more antennas 110. In particular, theP97341 radiofrequency transceiver 112 may be a Bluetooth radio, e.g., a BLE radio. Illustratively, the radiofrequency transceiver 112 may be a hardware transceiver configured to implement the BLE specification.

[0038] The signal processing portion 104 may be configured to carry out signal processing for transmission and reception according to one or more communication protocols. Illustratively, the signal processing portion 104 may be configured to control the radiofrequency transceiver 112 to transmit and receive radio signals according to the set of rules defined by the communication protocol(s), e.g., defined by the BLE communication protocol and / or iBeacon communication protocol. The signal processing portion 104 may thus be configured to instruct the radiofrequency transceiver 112 with instructions representative of signal modulation, signal frequency, timing, synchronization, etc., depending on the rules and instructions specified by the communication protocol(s) according to which the communication circuitry 100 transmits and / or receives radiofrequency signals.

[0039] For example, the signal processing portion 104 may include a digital signal processor 122 configured to perform physical layer (PHY) transmission and reception processing, and a protocol manager 124 configured to carry out functions associated with upper-layers in the protocol stack of the communication protocol. The digital signal processor 122 may thus be configured to receive data and information from the protocol manager 124, and may be configured to prepare the received data and information for transmission via the transmitter circuit 112. At the receiver side, the digital signal processor 122 may be configured to receive digital signals from the receiver circuit 114, and prepare the digital signals for processing by the protocol manager 124.

[0040] As exemplary physical layer processing functions, the digital signal processor 122 may be configured to carry out error detection, error correction, signal encoding, signal decoding, channel modulation, channel demodulation, power control, time synchronization, frequency synchronization, and the like.

[0041] The protocol manager 124 may be configured to control the radio communication components of the communication circuitry 100 (e.g., the antennas 110, the radiofrequency transceiver 112, the digital signal processor 122) according to the communication protocol(s) used for signal transmission and reception.

[0042] The signal processing portion 104 may further include an application processor 126 configured to carry out processing in the layers above the protocol stack. For example, the application processor 126 may be configured to execute programs and applications at the application layer of a communication device including the communication circuitry 100. AsP97341 examples, the application processor 126 may be configured to implement an operating system (OS), a user interface (UI), or any suitable control function related to interactions with a user.

[0043] The communication circuitry 100 may further include a memory 130 coupled with the signal processing portion 104. The memory 130 may be configured to store any suitable information relevant for the operation of the communication circuitry 100. For example, the memory 130 may be configured to store instructions to be carried out by the signal processing portion 104, data to be transmitted via the transmitter circuit 112, data received via the receiver circuit 114, and the like.

[0044] Turning now to the adapted method of establishing a communication session proposed herein, the aspects related to the communication device that transmits the initial iBeacon message will be discussed in relation to FIG.2A to FIG.4C, and the aspects related to the communication device that receives the initial iBeacon message will be discussed in relation to FIG.5 A and FIG.5B. Without loss of generality, the communication device that transmits the initial iBeacon message may be referred to herein as “first” communication device, and the device that receives the initial iBeacon message may be referred to herein as “second” communication device. It is however understood that the terms “first” and “second” serve merely to distinguish the two devices, and do not imply any specific preference, hierarchy, order, or the like.

[0045] FIG.2A shows a (first) communication device 200 configured to carry out communication according to the hybrid approach proposed herein, in a schematic representation according to various aspects. The communication device 200 may generally be configured for wireless communication, and may include a processor 202 coupled to a memory 204. The memory 204 may be configured to store instructions (e.g., software instructions) executed by the processor 202. The instructions may cause the processor 202 to perform an adapted method 210 of establishing a communication session with another communication device 242, which is described in further detail below. Aspects described with respect to a configuration of the processor 202 may also apply to the method 210 and vice versa.

[0046] The wireless communication device 200 may further include communication circuitry 206 configured to enable wireless communication. The communication circuitry 206 may generally be configured as the communication circuitry 100 described in FIG.l, e.g., the communication circuitry 206 may include a communication portion for transmitting / receiving radiofrequency waves, and may include a signal processing portion for processing the signals received / to be transmitted. In this regard, the signal processing portion may be a dedicated circuit, or the processor 202 may be further configured to implement signal processingP97341 functionalities for transmission / reception. In particular, the communication circuitry 206 may be configured for transmission and reception of signals according to the BLE communication protocol and iBeacon communication protocol, as discussed in relation to FIG.l. The communication device 200 may thus be understood as a BLE-enabled device and iBeacon device (or iBeacon-enabled device).

[0047] In general, the processor 202 may be configured to receive an input from a user (illustratively, a user input), and to establish a communication session with another communication device 242 in response to the input from the user (see also FIG.6A). In this regard, the processor 202 may be configured to detect a user-triggered event 220 at the (first) communication device 200. Illustratively, the processor 202 may be configured to determine that the user of the communication device 200 performed an action at the communication device 200 that triggers the communication with the other communication device 242.

[0048] Stated differently, the processor 202 may be configured to detect the occurrence of an event triggered by an interaction of the user with the communication device 200, and may react accordingly to initiate the establishment of a communication session with the other communication device 242, as discussed in further detail below. Illustratively, the processor 202 may be configured to detect (as “user-triggered event” 222) an action by the user, and carry out the subsequent steps of the method 210 in response to detecting the action. In this regard, the “user-triggered event” 222 may be any suitable type of event (illustratively, any suitable type of interaction) depending on the general configuration of the communication device 200 and on the intended use case for the hybrid approach proposed herein. Aspects related to the user-triggered event 222 will be discussed in further detail in relation to FIG.2B.

[0049] The processor 202 may be further configured to generate a (first) message 232 according to the iBeacon communication protocol in response to detecting the user-triggered event. The first message 232 may thus be a data packet having a format defined by the iBeacon communication protocol. In this regard, the first message 232 may include a plurality of fields according to the structure defined by the iBeacon protocol. According to the approach proposed herein, the first message 232 may include event-related information 234, identifier information 236, and random information 238, as discussed in further detail below.

[0050] In addition, the first message 232 may include any further suitable field or type of information according to the iBeacon protocol, such as a preamble and power-related information. The preamble may be a 9-Bytes constant preamble, and may include data length, data type, flags, and manufacturer-specific data (e.g., length, type, company ID, etc.). The power-related information may be representative of the transmit power, and may represent theP97341 average signal power measured at a predefined distance from the communication device 200 (e.g., at a distance of 1 meter). The power-related information may allow the other communication device 242 that receives the first message 232 to determine the distance from the communication device 200 (e.g., near, intermediate, far) depending on the power of the signal received at the other communication device 242. The first message 232 may thus be understood as an iBeacon-type message, further adapted to contain information that enables the hybrid approach proposed herein.

[0051] The information contained in the first message 232 will be discussed in further detail in relation to FIG.4A to FIG.4C. In general, the identifier information 236 is representative of the communication device 200. Illustratively, the identifier information 236 is configured to enable the other communication device 242 that receives the message 232 to identify the communication device 200 from which the message 232 originated (see also FIG.4C). The event-related information 234 is representative of the user-triggered event 222. Illustratively, the event-related information 234 may include one or more properties of the user-triggered event 222 (see also FIG.4A), thus allowing the communication device 242 that receives the message 232 to determine an appropriate response to the event 222. Finally, the random information 238 may include randomly generated information, e.g., information that is not predefined but is generated for inclusion in the message 232 in a random manner (see also FIG.4B).

[0052] The processor 202 may be further configured to cause a transmission of the first message 232 to a second (other) communication device 242. Illustratively, after having generated the message 232, the processor 202 may instruct the communication circuitry 206 to transmit the first message 232 (e.g., to transmit a radiofrequency signal that represents the message 232). The processor 202 may thus prepare the message 232 by including the above-mentioned information, and then may transmit the message 232 to the second communication device 242. The second communication device 242 will be described in further detail in relation to FIG.5 A and FIG.5B. In general, the second communication device 242 may be a further BLE-enabled (and iBeacon-enabled) device within communication range of the (first) communication device 200.

[0053] The processor 202 may be further configured to receive, from the other communication device 242, a request 252 to establish a communication session according to the BLE communication protocol between the communication device 200 and the other communication device 242. Illustratively, as will be discussed in further detail in relation to FIG.5A, the other communication device 242 may evaluate the information contained in the message 232 and, ifP97341 appropriate, request the establishment of a BLE communication session with the (first) communication device 200. The communication circuitry 206 may thus receive a signal (a BLE message) representing the request 252, and may deliver the request 252 to the processor 202.

[0054] Stated in a different fashion, the processor 202 may receive a connection request 252 from the other communication device 242 in response to transmission of the message 232 and reception / processing of the message 232 by the other communication device 242. The proposed approach includes thus the initial iBeacon message 232 for informing the other communication device 242 of the event 222, and further includes the establishment of a BLE communication session (via the corresponding request 252) for the subsequent exchange of information between the communication device 200 and the other communication device 242.

[0055] Although not shown, the processor 202 may be further configured to accept the request 252, and establish (and carry out) the BLE communication session with the other communication device 242. During the BLE communication session, the communication devices 200, 242 may communicate with one another according to the BLE protocol, as discussed in further detail below, thus enabling an exchange of feedback information that would otherwise not be supported by the iBeacon technology. Further aspects related to the communication session and to the behavior of the communication device 200 during the established communication session will be discussed in relation to FIG.6A.

[0056] In this context, the term “establish(ing)” or “establishment” may include any suitable tasks and operations to bring the communication session into existence. The term “establish(ing)” or “establishment” may thus refer to tasks and operations for initiating, starting, setting up, or generally making “ready for use” the communicative relationship between the first communication device and the second communication device. Furthermore, any definition for the term “establish” or “establishment” defined in any of the above-identified specifications or standards may be used for purposes of the present disclosure.

[0057] Further in this context, the term “communication session” describes a temporary and interactive exchange of information between two entities (e.g., between the first communication device and the second communication device). For example, the term “communication session” may describe a bidirectional flow of messages between the two entities over a certain time period (e.g., from a start of the communication session to an end of the communication session). In particular, the term “communication session” may refer herein to a communication session according to the BLE communication protocol, in which the entities involved in the communication session exchange information according to the rules and formats specified by the BLE protocol. A “communication session” may thus be a structured communicativeP97341 interaction between the involved entities, e.g., according to the structure defined by the BLE technology.

[0058] From the point of view of the method 210, the method 210 may include, in 220, detecting the occurrence of the user-triggered event 222 at the communication device 200. The method 210 may further include, in 230, generating the first message 232 according to the iBeacon communication protocol in response to detecting the occurrence of the user triggered event 222. The method 210 may further include, in 240, transmitting the first message 232 to a second communication device 242. The method 210 may further include, in 250, receiving a request 252 to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device 200 and the second communication device 242.

[0059] As mentioned, the user-triggered event 222 may be any suitable type of interaction that the user has with the communication device 200 for prompting the processor 202 to generate / transmit the first message 232 and for the subsequent communication with the other communication device 242. In a preferred configuration, which provides the most relevant use case for the approach proposed herein, the user-triggered event 222 may include the switching of a switchable element 260 of the communication device 200, shown in FIG.2B.

[0060] In various aspects, the communication device 200 may include a switchable element 260 that is controllable (e.g., switchable) by the user of the communication device 200, and the user-triggered event 222 may include the user operating the switchable element 260. For example, the switchable element 260 may be switchable between a plurality of states, e.g., at least a first state and a second state, or more than two states (e.g., a third state, a fourth state, etc.). In this scenario, the user-triggered event 222 may include a switching of the switchable element 260 (by the user) from one state to another state, e.g., from the first state into the second state (or from the second state to a third state, etc.), or vice versa.

[0061] Stated differently, the switchable element 260 may be a user-operable element of the communication device 200, and the processor 202 may be configured to detect the occurrence of the event 222 by detecting a change of state of the switchable element 260. For example, the processor 202 may determine that the user-triggered event 222 occurred if the switching fulfills one or more predefined criteria, e.g., a certain number of consecutive switching, a certain duration of the switchable element 260 being in a certain state, and the like, thus carrying out the rest of the procedure to establish the communication session only in case of an intentional action by the user.P97341

[0062] In a preferred configuration, the user-triggered event 222 may include a predefined number of switching operations of the switchable element 260, illustratively a predefined number of changes of state of the switchable element 260. The processor 202 may thus determine that the user-triggered event 222 occurred if the switchable element 260 changed state (e.g., from the first state into the second state) a predefined number of times, e.g., a predefined plurality of times within a predefined time period. Stated differently, the processor 202 may determine that the user of the communication device 200 is intentionally prompting the communication device 200 to initiate the procedure for establishing the communication session with the other communication device 242 if the switchable element 260 is switched from the first state into the second state (or between the first state and the second state, or any other state) the predefined number of times. The predefined number of times may include any suitable number that provides a balance between a fast response and avoiding undesired activations by the user. As examples, the predefined number of times may be one, two, three, four, five, or more than five.

[0063] It is however understood that in principle any suitable criterion may be used. As another example, the user-triggered event 222 may include a predefined duration of the switchable element 260 being in one of the states (e.g., the second state). For example, one of the states (e.g., the first state) may be a default or non-switched state of the switchable element 260, and another one of the states (e.g., the second state) may be a switched state of the switchable element 260, and the processor 202 may determine that the user-triggered event 222 occurred if the switchable element 260 remains in the switched state for a predefined period of time (e.g., for more than a predefined threshold, e.g., more than 250 milliseconds, more than 1 second, more than 5 seconds, more than 10 seconds, as examples).

[0064] In a preferred configuration, as will be discussed in further detail in relation to FIG.3 A to FIG.3C, the switchable element 260 may be a physical button that is switchable between a released state (as first state, e.g., as default state) and a pressed state (e.g., as second, switched state). In this configuration, the user-triggered event 222 may include a pressing (in other words, a pushing) and / or a releasing of the physical button (by the user of the communication device 200). In this scenario, the processor 202 may determine that the user-triggered event 222 occurred if the button was pressed (e.g., changed from the released state into the pressed state) a predefined number of times.

[0065] As mentioned, a physical button is a relevant use case as the proposed communication strategy is of particular relevance in the context of physical safety buttons. It is however understood that in principle the user-triggered event 222 may be any suitable type of action byP97341 the user of the communication device, and / or that the communication device 200 may include any suitable type of user-operable element whose operation / activation by the user defines the user-triggered event.

[0066] As another example, the user-triggered event 222 may include an audio input by the user, e.g., a certain sound or sequence of sounds input by the user to the communication device 200 (e.g., to a microphone of the communication device 200). For example, the user-triggered event 222 may include a predefined word pronounced by the user. As a further example, the user-triggered event 222 may include a visual input by the user, e.g., the communication device 200 may be configured to carry out face recognition or eye tracking, and the user-triggered event 222 may include a recognition of the face of the user, or the recognition of a gaze of the user in a certain direction.

[0067] As a further example of user-operable element, the communication device 200 may include a knob that is rotatable between a plurality of different positions, and the user-triggered event 222 may include a rotation of the knob from a first position to a second position. As a further example of user-operable element, the communication device 200 may include a sliding element that is slidable between a plurality of different positions, and the user-triggered event 222 may include a sliding of the sliding element from a first position to a second position.

[0068] As a further example, the user-operable element may be a sensor configured to sense a physical quantity, and the user-triggered event 222 may include the sensed physical quantity fulfilling a predefined criterion (e.g., the sensed physical quantity being greater or less than a predefined threshold). For example, the communication device 200 may include a light sensor, and the user-triggered event 222 may include the light sensor detecting no light or light below a certain illumination threshold (in this case the activation may be the user covering the light sensor with a finger). For example, the communication device 200 may include a gyroscope, and the user-triggered event 222 may include an acceleration of the communication device 200 being greater than a predefined threshold (in this case the activation may be the user rapidly moving or shaking the device).

[0069] As another example, the communication device 200 may include a touch screen, and the user-operable element may include an element displayed on the screen. In this scenario, the user-triggered event 222 may include a touch of the user on the touch screen, e.g., a touch corresponding to a virtual switching of the operable-element. For example, the user-triggered event 222 may include a predefined pattern drawn by the user on the touch screen.

[0070] It is also understood that the communication device 200 may include more than one user-operable element, e.g., more than one switchable element 260, and the user-triggered eventP97341222 may include an operation by the user of the plurality of user-operable elements (e.g., a switching of the plurality of switchable elements), for example in a certain sequence, or according to a certain pattern, and the like.

[0071] In general, the communication device 200 may be any suitable type of device. In particular, the communication device 200 may be a portable device. In this scenario, the communication device 200 may be a battery-powered device, e.g., a device including a rechargeable battery or a device configured to receive a rechargeable battery. The communication device 200 may thus include a battery slot configured to receive a battery (or a plurality of batteries). In some aspects, the communication device 200 may include the battery or batteries providing power to the various components of the communication device 200.

[0072] In this regard, FIG.3A to FIG.3C show a portable safety button 300, which may be a preferred realization of the (first) communication device 200. It is understood that the configuration of the portable safety button 300 is exemplary, and that the portable safety button may include additional, fewer, or alternative components with respect to those shown. It is also understood that the approach proposed herein may be applied to other types of (first) communication devices 200, such as mobile communication devices (e.g., a smartphone, a tablet, a laptop, a netbook, a pager, etc.), wearable devices (e.g., a smartwatch, smart glasses, earbuds, etc.), and the like.

[0073] In the exemplary configuration of FIG.3A to FIG.3C, the portable safety button 300 may include a housing 302 that encloses the internal components of the portable safety button 300. For example, the housing 302 may be made of a plastic material. The portable safety button 300 may further include a physical button 304 (an exemplary realization of the switchable element 260), which the user or owner of the portable safety button 300 may press in case of emergency. The portable safety button 300 may further include one or more elements operable to provide a feedback to a user. As an example, as shown in FIG.3 A, the portable safety button 300 may include a light-emitting element 306, e.g., a light-emitting diode (LED) ring, configured to emit light. For example, the light-emitting element 306 may emit light to signal that the button 304 has been pressed, or to signal a feedback from another device. As other examples of elements operable to provide a feedback to a user the portable safety button 300 may include, in addition or in alternative to the light-emitting element 306, a vibrating element to provide a tactile feedback as a vibration of the portable safety button 300 and / or a speaker to provide an audible feedback (e.g., a sound).

[0074] The various components of the portable safety button 300 may be mounted on a circuit substrate 308, e.g., a printed circuit board. The portable safety button 300 may further includeP97341 a mounting hole 310 to facilitate transport of the button 300 by the user, e.g., to allow mounting the button 300 to a key chain, to a necklace, to a bracelet, and the like.

[0075] FIG.3B shows a view of the interior of the button 300, illustratively of the interior of the housing 302. As shown, in this exemplary configuration the button 300 may include a power supply 312, e.g., a battery (e.g., a rechargeable battery). The button 300 may further include a processor 314, e.g., a central processing unit, CPU, (e.g., an exemplary realization of the processor 202). The processor 314 may be a system on chip configured to control the operation of the button 300. The button 300 may further include a BLE radio and antenna 316, illustratively a communication interface configured to enable communication according to the BLE (and iBeacon) communication protocol, e.g., an exemplary realization of the communication portion 102 discussed in FIG. l.

[0076] FIG.3C shows an exemplary activation 320 of the button 300 by the user. As shown, the user 322 presses the physical button 304 (e.g., once, or a predefined number of times). The firmware 324 reacts by waking up the system, starting radio communication and transferring information. According to the proposed approach, the firmware 324 may react to the pressing of the button by generating the message according to the iBeacon protocol, initiating the BLE communication session with the other communication device, and carrying out a transfer of information during the BLE communication session. The firmware may further receive a command (during the BLE communication session) to play out a blink pattern using the lightemitting element 306, e.g., using the LED ring.

[0077] The content of the (first) message 232 according to the iBeacon protocol will be discussed in further detail in relation to FIG.4A to FIG.4C. Illustratively, FIG.4A to FIG.4C describe possible configurations of the event-related information 234, identifier information 236, and random information 238. The aspects of FIG.4A to FIG.4C may be combined with one another, e.g., such that the first message 232 includes event-related information 400 configured as described in relation to FIG.4A, and / or random information 410 configured as described in relation to FIG.4B, and / or identifier information 420 configured as described in relation to FIG.4C.

[0078] In this regard, FIG.4A shows event-related information 400 in a schematic representation according to various aspects. The event-related information 400 may be an exemplary configuration of the event-related information 234 contained in the message 232 described in relation to FIG.2A, so that aspects described in relation to the event-related information 400 may apply to the event-related information 234, and vice versa.P97341

[0079] In general, the event-related information 400 may represent any suitable property or parameter associated with the user-triggered event 222 that allows the (second) communication device 242 that receives the information to determine whether an action is to be taken, and the type of action to be taken. Illustratively, the event-related information 400 may be representative of information that prompts the (second) communication device 242 to carry out a corresponding action in response to the user-triggered event 222 (see also FIG.5A and FIG.6A).

[0080] For example, the event-related information 400 may be representative of whether the user-triggered event 222 fulfills a predefined criterion, e.g., such that the (second) communication device 242 may carry out a corresponding action if the user-triggered event 222 fulfills the criterion, and may refrain from carrying out the corresponding action if the user-triggered event 222 does not fulfill the criterion. The event-related information 400 may thus include a direct indication of whether the user-triggered event 222 fulfills the predefined criterion (e.g., a flag representing “yes” or “no”), or may include information that allows the (second) communication device 242 to determine whether the user-triggered event 222 fulfills the predefined criterion.

[0081] In a preferred configuration, which has been found to provide a simple, yet-efficient assessment of the user-triggered event 222, the event-related information 400 may be representative of a number of occurrences 402 of the user-triggered event 222, e.g., within a predefined time period. For example, the event-related information 400 may describe how many times the user interacted with the (first) communication device 200 within a certain time period. The predefined time period may be freely selected to ensure that the occurrences 402 of the user-triggered event 222 are related to one another, and do not refer to separate and independent events. For example, the duration of the predefined time period may be in the range from 10 seconds to 2 minutes, for example in the range from 30 seconds to 1 minute.

[0082] As another example, the event-related information 400 may be representative of a number of occurrences 402 of the user-triggered event 222 that are separated in time from one another by a predefined time interval, e.g., by less than 2 seconds, or less than 1 seconds, or less than 250 milliseconds, as a numerical example.

[0083] Considering the preferred configuration in which the user-triggered event 222 includes the switching of a switchable element 260 of the (first) communication device 200 (e.g., the pressing / releasing of a button, e.g., in a portable safety button), the number of occurrences 402 of the user-triggered event 222 may be a number of switching operations of the switchable element 260, as discussed in relation to FIG.2B. For example, the number of occurrences 402P97341 of the user-triggered event 222 may be a number of activations of the button (a number of times the button was pressed, e.g., in a predefined time period, or at predefined time intervals).

[0084] Additionally or alternatively to the number of occurrences 402 of the user-triggered event 222, as a further parameter that has been found to enable a simple, yet efficient assessment, the event-related information 400 may be representative of a duration 404 of the user-triggered event 222. For example, the event-related information 400 may describe the length of the event-related user interaction with the (first) communication device 200.

[0085] Considering the preferred configuration in which the user-triggered event 222 includes the switching of a switchable element 260 of the (first) communication device 200 (e.g., the pressing / releasing of a button, e.g., in a portable safety button), the duration 404 of the user-triggered event 222 may be a duration of the switching operation of the switchable element 260. For example, the duration of the switching operation of the switchable element 260 may represent the total time during which the user activated the switch, e.g., from a start time of an initial switching (an initial change of state) to an end time of a final switching (a final change of state). As another example, the duration of the switching operation of the switchable element 260 may represent the time in which the switchable element 260 is in the switched state (e.g., in the second state). Considering a button, the duration 404 of the user-triggered event 222 may be a time in which the button is in the pressed state.

[0086] FIG.4B shows random information 410 in a schematic representation according to various aspects. The random information 410 may be an exemplary configuration of the random information 238 contained in the message 232 described in relation to FIG.2A, so that aspects described in relation to the random information 410 may apply to the random information 238, and vice versa.

[0087] In general, the random information 410 may be any suitable type of information that varies in a random manner, such that the (first) message 232 is not ignored by the (second) communication device 242. Illustratively, the random information 410 may be any suitable type of randomly generated information that prompts the (second) communication device 242 to process the content of the (first) message 232 (and carry out a corresponding action in response to the user-triggered event 222).

[0088] The random information 410 may thus include random elements 412, which are not predefined and vary among different messages that are generated / transmitted by the (first) communication device 200 at which the user-related event occurs. For example, each message generated / transmitted by the (first) communication device 200 may include respective random information 410 that is different from the random information 410 contained in another messageP97341 generated / transmitted by the (first) communication device 200, e.g., at least one random element 412 may be different.

[0089] The random information 410 may be unique for each message generated / transmitted by the (first) communication device 200. Illustratively, considering a random generation process, the chance of random information 410 repeating itself in different messages may be negligible. In this regard, the (first) communication device 200 may generated the random information 410 according to any suitable process, e.g., based on ambient noise, based on a state of the processor, based on an algorithm with an initial seed key, and the like.

[0090] In a preferred configuration, the random information 410 may include a random number, illustratively a randomly generated number. A random number may be represented in a compact manner for transmission in an iBeacon data packet, as discussed in further detail below. In this scenario, the random elements 412 may be digits assuming a random value. The length of the randomly generated number may be freely adapted to have negligible chances of repetition while maintaining a sustainable computational effort. For example, the randomly generated number may have a length of 1 Byte. In general, the message 232 may include a sequence of bits representing the random information 410, and the use of a random number may facilitate such representation.

[0091] As another example, the random information 410 may include a random string of characters. In this scenario, the random elements 412 may be random characters. As a further example, the random information 410 may include a random alphanumerical code. In this scenario, the random elements 412 may be random characters and random digits, etc.

[0092] FIG.4C shows identifier information 420 in a schematic representation according to various aspects. The identifier information 420 may be an exemplary configuration of the identifier information 236 contained in the message 232 described in relation to FIG.2A, so that aspects described in relation to the identifier information 420 may apply to the identifier information 236, and vice versa.

[0093] In general, the identifier information may be any suitable type of information that allows the (second) communication device 242 that receives the message 232 to identify the (first) communication device 200 from which the message 232 originated. In the iBeacon context, the identifier information 420 may include a Universally Unique Identifier (UUID), a major identifier (major ID) and a minor identifier (minor ID). As generally known, the UUID is a unique identifier, usually 128-bit long, associated with a group of iBeacon devices. The major ID is an identifier, usually 16-bit long, associated with a subset of iBeacon devices in the groupP97341 corresponding to the UUID. The minor ID is a further identifier associated with an individual iBeacon device of the subset, and is usually 16-bit long.

[0094] According to various aspects, the minor ID may be adapted with respect to a conventional “iBeacon configuration”, to contain further information that enables the hybrid communication. Illustratively, the event-related information 234, 400, and the random information 238, 410 may in principle be included in any suitable field of the structure of the first message 232. However, in a preferred configuration the minor ID of the iBeacon message may be adapted to contain event-related information 234, 400, and random information 238, 410, thus providing a resource-efficient implementation of the proposed strategy.

[0095] As shown in FIG.4C, the identifier information 422 may include (among others) a major ID 422 and a minor ID 424. In this regard it is understood that the values and bits shown in FIG.4C are merely exemplary. The major identifier 422 includes identifier information representative of the first communication device 200. The major identifier 422 may be used at the receiving communication device 242 as primary filter to decide whether the request from the first communication device 200 is “interesting” and should be acted upon.

[0096] The minor identifier 424 may include a first portion 426 and a second portion 428. For example, the first portion 426 may be a lower byte and the second portion may be a higher byte, but the length of the portions 426, 428 is not limited to such value. For example, one portion may be made longer than the other portion. In this configuration, one of the portions (e.g., the first portion 426) may include the event-related information 234, 410 representative of the user-triggered event, and the other portion (e.g., the second portion 428) may include the random information 238, 410. In some aspects, the minor identifier 424 may consist of the first portion 426 and second portion 428, each with size of 1 byte.

[0097] Thus, in some aspects the lower byte of the minor ID 424 may be used to communicate the event. As an exemplary configuration, the lower byte of the minor ID 424 may include values lower than 16 for click counts and long press and higher values for generic events. The higher byte of the minor ID 424 may be used to add random noise to “trick” the receiver to not see values as already known (cached) information.

[0098] Turning now to the other participating entity in the communication approach proposed herein, FIG.5A shows a (second) communication device 500 configured to carry out communication according to the hybrid approach proposed herein, in a schematic representation according to various aspects. The communication device 500 may generally be configured for wireless communication, and may include a processor 502 coupled to a memory 504. The memory 504 may be configured to store instructions (e.g., software instructions) executed bythe processor 502. The instructions may cause the processor 502 to perform an adapted method 510 of establishing a communication session with another (first) communication device 532 (illustratively, the first communication device 200). Aspects described with respect to a configuration of the processor 502 may also apply to the method 510 and vice versa.

[0099] The (second) communication device 500 may generally be configured as the (second) communication device 242 described in relation to FIG.2A, so that aspects discussed in relation to the communication device 500 may apply to the communication device 242, and vice versa. In a corresponding manner, the (first) communication device 532 may generally be configured as the (first) communication device 200 described in relation to FIG.2A, so that aspects discussed in relation to the communication device 532 may apply to the communication device 200, and vice versa.

[0100] The wireless communication device 500 may further include communication circuitry 506 configured to enable wireless communication. The communication circuitry 506 may generally be configured as the communication circuitry 100 described in FIG.l, e.g., the communication circuitry 506 may include a communication portion for transmitting / receiving radiofrequency waves, and may include a signal processing portion for processing the signals received / to be transmitted. In this regard, the signal processing portion may be a dedicated circuit, or the processor 502 may be further configured to implement signal processing functionalities for transmission / reception. In particular, the communication circuitry 506 may be configured for transmission and reception of signals according to the BLE communication protocol and iBeacon communication protocol, as discussed in relation to FIG.l. The communication device 500 may thus be understood as a BLE-enabled device and iBeacon-enabled device.

[0101] In general, the processor 502 may be configured to receive an input in relation to a user-triggered event at another communication device 532, and to establish a communication session with the other communication device 532 in response to the input. In this regard, the processor 502 is configured to receive a (first) message 512 according to the iBeacon communication protocol from another (first) communication device 532. The (first) message 512 may be configured as the first message 232 described in relation to FIG.2A, and may include event-related information 514 (configured as the event-related information 234, 400), identifier information 516 (configured as the identifier information 236, 420), and random information 518 (configured as the random information 238, 410).

[0102] The processor 502 may be further configured to issue, in response to the first message 512, a request 534 to the other (first) communication device 532 to establish a communicationP97341 session according to BLE protocol between the first communication device 532 and the (second) communication device 500. Illustratively, the processor 502 may generate the request 534 and cause a transmission of the request 534 to the other communication device 532 for inviting the other communication device 532 to carry out the BLE communication session. The processor 502 may thus respond to the iBeacon message 512 with a BLE request 534, combining the strengths of the two approaches, as discussed above.

[0103] According to various aspects, the processor 502 may be configured to determine whether to react to the user-triggered event at the other communication device 532 represented by the first message 512. Illustratively, the processor 502 may be configured to determine whether to carry out the establishment of the communication session for the user-triggered event reported by the first message 512, or whether to refrain from establishing the communication session for this user-triggered event. Stated differently, the processor 502 may be configured to determine whether to issue the request 534 or to refrain from issuing the request 534 for the user-triggered event at the other communication device 532.

[0104] The assessment may include multiple aspects. For example, the processor 502 may be configured to determine whether the first message 512 is coming from a communication device 532 to which a response should be provided. For example, the processor 502 may be configured to determine whether the (first) communication device 532 is a known device and accordingly whether a communication session with that communication device 532 is appropriate.

[0105] The processor 502 may thus be configured to determine, based on the identifier information 516, whether to issue the request 534. In particular, the processor 502 may issue (e.g., generate and transmit) the request 534 if the identifier information 516 represents a known communication device 532 (e.g., a communication device 532 paired with the communication device 500, e.g., paired with an application 540 of the communication device 500 discussed below). On the other hand, the processor 502 may refrain from issuing the request 534 if the identifier information 516 represents an unknown communication device 532 (e.g., a non-paired device).

[0106] For example, the assessment may be based on a major identifier included in the message 512. Illustratively, the 16-bit major ID may act as primary filter whether request is interesting for the receiving communication device 500 (e.g., the receiving application). In the iBeacon context it may happen that the iBeacon ID is not necessarily unique. Thus, in some aspects, the assessment may be based (additionally or alternatively) on the Bluetooth Device Address of the (first) communication device 532. The Bluetooth Device Address may be part of the identifier information 516 of contained in the first message 512, and may be a uniqueP97341 identifier associated with the (first) communication device 532 (whereas, the UUID and Major ID may be common to a group or a subset of devices). The Bluetooth Device Address may also be referred to as BLE Media Access Control (BLE MAC).

[0107] The processor 502 may thus be configured to issue the request if the BLE MAC contained in the first message 512 represents a known communication device 532 with which a communication session may be carried out. In this context, the initial check of the major ID may be a coarser filtering to exclude categories or groups of devices, and the check of the BLE MAC may be a finer filtering to assess specific individual communication partners.

[0108] In addition or in alternative to the assessment of the identifier information 516, the processor 502 may assess the event-related information 514 to determine whether (and how) to react to the message 512. For example, if the processor 502 performs the assessment of the identifier information 516, the processor 502 may assess the event-related information 514 after having determined that the (first) communication device 532 is a known device for which the request 534 may be issued.

[0109] In this regard, the processor 502 may be configured to determine, based on the event-related information 514, whether the user-triggered event at the other communication device 532 fulfills a predefined criterion. The processor 502 may then issue the request 534 if the user-triggered event fulfills the criterion, or may refrain from issuing the request 534 if the user-triggered event does not fulfill the criterion.

[0110] In this connection, the aspects described in relation to FIG.4A apply to the assessment. For example, the event-related information 514 may include a direct indication of whether the user-triggered event include a direct indication of whether the user-triggered event, and the processor 502 may issue the request 534 if the direct indication is indicative of the criterion being fulfilled. As another example, the event-related information 514 may represent one or more properties or parameters of the user-triggered event and the processor 502 may determine whether the event fulfills the predefined criterion based on the properties / parameters.

[0111] As discussed, for example the processor 502 may determine that the event fulfills the predefined criterion if a number of occurrences of the user-triggered event (e.g., within a predefined time period) is greater than a threshold value (e.g., greater than 1, greater than 2, etc.). In particular, the processor 502 may determine that the event fulfills the predefined criterion if a number of switching operations of a switchable element of the other communication device 532 (e.g., a number of button presses, e.g., of a portable safety button) is greater than a threshold value.P97341

[0112] As another example, the processor 502 may determine that the event fulfills the predefined criterion if a duration of the user-triggered event is greater than a threshold value (e.g., more than 250 milliseconds, more than 2 seconds, more than 10 s, more than 30 s, more than 1 minute, etc.). In particular, the processor 502 may determine that the event fulfills the predefined criterion if a duration of a switching operation of a switchable element of the other communication device 532 is greater than the threshold value. For example, the processor 502 may determine that the event fulfills the predefined criterion if a duration of a time in which the switchable element is in the switched state (e.g., a time in which a button is in the pressed state) is greater than the threshold value.

[0113] Although not shown, the processor 502 may be further configured to carry out the BLE communication session with the other communication device 532 (after the other device 532 accepts the request 534). During the BLE communication session, the communication devices 500, 532 may communicate with one another according to the BLE protocol, as discussed above.

[0114] From the point of view of the method 510, the method 510 may include, in 520, receiving a first message 512 according to the iBeacon communication protocol from a first communication device 532. The method 510 may further include, in 530, issuing, in response to the first message 512, a request 534 to the first communication device 532 to establish a BLE communication session.

[0115] In general, the (second) communication device 500 may be any suitable type of communication device. In a preferred configuration, the communication device 500 may be a portable communication device, e.g., a mobile communication device. In particular, the communication device 500 may be smartphone, e.g., a smartphone paired with a portable safety button (as first communication device). It is however understood that in principle the communication device 500 may be another type of device, such as a tablet, a laptop, a notebook, a netbook, a computer, a Wi-Fi access point, a gateway configured according to Long Term Evolution (LTE) or 5G, a gateway configured according to LoRa or LoRa Wide Area Network (WAN), and the like.

[0116] Furthermore, according to various aspects and as shown in FIG.5B, the (second) communication device 500 may include a software application 540 installed thereon. The software application 540 may be configured to carry out a corresponding action upon receiving information of the occurrence of a user-triggered event (e.g., from a known device and fulfilling a predefined criterion). Illustratively, the software application 540 may be responsible for suitably reacting to the user interaction with the first communication device 532.P97341

[0117] In particular, the software application 540 may be paired with one or more predefined other (first) communication devices (e.g., one or more portable safety buttons), and the initial assessment based on the identifier information of the first message 512 may determine whether the identifier information (e.g., the major ID, the BLE MAC) is representative of a (first) communication device that is paired with the software application 540. The processor 502 may then proceed further with the issuing of the request 534 (and with a corresponding action) if the identifier information indicates that the (first) communication device that is paired with the software application 540.

[0118] In this regard, the term “paired” may indicate a previously performed identification and / or authentication procedure involving the first communication device 532 and the second communication device 500, such that the first communication device 532 may be part of a “list” of known (e.g., paired) devices with which the software application 540 may interact.

[0119] In this scenario, the processor 502 may activate the software application 504 in response to receiving the first message 512 (e.g., based on the identifier information), and deliver the first message 512 to the software application 504 for further processing. The software application 504 may then assess the user-triggered event (e.g., based on the criterion described above) and may be configured to provide a corresponding response. In particular, in this scenario, the BLE communication session may be understood as a communication session between the first communication device 532 and the software application 540.

[0120] The software application 504 may have any suitable configuration depending on the intended use case and, in a corresponding manner the action implemented by the software application 504 for the event may be of any suitable type depending on the desired implementation.

[0121] In a preferred configuration, the user-triggered event at the first communication device 532 may be indicative of a safety -related situation for the user, e.g., an emergency situation for the user. Illustratively, the interaction of the user with the first communication device 532 (e.g., the pushing of the button) may indicate that the user is in need for assistance, i.e., the user-triggered event may be indicative of a request for assistance by the user. In this scenario, the software application 504 may carry out a response to the safety-related situation, e.g., a response to the request for assistance.

[0122] The software application 504 may thus carry out a safety -related response to the safety- related situation for the user. The safety-related response may be of any suitable type, and may include for example transmitting an alert to an emergency service, initiating a call to the police,P97341 initiating a call to the hospital, notifying one or more predefined emergency contacts for the user, emitting a visible signal or a sound signal to attract attention, and the like.

[0123] As mentioned, the proposed approach is not limited to the context of portable safety buttons. In another exemplary scenario, the first communication device 532 may also have the software application 540 installed therein, and the communication session may be between a first instance of the software application 540 in the first communication device 532 and a second instance of the software application 540 in the second communication device 500. Illustratively, in some aspects a “mesh mode” may be provided, in which the software applications installed in different communication devices 500, 532 interact with one another according to the proposed hybrid approach, without the need for a connection to the internet.

[0124] FIG.6A shows a schematic communication flow 600 between a first communication device 604 and a second communication device 606. The first communication device 604 may generally be configured as the (first) communication device 200, 532 described in relation to FIG.2A and FIG.5 A, so that aspects discussed in relation to the first communication device 604 may apply to the communication device 200, 532 and vice versa. The second communication device 606 may generally be configured as the (second) communication device 242, 500 described in relation to FIG.2A and FIG.5A, so that aspects discussed in relation to the second communication device 606 may apply to the communication device 242, 500 and vice versa. The aspects discussed for the communication flow 600 may apply to the methods 210, 510 and vice versa.

[0125] As shown, the communication flow 600 may start with the user 602 triggering the event 610 at the first communication device 604. In response to the user-triggered event 610, the first communication device 604 may generate and transmit the iBeacon message 612 representing the event 610 (together with identifier information of the device 604 and random information) to the second communication device 606. The second communication device 606 may then issue the request 614 for establishing a BLE communication session 620, in response to the first message 612 (e.g., based on the fulfillment of certain criteria, as discussed above). Illustratively, the second communication device 606 (e.g., the application installed thereon) may connect via BLE with the first communication device 604 in response to the message 612.

[0126] During the BLE communication session 620 the communication devices 604, 606 communicate according to the BLE protocol. This enables a feedback mechanism, as mentioned above. Thus, according to various aspects, the second communication device 606 (e.g., its processor, e.g., the application installed therein) may transmit, during the BLE communication session 620, feedback information 622 to the first communication device 604. The secondP97341 communication device 606 may generate a BLE message that contains feedback information 622 (illustratively, a data packet according to the BLE structure) and may transmit the BLE message to the first communication device 604. The BLE session thus enables a bidirectional exchange of information between the devices 604, 606.

[0127] The feedback information 622 may in general be representative of the action carried out by the second communication device 606 in response to the first message 612 (e.g., in response to the user-triggered event 610). Considering the preferred configuration discussed above, the feedback information may be representative of the safety-related response implemented by the second communication device 606 in response to the request of assistance by the user 602. For example, the feedback information may include a chat message addressed to the user 602. Only as further examples relevant in the “safety context”, the feedback information may be representative of “alarm successfully delivered”, “emergency service accepted to help with the incident”, “emergency service (e.g., guard) nearby”, “no help nearby found, escalate to 112 (or 911)”, etc.

[0128] In some aspects, the feedback information 622 may cause a user-perceptible event at the first communication device 604. Illustratively, the first communication device 604 may generate a user-perceptible signal in response to the received feedback information 622. The user-perceptible signal may inform the user 602 of the occurred response by the second communication device 606. In this regard, the user-perceptible signal may be any suitable type of signal, e.g., depending on the configuration of the first communication device 604.

[0129] As an example, the user-perceptible signal may include a visual signal (e.g., light emitted by a light-emitting element of the first communication device 604, e.g., by a LED ring of a physical safety button). As another example, the user-perceptible signal may include an audible signal or a haptic signal (e.g., a vibration of the first communication device 604). As a further example, if the first communication device 604 includes a display (e.g., in case of a smartphone), the user-perceptible signal may include a notification shown on the display to inform the user 602.

[0130] Communication according to the BLE protocol may be carried out also by the first communication device 604 during the BLE communication session 620. For example, the first communication device 604 may detect a second user-triggered event 624 during the established BLE communication session 620, and may generate a corresponding second message 626 according to the BLE protocol in response to detecting the second user-triggered event 624. Illustratively, the first communication device 604 may prepare a BLE message 626 containing event-related information representative of the second user-triggered event 624 (e.g., a numberof occurrences, a duration, etc.), and may transmit the BLE message 626 to the second communication device 626 according to the BLE protocol. It is understood that in addition to the event-related information the BLE message 626 may include any further information provided in the BLE-context.

[0131] Although a single instance of feedback mechanism and a single instance of further events are shown in FIG.6A, it is understood that the second communication device 606 may provide more than one BLE message containing feedback information to the first communication device 604, and that the first communication device 604 may report more than one user-triggered event during the BLE communication session. For example, the further user- triggered events may prompt further actions by the second communication device 606, e.g., further safety-related responses.

[0132] Regarding the termination of the BLE communication session 620, it may be based on any desired criterion. For example, a user-triggered event at the first communication device 604 may cause the termination of the BLE communication session 620. As another example, the second communication device 606 (e.g., the installed application), may cause the termination of the BLE communication session 620 after having carried out the action related to the event 610 (e.g., the safety-related response).

[0133] In a preferred configuration, the BLE communication session 620 may have a predefined duration 630, and the communication flow 600 (e.g., the method 210, 510) may include terminating the BLE communication session 620 after a predefined time has elapsed (since the establishment of the BLE communication session 620). The setting of a predefined duration may provide saving resources in the context of energy-constrained devices, by avoiding excessively long interactions. In this regard, the predefined duration 630 may be freely selected to ensure that the exchange of information may be carried out in a manner that ensures an appropriate response, while avoiding excessive consumption of resources at the communication devices 604, 606. Only as a numerical example, the predefined duration 630 may be in the range from 1 minute to 10 minutes, e.g., in the range from 2 minutes to 5 minutes.

[0134] According to various aspects, the first communication device 604 may be configured to enter a low-power state after termination of the BLE communication session 620. The first communication device 604 may thus go into a low energy-consumption state, waiting for the next user-triggered event. Entering the low-power state may preserve the resources (e.g., the battery) of the first communication device 604. A “low-power state” may illustratively describe an operation state in which the first communication device 604 consumes less power with respect to the operation of the first communication device 604 in an active state (e.g., withP97341 respect to the operation during the communication session 620). For example, in the low-power state the first communication device 604 may communicate according to the iBeacon protocol and not according to the BLE protocol.

[0135] FIG.6B shows a schematic communication flow 650 between a physical safety button 654 and a software application 656 (e.g., installed in a smartphone). The communication flow 650 may be an exemplary scenario of the communication flow 600, with an exemplary realization of the first communication device 604 and second communication device 606.

[0136] Initially, the action button device 654 may be in a low-power state. Upon pressing the button by a user 652 (e.g., three times), the device 654 activates the iBeacon protocol with a specific major ID as the identifier. The minor ID may consist of two bytes. The two bytes include an upper byte set to a random number to introduce variability, ensuring the operating system at the application side does not ignore the beacon due to familiarity. The two bytes further include a lower byte, and the lower byte may include a lower nibble (e.g., 4 bits) representing the click count (e.g., 0x03 for three clicks, with a maximum of 0x07 clicks expressible). The top bit of the lower nibble may be set if the last press was a long press (e.g., 0x05 for five clicks plus 0x08 for long press = OxOD). The remaining bits may be reserved for future use.

[0137] The iBeacon signal triggers the OS to wake up the paired application 656 even if it is not running. The application 656 reads the iBeacon information (major ID, minor ID) to check if it wants to react on the event and to determine the number of clicks as well as the presence of a long press. The application 656 processes the initial event and then establishes a BLE connection with the button device 654.

[0138] Once connected via BLE, the button device 654 may provide feedback through visual, haptic, or audible signals as supported. The BLE connection is maintained for a configurable duration (e.g., several minutes) for ongoing interaction and feedback. While the BLE communication session is active, click events are communicated directly via BLE instead of iBeacon. The button device 654 may revert to iBeacon mode after the BLE connection times out to conserve battery.

[0139] In particular, the button device 654 may be function as a physical alarm button, which, when pressed, may be detected by a smartphone, computer, or other devices like WiFi access points with loT capabilities. The system may be applied to any scenario where a device or application needs to signal an event. The lower byte of the minor ID allows for up to OxFF possible events to be communicated without the need for a constant BLE connection or other communication means.

[0140] The term “processor” as used herein may be understood as any kind of technological entity that allows handling of data. The data may be handled according to one or more specific functions that the “processing circuit” may execute. Further, a “processing circuit” as used herein may be understood as any kind of circuit, e.g., any kind of analog or digital circuit. A “processing circuit” may thus be or include an analog circuit, digital circuit, mixed-signal circuit, logic circuit (e.g., a hard-wired logic circuit or a programmable logic circuit), microprocessor, Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), integrated circuit, Application Specific Integrated Circuit (ASIC), etc., or any combination thereof. In some aspects, a “processing circuit” may be understood as a software-based implementation of the functionalities carried out by the processing circuit.

[0141] The term “memory” as used herein may be understood as a computer-readable medium (e.g., a non-transitory computer readable medium) in which data or information can be stored for retrieval. References to “memory” included herein may thus refer to volatile or non-volatile memory, including random access memory (RAM), read only memory (ROM), flash memory, solid state storage, magnetic tape, hard disk drive, optical drive, among others, or any combination thereof. Registers, shift registers, processor registers, data buffers, among others, are also embraced herein by the term memory.

[0142] The term “application” may describe a computer program designed to carry out a specific task other than one relating to the operation of the computer itself. For example, an “application” may be a complete and deployable package to achieve a certain function in an operational environment.

[0143] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration”. Any aspect or configuration described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or configurations.

[0144] The phrase “at least one” and “one or more” may be understood to include a numerical quantity greater than or equal to one (e.g., one, two, three, four, [...], etc.). The phrase “at least one of’ with regard to a group of elements may be used herein to mean at least one element from the group consisting of the elements. Unless specified otherwise, the term “subset” in relation to a group of elements may be understood to include a numerical quantity equal to or greater than one and less than a total number of the implied elements. Considering for example a group of ten elements, a “subset” of the group may include one, two, three, four, five, six, seven, eight, or nine elements. The term “subset” in relation to a group may thus describe a“proper subset” of the group, so that all the elements of the subset belong to the group, but at least one element of the group does not belong to the subset.

[0145] The term “transmit” as used herein may include both direct (point-to-point) and indirect transmission (via one or more intermediary points). Similarly, the term “receive” may include both direct and indirect reception. Furthermore, the terms “transmit,” “receive,” “communicate,” and other similar terms may include both physical transmission (e.g., the transmission of radio signals) and logical transmission (e.g., the transmission of digital data over a logical software-level connection). In general, the term “communicate” may include the exchange of data, e.g., unidirectional or bidirectional exchange of data.

[0146] Implementations of methods described herein may be demonstrative in nature and may be implemented in a corresponding device. In a corresponding manner, implementations of devices or circuits described herein may be implemented with a corresponding method. It is thus understood that a device or circuit corresponding to a method may include one or more components configured to perform each aspect of the related method.

[0147] All acronyms defined in the above description additionally hold in all claims included herein.

[0148] While the invention has been particularly shown and described with reference to specific aspects, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention as defined by the appended claims.

Claims

P97341Claims1. A method (210) of establishing a communication session, the method (210) comprising: detecting a user-triggered event (222) at a first communication device (200); generating, by the first communication device (200) and in response to the detection of the user-triggered event (222), a first message (232) according to the iBeacon communication protocol, wherein the first message (232) comprises: identifier information (236) representative of the first communication device (200), random information (238), and event-related information (234) representative of the user-triggered event (222); transmitting, by the first communication device (200) and according to the iBeacon communication protocol, the first message (232) to a second communication device (242); and receiving, at the first communication device (200), a request to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device (200) and the second communication device (242). A method (510) of establishing a communication session, the method (510) comprising: receiving, at a second communication device (500), a first message (512) according to the iBeacon communication protocol from a first communication device (532), wherein the first message (512) comprises: identifier information (516) representative of the first communication device (532), random information (518), and event-related information (514) representative of a user-triggered event at the first communication device (532); and issuing, by the second communication device (500) and in response to the first message (512), a request to the first communication device (532) to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device (532) and the second communication device (500).P973413. The method (210, 510) according to claim 1 or 2, further comprising: wherein the event-related information (234, 514) is representative of a number of occurrences of the user-triggered event (222), and / or wherein the event-related information (234, 514) is representative of a duration of the user-triggered event (222).

4. The method (210, 510) according to any one of claims 1 to 3, wherein the first communication device (200) comprises a switchable element (260) switchable between at least a first state and a second state, and wherein the user-triggered event (222) comprises a switching of the switchable element (260) from the first state into the second state.

5. The method (210, 510) according to claim 4, wherein the user-triggered event (222) comprises a predefined number of switching operations of the switchable element (206) by a user of the first communication device (200).

6. The method (210, 510) according to claim 4 or 5, wherein the switchable element (260) is a physical button switchable between a released state and a pressed state, and wherein the user-triggered event (222) comprises a pressing and / or a releasing of the physical button.

7. The method (210, 510) according to any one of claims 1 to 6, further comprising: establishing the communication session between the first communication device (200, 532) and the second communication device (242, 500),37P97341 wherein, during the communication session, the first communication device (200, 532) and the second communication device (242, 500) communicate with one another according to the BLE protocol.

8. The method (210, 510) according to any one of claims 1 to 7, further comprising: detecting a second user-triggered event (624) at the first communication device (200, 532, 604) during the established communication session (620); generating, by the first communication device (200, 532, 604) and in response to the detection of the second user-triggered event (624), a second message (626) according to the BLE communication protocol, wherein the second message (626) comprises event-related information representative of the second user-triggered event (624); and transmitting, by the first communication device (200, 532, 604) and according to the BLE communication protocol, the second message (626) to the second communication device (242, 500, 606). The method (210, 510) according to any one of claims 1 to 8, wherein the second communication device (242, 500) comprises a software application (540) paired with the first communication device (200, 532), and wherein the method (210, 510) further comprises: activating the software application (540) in response to receiving the first message (232, 512) at the second communication device (242, 500), and / or delivering the first message (232, 512) to the software application (540).10 The method (210, 510) according to any one of claims 1 to 9, wherein issuing the request (252, 534) to the first communication device (200, 532) to establish the communication session comprises:P97341 determining, at the second communication device (242, 500) and based on the event-related information (234, 514), whether the user-triggered event (222) fulfills a predefined criterion, and issuing the request (252, 534) to the first communication device (200, 532) to establish the communication session in the case that the user-triggered event (222) fulfills the predefined criterion.

11. The method (210, 510) according to any one of claims 1 to 10, wherein the first message (232, 512) comprises: a major identifier (422) containing the identifier information (236, 516) representative of the first communication device (200, 532); and a minor identifier (424) comprising a first portion (426) containing the random information (238, 518), and a second portion (428) containing the event-related information (234, 514) representative of the user-triggered event (222).

12. The method (210, 510) according to any one of claims 1 to 11, further comprising: during the established communication session (620), transmitting, by the second communication device (242, 500, 606) and according to the BLE communication protocol, feedback information (622) to the first communication device (200, 532, 604).

13. A communication device (200) comprising a processor (202) configured to: detect a user-triggered event (222) at the communication device (200); generate, in response to the detection of the user-triggered event (222), a first message (232) according to the iBeacon communication protocol, wherein the first message (232) comprises identifier information (236) representative of the communication device (200), random information (238), and event-related information (234) representative of the user-triggered event (222); cause a transmission, according to the iBeacon communication protocol, of the first message (212) to a second communication device (242); andP97341 receive a request (252) to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the communication device (200) and the second communication device (242).

14. The communication device (200) according to claim 13, configured as a portable safety button.

15. A communication device (500) comprising a processor (502) configured to: receive a first message (512) according to the iBeacon communication protocol from a first communication device (532), wherein the first message (512) comprises identifier information (516) representative of the first communication device (532), random information (518), and event-related information (514) representative of a user-triggered event at the first communication device (532); and issue, in response to the first message (512), a request (534) to the first communication device (532) to establish a communication session according to the Bluetooth Low-Energy, BLE, protocol between the first communication device (532) and the communication device (500).

Images