System and method for customizing beacon packets

Abstract

An example device includes a communication interface including a beacon; and a controller interconnected with the communication interface, the controller configured to: receive, via the communication interface, an initialization request including a beacon type; in response to the initialization request: obtain configuration data for the beacon type; and construct a format of a beacon packet according to the configuration data for the beacon type; and control the beacon to broadcast the beacon packet.

Description

Background Technology

[0001] Beacons can be used to broadcast beacon packets for nearby devices to receive. Different beacon communication protocols define different standards, according to which beacon packets are formatted. Therefore, a beacon that broadcasts beacon packets using one standard is incompatible with receiving devices configured to parse packets using a different standard. Attached Figure Description

[0002] The accompanying drawings (in which the same reference numerals in the individual views refer to the same or functionally similar elements) are incorporated in and form part of the specification together with the following detailed description and are used to further illustrate embodiments of the schemes including the claimed invention and to explain the various principles and advantages of these embodiments.

[0003] Figure 1 This is a schematic diagram of a system used for customizing beacon packets.

[0004] Figure 2 yes Figure 1 A block diagram of some of the internal hardware components of a computing device.

[0005] Figure 3 This is a flowchart of the method for customizing beacon packets.

[0006] Figure 4 yes Figure 3 An exemplary execution diagram of block 310 of the method.

[0007] Those skilled in the art will understand that the elements in the accompanying drawings are shown for simplicity and clarity and are not necessarily drawn to scale. For example, the dimensions of some elements in the drawings may be exaggerated relative to other elements in order to help improve the understanding of embodiments of this disclosure.

[0008] In the accompanying drawings, device and method components have been indicated by conventional symbols where appropriate, and only those specific details relevant to understanding embodiments of this disclosure are shown so as not to obscure this disclosure by means of details that would be obvious to those of ordinary skill in the art who would benefit from the description herein. Detailed Implementation

[0009] The examples disclosed herein relate to a device including: a communication interface including a beacon; and a controller interconnected with the communication interface, the controller being configured to: receive an initialization request including a beacon type via the communication interface; in response to the initialization request: acquire configuration data for the beacon type; construct a format for a beacon packet based on the configuration data for the beacon type; and control the beacon to broadcast the beacon packet.

[0010] Other examples disclosed herein relate to a method including: receiving an initialization request including a beacon type; in response to the initialization request: obtaining configuration data for the beacon type; constructing a format for a beacon packet based on the configuration data for the beacon type; and controlling a beacon to broadcast the beacon packet.

[0011] Figure 1 A system 100 for customizing beacon packets according to the teachings of this disclosure is depicted. System 100 includes a computing device 104 (also referred to herein as device 104) interconnected with a configuration device 108.

[0012] In this example, computing device 104 is shown as a printer, but in other examples it could be other mobile devices, such as barcode scanners, sensors, wearable devices, etc., equipped with beacons to broadcast beacon packets 110, which will be described further herein. Configuration device 108 is a computing device, such as a mobile computing device including a telephone, tablet, etc., or a fixed computing device, such as a server, desktop computer, etc.

[0013] Device 104 and configuration device 108 can communicate with each other via communication link 112, which is shown in this example as including a wireless link. For example, link 112 may be provided by a wireless local area network (WLAN) deployed by one or more access points (not shown). In other examples, link 112 may be a short-range wireless communication link, such as a Bluetooth connection, a wired connection (e.g., via a Universal Serial Bus or USB connection, etc.), a combination of the above, etc.

[0014] In operation, system 100 allows beacon packets 110 transmitted by device 104 to be customized according to the environment in which device 104 operates. For example, system 100 may also include one or more receiving devices 116, which may be, for example, beacon receivers / locators (which may be distributed throughout the facility, such as mounted on a ceiling or other structure) and / or other mobile computing devices, including smartphones, tablets, mobile computers, etc., for the purpose of operating in the facility or environment in which system 100 is deployed. Therefore, device 104 can be customized according to the operating system used by the receiving devices 116 within the facility.

