Role switching in mesh network using periodic advertising

By implementing the system and method of rotating control node roles between devices in the wireless mesh network of IoT devices, the problem of continuous consumption of battery power by controlling node roles is solved, and the battery consumption balance and the equipment working life are achieved.

CN119769173APending Publication Date: 2025-04-04QUALCOMM INC
View PDF 0 Cites 2 Cited by

Patent Information

Application Number
CN202380060925.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-09-07
Filing Date
2023-06-28
Publication Date
2025-04-04

AI Technical Summary

Technical Problem

When existing Internet of Things (IOT) devices use Bluetooth low energy (BLE) for wireless communication, the control node role continuously consumes battery power, resulting in the device being unable to act as a control node for a long time before depleting the battery.

Method used

By implementing the system and method of rotating control node roles between devices in the control cluster of wireless mesh network, the scheduling mechanism is used to define the duration of each device's control node role, and the system and method of rotating control node roles are executed through the processor.

Benefits of technology

It achieves balancing battery consumption that acts as a control node in IoT devices, extends the working life of the device, and avoids the rapid battery exhaustion caused by long-term operation of a single device.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119769173A_ABST
    Figure CN119769173A_ABST
Patent Text Reader

Abstract

Various embodiments include methods for rotating control node roles between devices in a control cluster of a wireless mesh network. A method may include assuming, by a first device, a control node role based on a control node assumption timing in a schedule, and transmitting a periodic message to support the wireless mesh network. The method may also include using the schedule to identify a control node role end timing and a third device in the control cluster that will assume the control node role; after the control node role ends timing, sending the periodic message while monitoring an extended advertisement from the third device until the extended advertisement from the third device is received; and assuming a passive node role when receiving the extension announcement from the third device, or continuing the control node role when no extension announcement is received from the third device.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Related Applications

[0002] This application claims the benefit of priority to U.S. non-provisional application No. 17 / 930,210, filed on September 7, 2022; the entire contents of which are incorporated herein by reference. Background Art

[0003] Internet of Things (IoT) devices can communicate with each other and with network access points (APs) using energy-saving, short-range wireless communication protocols such as Bluetooth Low Energy (BLE). IoT devices can broadcast periodic advertisement (PA) messages to nearby mesh networks of IoT device collections at regular intervals. Such PA messages can act as synchronization signals and can enable responses from network devices in the assigned period. Summary of the invention

[0004] Various aspects include systems and methods executed by a processor for rotating control node roles between devices in a control cluster of a wireless mesh network, the systems and methods comprising: identifying a control node assumption timing in a schedule stored on a first device within the control cluster, the control node assumption timing defining when the first device is scheduled to assume the control node role of the wireless mesh network from a second device in the control cluster; and assuming the control node role by the first device based on the control node assumption timing in the schedule, the control node role including sending periodic messages to support the wireless mesh network.

[0005] Some aspects may also include: identifying the control node role end timing in the schedule stored on the first device; identifying a third device in the control cluster that will assume the control node role based on the schedule; monitoring an extended announcement from the third device after the control node role end timing indicates that the third device has assumed the control node role; sending the periodic message after the control node role end timing until the extended announcement from the third device is received; and upon receiving the extended announcement from the third device, assuming the passive node role of listening to the periodic message from the third device after the control node role end timing; or continuing the control node role when no extended announcement is received from the third device.

[0006] In some aspects, continuing the control node role when no extended notification is received from the third device also includes: identifying a fourth device in the control cluster that will assume the control node role based on the schedule; adjusting the schedule to shift the control node assumption timing of the fourth device; requesting an early transfer of the control node role; receiving confirmation of the shift of the control node assumption timing from the fourth device; monitoring periodic notifications from the fourth device after the confirmation indicates that the fourth device has assumed the control node role; and upon receiving the periodic notifications from the fourth device, assuming the control node role of listening for periodic messages from the third device after the control node role end timing.

[0007] In some aspects, continuing the control node role when no extension advertisement is received from the third device may also include continuing the control node role until the scheduling provides another device of the control cluster to assume the control node role.

[0008] Some aspects may also include: receiving multiple attributes from a device during organization of the mesh network; identifying multiple devices within the mesh network that are suitable for the control cluster based on the received multiple attributes; compiling the schedule for transferring the control node role between the multiple devices of the control cluster; storing the schedule in a memory of the first device; and communicating the schedule to each of the multiple devices of the control cluster for storage.

[0009] Some aspects may also include: collaborating with one or more of the multiple devices of the control cluster to identify a sequence of control node role assignments, wherein the first device is a member of the control cluster, and wherein at least two of the multiple devices of the control cluster are identified in the schedule stored on the first device.

[0010] In some aspects, the plurality of attributes includes at least one attribute related to suitability for service in the control cluster, the at least one attribute selected from battery charge, expected battery life, proximity to other devices of the cluster, transceiver battery usage, or operating power mode.

[0011] Some aspects may also include: receiving one or more consensus inputs from the plurality of devices of the control cluster to define the schedule, the one or more consensus inputs being related to an order of transferring the control node roles in the control cluster. Some aspects may also include: sending a plurality of attributes from the first device to other devices in the control cluster.

[0012] Further aspects include a device having a processor configured to perform one or more operations of any of the methods outlined above. Further aspects include a processing device for use in a device, the processing device being configured with processor-executable instructions to perform the operations of any of the methods outlined above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of the device to perform the operations of any of the methods outlined above. Further aspects include a device having components for performing the functions of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a system diagram illustrating an example communication system suitable for implementing any of the various aspects.

[0014] Figure 1B is a system diagram illustrating an example decomposed base station architecture suitable for implementing any of the various embodiments.

[0015] Figure 2 is a transmission diagram illustrating a communication mode according to various aspects.

[0016] Figure 3A is a system diagram illustrating an example communication system suitable for implementing any of the various aspects.

[0017] Figure 3B is a flow chart illustrating an example method for implementing various aspects.

[0018] Figure 4 is a process flow diagram illustrating an example process for network formation suitable for implementing various aspects.

[0019] Figure 5 is a system diagram of devices and components suitable for implementing various aspects.

[0020] Figure 6 is a system diagram of devices and components suitable for implementing various aspects.

[0021] Figure 7 is a component block diagram of an example of a computing device suitable for implementing various aspects.

[0022] Figure 8 is a process flow diagram illustrating example methods according to various aspects.

[0023] Fig. 9 is a process flow diagram illustrating an example method according to some aspects.

[0024] Fig.10 is a system block diagram illustrating components suitable for implementing various aspects. DETAILED DESCRIPTION

[0025] Various aspects and implementations will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar components. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of protection of the claims.

[0026] Various embodiments provide methods and systems for implementing these methods to support a wireless mesh network of IoT devices with BLE capabilities to periodically shift the role of a control node between multiple devices in a control cluster to average the battery consumption of acting as a control node. Various embodiments include organizing such a mesh network, identifying IoT devices in a control cluster, scheduling the sequence and periodicity of shifting the control node role between devices in the control cluster, and performing a process of shifting the control node role without interrupting mesh network service.

[0027] The term "user equipment" (UE) is used herein to refer to any or all of the following: wireless communication devices, wireless appliances, cellular phones, smart phones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, handheld computers, wireless email receivers, virtual reality displays, extended reality displays, Internet-enabled multimedia cellular phones, wireless router devices, medical devices and equipment, biometric sensors / devices, wearable devices (including smart watches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings, smart bracelets)), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), wireless network-enabled Internet of Things (IoT) devices (including smart meters / sensors, industrial manufacturing equipment, large and small machines and appliances for home or business use), wireless communication elements within autonomous and semi-autonomous vehicles, wireless devices attached to or incorporated into various mobile platforms, global positioning system devices, and similar electronic devices that include memory, wireless communication components and programmable processors.

[0028] The term "system on chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources or processors integrated on a single substrate. A single SOC may include circuits for digital, analog, mixed signal, and radio frequency functions. A single SOC may also include any number of general or special processors (digital signal processors, modem processors, video processors, etc.), memory blocks (such as ROM, RAM, flash memory, etc.), and resources (such as timers, voltage regulators, oscillators, etc.). Each SOC may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0029] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs coupled together via high-speed communication circuits and packaged in close proximity (such as on a single motherboard or in a single wireless device). The proximity of the SOCs facilitates high-speed communication and sharing of memory and resources.

[0030] As used herein, the terms "network," "system," "wireless network," "cellular network," and "wireless communication network" may interchangeably refer to a portion or all of a wireless network of a carrier associated with a wireless device and / or a subscription on a wireless device. The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA), time division multiple access (TDMA), FDMA, orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), frequency hopping, spread spectrum, and other networks. In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support at least one radio access technology that may operate on one or more frequencies or frequency ranges. In another example, an OFDMA network may implement Evolved UTRA (E-UTRA) (including the LTE standard), Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash- Etc. In another example, a frequency hopping spread spectrum network may implement Bluetooth (Bluetooth SIG) 5.0 and its variants, predecessors, and successors.