[0015] For example, if receiving device 116 operates in a facility primarily using Apple devices, beacon packets 110 transmitted by device 104 can be formatted with fields according to the iBeacon standard to allow receiving device 116 to receive and process beacon packets 110 transmitted by device 104. Similarly, beacon packets 110 can be formatted with fields according to Eddystone, AltBeacon, or other proprietary standards used by receiving device 116. Therefore, when device 104 is deployed in system 100, configuration device 108 can configure device 104 according to the operating system of receiving device 116 and allow reconfiguration of device 104 if the system's beacon protocol changes.

[0016] Specifically, device 104 can customize the broadcast beacon packet 110 based on an initialization request received from configuration device 108. For example, the initialization request can specify a beacon type and may additionally include configuration data for that beacon type. Device 104 can then apply the configuration data to the beacon packet 110, thereby allowing device 104 to construct the format of the beacon packet 110 according to the criteria specified for that beacon type.

[0017] Now go to Figure 2 The diagram illustrates some internal components of device 104. Device 104 includes a processor 200 interconnected with a non-transitory computer-readable storage medium, such as memory 204. Memory 204 includes a combination of volatile memory (e.g., random access memory or RAM) and non-volatile memory (e.g., read-only memory or ROM, electrically erasable programmable read-only memory or EEPROM, flash memory). Processor 200 and memory 204 may each include one or more integrated circuits. Memory 204 stores computer-readable instructions for execution by processor 200, including one or more applications that, when executed, configure processor 200 to perform various functions of device 104.

[0018] Device 104 also includes a communication interface 208 that enables device 104 to exchange data with other computing devices, such as configuring device 108 or receiving device 116. Communication interface 208 is interconnected with processor 200. Communication interface 208 includes controller 212, and one or more antennas, transmitters, receivers, etc., to allow device 104 to communicate with other computing devices such as devices 108 and 116.

[0019] Specifically, communication interface 208 includes beacon 216 configured to broadcast beacon packets 110 for reception by nearby devices, such as receiving device 116. Beacon 216 may operate, for example, according to Bluetooth Low Energy protocol or other suitable wireless transmission protocols. Beacon 216 may utilize some or all of the same components as communication interface 208, or beacon 216 may include dedicated hardware (e.g., including a dedicated radio and / or antenna, controller, etc.) for its broadcasting function.

[0020] Controller 212 may be a microcontroller, microprocessor, or other suitable device or logic circuit capable of executing computer-readable instructions to control components of communication interface 208 (e.g., antenna, transmitter, receiver, etc.) to perform the functions described herein. Controller 212 may include one or more integrated circuits and may include and / or be interconnected with a non-transitory computer-readable storage medium storing computer-readable instructions that, when executed, configure controller 212 and / or communication interface 208 to perform the functions described herein. In particular, controller 212 may control the configuration of beacon packet 110 and subsequent broadcast operations of beacon 216.

[0021] In some examples, some or all of the configuration and / or broadcasting functions of device 104 can be performed by processor 200. For example, configuration initialization, configuration parameters, broadcast parameters, etc., can be received at communication interface 208 and processed by processor 200 through a predefined device configuration interface. When parsing the received request through the predefined device configuration interface, processor 200 can send the request to controller 212 for appropriate configuration of beacon 216. For example, device 104 may be equipped with Set-Get-Do (SGD) firmware and / or Zebra Programming Language (ZPL) firmware configured to receive SGD and / or ZPL configuration commands for overall configuration of device 104 for use. In other examples, memory 204 may store applications executable by processor 200 to process SGD and / or ZPL commands, JavaScript Object Notation (JSON) commands, etc., for overall configuration of device 104 for use.

[0022] Device 104 may also include one or more input and / or output devices (not shown) adapted to allow an operator to interact with device 104. Input devices may include one or more buttons, keyboards, touch-sensitive displays, etc., for receiving input from the operator. Output devices may also include one or more displays, sound generators, vibrators, etc., for providing output or feedback to the operator.

[0023] Now go to Figure 3 The functions implemented by device 104 will be discussed in more detail. Figure 3 A method 300 for customizing beacon packets is illustrated. Method 300 will be described in conjunction with its performance within system 100, particularly by device 104. Specifically, method 300 will refer to... Figure 1 and Figure 2 The components are described. In other examples, method 300 may be performed by other suitable devices or systems.

[0024] Method 300 begins at block 305, where device 104 receives an initialization request, for example, from configuration device 108. Specifically, the initialization request can be received via communication interface 208. For example, configuration device 108 can communicate with device 104 via Bluetooth, so the initialization request can be received via Bluetooth. In some examples, the initialization request can be received as a general configuration request for device 104 (e.g., via SGD commands, ZPL commands, etc., for configuring, for example, a Zebra printer). Therefore, processor 200 can process this configuration request and can pass the initialization request to controller 212.

[0025] The initialization request can also specify a beacon type, based on which the format of beacon packet 110 is constructed. For example, the initialization request can specify a particular beacon type (e.g., Eddystone, iBeacon, proprietary custom beacon format, etc.), or the initialization request can indicate that the default beacon type will be used.

[0026] At block 310, device 104 obtains configuration data for the beacon type specified in the initialization request. For example, when the beacon type specified in the initialization request is the default beacon type, device 104 can retrieve configuration data for that default beacon type from the device 104's memory (e.g., memory 204 or memory associated with and / or integrated with controller 212).

[0027] In other examples, device 104 may receive configuration data from configuration device 108 or other suitable device. For example, the configuration data may be included in an initialization request or in other subsequent configuration requests or messages received from configuration device 108. Specifically, the configuration data may correspond to a format adopted by receiving device 116 to allow receiving device 116 to receive and interpret subsequently broadcast beacon packets 110.

[0028] refer to Figure 4 Example method 400 for retrieving configuration data at box 310 is described.

[0029] At box 405, device 104 may receive a configuration request containing configuration data from configuration device 108, for example, via communication interface 208. For example, the configuration request may be received as an SGD or ZPL command or a similar command for overall configuration of device 104. The configuration request may be received in the form of length-type-value (LTV) format elements, where the request is divided into LTV elements, each having a length portion, a type portion, and a value portion. In an LTV element, the length portion specifies the length of the combination of the type and value portions, the type portion specifies the type of data represented in the value field according to a predefined type code (e.g., specified in the Bluetooth core specification for Bluetooth messages), and the value indicates the configuration data that allows device 104 to configure beacon packet 110 according to the beacon type. In some examples, the configuration request may include multiple LTV elements, for example, specifying different types from the Bluetooth specification (or other suitable communication protocols used for broadcasting beacon packet 110), and corresponding configuration data in the format that constructs beacon packet 110.

[0030] In some examples, configuration device 108 can instruct the use of a default beacon type and / or retrieve default configuration data from memory by including blank configuration data in the configuration request. Therefore, at block 410, device 104 can determine whether the configuration request includes configuration data. For example, device 104 can check whether the value portion containing the configuration data is blank or empty, or whether the configuration request actually contains an LTV element.

[0031] If at block 410, device 104 determines that the configuration request does not include configuration data, then device 104 proceeds to block 415. At block 415, device 104 retrieves default configuration data from memory.

[0032] If at box 410, device 104 determines that the configuration request includes configuration data, then device 104 proceeds to box 420. At box 420, device 104 may extract the configuration data from the value portion of the LTV element of the configuration request.

[0033] At box 425, device 104 may verify configuration data. For example, device 104 may verify that the configuration data has an acceptable format (e.g., hexadecimal value), has an appropriate range and / or size (e.g., between 2 bytes and 28 bytes), that the configuration data type specified in the type section is a permitted type (i.e., the type in the communication protocol standard is allowed to be changed or configured), or perform other appropriate verification.

[0034] If at box 425, device 104 determines that the configuration data has been verified, then device 104 may return to method 300, and more specifically, to box 315.

[0035] If at box 425, device 104 determines that the configuration data has not been validated, i.e., the configuration data contains some errors or invalid parameters, then device 104 proceeds to box 430. At box 430, device 104 rejects the configuration request. In response to rejecting the configuration request, device 104 may return an error message or similar information to configuration device 108, indicating the rejection and / or providing an indication of the error condition.