[0031] The Internet of Things (IoT) provides unlimited connection opportunities between devices and device organizations. IoT devices can be connected to access points that provide high-power reliable signals. Such access points may require constant power connections due to their high power usage. IoT devices can be connected via Bluetooth Low Energy (BLE) mesh protocols / profiles that allow the creation of mesh networks. The organization of mesh networks based on legacy Bluetooth data channels may cause channel congestion, interference, and unbounded delivery times.

[0032] IoT devices implementing BLE can send or receive regular transmissions called periodic announcements, which broadcast information from the control node to the peripheral nodes. These periodic announcements are unidirectional, which may prevent the use of such periodic announcements when forming a mesh network. Periodic announcements (PA) can be used to request reports from other IoT devices that add two-way communication capabilities without establishing a negotiated BLE link by requesting the receiving IoT device to send a response to the periodic announcement. This communication method is called PA with response (or PAwR). Since the periodic announcement can include an identifier of a specific IoT device, the PAwR message exchange can be directed to each IoT device. The IoT device receiving PAwR can check the announcement to detect whether it includes an identifier that matches the identifier of the IoT device, and if so, it can send a response to the query or information included in the payload of the PA depending on whether the received command seeks a response.

[0033] This directional query and response communication signaling without the need to negotiate a BLE link between devices can be used to support the creation of a collaborative mesh network of BLE-capable IOT devices. In a wireless mesh network based on periodic announcements with responses, one of the devices acts as a "control node" by transmitting periodic announcement messages according to a predefined schedule known to all other nodes in the mesh network (called "peripheral nodes") and receiving corresponding responses from the addressed peripheral nodes. The network can rely on conventional PA messages to synchronize with the periodicity of these messages and the timing for sending responses. Therefore, the network may need a control node that is reliable and can reach other nodes of the network with sufficient signal strength. Although this network can have many different applications, in a conventional mesh network of BLE-capable IOT devices, the control device will need to receive power from an external source because the control node role will consume enough power so that the battery-powered IOT that performs this role will not be able to do so long before its battery is exhausted.

[0034] Various embodiments enable deployment of a wireless mesh network of BLE-enabled IoT devices, wherein the role of a control node is periodically shifted between multiple IoT devices in a control cluster, thereby balancing battery consumption of devices acting as control nodes. Such a mesh network can be self-organizing, and a sequence and periodicity of processes including identifying IoT devices in a control cluster and scheduling execution of shifting the role of a control node from one node to the next can be performed without establishing a direct BLE communication link and without interrupting mesh network service.

[0035] A device acting as a control node sends periodic announcement messages at regular intervals. Such messages may include data for passive nodes in the network. Using the PAwR messaging option, a control node may send data or queries to a specific peripheral node by including in the message payload an identifier of the target node and an indication of the type of reply that should be sent in response. Periodic announcement messages may be used to synchronize devices in a mesh network, enabling peripheral devices to determine when to activate a radio receiver to receive a periodic announcement message and, where appropriate, when to send a reply. In this way, communications between the various nodes of a mesh network may be multiplexed in the time domain. A control node may listen for responses at assigned intervals and decide how to use the received information (e.g., relay or respond).

[0036] In various embodiments, the role of the control node is shifted or rotated to another device within the control cluster to distribute the power requirements of the mesh network between the control clusters. In various embodiments, this shift or rotation of the control node role from one device to another can be completed according to a schedule known to at least the device performing the control node role, and in some embodiments, it is a schedule known to all nodes in the control cluster. By shifting or rotating the control node role according to the schedule, the role switching / rotation process can be completed between the control cluster devices without further information signaling (e.g., exchanging battery charge status) between the devices. In some embodiments, the schedule can be defined and stored in all devices within the control cluster, such as when organizing the control cluster. In some embodiments, the schedule can be known to and maintained by the device performing the control node role, and is communicated to the control cluster device by the control node, which then takes over the control node before the control node role shift will occur. In some embodiments, the device performing the control node role can adjust the schedule and communicate the adjusted schedule to other devices in the control cluster.

[0037] Various embodiments enable deployment of wireless mesh networks of battery-powered devices, since the battery consumption of acting as a control node is shared among a group of devices. Various embodiments may be particularly useful for mesh networks organized around battery-operated IOT devices, since the self-organizing and role-sharing approach avoids any one device having to continuously act as a control node.

[0038] Figure 1A 1 is a system diagram illustrating an example communication system suitable for implementing a mesh network 100. As described, the mesh network may include a control node 120a that sends messages to and receives messages from various devices that act as peripheral nodes 110, 120 in the mesh network. The control node 120a may also communicate with a network node 130 connected to the communication network 108.

[0039] In various embodiments, the wireless mesh network 100 will include one or more devices that always act as peripheral nodes (referred to herein as "peripheral devices 110" or "peripheral nodes") and a group of devices that are configured to periodically act as control nodes 120a (referred to herein as "control cluster devices" 120 or "control cluster nodes"). Specifically, the term "control cluster device" 120 or "control cluster node" refers to a device in a control cluster that does not act as a control node (i.e., acts as a peripheral node) to distinguish it from a device in a control cluster that acts as a control node.

[0040] The peripheral devices 110 and the control cluster devices 120 may form a mesh network with communications synchronized by the control node 120a. The control node 120a may send periodic announcements according to the periodicity of a synchronization signal that may serve as a network, while also sending data to passive nodes in the mesh network. The control node 120a may collaboratively communicate or reference one or more decisions to the group of control cluster devices 120. Thus, the mesh network 100 may connect devices of various capabilities to each other and to various external assets.

[0041] Devices in the mesh network 100 can be synchronized to communicate via Bluetooth, Bluetooth Low Energy (BLE), or other Bluetooth standard messages. Bluetooth allocates a large portion of its spectrum to data channels that can be used for device-to-device communications. Implementing a mesh network or one-to-many network in these data channels can quickly overwhelm these channels and quickly increase interference and delivery times. Bluetooth allocates several time slots on the data channel for periodic announcements or broadcasts to devices in range. A Bluetooth device can broadcast periodic announcements along with the data and can connect two or more announcements into a chain or queue (for example, if the data to be sent is too large for one announcement). Other Bluetooth devices can activate their wireless transceivers when periodic announcements are sent in order to receive such messages, while powering down the transceivers at other times. Reference Figure 2The nature of transmissions in the advertising channel of the Bluetooth protocol is described in more detail.

[0042] The mesh network 100 can support bidirectional communication between all nodes of the mesh. That is, the announcement channel and its management protocol can enable responses from peripheral devices 110. Device 110 can be a passive or active device, where in a passive role, device 110 may not be configured to respond and may only initiate a connection and listen (receive). For example, device 110 may be a programmable tag that contains identification information and sends via Bluetooth. Tags can save power by only waking up to receive periodic announcements and waking up as commanded by the control node via the announcement. Other specific implementations are contemplated, including industrial process control, distributed processing clock synchronization, and other decomposed device architectures.

[0043] The control cluster device 120 may be configured with one or more characteristics or attributes that enable each device to perform the role of a control node 120a. The control cluster device 120 may rotate or deterministically assign the role of a control node to each control cluster device 120 according to a schedule stored in each control cluster device. When it is time to assume the role of a control node 120a, the control cluster device 120 may begin sending periodic announcements that include data and information received by other control cluster devices 120 and peripheral devices 110. Once synchronization has been established, the mesh network 100 and the group of control cluster devices 120 may be managed entirely via the announcement channel without having to send on a legacy Bluetooth channel or Bluetooth data channel. The mesh network 100 may be organized via another wired or wireless protocol that provides periodic broadcast packets to synchronize and notify the network.

[0044] In some implementations, there may be more than one mesh network adjacent to each other (in the communication space), in which case the control node 120a may communicate with the control node of the adjacent mesh network directly or by relaying messages through the two mesh networks. One or more control cluster devices 120 or devices 110 with transmission capabilities may operate as wireless communication routers to other mesh networks.

[0045] The control node 120a can prioritize or schedule a longer response time for the control cluster devices 120 that form part of the decision-making device and sensing infrastructure of the mesh network 100. For example, the control node 120a can periodically request the control cluster devices 120 and the peripheral devices 110 to provide the signal strength of the neighboring devices 110. Alternatively, the control node 120a can periodically request the control cluster devices 120 and the peripheral devices 110 to scan for active control tags nearby. The group of control cluster devices 120 and the allocated communication time can ensure the reliability and self-healing capability of the mesh network 100.

[0046] As illustrated, the control node 120a may operate as a bridge to other networks (e.g., cellular networks, WLAN, Wi-Fi) via the network node 130 or the communication network 108. For example, the network node 130 and the communication network 108 may be a cellular wireless wide area network (WWAN), such as a 5G or later generation wireless network. Specifically, the network node 130 may be a 5G New Radio (NR) network node, a Wi-Fi access point, or any other suitable network, such as a Long Term Evolution (LTE) network or a later generation network. Therefore, references to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting. The communication system 100 may be a heterogeneous network including peer links, relay links, and one or more links to a network node (e.g., the network node 130). The network node 130 may be connected to other assets via a backhaul link or other network links. In Figure 1B The various connections in the 5G radio system are described in more detail in .

[0047] The network node 130 may be connected to the communication network 108 via a wired or wireless communication link (such as Ethernet, TV cable, telephone, fiber optic, and other forms of physical network connection) and enables the control node 120a to communicate with the backend server via the communication network 108. The control node 120a may communicate with the network node 130 via the wireless communication link.

[0048] The communication network 108 may include a plurality of network nodes 130 and other network entities, such as base stations and access points. The network node 130 is an entity that communicates with a user equipment and may be referred to as a Node B, an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio head, a transmit receive point (TRP), a new radio base station (NR BS), a 5G Node B (NB), a next generation Node B (gNodeB or gNB), etc. In various communication network implementations or architectures, the network node may be implemented as an aggregated base station, a decomposed base station, an integrated access and backhaul (IAB) node, a relay node, a sidelink node, etc., such as a virtualized radio access network (vRAN) or an open radio access network (O-RAN). In addition, in various communication network implementations or architectures, the network equipment (or network entity) may be implemented in an aggregated or monolithic base station architecture, or alternatively, in a decomposed base station architecture, and may include one or more of a centralized unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (RT) RAN intelligent controller (RIC), or a non-real-time RIC. Each network device may provide communication coverage for a specific geographic area. In 3GPP, the term "cell" may refer to a coverage area of ​​a network device, a network device subsystem serving the coverage area, or a combination thereof, depending on the context in which the term is used.

[0049] The wireless communication links and network nodes 130 of the wireless network 108 may include multiple carrier signals, frequencies or frequency bands, each of which may include multiple logical channels. The wireless communication links may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in wireless communication links include: 3GPP LTE, 3G, 4G, 5G (such as NR), GSM, code division multiple access (CDMA), wideband code division multiple access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), time division multiple access (TDMA), and other mobile phone communication technology cellular RATs. The nodes of the wireless mesh network 100 may use medium-range protocol RATs (such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire) and relatively short-range RATs (such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE)).

[0050] Although the description of some specific implementations of the network node 130 and the communication network 108 may use terms and examples associated with LTE technology, some specific implementations may be applicable to other wireless communication systems (such as new radio (NR) or 5G networks). NR can utilize orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) on the uplink (UL) and downlink (DL), and includes support for half-duplex operation using time division duplex (TDD). A single component carrier bandwidth of 100 MHz can be supported. NR resource blocks can span 12 subcarriers with a subcarrier bandwidth of 75 kHz over a duration of 0.1 milliseconds (ms). Each radio frame may include 50 subframes with a length of 10 ms. Therefore, each subframe may have a length of 0.2 ms. Each subframe may indicate a link direction (i.e., DL or UL) for data transmission, and the link direction of each subframe may be dynamically switched. Each subframe may include DL / UL data and DL / UL control data. Beamforming may be supported and the beam direction may be dynamically configured. Multiple-input multiple-output (MIMO) transmission with precoding may also be supported. MIMO configuration in DL may support up to eight transmit antennas, multi-layer DL transmission with up to eight streams and up to two streams per UE. Multi-layer transmission with up to 2 streams per UE may be supported.

[0051] The deployment of a wireless communication system 108 (such as a 5G NR system) can be arranged with various components or constituent parts in a variety of ways. In a 5G NR system or network, a network node, a network entity, a mobility element of a network, a radio access network (RAN) node, a core network node, a network element or a network equipment (such as a base station (BS), or one or more units (or components) that perform base station functionality) can be implemented in an aggregated or decomposed architecture. For example, a base station (such as a Node B (NB), an evolved NB (eNB), an NR BS, a 5G NB, an access point (AP), a transmit receive point (TRP) or a cell, etc.) can be implemented as an aggregated base station (also referred to as an independent BS or a monolithic BS) or a decomposed base station.

[0052] A converged base station may be configured to utilize a radio protocol stack physically or logically integrated within a single RAN node. A decomposed base station may be configured to utilize a protocol stack physically or logically distributed between two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some aspects, a CU may be implemented within a RAN node, and one or more DUs may be co-located with the CU, or alternatively, may be geographically or virtually distributed in one or more other RAN nodes. A DU may be implemented to communicate with one or more RUs. Each of a CU, a DU, and a RU may also be implemented as a virtual unit (referred to as a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU)).

[0053] Base station type operations or network designs may take into account the aggregated nature of base station functionality. For example, a disaggregated base station may be used in an integrated access backhaul (IAB) network, an open radio access network (O-RAN) (such as a network configuration initiated by the O-RAN Alliance), or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN)). Decomposition may include distributing functionality across two or more units at various physical locations, as well as virtually distributing functionality of at least one unit, which may enable flexibility in network design. Individual units of a disaggregated base station or disaggregated RAN architecture may be configured for wired or wireless communication with at least one other unit.

[0054] Figure 1B is a system block diagram illustrating an example decomposed base station 160 architecture suitable for implementing any of the various embodiments. Figure 1A and Figure 1B, the decomposed base station 160 architecture may include one or more central units (CU) 162, which may communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more decomposed base station units (such as a near real-time (Near-RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time (Non-RT) RIC 168 associated with a service management and orchestration (SMO) framework 166, or both). The CU 162 may communicate with one or more distributed units (DU) 170 via corresponding midhaul links (such as an F1 interface). The DU 170 may communicate with one or more radio units (RU) 172 via corresponding fronthaul links. The RU 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, a UE 120 may be served by multiple RUs 172 simultaneously.

[0055] Each of the units (i.e., CU 162, DU 170, RU 172), as well as near-RT RIC 164, non-RT RIC 168, and SMO framework 166 may include one or more interfaces, or be coupled to one or more interfaces configured to receive or send signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of these units or an associated processor or controller that provides instructions to the communication interface of these units may be configured to communicate with one or more of the other units via a transmission medium. For example, these units may include a wired interface that is configured to receive or send signals to one or more of the other units via a wired transmission medium. Additionally, the unit may include a wireless interface that may include a receiver, a transmitter, or a transceiver (such as a radio frequency (RF) transceiver) that is configured to receive or send signals or both to one or more of the other units via a wireless transmission medium.

[0056] In some aspects, CU 162 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to communicate signals with other control functions hosted by CU 162. CU 162 may be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some specific implementations, CU 162 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (such as an E1 interface). As needed, CU 162 may be implemented to communicate with DU 170 for network control and signaling.

[0057] DU 170 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 172. In some aspects, DU 170 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) depending at least in part on a functional split such as that defined by the Third Generation Partnership Project (3GPP). In some aspects, DU 170 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface that is configured to communicate signals with other layers (and modules) hosted by DU 170 or with control functions hosted by CU 162.

[0058] The lower layer functionality may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DUs 170 may correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transforms (FFTs), inverse FFTs (iFFTs), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on functional splits (such as lower layer functional splits). In such an architecture, the RUs 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs and a control node 120a of a wireless mesh network. In some specific implementations, real-time and non-real-time aspects of control and user plane communications with the RUs 172 may be controlled by the corresponding DUs 170. In some scenarios, this configuration may enable the DUs 170 and CUs 162 to be implemented in a cloud-based RAN architecture (such as a vRAN architecture).