[0036] Return now Figure 3 In box 315, device 104 is configured to construct the format of beacon packet 110 based on configuration data obtained in box 310. Device 104 can be configured according to a specified beacon protocol and can use... Figure 3 and Figure 4 The method described herein allows for reconfiguration to change the beacon protocol to another beacon protocol as needed, thereby allowing the beacon of device 104 to be customized both during device 104 deployment and at any time after device 104 deployment.

[0037] In some examples, the configuration data obtained at box 310 can be formatted according to a specified beacon type standard. For example, the value portion of a single received LTV element may correspond to the payload of beacon packet 110. Therefore, it may not be necessary to apply additional changes to the value portion to construct the format of beacon packet 110.

[0038] For example, when the beacon type is iBeacon, beacon 216 is configured as a broadcast advertising packet (i.e., a Bluetooth specification type with "FF"). Therefore, the LTV element can specify the length of 1A, the type of FF, and include a hexadecimal string value that defines the predefined iBeacon prefix (e.g., fixed according to the iBeacon standard), as well as a unique identifier for device 104. Similarly, the value portion for other beacon types can specify different prefixes, other header types, codes, and other identifiers according to the standard format for that beacon type.

[0039] In some examples, the prefix, header and other formatted data, as well as the unique identifier of device 104, can be specified by configuration device 108 and inserted as part of the configuration request into the value part of the LTV element, thereby allowing the configuration data to be used directly for beacon packet 110 for broadcast by beacon 216.

[0040] In other examples, device 104 may prepend or postpend prefixes, headers, and other formatted data, and may insert unique identifiers. For example, device 104 may combine more than one value portion of multiple received LTV elements to construct the format of beacon packet 110 according to predefined rules stored at device 104. The value portion of the LTV element may include placeholders for a unique identifier for device 104 to replace.

[0041] Device 104 can also be configured to generate a unique identifier for itself based on the beacon type standard of the selected beacon type. For example, AltBeacon uses a 20-byte unique identifier. The first 16 bytes are the unique identifier, which device 104 can generate, for example, based on the product name and serial number of device 104. The next 4 bytes can be subdivided into two 2-byte identifiers, which can have default values ​​but can also be configured based on the specific context of device 104 (e.g., based on configuration data received from configuration device 108). Device 104 can then apply this unique identifier to the configuration data. In other examples, the generation of the unique identifier and its application to the configuration data can occur at configuration device 108.

[0042] Therefore, some or all of the parameters defined in the configuration data can be defined by configuration device 108 and provided to device 104. For example, configuration device 108 may be specifically configured to provide context configuration parameters. In addition, some parameters used to ultimately determine the format of beacon packet 110 can be inserted or updated by device 104, such as device-specific parameters that are recognizable by device 104.

[0043] At frame 320, device 104 can acquire broadcast parameters for broadcasting beacon packets 110. Broadcast parameters may include start conditions, stop conditions, beacon frequency, etc.

[0044] For example, a startup condition may specify a device condition detected by device 104, in which beacon 216 is configured to begin broadcasting beacon packets. For example, a device condition may be that device 104's battery is depleted to a threshold level, device 104's WLAN or other connection is lost, or other similar conditions. In other examples, a startup condition may be to start broadcasting immediately, or to start broadcasting upon receiving an enable request as described below. A stop condition may specify a condition detected by device 104, in which beacon 216 is configured to stop broadcasting beacon packets. For example, a stop condition may be a timeout condition, device 104's WLAN or other connection being reconnected, receiving an explicit command at or from device 104, or other similar conditions. Other broadcast parameters may include a beacon frequency defining the transmission interval to balance the power consumption and transmission frequency of beacon 216, a transmission power level for beacon transmission power, and other similar parameters.

[0045] In some examples, beacon 216 and / or communication interface 208 can be configured for another broadcast or advertising function, such as in association with normal operation of device 104. In such examples, broadcast parameters may include scheduling rules or similar rules to coordinate the broadcast of beacon packet 110 with device advertising functions.

[0046] In some examples, device 104 may obtain default broadcast parameters from its own memory (e.g., memory 204 or memory associated with and / or integrated with controller 212). In other examples, broadcast parameters may be received via communication interface 208, for example as SGD or ZPL commands for overall configuration of device 104.