[0059] The SMO framework 166 may be configured to support RAN deployment and provisioning of non-virtualized network elements and virtualized network elements. For non-virtualized network elements, the SMO framework 166 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 166 may be configured to interact with a cloud computing platform (such as an open cloud (O-Cloud) 176) to perform network element lifecycle management (such as to instantiate virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, CU 162, DU 170, RU 172, and near-RT RIC 164. In some specific implementations, the SMO framework 166 may communicate with hardware aspects of the 4G RAN (such as an open eNB (O-eNB) 174) via the O1 interface. Additionally, in some specific implementations, the SMO framework 166 may communicate directly with one or more RUs 172 via the O1 interface. The SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166 .

[0060] The non-RT RIC 168 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 may be coupled to or in communication with the near-RT RIC 164 (such as via an A1 interface). The near-RT RIC 164 may be configured to include logic functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface (such as via an E2 interface) that connects one or more CUs 162, one or more DUs 170, or both, and the O-eNB with the near-RT RIC 164.

[0061] In some implementations, in order to generate an AI / ML model to be deployed in the near-RT RIC 164, the non-RT RIC 168 may receive parameters or external enrichment information from an external server. Such information may be utilized by the near-RT RIC 164 and may be received from a non-network data source or from a network function at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns of performance and employ AI / ML models to perform corrective actions through the SMO framework 166 (such as via reconfiguration of O1) or via the creation of RAN management policies (such as A1 policies).

[0062] Figure 2 is a signal timing diagram illustrating a portion of the communication between the control node 120a and the mesh network 100. Figures 1A to 2 , Figure 2 The signal sequence exemplified in can be represented by Figure 1A to Figure 1B This is achieved by one or more of a communication connection, a network node, an access point, or a routing device. Figure 2 Devices #1 to #5 of the control cluster device 120 can be selected from the device 110 and the control cluster device 120, and can receive periodic announcements in the scanning cycle 210. The scanning cycle 210 can occur at regularly scheduled intervals and can be repeated periodically so that devices #1 to #5 wake up during the repeated scanning cycle 210 to scan for messages. The control node 120a can provide periodic announcements to devices #1, #2, #3, #4 and #5 via broadcast or multicast in the scanning cycle 210. For the control node 120a, this is its main transmission cycle. The transmission can include multiple announcements in the queue. One or more parts of the announcement can be directed to one or more devices in the device #1 to #5. Devices #1 to #5 can decode or filter messages intended for each specific device and sent during the cycle when all devices are receiving. In this way, the device 110 and the control cluster device 120 can be reprogrammed, updated, or a request is transmitted from the control node 120a, or relayed from another device through the control node 120a. The periodic advertisement (PA) from the control node 120 a may set a response period for one or more of the devices 110 or the control cluster devices 120 .

[0063] As illustrated, in the time following the scan cycle 210, devices #1 through #5 are each assigned a response cycle 220, 222, 224, 226, 228. The first response cycle 220 may begin after a brief idle time 215 following the scan cycle 210, where the idle period is long enough to provide the sender device with an opportunity to engage in other Bluetooth-related activities. The assigned cycles may also be limited to or specify a specific frequency of the advertising channel on which to respond. Figure 2 In the example, device #1 is assigned response period 220; device #2 is assigned response period 222; device #3 is assigned response period 224; device #4 is assigned response period 226; and device #5 is assigned response period 228; control node 120a may store properties of device 110 and control cluster device 120, including whether the device is able to send or respond. PA signaling followed by a response is referred to as periodic advertisement with response (PAwR).

[0064] For example, device #3 may be Figure 5 The tag 510 of the mesh network 100 may be received from the control node 120a in the scanning cycle 210. The PA received at device #3 may include a specified start time for the response cycle 224, or may include a schedule of response start times for devices including device #3. The response of device #3 to the control node 120a may include an acknowledgment, a status code, and other information such as battery life, received signal strength, or an error notification. The response of device #3 may include information to be relayed by the control node 120a to another device of the mesh network 100. The response may include a packet with a header and may conform to any Bluetooth protocol. The response may be sent to the control node 120a in the data channel of the Bluetooth protocol. The PA and responses from all devices may use only the announcement channel of the Bluetooth protocol.

[0065] A device that has been assigned a response period (e.g., device #5) may not respond and may determine that it has no signals to send. In other words, devices #1 to #5 may determine what response (if any) is required and may or may not respond to the request transmitted from the control node 120a. Response periods 220 to 228 may be assigned based on a request for this period in an open transmit time, which is transmitted to the control node 120a. Response periods 220 to 228 may be assigned based on which devices the control node 120a has requested to transmit data or acknowledgments. PA messages and responses may be frequency hopping of an announcement channel in Bluetooth, a time synchronization channel, or an extension channel. Regarding Figure 3A and Figure 4 A further description of the organization of a mesh network is provided.

[0066] Figure 3Ais a system diagram illustrating control node role switching between the group of control cluster devices 120 according to various embodiments. Figures 1A to 3A , the group of control cluster devices 120 may include one device acting as a control node 120a, and may communicate with each other via wired or wireless communications (e.g., BLE, WLAN). The organization and collaboration of managing the cluster of devices constituting the wireless mesh network (e.g., 110, 120) may be performed only via the announcement channel, or may be performed using one or more data channels of the BLE protocol as well as the announcement channel (e.g., PAwR).

[0067] The group of control cluster devices 120 can each store information about the devices that make up the mesh network 100. This information can be used by various devices (including devices acting as control nodes 120a) to perform operations sufficient to ensure that the mesh network is self-healing based on the built-in redundancy provided by many devices acting as peripheral nodes 110, 120. For example, each control cluster device 120 can store information about peripheral devices 110 and control cluster devices 120, including round-trip time relative to the control node 120a to each device, battery life, status codes, protocol capabilities (e.g., Wi-Fi, 5G, BLE), and assigned response cycles. Therefore, when the control node 120a switches out of the control mode function and returns to operating as a peripheral node within the control cluster, another control cluster device 120 can seamlessly transition to acting as a control node 120a without data transfer or device profile sharing.

[0068] Control cluster devices 120 may store a schedule indicating when each control cluster device 120 will assume the role of a control node for mesh network 100. The schedule enables the role of control node to periodically shift from one control cluster device to the next without requiring a negotiated direct connection between devices to effect the role transfer.

[0069] In one embodiment, the schedule can be in the form of a data table stored on the control node 120a and each control cluster device 120, which includes the start time when each control cluster device should start sending PA for the network and assume the role of control node, and the end time when the control node 120a should stop sending PA, give up the role of control node and start listening as a passive node 110, 120.

[0070] In another embodiment, the scheduling can be in the form of a sequence list of devices in the control cluster plus the control function duration. Specifically, the control node 120a and each control cluster device 120 can store a list of control node device identifiers (e.g., a data table), which identifies the sequence of multiple control node devices 120 that should assume the control node function plus the control function duration that each device should act as a control node. In this embodiment, when the control function duration of the current control node 120a expires, the next control cluster device 120 in the sequence can start sending PA for the network, assuming the control node role during the control function duration, and after the control function duration, once it confirms that the next node in the sequence has taken over, the device will give up the control node role and start acting as a passive node. In some embodiments, the sequence of devices that assume the control node role in the core cluster can be updated by the current control node and communicated to the control cluster device or all control cluster devices that will assume the control node role next.

[0071] The role transfer is exemplified as Figure 3A Switching in 1. The control cluster device that assumes the control node role can send PA in a short period simultaneously with the control cluster device that releases the control node role to ensure that the handover is completed. At least a portion of the PA message from any control cluster device sent in the control node role can be the same or substantially similar, so that the role switch is transparent to the mesh network. For example, the identification code of the control node used to send periodic announcements can be changed, but the remainder of the PA message can remain the same as before the transfer. For the peripheral device 110 and the control cluster device 120, the switch in the control node role can be transparent and maintain synchronization. The peripheral device may have stored information about periodic announcements from the control node from an existing or ongoing PA queue. The stored information about the periodic announcements may include timing information, channel mapping, access address, message integrity check seed, and PA message counter.

[0072] In some embodiments, the schedule defining the timing of the control node role switches may include switch 1, switch 2, switch 3, switch 4, switch 5, and switch 6, as illustrated. For a larger group of control cluster devices 120, more switches are considered. The sharing of the control node role reduces overall battery usage and enables a mesh network to be implemented by devices with BLE capabilities.

[0073] When the control node 120a transfers its role to another control cluster device 120, the control node 120a may perform various processes to ensure that the next device has taken over the role. The control node 120a may identify the next control cluster device (sometimes referred to herein as the third device in the control cluster) that will assume the role of the control node based on the schedule. The control node 120a may monitor an extended notification sent by the control cluster device assuming the role (i.e., the third device) indicating that the third device has assumed the role of the control node, or may request confirmation that it will assume or can assume the role of the control node. In some embodiments, the schedule may be only on the current control node, and the next control node may also be notified in a timely manner to take over the role of the control node. Reference Figure 8 and Fig. 9 The process is described in further detail.

[0074] When no confirmation or PA message is received, the control node 120a may continue to control the node role until the scheduling provides another device of the control cluster to assume the control node role. In some embodiments, the control node 120a may continue to control the node role until the next transition time. In some embodiments, the control cluster device 120 may communicate to identify a replacement control cluster device for the control node role before the next scheduled switch. In other words, the control cluster device 120 may collaborate to reorganize the schedule to assume the control node function in response to a failure of the control cluster device, such as when the control cluster device fails or moves out of the wireless reception range of other cluster devices or is determined to be insufficiently suitable for performing the role of the control node.

[0075] A schedule for switching control node functions between control cluster devices may be developed or determined based on one or more communications between control cluster devices (e.g., information sharing such as battery power) when organizing the mesh network or at another point in time. This collaboration may be exchanged between control cluster devices 120 via a notification channel (e.g., BLE notifications and responses), or may be exchanged via a data channel or other channel. As previously described, the control cluster devices 120 may share their attributes or specifications, and this information may be used by the device to determine the order of the control cluster devices in the schedule. Therefore, the control cluster devices of the mesh network may implement a management solution that is both collaborative and centralized.

[0076] Figure 3B is a process block diagram illustrating an example sequence of events that may enable a wireless device to join a wireless mesh network and be assigned a role, such as a peripheral node or a controlling cluster node.

[0077] In box 310, the new device transmits a join signal via an extension channel, or via a pairing process according to the Bluetooth protocol, or via a BLE beacon. After the new device initially notifies the mesh network 100 of its existence, the control node 120a can receive the notification, and in box 320, a time slot for response can be assigned after the next PA, and the assigned time slot in the PA can be notified. In box 330, the new device can respond with the specifications or attributes of the new device in the assigned response time slot (e.g., response cycle 220). For example, the new device can indicate that it periodically requires data updates or that it periodically needs a response time slot to send data (e.g., periodic reports such as refrigerator temperature or bottle temperature). The new device can provide information about capabilities such as transmission strength, battery charge status and / or storage capacity, other communication connection capabilities, and proximity to other devices within the mesh network.

[0078] In block 340, the controlling cluster device or control node 120a may decide where to add the device to the mesh network 100. For example, the new device may be rejected after a security check, failed authentication, or determined to be incompatible.

[0079] In block 360 , as part of adding the new device to the control cluster, the control cluster device or control node may share specifications or capabilities of the new device with other control cluster devices.

[0080] In block 350, one or more control cluster devices or control nodes may determine that the new device does not meet one or more criteria to be a control node and, in response, add the new device as a peripheral node.A peripheral device may participate in the mesh network but not join the set of control cluster devices.

[0081] In block 370, the control cluster device or control node may determine a timing for assuming the control node role of the new device. In other words, the new device may be added to the schedule based on a collaborative or shared specification. For example, the new device may be added to the schedule later after one or more conditions change. Thus, the group of control cluster devices 120 may collaborate to manage the addition of the mesh network 100.

[0082] Figure 4 is a process flow diagram illustrating a series of operations that may be performed to initialize a mesh network. Figures 1A to 4In block 410, a plurality of nodes or devices may be powered on or begin signaling (e.g., transmitting BLE beacons). In block 420a, one or more initialized devices or nodes may form a first cluster #1. In block 420b, one or more initialized devices or nodes may form a second cluster #2. When forming each cluster, the relative signal strengths of surrounding devices may be used by various devices to identify those devices with which wireless communications may be reliably exchanged, wherein the first cluster and the second cluster are combined such that all devices in one cluster may reliably communicate with all other devices in the same cluster.

[0083] In some embodiments, as part of forming each cluster in blocks 420a and 420b, the device may identify a group of devices capable of acting as control nodes based on location and device capabilities, and organize a control cluster as described herein. In some implementations, all devices in the mesh network may have the ability to act as control nodes, in which case only location (e.g., based on signal strength measurements) may be the basis for selecting devices to include in a control cluster. As part of the process of selecting / identifying control cluster devices, the control cluster devices may develop or identify a schedule or sequence plus duration for rotating control node functionality as described herein.

[0084] In block 430, the node may merge two or more clusters (e.g., cluster #1 and cluster #2) by forming a communication link between the clusters. The merging of clusters may be performed by a consensus of the control nodes of each cluster or the control cluster devices of the clusters. The merging may be based on the proximity of the control cluster devices of each cluster, the distance to the peripheral devices of each cluster, the battery life of the cores, or other aspects of the clusters so that the merging enhances the performance and stability of the network. The merging process may begin after the control cluster devices of the clusters no longer receive join requests from new devices or when such activity has dropped below a threshold.

[0085] After zero, one or more merges, the control node or control cluster device 120 may determine that the nearby cluster should not be merged or joined. In other words, the membership of the devices 110 and the control cluster devices 120 in each cluster may become stable, and one or more devices 110 / 120 may be aware of adjacent clusters. In box 440, the control cluster device 120 may identify a router node that may be configured or may be configured to route messages from a control cluster device in one cluster to one or more control cluster devices in another cluster. The controlled flooding routing of the mesh network of the cluster may forward one or more specified packets between the control cluster device 120 and the devices 110 on the periphery, so that the specified packets arrive at the router node and are passed to another cluster. The router node may be synchronized in two separate clusters, and listen to PA messages from the two clusters, and may respond in the two clusters.

[0086] In block 450 , the control cluster device 120 may identify a list of such devices that belong to the same cluster and may determine a shared schedule for switching the role of the control node 120a between the control cluster devices.

[0087] In block 460 , the control cluster device and the control node may begin switching control node functionality based on a schedule as described herein.

[0088] Figure 5 is a component block diagram of an example of an IOT device with BLE capabilities in the form of an electronic tag 510 that can act as a peripheral device in a wireless mesh network according to various embodiments. Figures 1A to 5 , the electronic tag 510 may include a display 515 and an illuminator 517 (e.g., a light emitting diode (LED) or other type of visible indicator), which is coupled to a processor 502 configured with processor executable instructions, which are configured to cause the processor to perform the operations of various embodiments. The processor 502 may be coupled to a wireless transceiver 504, such as a BLE transceiver or a combination of a BLE and a Wi-Fi transceiver, which is coupled to an antenna 506 for transmitting and receiving radio frequency (RF) signals as described herein. In various embodiments, the processor 502 may include a SOC (e.g., 602, 604). The electronic tag 510 may be powered by a battery 508, so that the electronic tag 510 does not have to be connected to a wired power source. Alternatively, the electronic tag 510 may be powered by an external power source.

[0089] The electronic tag 510 may be configured to receive periodic announcements (e.g., price updates of the display 515) via the transceiver 504. The electronic tag 510 may be configured to send periodic announcements and responses via the transceiver 504. The electronic tag 510 may be configured for a passive mode in which PA messages are not transmitted, or may be configured for a listen-only mode in which PA messages are received and may be used but responses are not part of its regular communications with the mesh network. Based on the configuration of the electronic tag 510, it may be added to the mesh network by a control node or a control cluster device as a peripheral device or a non-control cluster device.

[0090] Figure 6 is a component block diagram of an example of a BLE-enabled IOT device in the form of an electronic tag 510 that can act as a control cluster device 610 (eg, control node 120a) according to various embodiments. Figures 1A to 6 , the control cluster device 610 may include processors 602, 604 coupled to volatile memory 606 and optionally large-capacity non-volatile memory 608. The control cluster device 610 may also include peripheral memory access devices, such as flash drives, coupled to the processors 602, 604. The control cluster device 610 may also include a network access port 614 (or interface) coupled to the processors 602, 604 for establishing a data connection with a network (such as the Internet and / or a local area network coupled to other system computers and servers). The control cluster device 610 may include additional access ports for coupling to peripheral devices, external memory or other devices, such as USB, FireWire, Thunderbolt, etc. The control cluster device 610 may include one or more antennas 607 coupled to a transceiver 617 for transmitting (i.e., sending) and receiving electromagnetic radiation that can be connected to a wireless communication link. The control cluster device 610 may be battery powered or may be hardwired for power.

[0091] The control cluster device 610 may be configured to receive periodic advertisements via the transceiver 617. The control cluster device 610 may be configured to send periodic advertisements and responses via the transceiver 617. Various attributes such as a higher gain antenna, longer battery life, no display to reduce battery life, or a larger processor 602 / 604 may enable the control cluster device 610 to operate as a control node 120a and thus be added as a control cluster device 120 of a cluster of the mesh network 100.

[0092] Figure 7700 is a system component diagram of a control cluster device 702 (e.g., control cluster device 120 / 610) suitable for use with various embodiments. The control cluster device 702 can be configured to communicate with external resources via a wireless connection 705 / 707 to a wireless communication network 108 (such as a cellular wireless communication network). The wireless connection 705 can be a radio link to a picocell 706, which can be connected to the communication network 108 via a backhaul or midhaul 730. The wireless connection 707 can be a radio link to a gNB 704, which can be connected to the communication network 108 via a backhaul or midhaul 732. The communication network 108 can be connected to a data server via a link 711 (e.g., optical fiber). The control cluster device 702 can be connected to a user equipment (UE) 750 (e.g., a cellular phone) via a wireless connection 745 and can be connected to an electronic tag 510 via a wireless connection 740.

[0093] The control cluster device 702 may include one or more processors 710, electronic storage 712, one or more sensors 714, a transceiver 716 (e.g., a wireless transceiver), and other components. The control cluster device 702 may include communication lines or ports to enable information exchange with a network and / or other computing platforms. Figure 7 The illustration of the control cluster device 702 in is not intended to be limiting. The control cluster device 702 may include a number of hardware, software, and / or firmware components that operate together to provide the functionality attributed to the control cluster device 702 herein.

[0094] The electronic storage device 712 may include a non-transitory storage medium that electronically stores information. The electronic storage medium of the electronic storage device 712 may include a system storage device provided integrally (i.e., substantially non-removable) with the control cluster device 702 and / or one or both of a removable storage device that is removably connected to the control cluster device 702 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage device 712 may include one or more of the following: an optically readable storage medium (e.g., an optical disk, etc.), a magnetically readable storage medium (e.g., a magnetic tape, a magnetic hard drive, a floppy disk drive, etc.), a charge-based storage medium (e.g., an EEPROM, a RAM, etc.), a solid-state storage medium (e.g., a flash drive, etc.), and / or other electronically readable storage medium. The electronic storage device 712 may include one or more virtual storage resources (e.g., a cloud storage device, a virtual private network, and / or other virtual storage resources). Electronic storage 712 may store software algorithms, information determined by processor 710, information received from control cluster device 702, information received from server 710, external resources (e.g., UE 750), and / or other information that enables control cluster device 702 to function as described herein.

[0095] Processor 710 may include one of a plurality of local processors (as described with respect to FIG. 12 ) that may be configured to provide information processing capabilities in control cluster device 702 (e.g., control cluster device 610 ). Thus, processor 710 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although processor 710 may be configured to provide information processing capabilities in control cluster device 702 (e.g., control cluster device 610 ), processor 710 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Figure 7 710 is shown as a single entity for illustrative purposes only. In some embodiments, processor 710 may include multiple processing units. These processing units may be physically located within the same device, or processor 710 may represent the processing functionality of multiple devices operating in coordination.

[0096] The control cluster device 702 may be configured by machine-readable instructions 720, which may include one or more instruction modules. The instruction modules may include computer program components. Specifically, the instruction modules may include one or more of a scheduling processing component 722, a routing component 724, a data component 726, a notification component 728, and / or other instruction modules. These components (e.g., 722 to 728) of the control cluster device 702 may together manage one or more aspects of the mesh network 100, as also shown in FIG. 1 and FIG. Figure 3A shown.

[0097] The scheduling processing component 722 may receive one or more start times or suggested start times for starting the role of a control node from one or more control cluster devices. The scheduling processing component 722 may receive updates on status (e.g., connection status) and capabilities from the control cluster device. The scheduling processing component 722 may receive internal updates on the status of the control cluster device 702. The scheduling processing component 722 may process the information to propose a start time for the control cluster device 702 to assume the role of a control node, and may process the information to propose a schedule for the start time of one or more other control cluster devices. As a non-limiting example, the processor 710 of the control cluster device 702 may receive scheduling information and specifications, and / or use one or more transceivers (e.g., 716) to detect available wireless connections (e.g., Wi-Fi, Bluetooth, cellular, etc.) and obtain other device attributes and sense cluster attributes.

[0098] The routing component 724 may include one or more processes for managing queues of data packets and for monitoring signals received from the transceiver 716 for information to be forwarded as part of controlled flood routing of the mesh network. For example, the routing component 724 may determine which packets or announcements are retransmitted and may store one or more packets or announcements. As a non-limiting example, the processor 710 controlling the cluster device 702 may execute one or more routing algorithms on the processor and / or use one or more transceivers (e.g., 716) to receive and send announcements and responses in the BLE mesh network.

[0099] The data component 726 may receive information sent via a data channel of a Bluetooth network or other wireless network from one or more devices on the network. The data component 726 may convert one or more data packets received from the data channel into elements of a periodic announcement to be sent via an announcement channel. For example, the data component 726 may receive and store updated price information and information about the associated electronic tags 510, and the data component 726 may convert the update information into a PA message for all electronic tags 510 included in the update. As a non-limiting example, the processor 710 of the control cluster device 702 may store and use data that has been received by the data channel of the BLE protocol. The transceiver 716 of the control cluster device 702 may send one or more data messages on the data channel, and may send a PA message from the data component 726.

[0100] The announcement component 728 of the control cluster device 702 can receive information sent via an announcement channel of a Bluetooth network or other wireless network from one or more devices on the network. The announcement component 728 can convert one or more PA messages received from the announcement channel into data to be stored in the electronic storage device 712 or retransmitted according to the determination of the routing component 724. The announcement component 728 can receive a response request or generate a response request for the control cluster device 702 to respond to another device via the announcement channel. As a non-limiting example, the processor 710 of the control cluster device 702 can perform processing of the PA message on the processor, and / or use one or more transceivers (e.g., 716) to connect to the mesh network for announcement and response. The processor 310 of the computing device 302 can execute the announcement component 728 to provide a network organization method that can operate only via the announcement channel.

[0101] Figure 8 is a process flow diagram illustrating a method 800 for switching a control node role between control cluster devices of a wireless mesh network. Figures 1A to 8 , various operations of method 800 may be performed by a processor (eg, 602, 604, 710) coupled to a memory (eg, 712) of a wireless device (eg, 120, 120a).

[0102] In block 802, a control cluster device (a "first device" in the claims) within a control cluster may identify a control node assumption timing in a schedule stored in a memory (e.g., 712). As described, the control node assumption timing may identify when the control cluster device (i.e., the first device) is scheduled to assume the control node role of the wireless mesh network from the current control node in the control cluster (a "second device" in the claims). As described, this may involve identifying from the schedule when the control cluster device is scheduled to assume the control node function, which may be based on a stored data table or a stored sequence plus the expiration of the control function duration. A component for performing the operation of block 802 may include a processor (e.g., 602, 604, 710) coupled to a memory (e.g., 712).

[0103] In block 804, the control cluster device may assume the control node role from the first control cluster device based on the control node assumption timing in the schedule stored in the memory (e.g., 712). Assuming the control node role may include sending periodic messages to support the wireless mesh network. The means for performing the operations of block 804 may include a processor (e.g., 602, 604, 710) coupled to the memory (e.g., 712).

[0104] Fig. 9 is a process flow diagram illustrating an example process 900 for switching the control node role of a network. Figures 1A to 9, various operations of method 800 may be performed by a processor (eg, 602, 604, 710) coupled to a memory (eg, 712) of a wireless device (eg, 120, 120a).

[0105] A moment after performing the control node function in block 804, the control cluster device (i.e., the first device) may identify the control node role end timing in the schedule stored in the memory (e.g., 712). Again as described, this may involve identifying from the schedule when the control cluster device is scheduled to relinquish the control node function, which may be based on a stored data table or a stored sequence plus the expiration of the control function duration. The means for performing the operations of block 902 may include a processor (e.g., 602, 604, 710) coupled to the memory (e.g., 712).

[0106] In block 904, the control cluster device (i.e., the first device) may identify the next control cluster device (the "third device" in the claims) that will assume the role of the control node based on the schedule stored in the memory. The means for performing the operation of block 904 may include a processor (e.g., 602, 604, 710) coupled to a memory (e.g., 712).

[0107] In block 906, the control cluster device (i.e., the first device) may monitor the periodic notification sent by the third device after the scheduled control node role ends timing. Receiving the periodic notification from the third device may indicate that the third device has successfully assumed the control node role. The means for performing the operation of block 906 may include a processor (e.g., 602, 604, 710) coupled to a memory (e.g., 712).

[0108] While monitoring the periodic advertisements sent by the third device in block 906, the controlling cluster device (i.e., the first device) may continue to send the periodic advertisements in block 908. Means for performing the operations of block 908 may include a processor (e.g., 602, 604, 710) coupled to a memory (e.g., 712).

[0109] In determination block 910, the control cluster device (i.e., the first device) may determine whether a periodic announcement is received from a third device. The means for performing the operation of block 910 may include a processor (e.g., 602, 604, 710) and related components coupled to a memory (e.g., 712) or using a transceiver (e.g., 617, 716) from a remote source (such as a remote system or external resource). If yes, the control cluster device may continue to block 912; and if no, the control cluster device may continue to block 914.

[0110] In response to determining that a periodic advertisement has been received from the third device (i.e., determination block 910 = "Yes"), the controlling cluster device (i.e., the first device) may assume the peripheral node role in block 912. In the peripheral role, the controlling cluster device (i.e., the first device) may begin listening for periodic advertisements sent by the third device and respond like other peripheral nodes until the next time the device should assume the controlling node role. Means for performing the operations of block 912 may include a processor (e.g., 602, 604, 710) coupled to a memory (e.g., 712).

[0111] In response to determining that periodic notifications have not been received from the third device (i.e., determination block 910 = "No"), the control cluster device (i.e., the first device) may continue to send periodic notifications in the control node role without interruption. The control cluster device (i.e., the first device) may continue the control node role until the next end time for switching the control node function, such as determined in block 902. In some embodiments, the control cluster device (i.e., the first device) may use the control node role to reorder or reorganize the scheduling for shifting the control node function between control cluster devices, such as in response to a control cluster device failure or physical removal from the mesh network. The components for performing the operation of block 914 may include a processor (e.g., 602, 604, 710) and related components coupled to a memory (e.g., 712) or using a transceiver (e.g., 617, 716) from a remote source (such as a remote system or external resource).

[0112] Fig.10 is a component block diagram illustrating an example computing and wireless modem system 1000 suitable for use in implementing any of the various embodiments. The example computing and wireless modem system 1000 may be implemented on a number of single-processor and multi-processor computer systems, including a system on a chip (SOC) or a system in a package (SIP).

[0113] refer to Figures 1A to 10, the illustrated example computing system 1000 includes two SOCs 602, 604 coupled to a clock 1006, a voltage regulator 1008, and a wireless transceiver 1066, which is configured to transmit and receive wireless communications to / from a UE (e.g., 750) or a network device (e.g., 110, 120, 510) via an antenna (not shown). In some specific implementations, the first SOC 602 can operate as a central processing unit (CPU) that controls the cluster device 120, which executes these instructions by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions of the software application. In some specific implementations, the second SOC 604 can operate as a dedicated processing unit. For example, the second SOC 604 can operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (such as 5Gbps, etc.) and / or ultra-high frequency short wavelength (such as 28GHz millimeter wave spectrum, etc.) communications.

[0114] The first SOC 602 may include a digital signal processor (DSP) 1010, a modem processor 1012, a graphics processor 1014, an application processor 1016, one or more coprocessors 1018 (such as a vector coprocessor) connected to one or more of these processors, memory 1020, custom circuits 1022, system components and resources 1024, interconnects / bus modules 1026, one or more temperature sensors 1030, a thermal management unit 1032, and a thermal power envelope (TPE) component 1034. The second SOC 604 may include a 5G modem processor 1052, a power management unit 1054, an interconnect / bus module 1064, multiple millimeter wave transceivers 1056, memory 1058, and various additional processors 1060, such as an application processor, a packet processor, etc.

[0115] Each processor 1010, 1012, 1014, 1016, 1018, 1052, 1060 may include one or more cores and one or more temperature sensors, and each processor / core may perform operations independently of other processors / cores. For example, the first SOC 602 may include a processor that executes a first type of operating system (such as FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (such as MICROSOFT WINDOWS10). In addition, any or all of the processors 1010, 1012, 1014, 1016, 1018, 1052, 1060 may be included as part of a processor cluster architecture (such as a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0116] The first SOC 602 and the second SOC 604 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 1024 of the first SOC 602 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on control cluster devices. System components and resources 1024 and / or custom circuits 1022 may also include circuits for docking with peripheral devices (such as cameras, electronic displays, wireless communication devices, external memory chips, etc.).

[0117] The first SOC 602 and the second SOC 604 may communicate via an interconnect / bus module 1050. The various processors 1010, 1012, 1014, 1016, 1018 may be interconnected to one or more memory elements 1020, system components and resources 1024, and custom circuits 1022, and a thermal management unit 1032 via an interconnect / bus module 1026. Similarly, the processor 1052 may be interconnected to a power management unit 1054, a millimeter wave transceiver 1056, a memory 1058, and various additional processors 1060 via an interconnect / bus module 1064. The interconnect / bus modules 1026, 1050, 1064 may include an array of reconfigurable logic gates and / or implement a bus architecture (such as CoreConnect, AMBA, etc.). Communications may be provided by an advanced interconnect, such as a high-performance network on chip (NoC).

[0118] The first SOC 602 and / or the second SOC 604 may also include an input / output module 1068 for communicating with resources external to the SOC, such as a clock 1006 and a voltage regulator 1008. Resources external to the SOC, such as a clock 1006, a voltage regulator 1008, may be shared by two or more of the internal SOC processors / cores. In addition to the example SIP 1000 discussed above, some implementations may also be implemented in a variety of computing systems that may include a single processor, multiple processors, a multi-core processor, or any combination thereof.

[0119] The processor controlling the cluster device and the network server 1000 may be any programmable microprocessor, microcomputer, or one or more multi-processor chips that can be configured by software instructions (applications) to perform a variety of functions including some of the specific implementations described below. In some wireless devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions within the SOC 604 and one processor dedicated to running other applications within the SOC 602. Software applications may be stored in the memory 712 and then accessed and loaded into the processor. The processor may include an internal memory sufficient to store application software instructions.

[0120] The various implementations illustrated and described are provided merely as examples of illustrating the various features of the claims. However, the features shown and described for any given implementation are not necessarily limited to the associated implementation and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one example implementation. For example, Figure 8 and Fig. 9 One or more of the methods and operations may be replaced or combined Figure 8 and Fig. 9 One or more operations in the methods and operations.

[0121] Specific implementation examples are described in the following paragraphs. Although some of the specific implementation examples in the following specific implementation examples are described in terms of example methods, other example implementation examples may include: the example methods discussed in the following paragraphs implemented by a device (e.g., a wireless device), the device including a processor configured with processor-executable instructions to perform the operations of the methods of the following specific implementation examples; the example methods discussed in the following paragraphs implemented by a device including components for performing the functions of the methods of the following specific implementation examples; and the example methods discussed in the following paragraphs may be implemented on a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the device to perform the operations of the methods of the following specific implementation examples.

[0122] Embodiment 1. A method for rotating control node roles between devices in a control cluster of a wireless mesh network, the method comprising: identifying a control node assumption timing in a schedule stored on a first device within the control cluster, the control node assumption timing defining when the first device is scheduled to assume the control node role of the wireless mesh network from a second device in the control cluster; and assuming the control node role by the first device based on the control node assumption timing in the schedule, the control node role comprising sending periodic messages to support the wireless mesh network.

[0123] Embodiment 2. According to the method described in Embodiment 1, the method further includes: identifying the control node role end timing in the schedule stored on the first device; identifying a third device in the control cluster that will assume the control node role based on the schedule; monitoring extended notifications from the third device after the control node role end timing indicates that the third device has assumed the control node role; sending the periodic messages after the control node role end timing until the extended notification from the third device is received; and upon receiving the extended notification from the third device, assuming the passive node role of listening to the periodic messages from the third device after the control node role end timing; or continuing the control node role when no extended notification is received from the third device.

[0124] Embodiment 3. A method according to embodiment 2, wherein continuing the control node role when no extended notification is received from the third device also includes: identifying a fourth device in the control cluster that will assume the control node role based on the scheduling; adjusting the scheduling to shift the control node assumption timing of the fourth device; requesting a premature transfer of the control node role; receiving confirmation of the shift of the control node assumption timing from the fourth device; monitoring periodic notifications from the fourth device after the confirmation indicates that the fourth device has assumed the control node role; and upon receiving the periodic notifications from the fourth device, assuming the control node role of listening for periodic messages from the third device after the control node role end timing.

[0125] Embodiment 4. The method according to embodiment 2, wherein continuing the control node role when no extension notification is received from the third device further comprises: continuing the control node role until the scheduling provides another device of the control cluster to assume the control node role.

[0126] Embodiment 5. According to the method described in any one of Embodiments 1 to 4, the method further includes: receiving multiple attributes from a device during organization of the mesh network; identifying multiple devices within the mesh network that are suitable for the control cluster based on the received multiple attributes; compiling the schedule for transferring the control node role between the multiple devices of the control cluster; storing the schedule in the memory of the first device; and communicating the schedule to each of the multiple devices of the control cluster for storage.

[0127] Embodiment 6. According to the method described in any one of Embodiments 1 to 5, the method further includes: collaborating with one or more devices among the multiple devices of the control cluster to identify a sequence of control node role assignments, wherein the first device is a member of the control cluster, and wherein at least two devices among the multiple devices of the control cluster are identified in the schedule stored on the first device.

[0128] Embodiment 7. A method according to any one of embodiments 1 to 6, wherein the multiple attributes include at least one attribute related to suitability for serving in the control cluster, the at least one attribute being selected from: battery charge; expected battery life; proximity to other devices in the cluster; transceiver battery usage; or operating power mode.

[0129] Embodiment 8. According to the method described in any one of Embodiments 1 to 7, the method further includes: receiving one or more consensus inputs from the multiple devices of the control cluster to define the scheduling, and the one or more consensus inputs are related to the order of transferring the control node roles in the control cluster.

[0130] Embodiment 9: According to any one of embodiments 1 to 8, the method further comprises: sending a plurality of attributes from the first device to other devices in the control cluster.

[0131] As used in this application, the terms "component", "module", "system", etc. are intended to include computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software being executed, which are configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, or a computer. By way of example, both an application running on a wireless device and a wireless device can be referred to as a component. One or more components may reside within a process or a thread of execution, and a component may be localized on a processor or core or distributed between two or more processors or cores. In addition, these components may be executed from various non-transitory computer-readable media having various instructions or data structures stored thereon. Each component may communicate via local or remote processes, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, or process-related communication methodologies.

[0132] Several different cellular and mobile communication services and standards are available and are contemplated in the future, all of which can be implemented and benefit from various implementations. Such services and standards include, for example, the Third Generation Partnership Project (3GPP), Long Term Evolution (LTE) system, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G) and later generation 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling and / or content messages. It should be understood that any reference to terminology and / or technical details related to individual telecommunication standards or technologies is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

[0133] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. In addition, any reference to a claim element in the singular form (e.g., a reference using the article "one," "an," or "the") should not be interpreted as limiting the element to the singular.

[0134] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The technician may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0135] The hardware for implementing the various exemplary logic components, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed with a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof designed to perform the functions described herein. Although a general purpose processor may be a microprocessor, in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver smart objects, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.

[0136] In one or more embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transient computer-readable storage medium or a non-transient processor-readable storage medium. The operation of the method or algorithm disclosed herein may be implemented in a processor-executable software module or a processor-executable instruction, which may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and without limitation, such non-transient computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage device, magnetic disk storage device or other magnetic storage smart object, or any other medium that can be used to store the required program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical discs reproduce data optically with lasers. The above combinations are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable storage medium and / or computer-readable storage medium, which may be incorporated into a computer program product.

[0137] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but should be accorded the broadest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for rotating control node roles between devices in a control cluster of a wireless mesh network, the method comprising: identifying a control node assumption timing in a schedule stored on a first device within the control cluster, the control node assumption timing defining when the first device is scheduled to assume the control node role of the wireless mesh network from a second device of the control cluster; as well as The control node role is assumed by the first device based on the control node assuming timing in the schedule, the control node role including sending periodic messages to support the wireless mesh network.

2. The method according to claim 1, further comprising: Identify an end timing of a control node role in the schedule stored on the first device; identifying a third device in the control cluster that will assume the control node role based on the scheduling; monitoring an extended notification from the third device after the control node role end timing indicates that the third device has assumed the control node role; sending the periodic message after the control node role ends timing until the extended notification from the third device is received; as well as Upon receiving the extended notification from the third device, assuming the passive node role of listening to periodic messages from the third device after the control node role ends timing; or The control node role is continued when no extended notification is received from the third device.

3. The method of claim 2, wherein continuing the control node role when no extended notification is received from the third device further comprises: identifying a fourth device in the control cluster that will assume the control node role based on the scheduling; adjusting the scheduling to shift the control node of the fourth device to assume timing; Requesting a premature transfer of the control node role; receiving, from the fourth device, confirmation of the shift in timing undertaken by the control node; monitoring periodic notifications from the fourth device after the confirmation indicates that the fourth device has assumed the control node role; as well as Upon receiving the periodic notification from the fourth device, the control node assumes the role of the control node that listens to the periodic message from the third device after the control node role ends timing.

4. The method of claim 2, wherein continuing the control node role when no extended notification is received from the third device further comprises: The control node role continues until the scheduling provides another device of the control cluster to assume the control node role.

5. The method according to claim 1, further comprising: receiving a plurality of attributes from a device during organization of the mesh network; identifying a plurality of devices within the mesh network applicable to the control cluster based on the received plurality of attributes; compiling the schedule for transferring the control node role between the plurality of devices of the control cluster; storing the schedule in a memory of the first device; as well as The schedule is communicated to each device of the plurality of devices of the control cluster for storage.

6. The method according to claim 5, further comprising: Collaborate with one or more of the plurality of devices of the control cluster to identify a sequence of control node role assignments, wherein the first device is a member of the control cluster, and wherein at least two of the plurality of devices of the control cluster are identified in the schedule stored on the first device.

7. The method of claim 5, wherein the plurality of attributes includes at least one attribute related to suitability for serving in the control cluster, the at least one attribute selected from: Battery level; Expected battery life; Proximity to other devices of the cluster; Transceiver battery usage; or Operating power mode.

8. The method according to claim 5, further comprising: One or more consensus inputs are received from the plurality of devices of the control cluster to define the schedule, the one or more consensus inputs relating to an order in which to transfer the control node roles in the control cluster.

9. The method according to claim 5, further comprising: A plurality of attributes is sent from the first device to other devices in the control cluster.

10. A device, comprising: Bluetooth transceiver; Memory; and a processor coupled to the Bluetooth transceiver and the memory and configured to: identifying a control node assumption timing in a schedule stored in the memory, the control node assumption timing defining when the device is scheduled to assume a control node role of a wireless mesh network from a second device in a control cluster of the mesh network; as well as Assuming the control node role of the wireless mesh network based on the control node assumption timing in the schedule, the control node role includes sending periodic messages to support the wireless mesh network.

11. The apparatus of claim 10, wherein the processor is further configured to: identifying an end timing of a control node role in the schedule stored in the memory; identifying a third device in the control cluster that will assume the control node role based on the scheduling; monitoring an extended notification from the third device after the control node role ends timing, wherein the received extended notification indicates that the third device has assumed the control node role; sending the periodic message after the control node role ends timing until the extended notification is received from the third device; and Upon receiving the extended notification from the third device, assuming the passive node role of listening to periodic messages from the third device after the control node role ends timing; or The control node role is continued when no extended notification is received from the third device.

12. The device according to claim 11, wherein the processor is further configured to continue the control node role by the following process when no extended notification is received from the third device: identifying a fourth device in the control cluster that will assume the control node role based on the scheduling; adjusting the scheduling to shift the control node of the fourth device to assume timing; Requesting a premature transfer of the control node role; receiving, from the fourth device, confirmation of the shift in timing undertaken by the control node; monitoring periodic notifications from the fourth device after the confirmation indicates that the fourth device has assumed the control node role; as well as Upon receiving the periodic notification from the fourth device, the control node assumes the role of the control node that listens to the periodic message from the third device after the control node role ends timing.

13. The device according to claim 11, wherein the processor is further configured to continue the control node role by the following process when no extension notification is received from the third device: The control node role continues until the scheduling provides another device of the control cluster to assume the control node role.

14. The apparatus of claim 10, wherein the processor is further configured to: receiving a plurality of attributes from a device during organization of the mesh network; identifying a plurality of devices within the mesh network applicable to the control cluster based on the received plurality of attributes; compiling the schedule for transferring the control node role between the plurality of devices of the control cluster; storing the schedule in the memory; as well as The schedule is communicated to each of the devices of the control cluster for storage.

15. The apparatus of claim 14, wherein the processor is further configured to: and cooperating with one or more of the plurality of devices of the control cluster to identify a sequence of control node role assignments, wherein at least two of the devices of the control cluster are identified in the schedule stored in the memory.

16. The apparatus of claim 14, wherein the plurality of attributes includes at least one attribute related to suitability for serving in the control cluster, the at least one attribute selected from: Battery level; Expected battery life; Proximity to other devices of the cluster; Transceiver battery usage; or Operating power mode.

17. The apparatus of claim 14, wherein the processor is further configured to: One or more consensus inputs are received from the plurality of devices of the control cluster to define the schedule, the one or more consensus inputs relating to an order in which to transfer the control node roles in the control cluster.

18. The apparatus of claim 14, wherein the processor is further configured to: A plurality of attributes are sent to other devices in the control cluster.

19. A device, comprising: means for identifying a control node assumption timing in a schedule stored in a memory, the control node assumption timing defining when the device is scheduled to assume a control node role of a wireless mesh network from a second device in a control cluster of the mesh network; as well as Means for assuming the control node role of the wireless mesh network based on the control node assumption timing in the schedule, the control node role comprising sending periodic messages to support the wireless mesh network.

20. The device according to claim 19, further comprising: means for identifying an end timing of a control node role in said schedule stored in said memory; means for identifying a third device in the control cluster that will assume the control node role based on the scheduling; means for monitoring an extended notification from the third device after the control node role ends timing, wherein receipt of the extended notification indicates that the third device has assumed the control node role; means for sending the periodic message after the control node role ends timing until the extended notification from the third device is received; a component for assuming a passive node role of listening to periodic messages from the third device after the control node role ends timing upon receiving the extended notification from the third device; as well as Means for continuing said control node role when no extended notification is received from said third device.

21. The device of claim 20, wherein the means for continuing the control node role when no extended advertisement is received from the third device comprises: means for identifying a fourth device in the control cluster that will assume the control node role based on the scheduling; means for adjusting the scheduling to shift the control node of the fourth device to assume timing; means for requesting a premature transfer of said control node role; means for receiving from said fourth device an acknowledgement of said shift in timing undertaken by said control node; means for monitoring periodic notifications from the fourth device after the confirmation indicates that the fourth device has assumed the control node role; as well as means for assuming the control node role of listening to periodic messages from the third device after the control node role end timing when the periodic notification from the fourth device is received.

22. The device of claim 20, wherein the means for continuing the control node role when no extended advertisement is received from the third device comprises: Means for continuing the control node role until the scheduling provides another device of the control cluster to assume the control node role.

23. The device of claim 19, further comprising: means for receiving a plurality of attributes from a device during organization of said mesh network; means for identifying a plurality of devices within the mesh network applicable to the control cluster based on the received plurality of attributes; means for compiling the schedule for transferring the control node role between the plurality of devices of the control cluster; means for storing said schedule in said memory; as well as Means for communicating the schedule to each of the devices of the control cluster for storage.

24. The device according to claim 23, further comprising: Means for cooperating with one or more of the plurality of devices of the control cluster to identify a sequence of control node role assignments, wherein at least two of the devices of the control cluster are identified in the schedule stored in the memory.

25. The apparatus of claim 23, wherein the plurality of attributes includes at least one attribute related to suitability for serving in the control cluster, the at least one attribute selected from: Battery level; Expected battery life; Proximity to other devices of the cluster; Transceiver battery usage; or Operating power mode.

26. The device of claim 23, further comprising: Means for receiving one or more consensus inputs from the plurality of devices of the control cluster to define the schedule, the one or more consensus inputs relating to an order for transferring the control node roles in the control cluster.

27. The device of claim 23, further comprising: Means for sending a plurality of attributes to other devices in the control cluster.

28. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of a device for use in a wireless mesh network to perform operations comprising: identifying a control node assumption timing in a schedule stored in a memory, the control node assumption timing defining when the device is scheduled to assume a control node role of the wireless mesh network from a second device in a control cluster of the mesh network; and Assuming the control node role of the wireless mesh network based on the control node assumption timing in the schedule, the control node role includes sending periodic messages to support the wireless mesh network.

29. The non-transitory processor-readable medium of claim 28, wherein the stored processor-executable instructions are configured to cause the processor of the device for use in the wireless mesh network to perform operations further comprising: Identify the control node role end timing in the schedule stored in the memory; identifying a third device in the control cluster that will assume the control node role based on the scheduling; monitoring an extended notification from the third device after the control node role ends timing, wherein the received extended notification indicates that the third device has assumed the control node role; sending the periodic message after the control node role ends timing until the extended notification from the third device is received; Upon receiving the extended notification from the third device, assuming a passive node role of listening to periodic messages from the third device after the control node role ends timing; and The control node role is continued when no extended notification is received from the third device.

Citation Information

Cited By

  • Emergency state communication method and system of law enforcement recorder

    CN121218236A

  • An emergency communication method and system for law enforcement recorders

    CN121218236B