[0047] At box 325, device 104 receives an enable request for enable beacon 216. In some examples, the fact that an initialization request is received at box 305 and subsequently configuration data is obtained at box 310 and / or broadcast parameters are obtained at box 320 can serve as the enable request at box 325. In other examples, the enable request may be a standalone request received via communication interface 208. This enable request may also be received as an SGD or ZPL command for configuring device 104 in general and passed to controller 212 for configuring beacon 216.

[0048] At box 330, in response to receiving an enable request, device 104 is configured to broadcast beacon packet 110 according to the broadcast parameters obtained at box 320.

[0049] For example, device 104 can periodically check whether the startup conditions have been met by monitoring device 104's battery level, WLAN or other connections. When the startup conditions are met, controller 212 can control beacon 216 to broadcast beacon packets 110. In addition, controller 212 can control beacon 216 to transmit beacon packets 110 at the transmission interval (i.e., beacon frequency) defined in the broadcast parameters.

[0050] Beacon packet 110 can be received by receiving device 116. Furthermore, receiving device 116 can be configured to interpret beacon packet 110 because it is formatted to be recognizable by receiving device 116. Therefore, receiving device 116 can identify the unique identifier of device 104 and determine data such as the signal strength of signals received from device 104. Thus, for example, if the activation condition is that the battery power of device 104 drops below a threshold level, receiving device 116 can be configured to guide the user of receiving device 116 to locate device 104 to replace or recharge the battery. For example, receiving device 116 can use the signal strength of beacon packet 110, combined with the signal strength of beacon packets 110 received by other nearby receiving devices 116, to triangulate the location of device 104.

[0051] The controller 212 can also be configured to control the beacon 216 to stop transmitting beacon packets 110 in response to the detection of a stop condition. For example, after locating device 104, a user can provide input to device 104 to stop broadcasting. Alternatively, a user can trigger the stop condition by replacing the battery or inserting device 104 for recharging.

[0052] Therefore, as described above, device 104, and more specifically, beacon 216, is configured to transmit custom beacon packets. This allows device 104 and beacon 216 to be compatible and adaptable to various different contexts, and allows beacon packets to be successfully received and interpreted on receiving device 116 with minimal hardware modifications.

[0053] In this example, the customizable beacon 216 is integrated into device 104, so the customization or configuration of beacon 216 can be performed via the configuration interface of device 104. In other examples, the customization or configuration of beacon 216 can be performed via direct communication with beacon 216. Furthermore, in some examples, beacon 216 may be a standalone device, not integrated with other types of computing devices.

[0054] Specific embodiments have been described in the foregoing specification. However, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of the invention as set forth in the following claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the invention.

[0055] Benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become more significant should not be construed as key, essential, or fundamental features or elements of any or all claims. The invention is defined solely by the appended claims, which include any modifications made during the pending period of this application and all equivalents of those claims.

[0056] Furthermore, in this document, relational terms such as first and second, top and bottom, etc., may be used only to distinguish one entity or action from another entity or action, without necessarily requiring or implying any actual such relationship or order between these entities or actions. The terms “comprising,” “including,” “having,” “having,” “containing,” “comprising,” “including,” “containing,” “also,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, or contains a list of elements includes not only those elements but may also include other elements not expressly listed or inherent to such a process, method, article, or apparatus. Without further limitation, an element beginning with “comprising…,” “having…,” “including…,” or “containing…” does not exclude the presence of additional identical elements in a process, method, article, or apparatus that comprises, has, includes, or contains that element. The terms “a” and “an” are defined as one or more unless expressly stated otherwise herein. The terms “substantially,” “substantially,” “about,” “approximately,” or any other form thereof are defined as close to what a person skilled in the art would understand, and in one non-limiting embodiment, the term is defined as within 10%, in another within 5%, in yet another within 1%, and in yet another within 0.5%. The term “connection” as used herein is defined as a link, although not necessarily a direct link or a mechanical link. A device or structure “constructed” in a certain way is constructed at least in the manner described, but may also be constructed in ways not listed.

[0057] It should be understood that some embodiments may consist of one or more dedicated processors (or "processing devices") and unique stored-program instructions (including software and firmware), such as microprocessors, digital signal processors, custom processors, and field-programmable gate arrays (FPGAs), which control the one or more processors to implement some, most, or all of the functions of the methods and / or devices described herein, together with some non-processor circuitry. Optionally, some or all of the functions may be implemented by a state machine without stored-program instructions, or in one or more application-specific integrated circuits (ASICs), wherein each function or some combination of functions is implemented as custom logic. Of course, a combination of these two approaches may also be used.

[0058] Furthermore, one embodiment can be implemented as a computer-readable storage medium on which computer-readable code is stored for programming a computer (e.g., including a processor) to perform the methods described and claimed herein. Examples of such computer-readable storage media include, but are not limited to, hard disks, CD-ROMs, optical storage devices, magnetic storage devices, ROMs (read-only memories), PROMs (programmable read-only memories), EPROMs (erasable programmable read-only memories), EEPROMs (electrically erasable programmable read-only memories), and flash memory. Moreover, it is conceivable that, although it may require considerable effort due to available time, current technology, and economic considerations, and that many alternative designs exist, such software instructions, programs, and integrated circuits can be readily created by those skilled in the art with minimal experimentation, guided by the concepts and principles disclosed herein.

[0059] The abstract provided is intended to allow the reader to quickly determine the nature of the disclosed technology. It should be understood that the abstract should not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the preceding detailed description, various features have been combined in different embodiments to make the disclosure flow smoothly. However, this approach to disclosure does not imply that the claimed embodiments require more features than expressly recited in each claim. Rather, as reflected in the appended claims, the subject matter of the invention does not encompass all features of a single disclosed embodiment. Therefore, the appended claims are incorporated herein by reference, wherein each claim exists independently as a separate claimed subject matter.

Claims

1. An apparatus comprising: A communication interface, the communication interface including a beacon; and The controller, interconnected with the communication interface, is configured to: Receive initialization requests, including beacon types, via the communication interface; In response to the initialization request: Obtain configuration data for the beacon type; and The format of the beacon packet is constructed based on the configuration data for the beacon type; and Control the beacon to broadcast the beacon packet.

2. The device according to claim 1, wherein, The controller is configured to receive a configuration request that includes configuration data for the beacon type.

3. The device according to claim 2, wherein, The configuration request includes at least one length-type-value element containing the configuration data.

4. The device according to claim 1, wherein, The controller is configured to retrieve the configuration data from the device's memory.

5. The device according to claim 1, wherein, The controller is configured to generate a unique identifier for the device and apply the unique identifier to the configuration data.

6. The device according to claim 1, wherein, The controller is also configured to: Get broadcast parameters; and The beacon is controlled according to the broadcast parameters to broadcast the beacon packet.

7. The device according to claim 6, wherein, The broadcast parameters include one or more of the following: start conditions; stop conditions; and beacon frequency.

8. The device according to claim 1, wherein, The controller is also configured to: Receive enable request via the communication interface; and In response to the activation request, the beacon is controlled to broadcast the beacon packet.

9. The device according to claim 1, wherein, The initialization request is received as a configuration command for the device.

10. A method for customizing beacon packets in a device, the method comprising: Receive initialization requests, including those of beacon type; In response to the initialization request: Obtain configuration data for the beacon type; as well as Construct the format of the beacon packet based on the configuration data for the beacon type; and Control the beacon to broadcast the beacon packet.

11. The method of claim 10, further comprising receiving a configuration request including configuration data for the beacon type.

12. The method according to claim 11, wherein, The configuration request includes at least one length-type-value element containing the configuration data.

13. The method of claim 10, further comprising obtaining the configuration data from the memory of the device.

14. The method of claim 10, further comprising generating a unique identifier for the device and applying the unique identifier to the configuration data.

15. The method of claim 10, further comprising: Get broadcast parameters; as well as The beacon is controlled according to the broadcast parameters to broadcast the beacon packet.

16. The method according to claim 15, wherein, The broadcast parameters include one or more of the following: start conditions; stop conditions; and beacon frequency.

17. The method of claim 10, further comprising: Receive enable request; as well as In response to the activation request, the beacon is controlled to broadcast the beacon packet.

18. The method according to claim 10, wherein, The initialization request is received as a configuration command for the device.

Images