WO2022188869A1 - System and method for implementing relay nodes in a wireless network - Google Patents

System and method for implementing relay nodes in a wireless network Download PDF

Info

Publication number
WO2022188869A1
WO2022188869A1 PCT/CN2022/080399 CN2022080399W WO2022188869A1 WO 2022188869 A1 WO2022188869 A1 WO 2022188869A1 CN 2022080399 W CN2022080399 W CN 2022080399W WO 2022188869 A1 WO2022188869 A1 WO 2022188869A1
Authority
WO
WIPO (PCT)
Prior art keywords
relay
state
node
crn
neighbors
Prior art date
Application number
PCT/CN2022/080399
Other languages
English (en)
French (fr)
Inventor
Qing AN
Wenbing Chen
Original Assignee
Alibaba (China) Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba (China) Co., Ltd. filed Critical Alibaba (China) Co., Ltd.
Publication of WO2022188869A1 publication Critical patent/WO2022188869A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • This disclosure is generally related to wireless communication technologies. More specifically, this disclosure is related to a wireless communication network that includes a number of relay nodes.
  • Bluetooth Special Interest Group SIG
  • BLE Bluetooth Low Energy
  • Bluetooth Mesh enables the creation of large-scale device networks by implementing mesh topologies and supporting multi-hop connections, thus expanding the coverage area of a Bluetooth network. It is ideally suited for control, monitoring, and automation systems where hundreds, or thousands of devices need to communicate with one another, such as in smart homes or smart buildings that implement Internet of Things (IoT) technologies.
  • IoT Internet of Things
  • Bluetooth Mesh standard operates on a flood network principle where nodes in the network communicate with each other by sending messages. More specifically, each node in the network broadcasts to other nodes in the network messages (referred to as broadcast messages) ; after receiving a broadcast message, other nodes in the network may relay (or re-broadcast) the broadcast message until the destination node receives the broadcast message. In current Bluetooth Mesh networks, many invalid or unnecessary messages may be transmitted in the network, which may negatively affect the throughput of the network.
  • the system can obtain relay-state information associated with a plurality of neighboring nodes of a respective node in the wireless network.
  • the system can identify, among the plurality of neighboring nodes, a set of relay neighbors capable of relaying messages based on the obtained relay-state information and determine a connectivity status of the set of relay neighbors.
  • the system can then determine an expected relay state of the respective node based on a count and the connectivity status of the set of relay neighbors and can adjust a relay state of the respective node based on the expected relay state.
  • obtaining the relay-state information can include receiving a relay-state message from a respective neighboring node, and the relay-state message can include address information, a relay-state indicator, and neighbor information associated with the respective neighboring node.
  • the system in response to determining that the respective neighboring node is a relay neighbor based on the relay-state information, can store an entry corresponding to the respective neighboring node in a neighbor list maintained by the respective node. The system can further update the entry in response to receiving a subsequent relay-state message from the respective neighboring node.
  • the entry can include a timestamp associated with the relay-state message.
  • the system can delete the expired entry.
  • the system can send a state-request message to a corresponding neighboring node.
  • updating the entry can include deleting the entry from the neighbor list in response to determining, based on the relay-state indicator included in the subsequent relay-state message, that the relay state of the respective neighboring node is “off. ”
  • determining the expected relay state can include determining that the expected relay state is “on, ” in response to determining that the count of the set of relay neighbors equals or exceeds a predetermined neighbor threshold and that the set of relay neighbors are all relay neighbors of each other.
  • the system in response to detecting frequent flooding events in the wireless network, can decrement the neighbor threshold.
  • the system can periodically send relay-state messages and adjust a period for sending the relay-state messages based on a number of previously sent relay-state messages.
  • determining the expected relay state can include periodically executing a relay-decision operation, and a period for executing the relay-decision operation can be adjusted based on a number of previously executed relay-decision operations.
  • adjusting the relay state can include sending a relay-configuration message from a centralized controller to the respective node to instruct the respective node to adjust the relay state.
  • FIG. 1 illustrates an exemplary network with controllable relay nodes, according to one embodiment.
  • FIG. 2 presents a flowchart illustrating an exemplary process for broadcasting a relay-state message, according to one embodiment.
  • FIG. 3 presents a flowchart illustrating an exemplary process for receiving a relay-state message, according to one embodiment.
  • FIG. 4A presents a flowchart illustrating an exemplary process for making a relay decision, according to one embodiment.
  • FIG. 4B presents a flowchart illustrating an alternative process for making a relay decision, according to one embodiment.
  • FIG. 5 presents a flowchart illustrating an exemplary process for executing the relay-decision operation, according to one embodiment.
  • FIG. 6 presents a flowchart illustrating an exemplary process for detecting flooding events in the network, according to one embodiment.
  • FIG. 7 presents a flowchart illustrating an exemplary process for checking the validity of entries in the neighbor list, according to one embodiment.
  • FIG. 8 illustrates an exemplary mesh network with a centralized controller node, according to one embodiment.
  • FIG. 9 illustrates an exemplary application scenario, according to one embodiment.
  • FIG. 10 illustrates an exemplary communication process in a Bluetooth Mesh network, according to one embodiment.
  • FIG. 11 illustrates a block diagram of an exemplary controllable relay node (CRN) , according to one embodiment.
  • CRN controllable relay node
  • FIG. 12 illustrates an exemplary computer and communication system that facilitates relaying messages in a wireless network, according to one embodiment.
  • the disclosed embodiments provide a Bluetooth network that implements controllable or configurable relay nodes, where the relay state of the nodes can be controlled or configured automatically, either in a distributed manner or in a centralized manner.
  • a controllable or configurable relay node When a controllable or configurable relay node is in a relay-on state, it can re-transmit received broadcast messages, thus extending the Bluetooth communication range.
  • each controllable or configurable relay node can adjust its relay state (e.g., turning on or off its relay function) based on the connectivity status and the relay states of its neighboring controllable or configurable relay nodes.
  • the number of nodes in the network performing the relay operation can be controlled dynamically according to the real-time topology of the Bluetooth network, such that there are neither too many nor too few of them.
  • This approach not only can reduce the amount of invalid or unnecessary retransmission of broadcast messages (thus increasing throughput) but also can ensure the connectivity of the Bluetooth network.
  • a Bluetooth Mesh network may implement a direct forwarding mechanism by provisioning a subset of nodes as relay nodes with relay functionalities.
  • Each relay node can maintain, through path-discovery, a source address-destination address mapping table.
  • the above approach has two main shortcomings.
  • Second, the above approach cannot timely detect changes in the network topology. For example, a node on the relay path may be powered down or may change its location, and such a change may not be detected and may result in packet-forwarding failures.
  • the relay function of one or more nodes in a wireless mesh network can be dynamically activated or deactivated based on the current network topology as well as the relay state of their neighboring nodes.
  • FIG. 1 illustrates an exemplary network with controllable relay nodes, according to one embodiment.
  • a wireless network 100 can include a plurality of nodes, including controllable or configurable relay nodes (CRNs) (e.g., CRNs 102, 104, 106, and 108) and nodes without relay functions (also known as non-relay nodes or NRNs) (e.g. NRNs 110-120) .
  • CRNs controllable or configurable relay nodes
  • NRNs also known as non-relay nodes or NRNs
  • wireless network 100 is a Bluetooth Mesh network with each node being a Bluetooth-enabled device capable of communicating with other nodes in network 100 according to the Bluetooth standard.
  • Bluetooth-enabled devices can include but are not limited to: Bluetooth mobile phones, Bluetooth earphones, Bluetooth speakers, Bluetooth switches, Bluetooth televisions, Bluetooth lights, Bluetooth bracelets, etc.
  • a number of versions of the Bluetooth standard have been developed, including Bluetooth 1.0, Bluetooth 2.0, Bluetooth 3.0, and Bluetooth 4.0.
  • Various nodes in network 100 may support the same or different versions of the Bluetooth standard. The scope of this disclosure is not limited by the type or version of the communication standard implemented at each node.
  • the various nodes in network 100 are coupled to each other wirelessly, forming a mesh topology.
  • the scope of this disclosure is not limited by the topology of the network.
  • These coupled nodes may also form different topologies, including but not limited to: a star topology, a tree topology, a ring topology, a mesh topology, etc.
  • An NRN refers to a node without packet-retransmission capabilities.
  • Network 100 can include at least one NRN that is communicatively coupled to one or more CRNs (e.g., via Bluetooth communication links) .
  • An NRN can operate in a broadcast mode, meaning that it can receive and transmit, within its signal coverage range, Bluetooth broadcast messages.
  • Current versions of Bluetooth standards all support the broadcast mode, meaning that a Bluetooth device supporting any version of the Bluetooth standard can be used as an NRN. Therefore, although a hardware-limited Bluetooth device may not support higher versions of the Bluetooth standard, it can still be part of network 100, and it can extend its communication range with the assistance of the relay function of the CRNs. It is also possible for a hardware-advanced Bluetooth device to serve as an NRN.
  • a CRN refers to a node capable of retransmitting messages received from NRNs or other CRNs, and the relay function of the CRN can be controlled (i.e., activated or deactivated) .
  • Network 100 can include at least two CRNs that are communicatively coupled to each other. The communicative coupling between any pair of CRNs can be direct or indirect.
  • CRNs can be coupled to each other via Bluetooth communication links.
  • the Bluetooth standard supported by a CRN needs to support the network interconnect and relay functions, such as Bluetooth 4.0 or a higher version.
  • a typical CRN can be a Bluetooth device with better computing capabilities, such as Bluetooth mobile phones, Bluetooth televisions, Bluetooth speakers, etc.
  • a CRN can also communicate with other CRNs or NRNs. If the other communication party (either a CRN or an NRN) is within the coverage range of the Bluetooth signals of a particular CRN, the particular CRN can directly communicate with the other communication party; otherwise, the particular CRN can indirectly communicate with the other communication party with the assistance of the relay function of surrounding CRNs. Similarly, an NRN can communicate with other NRNs or CRNs. If the other communication party (either an NRN or a CRN) is within the coverage range of the Bluetooth signals of a particular NRN, the particular NRN can directly communicate with the other communication party; otherwise, the particular NRN can indirectly communicate with the other communication party with the assistance of the relay function of surrounding CRNs.
  • CRN 102 is inside its signal coverage area, whereas CRN 108 and NRN 120 are both outside of its signal coverage area.
  • CRN 102 needs the assistance of the relay function of CRN 102. More specifically, NRN 112 broadcasts messages to network 100, and CRN 102, which is within the signal coverage area of NRN 112, receives the broadcast message. CRN 102 determines that it is not the recipient of the broadcast message and then re-broadcasts the message to network 100.
  • CRN 108 or NRN 120 may then process the received messages.
  • nodes e.g., higher version Bluetooth devices
  • nodes operating in the broadcast mode can be configured as NRNs.
  • an NRN With the assistance of the relay function of the CRNs, an NRN is able to communicate with other NRNs or CRNs outside of its signal coverage area, thus extending the Bluetooth communication range.
  • Bluetooth devices configured as NRNs only need to support the Bluetooth broadcast functions.
  • the hardware requirement for the NRNs is low and not limited by the hardware capability of the Bluetooth devices.
  • different NRNs can be separately coupled to different CRNs, such that the communication load on each CRN is relatively low, thus lowering the power consumption of each CRN.
  • a CRN can adjust its relay state, such as turning on or off its relay function, based on the relay state and the connectivity status of its neighboring CRNs.
  • the relay state of a CRN is “on, ” the CRN is considered active and is capable of relaying messages; when the relay state of a CRN is “off, ” the CRN is considered inactive and cannot relay messages.
  • a CRN when a CRN is in a “relay-off” or inactive state, it functions similarly as an NRN and operates in the broadcast mode (i.e., it can receive and send messages but cannot relay messages) .
  • CRNs 102 and 108 have adjusted their relay state from “on” to “off, ” and CRNs 104 and 106 have adjusted their relay state from “off” to “on. ”
  • the number of active CRNs can be adjusted dynamically according to the real-time topology of the network. This way, at any given time, the number of active CRNs is neither too many nor too few, thus reducing the amount of invalid and unnecessary retransmission of Bluetooth messages, increasing the network throughput while maintaining the connectivity of the network.
  • the neighboring CRNs of a particular CRN can be its one-hop, two-hop, three-hop, or multi-hop neighbors. In one embodiment, neighboring CRNs of a particular CRN can be its one-hop neighbors. In the example shown in FIG. 1, CRNs 102 and 104 can be the neighbor of each other.
  • each CRN can determine whether to turn “on” or “off” its relay function based on the relay states of its neighboring CRNs. To do so, each CRN needs to broadcast its relay state to the network.
  • each node in the network can broadcast relay-state messages to the network and can also receive relay-state messages from other nodes in the network. Information included in a relay-state message can include whether the node is relay-enabled, the number of its neighboring relay nodes, and the addresses of the neighboring relay nodes. Table I presents an exemplary format of a relay-state message.
  • Each relay-state message can include at least two fields.
  • the relay-state-indicator field indicates the relay state of the node sending the message
  • the neighboring-relay-node-address-list (NbRelayAddrList) field includes the addresses of neighboring active CRNs.
  • the relay-state-indicator field can be one-byte long, with 0x00 indicating the relay state being “off” (or the CRN being inactive) and 0x01 indicating the relay state being “on” (or the CRN being active) .
  • the length of the relay-neighbor-address-list field can be between zero and five bytes and can include up to five addresses. Note that each node may maintain a list of 10 active CRN neighbors. If the number of active CRN neighbors of a node is greater than 5, addresses of those active CRN neighbors may be included in two separate relay-state messages.
  • each node in the network can periodically broadcast relay-state messages to the network.
  • the period for broadcasting the relay-state messages can be determined based on practical needs. In one embodiment, the default period can be 60 seconds.
  • a node can broadcast its relay-state message to the network in response to a predetermined trigger condition being met.
  • the predetermined trigger condition can include but is not limited to: the node being powered on, the node joining the network, the configuration of the node being updated, a change in the topology of the network being detected, etc.
  • a random delay (e.g., between 0 and 60 seconds) can be added the first time a node broadcasts the relay-state message to prevent the situation where two nodes simultaneously receive relay-state messages and both decide to turn off their relay function.
  • the time to live (TTL) value of the relay-state message can be set as 0, such that the relay-state message can only be received by the one-hop or immediate neighbors of the sending node.
  • the TTL of the relay-state message can be set as 1 or 2 to allow the two-and/or three-hop neighbors to receive the message.
  • each node can also actively monitor the relay state of its neighbors. More specifically, a node can determine if it has received a relay-state message from its neighboring node within a predetermined time internal. The time interval can be determined based on practical needs. In one embodiment, the default setting can be 70 seconds. If no relay-state message from its neighboring node is received within the interval, the node can send a state-request message to its neighboring node. In some embodiments, the state-request message can be a unicast message with the destination address being the address of the neighboring node. Upon receiving the state-request message, the neighboring node can respond with a relay-state message to report its relay state.
  • a node can be configured to scan its relay neighbors by periodically broadcasting state-request messages to the network.
  • a node when a predetermined trigger condition is met, a node can start to scan its relay neighbors by broadcasting the state-request message to the network.
  • the predetermined trigger condition can include but is not limited to: the node being powered on, the node joining the network, the configuration of the node being updated, a change in the topology of the network being detected, etc.
  • FIG. 2 presents a flowchart illustrating an exemplary process for broadcasting a relay-state message, according to one embodiment.
  • a node is powered on or joins the network (operation 202) .
  • a first delay is applied (operation 204) before the node broadcasts an initial relay-state message to the network (operation 206) .
  • the first delay can include a predetermined first relay-state-broadcast period and a random time delay.
  • the default first relay-state-broadcast period can be 60 seconds
  • the random time delay can be between 0 and 60 seconds.
  • the newly powered or connected CRN can first turn off its relay function before broadcasting its relay-state messages, thus ensuring that the existing active CRNs remain in a prolonged stable state.
  • the added random delay at the beginning of the broadcast can prevent the situation where multiple nodes are simultaneously powered on and are sending relay-state messages, which may cause congestion in the network and may possibly lead to instabilities.
  • the node determines whether a relay-state-message-counter value exceeds a predetermined threshold (operation 208) .
  • the counter value indicates the number of relay-state messages that have been sent by the newly powered or joined node.
  • the threshold value can be between 5 and 10. In one embodiment, the threshold value can be 10. Other threshold values are also possible. If the counter value is greater than the threshold, the node can determine a second delay as the time interval for broadcasting additional relay-state messages (operation 210) . In some embodiments, the second delay can be the first predetermined relay-state-broadcast period (e.g., 60 seconds) .
  • the node can determine a third delay as the time interval for broadcasting additional relay-state messages (operation 212) .
  • the third delay can be a second predetermined relay-state-broadcast period, which can be smaller than the first predetermined relay-state-broadcast period.
  • the second predetermined relay-state-broadcast period can be half of the first predetermined relay-state-broadcast period.
  • the default value of the second predetermined relay-state-broadcast period can be 30 seconds. Other values are also possible.
  • the second predetermined relay-state-broadcast period can be one-fourth, one-third, two-thirds, three-fourths, etc., of the first predetermined relay-state-broadcast period.
  • a newly powered or connected node may broadcast an initial set of relay-state messages at a faster rate, thus allowing its neighbors to learn its relay state faster, thereby facilitating the faster election of active CRNs and the maintaining of the network stability.
  • the node After broadcasting the initial set of relay-state messages, the node can broadcast subsequent relay-state messages at a slower rate.
  • the rate of broadcasting relay-state messages may be decreased further after a second set of relay-state messages.
  • the node can determine whether the number of stored relay neighbors is greater than a threshold value (operation 214) .
  • the threshold value can be five.
  • each node can store up to a predetermined number (e.g., 10) of relay neighbors (which are active CRNs) ; however, due to the size limit of Bluetooth Mesh messages, each relay-state message can only list a smaller number (e.g., five) of addresses.
  • the node can divide the relay neighbor address information into multiple (e.g., two) relay-state messages in order to include address information of all of its relay neighbors (operation 216) .
  • the node can subsequently broadcast the relay-state message (s) after the determined time interval (e.g., the second or third delay) and can increment the counter (operation 218) .
  • the process then returns to operation 208.
  • the newly powered or newly joined node broadcasts relay-state messages after an initial delay.
  • a node adjusts its relay state (e.g., from “on” to “off” or from “off” to “on” ) , it needs to broadcast its current relay state to its neighbors immediately (i.e., without delay) . In such a situation, the process starts from operation 206.
  • Each CRN in the network can maintain a relay-neighbor list that stores information of neighboring active CRNs.
  • each entry in the relay-neighbor list can correspond to a neighboring active CRN and can include relay information associated with the active CRN.
  • the relay information associated with an active CRN can include information that can uniquely identify the active CRN, including but not limited to: an Internet protocol (IP) address, a media-control-access (MAC) address, a node identifier, etc.
  • the relay information of the active CRN can also include its neighbor information (e.g., the identifiers of its relay neighbors) .
  • the neighbor information of a CRN is included in the relay-state message sent (either through broadcasting or unicasting) by the CRN. To indicate the freshness of the neighbor information, each entry in the relay-neighbor list also includes the timestamp of the relay-state message comprising such neighbor information.
  • Table II presents an exemplary format of a locally stored neighbor list of a CRN.
  • the locally stored neighbor list of a CRN includes four entries, with each entry corresponding to a relay neighbor, including nodes A0, A1, A2, and A3.
  • a relay neighbor refers to a CRN node in a “relay-on” or active state.
  • a relay neighbor can be a one-hop neighbor or a multi-hop neighbor.
  • a one-hop neighbor refers to a node within the Bluetooth signal range.
  • the number of entries in the neighbor list can be limited (e.g., limited by the memory size) .
  • the neighbor list can have up to ten entries, and additional relay neighbors may not be included in the neighbor list.
  • newly discovered relay neighbors may replace older relay neighbors (e.g., based on the timestamps) .
  • Each entry in the neighbor list can include the address (e.g., the IP or MAC address) of a relay neighbor, the timestamp of the last relay-state message received from the relay neighbor, and the neighbor information included in the last relay-state message.
  • the first entry of Table II includes the address of a node A0, a timestamp (Time_1) of the last relay-state message received from node A0, and relay neighbors (identified as nodes A1, A2, and A3) of node A0.
  • the second entry indicates that the relay neighbors of node A1 include nodes A0, A2, and A4; the third entry indicates that the relay neighbors of node A2 include nodes A0, A1, and A4; and the fourth entry indicates that the relay neighbors of node A3 include nodes A0, A5, and A6.
  • each node receives relay-state messages from its neighbor nodes continuously, the locally stored neighbor list is continuously updated based on the received relay-state messages. For example, each time the node receives a relay-state message from a neighbor node, it can check the locally stored neighbor list to determine whether the neighbor node has a corresponding entry. If a corresponding entry exists and the relay-state message indicates that the neighbor node has disabled its relay function, then the corresponding entry is deleted from the neighbor list. If the corresponding entry exists, and the relay-state message indicates that the neighbor node remains active, then the corresponding entry is updated based on the timestamp of the newly received relay-state message and neighbor information included in the newly received relay-state message.
  • an entry corresponding to the neighbor node is added to the locally stored neighbor list.
  • an existing entry with the oldest timestamp may be deleted to allow the newly discovered relay neighbor to be added to the neighbor list.
  • FIG. 3 presents a flowchart illustrating an exemplary process for receiving a relay-state message, according to one embodiment.
  • a node receives a relay-state message from a neighbor node (operation 302) and determines whether the relay state of the neighbor node is “on” (operation 304) .
  • the receiving node checks the relay-state-indicator field of the received relay-state message. If the relay-state-indicator field has a value of “0X00, ” the neighbor node is in a relay-off state or it is inactive; if the relay-state-indicator field has a value of “0X01, ” the neighbor node is in a relay-on state, or it is active.
  • the receiving node determines whether there is an entry in its locally stored neighbor list corresponding to the neighbor node (operation 306) . For example, the receiving node can compare the source address of the relay-state message with neighbor addresses listed in the locally stored neighbor list. If a corresponding entry is found, the receiving node deletes the corresponding entry from its locally stored neighbor list and decrements a counter that counts the number of entries in the list (operation 308) , and the process ends. Note that this counter value corresponds to the number of relay neighbors of the receiving node and can be used in operation 214 shown in FIG. 2. If a corresponding entry is not found, the receiving node discards the relay-state message (operation 310) , and the process ends.
  • the receiving node determines whether the signal strength of the neighbor node is greater than a predetermined threshold (operation 312) . For example, the receiving node can compare the received signal strength indicator (RSSI) of the relay-state message with the predetermined threshold. If the signal strength is smaller than the threshold, the receiving node discards the relay-state message (operation 310) , and the process ends.
  • RSSI received signal strength indicator
  • a node only considers neighbor nodes with good signals (e.g., RSSI greater than a threshold) as potential relay neighbors and disregards neighbor nodes with poor signals.
  • the receiving node determines whether there is an entry in its locally stored neighbor list corresponding to the neighbor node (operation 314) . If so, the receiving node updates the corresponding entry based on the received relay-state message (operation 316) , and the process ends. Updating the corresponding entry can include updating the timestamp of the entry and the neighbor information included in the entry.
  • the receiving node determines whether the locally stored neighbor list is full (operation 318) .
  • the locally stored neighbor list may be an array stored in a buffer with a predetermined depth. If the buffer is full, the receiving node may delete an entry in the buffer with the oldest timestamp and may add a new entry corresponding to the neighbor node sending the relay-state message (operation 320) , and the process ends. If the locally stored neighbor list is not full, the receiving node can add a new entry corresponding to the neighbor node sending the relay-state message to the list and can increment the counter that counts the number of entries in the list, which corresponds to the number of relay neighbors (operation 322) , and the process ends. Note that this counter value can be used in operation 214 shown in FIG. 2.
  • a CRN may perform a validity-check operation on each entry based on the timestamp of the entry. For example, the CRN can obtain a time difference by comparing the timestamp of an entry and the current time and can determine whether the time difference equals or is greater than a predetermined expiration threshold. If so, the CRN can determine that the entry has expired and can delete the entry from the neighbor list. If the time difference is less than the expiration threshold, the CRN can further determine if the time difference equals or is greater than a predetermined broadcast interval. If so, the CRN can determine that, although the entry is not yet expired, its update is overdue.
  • the CRN can send a state-request message to the corresponding neighbor, requesting the corresponding neighbor to send a relay-state message to refresh the entry.
  • Being able to delete expired entries is important to ensure that a failed node can be detected and replaced in a timely manner. For example, if a CRN has a device failure, it may stop sending relay-state messages to its neighbors, resulting in the expiration of the corresponding entry. After the neighbors delete the failed CRN from their neighbor list, one or more of the neighbors may decide to turn on their relay function so that they can replace the failed CRN to perform the needed message-relay services.
  • a node e.g., a CRN
  • a node can send relay-state messages to its neighbors and can also receive relay-state messages from its neighbors.
  • the timing of sending and receiving relay-state messages can be arbitrary.
  • a node can first send a relay-state message to its neighbors and then can receive a relay-state message from one of its neighbors, or vice versa.
  • the node receives relay-state messages from its neighbors before sending out its own relay-state messages.
  • Each CRN in the network can dynamically adjust its relay state (i.e., turning on or off its relay function) based on information included in the locally stored neighbor list.
  • changes of such information can reflect changes in the network, including topology changes (e.g., a node may be powered off or a new node may join the network) and relay-state changes (e.g., an active CRN becomes inactive or vice versa) .
  • the CRN can execute a relay-decision algorithm to determine whether to adjust its relay state.
  • a CRN determines that the number of its relay neighbors (i.e., active neighboring CRNs) exceeds or equals a predetermined threshold and these relay neighbors are all connected (e.g., they are also neighbors of each other) , the CRN may turn off its relay function. Otherwise, the CRN may turn on its relay function.
  • a state-adjust-protection interval can be introduced after the CRN adjusts its relay state. During the state-adjust-protection interval, the CRN cannot execute the relay-decision algorithm. The duration of the state-adjust-protection interval can be selected based on practical needs. In some embodiments, the default state-adjust-protection interval can be 120 seconds.
  • a CRN may determine the connectivity status among its relay neighbors based on the neighbor information in the locally stored neighbor list. In one embodiment, the CRN may compare two entries in the neighbor list to determine whether it is the only relay node connecting the two corresponding neighbors. If so, the CRN may need to ensure that its relay function is turned on or remains on.
  • the CRN (which can be referred to as node A) storing the list can determine that its neighbor A0 is also a neighbor (e.g., a one-hop neighbor) of A1, A2, and A3; and based on the second entry, node A can also determine that its neighbor A1 is also a neighbor of A0, A2, and A4. Accordingly, node A can determine that A1 and A2 are neighbors (e.g., one-hop neighbors) of each other and communication between A1 and A2 does not rely on A. On the other hand, by comparing the second and fourth entries, node A can determine that A3 is not a neighbor of A1. Hence, communication between A3 and A1 relies on the relay function of node A. In such a situation, node A needs to remain active (or in the relay-on state) .
  • a CRN A0 can have neighboring CRNs A1-A3, where A1 and A2 are active and A3 is inactive.
  • CRN A0 can send relay-state messages to CRNs A1-A3, the relay-state message including the relay state of A0 and information associated with its active neighbors A1 and A2.
  • Such information can include the address information and/or an identifier that can uniquely identify a node in the network.
  • nodes A1-A3 each can send its own relay-state messages to its neighboring CRNs; and A0 can also receive relay-state messages from A1-A3.
  • a relay-state message sent by CRN A0 and CRNs A1-A3 can be written as: A0: 1, (A1, A2) ; A1: 1, (A0, A2, A4) ; A2: 1, (A0, A1, A3) ; A3: 0, (A0, A2, A6) , respectively, where “0” indicates that the sending node is in the relay-off state and “1” indicates that the sending node is in the relay-on state.
  • the nodes included in the parentheses are the active neighboring CRNs of the sending CRN.
  • a particular CRN can obtain, based on the relay-state messages sent by its neighbors, not only the relay states of its neighbors but also information regarding a number of target CRNs.
  • a target CRN refers to an active neighbor of a neighbor of the particular CRN.
  • it receives the following relay-state messages: A0: 1, (A1, A2) ; A1: 1, (A0, A2, A4) ; A2: 1, (A0, A1, A3) ; A3: 0, (A0, A2, A6) .
  • relay message A1 1, (A0, A2, A4) as an example, the message indicates that, with regard to A0, A1 is a neighboring CRN in the relay-on state and A2 and A4 are target CRNs.
  • relay message A3: 0, (A0, A2, A6) as an example the message indicates that, with regard to A0, A3 is a neighboring CRN in the relay-off state and A2 and A6 are target CRNs.
  • the particular CRN can determine the connectivity among its neighboring CRNs. For example, by comparing the relay-state messages received by A0, A0 can determine that A1 and A2 are neighbors, and A2 and A3 are neighbors.
  • A0 can also determine that A1 and A3 are not neighbors. Hence, if CRN A0 turns off its relay function, A1 and A3 will not be able to communicate.
  • a CRN determines, based on the relay-state information and the connectivity status of its neighbors, that the CRN is the only relay node on the path between two of its neighbors, the CRN needs to turn on its relay function or remain in the relay-on state.
  • the CRN determines that all of its neighbors are neighbors of each other (i.e., they are all connected) , meaning that those neighbors can communicate with each other without the relay function of the CRN, then the CRN can turn off its relay function or remain in the relay-off state.
  • an essential CRN should switch to or remain in the relay-on state and a redundant CRN can switch to or remain in the relay-off state.
  • FIG. 4A presents a flowchart illustrating an exemplary process for making a relay decision, according to one embodiment.
  • a CRN determines whether it is currently within a state-adjust-protection interval (operation 402) .
  • the CRN determines whether its relay state has been adjusted recently (e.g., within the last two minutes) based on a recorded time of the most recent state-adjustment operation. If so, the CRN waits for the expiration of the state-adjust-protection interval. If not, the CRN determines whether its relay function is turned on (operation 404) .
  • the CRN determines whether the number of relay neighbors equals or exceeds a predetermined threshold and whether these relay neighbors are all connected (operation 406) .
  • the CRN can determine the number of its relay neighbors and the connectivity status of its relay neighbors based on information included in its locally stored neighbor list, such as the neighbor list shown in Table II. If the number of relay neighbors equals or exceeds the predetermined threshold and these relay neighbors are all connected, the CRN can determine that it is redundant and can then turn off its relay function (operation 408) . Otherwise, the CRN determines that it is not redundant and will keep its relay function on (operation 410) .
  • the CRN subsequently updates the recorded time of the most recent state-adjustment operation and broadcasts a relay-state message to the network (operation 412) . Note that the broadcast relay-state message indicates the newly adjusted relay-state of the CRN.
  • the CRN determines whether the number of relay neighbors is less than a predetermined threshold and whether there is at least one pair of relay neighbors that are not connected (operation 414) . If not, the CRN turns on its relay function (operation 416) . Otherwise, the CRN remains in the relay-off state (operation 418) . The CRN subsequently updates the recorded time of the most recent state-adjustment operation and broadcasts a relay-state message to the network (operation 412) .
  • FIG. 4B presents a flowchart illustrating an alternative process for making a relay decision, according to one embodiment.
  • a CRN determines the number of its relay neighbors and the connectivity among its relay neighbors (operation 422) . Such determination can be made based on information included in the locally stored neighbor list.
  • the CRN determines whether the connectivity status of its relay neighbors meets a predetermined connectivity condition (operation 424) .
  • the predetermined connectivity condition can be that all relay neighbors are one-hop neighbors of each other (or all relay neighbors are directly connected to each other) .
  • the CRN determines whether it is in a relay-on state (operation 426) . If not, the CRN adjusts its relay state from relay-off to relay-on (operation 428) . Otherwise, the CRN maintains its relay-on state (operation 430) .
  • the CRN determines whether the total number of its relay neighbors equals or exceeds a predetermined threshold value (operation 432) .
  • the threshold value can depend on the scale of the network. In one embodiment, the threshold value can be five. Other values are also possible, such as eight, ten, etc. If the total number of its relay neighbors is less than the threshold, the process goes to operation 426. Otherwise, the process goes to operation 434, where the CRN determines its relay state. If the relay state is off, the CRN remains in the relay-off state (operation 436) . If the relay state is on, the CRN turns off its relay function (operation 438) .
  • the CRN updates the recorded time of the most recent state-adjustment operation and broadcasts a relay-state message to the network (operation 440) .
  • a CRN is expected to be in a “relay-on” state if it is considered essential and in a “relay-off” state if it is considered redundant. More specifically, a CRN is considered redundant if the number of its relay neighbors equals or exceeds a threshold and if all of its relay neighbors are directly connected to each other (e.g., any relay neighbor is also a one-hop neighbor of any other relay neighbor) .
  • a CRN may periodically execute the relay-decision operation.
  • the interval between consecutive executions of the relay-decision operation can be adjusted. For example, when a node is powered on or joins the network, it may execute the relay-decision operation at a higher rate to reduce the time needed for electing active CRNs, thus enhancing the stability of the network.
  • FIG. 5 presents a flowchart illustrating an exemplary process for executing the relay-decision operation, according to one embodiment.
  • a random delay can be applied when the time for performing an initial relay-decision operation arrives (operation 502) .
  • an initial relay-decision operation is needed to set the relay state of the node. Applying the random delay prevents the situation where multiple newly powered or joined nodes perform the relay-decision simultaneously.
  • the random delay can be between 0 and 60 seconds.
  • the node executes the initial relay-decision operation (operation 504) .
  • the relay-decision operation can be similar to the process shown in FIG. 4A or 4B.
  • the node determines whether a count of the previously executed relay-decision operations is smaller than a threshold (operation 506) .
  • the threshold value can be 10. Other values (e.g., 5, 8, 15, etc. ) are also possible. If the number of previously executed relay-decision operations is smaller than the threshold, the node can set a first relay-decision interval (operation 508) . Otherwise, the node can set a second relay-decision interval (operation 510) .
  • the second relay-decision interval can be the default interval (e.g., 70 seconds) for performing relay-decision operations.
  • the first relay-decision interval is smaller than the second relay-decision interval to ensure that the node executes the relay-decision operation at a higher rate at the beginning of being powered on or joining the network.
  • the first relay-decision interval can be half, one-third, or one-fourth, etc., of the second relay-decision interval.
  • the first relay-decision interval can be 10 seconds. The node subsequently performs the relay-decision operation after the interval and increments the count of the executed relay-decision operations (operation 512) .
  • each time a node adjusts its relay state it enters a state-adjust-protection interval, during which the node does not adjust its relay state to prevent the relay state from being adjusted too frequently, which may cause network instability.
  • the state-adjust-protection interval is typically much longer than the first or second relay-decision interval set during operation 508 or 510, respectively. Hence, if a relay-decision operation is scheduled to occur during the state-adjust-protection interval, the node can skip the relay-decision operation until the expiration of the state-adjust-protection interval.
  • each CRN can set a flooding indicator (e.g., a flood_flag field) to indicate that flooding has been detected.
  • a flooding indicator e.g., a flood_flag field
  • each CRN can include a relay buffer for temporarily storing to-be-relayed messages.
  • an active CRN When an active CRN receives a broadcast message, it may determine whether it is the destination of the message. If not, the CRN is configured to relay (or re-broadcast) the message. Before relaying the message, the CRN can check its relay buffer to determine whether the relay buffer has a copy of the message. If so, the CRN can discard the received message. If not, the CRN stores the message in its relay buffer.
  • the size of the relay buffer can be designed to meet the buffering need under normal network operating conditions. However, when flooding occurs in the network, the CRN may receive many to-be-relayed messages, which can cause overflow of its relay buffer.
  • a CRN may clear the relay buffer (e.g., delete all messages) or may delete older messages from the relay buffer.
  • the relay buffer may frequently overflow.
  • the system can adjust the relay neighbor threshold value, which is used in the operations shown in FIG. 4A and FIG. 4B. More specifically, the relay neighbor threshold value can decrement by one each time a flooding event is detected until a minimum value is reached.
  • the default relay neighbor threshold value can be five and the minimum value of the relay neighbor threshold can be three.
  • the relay neighbor threshold can decrement by one until it reaches the minimum value of three.
  • the reduced relay neighbor threshold value may lead to the reduction of active CRNs in the network, thus reducing the number of messages being relayed.
  • the minimum relay neighbor threshold value can ensure sufficient relay coverage in the network.
  • FIG. 6 presents a flowchart illustrating an exemplary process for detecting flooding events in the network, according to one embodiment.
  • the CRN receives a to-be-relayed message (operation 602) and determines whether it is out of relay buffer (operation 604) . If not, the CRN buffers the message (operation 606) and continues to receive to-be-relayed messages (operation 602) .
  • the CRN can determine whether a time interval between two consecutive out-of-relay-buffer events is less than a threshold (operation 606) . If not, the CRN determines that the out-of-relay-buffer event is not caused by flooding and resets a counter of the out-of-relay-buffer events to zero (operation 608) and continues to receive to-be-relayed messages (operation 602) . Otherwise, the CRN increments the counter of the out-of-relay-buffer events (operation 610) .
  • the threshold for the time interval between two consecutive out-of-relay-buffer events can be determined based on practical applications. In one embodiment, the threshold can be three seconds.
  • the CRN determines whether the counter value of the out-of-relay-buffer events exceeds a predetermined threshold (e.g., three) (operation 612) . If so, the CRN detects flooding and sets the flooding indicator to “1” (operation 614) . The CRN increments a counter of the flooding events (operation 616) and determines whether the value of the flooding-event counter equals or exceeds a predetermined threshold (e.g., two) (operation 618) . If so, the CRN decrements the relay neighbor threshold value by one until a minimum value is reached (operation 622) . The CRN subsequently updates a time recording of the out-of-buffer event (operation 624) .
  • a predetermined threshold e.g., three
  • FIG. 7 presents a flowchart illustrating an exemplary process for checking the validity of entries in the neighbor list, according to one embodiment.
  • a random delay can be applied (operation 702) .
  • the random delay can be between 0 and 60 seconds. Applying the random delay can prevent multiple CRNs from turning off their relay functions simultaneously.
  • a CRN can determine whether its flooding indicator is set and whether a time interval from the most recent out-of-buffer event is less than a predetermined threshold (e.g., three seconds) (operation 704) . If so, the CRN turns off its relay function and clears the flooding indicator (i.e., sets it to “0” ) (operation 706) . The CRN subsequently updates the recorded time of the most recent state-adjustment operation and broadcasts a relay-state message to the network (operation 708) .
  • a predetermined threshold e.g., three seconds
  • the CRN checks the timestamp of an entry in its locally stored neighbor list to determine whether the entry has expired (operation 710) . If so, the entry is deleted from the neighbor list (operation 712) .
  • the entry expiration time can be 90 seconds, which is typically longer than the broadcast interval of relay-state messages.
  • the CRN can determine whether an interval since the last update of the entry exceeds a time threshold (i.e., whether an update is overdue) (operation 714) .
  • the time threshold can be longer than the broadcast interval of relay-state messages but shorter than the entry expiration time. In some embodiments, the time threshold for updating an entry can be 70 seconds. If the entry has not been updated after this time threshold, the CRN can send a state-request message to the corresponding relay neighbor to request its relay state and neighbor information (operation 716) .
  • the CRN determines whether the entry is the last entry in the neighbor list (operation 718) . If not, the CRN checks the validity of the next entry (operation 710) . If all entries have been checked, the CRN increments a counter for the validity-checking operation (operation 720) and then returns to operation 704.
  • a centralized-control mechanism can also be used to control the relay state of CRNs in the network.
  • the wireless network can include a centralized controller, which can reside in the gateway of the network, the cloud-based network control platform, or a node with a higher processing power.
  • FIG. 8 illustrates an exemplary network with a centralized controller node, according to one embodiment.
  • a network 800 can include a plurality of CRNs (e.g., CRN 802) , a plurality of NRNs (e.g., NRN 804) , and a centralized controller node 806.
  • the CRNs and NRNs in network 800 can be similar to the CRNs and NRNs in network 100 shown in FIG. 1.
  • Centralized controller node 806 can be a computing device with a relatively better processing capability than low energy Bluetooth devices.
  • Centralized controller node 806 can include terminal devices (e.g., a smartphone, a personal computer (PC) , a wearable device, a gateway of the Bluetooth network, etc. ) and servers (e.g., a standalone server, a server array or cluster, a cloud server, etc. ) .
  • Centralized controller node 806 can be responsible for receiving relay-state messages from all nodes in the network and for making relay decisions for all nodes in the network.
  • centralized controller node 806 can determine which CRNs should be placed in the relay-on state and which CRNs should be placed in the relay-off state.
  • the centralized control node can maintain a neighbor list for each CRN and can update the neighbor lists based on relay-state messages received from the CRNs.
  • centralized controller node 806 can send relay-configuration messages to the CRNs.
  • a relay-configuration message can include relay-configuration parameters associated with the relay function of a CRN.
  • the relay-configuration parameters can include but are not limited to: the relay-function enable signal, the interval for broadcasting relay-state messages, the interval for making a relay decision, the signal-strength threshold, the neighbor-list entry expiration threshold, the neighbor-list entry update threshold, the state-adjust-protection interval, etc.
  • a CRN may adjust its relay-configuration parameters according to current changes in the network. Therefore, in addition to sending the relay-configuration messages to CRNs in the network, centralized controller node 806 can also send relay-configuration-request messages to the CRNs, requesting the CRNs to report their current relay-configuration parameters. In some embodiments, the CRNs can send relay-configuration-response messages to centralized controller node 806. The relay-configuration-response message can include the current relay-configuration parameters implemented by the CRN.
  • a relay-configuration-request message sent by centralized controller node 806 can include a set of parameter identifiers to specify a set of relay-configuration parameters to be included in the corresponding relay-configuration-response message.
  • the parameter identifier can include the name, ID, or serial number, etc., of a parameter, which can be used to identify a certain relay-configuration parameter.
  • the format of the relay-configuration message (which sets the configuration parameters of a CRN) and the relay-configuration-response message (which reports the current configuration parameters implemented by a CRN) can be similar.
  • Table III presents the exemplary format of a relay-configuration-response message.
  • the relay-configuration messages can also be used in the distributed control scenario.
  • the CRNs may be configured according to the Bluetooth Mesh Foundation models (e.g., the Configuration Client model) .
  • a CRN may be preconfigured by its manufacturer or may be configured by the user when it first joins the network.
  • network 800 can also include one or more conventional relay nodes, such as relay node 808.
  • a conventional relay node refers to a relay node that cannot be configured or controlled to turn on or off its relay function. Instead, a conventional relay node will always relay messages from other nodes, including CRNs, NRNs, or other conventional relay nodes.
  • This disclosure does not limit the network topology formed by the CRNs, NRNs, and conventional relay nodes.
  • the CRNs, NRNs, and conventional relay nodes can form a star topology, a tree topology, a ring topology, a mesh topology, etc.
  • FIG. 9 illustrates an exemplary application scenario, according to one embodiment.
  • the Bluetooth network is used in the setting of a smart home.
  • a smart home network 900 can include a plurality of Bluetooth devices supporting Bluetooth Mesh standard. More specifically, a number of devices, including a smart speaker 902, a laptop computer 904, a smartphone 906, and a smart TV 908, can function as CRNs, whereas other devices, including switches 910 and 912, a home alarm 914, a light 916, a water heater 918, and a smart refrigerator 920, can function as NRNs.
  • a router 922 can be the gateway of smart home network 900 and can establish a communication link to a cloud server 924.
  • cloud server 924 can be the centralized controller node in smart home network 900 and can be responsible for configuring and controlling all nodes, including all CRNs in the network.
  • the NRNs including switches 910 and 912, home alarm 914, light 916, water heater 918, and smart refrigerator 920, can join smart home network 900 by sending a network-join request and by completing the network configuration operation to become Bluetooth nodes.
  • a user can issue a voice command to smart speaker 902, the voice command specifying an object of the command and a to-be-performed action.
  • a user can issue a voice command “turn on the light” to smart speaker 902.
  • smart speaker 902 can determine that the object of the command is light 916 and the action is “turn on. ”
  • Smart speaker 902 can then broadcast a Bluetooth message for turning on light 916.
  • Smart TV 908 is the one-hop neighbor of smart speaker 902 and is an active CRN.
  • smart TV 908 relays (e.g., re-broadcasts) the message to network 900.
  • Light 916 is the one-hop neighbor of smart TV 908 and can receive the “turn on the light” message relayed by smart TV 908. In response, light 916 can perform the action of turning on.
  • the wireless network is a Bluetooth Mesh network.
  • a wireless network can implement one of the following protocols: the infrared (IR) protocol, the ultra-wideband (UWB) protocol, the near-field communication (NFC) protocol, the Wi-Fi protocol, etc.
  • the wireless network can include CRNs and NRNs, with the CRNs being capable of turning on or off their relay functions. When its relay function is turned on, a CRN is able to relay packets (e.g., via broadcasting) to other nodes in the network.
  • each CRN can dynamically adjust its relay state based on relay-state packets received from its neighbors.
  • a relay-state message sent by a CRN includes the sending CRN’s relay-state information as well as information associated with its relay neighbors (which are neighboring CRNs in the relay-on state) .
  • a CRN Based on the received relay-state packets, a CRN can identify its relay neighbors and can determine their connectivity status. When a CRN has a sufficient number of relay neighbors and when these relay neighbors are also neighbors of each other, the CRN may be considered redundant and can turn off its relay function. This way, the number of CRNs that actively relay packets can be kept to a minimum value, thus significantly reducing the amount of unnecessary relay traffic, increasing the throughput of the network.
  • FIG. 10 illustrates an exemplary communication process in a Bluetooth Mesh network, according to one embodiment.
  • a CRN receives a plurality of relay-state messages from a plurality of CRNs in the network (operation 1002) .
  • the CRN can identify its relay neighbors (operation 1004) .
  • the relay neighbors are neighboring CRNs that are in a relay-on state.
  • the relay neighbors of a CRN are neighboring nodes that can relay messages sent by the CRN.
  • the CRN can determine the connectivity status of its relay neighbors (operation 1006) .
  • the CRN can maintain a neighbor list, with different entries in the neighbor list corresponding to different relay neighbors.
  • a respective neighbor entry can include address information as well as neighbor information (e.g., relay neighbors) associated with the corresponding relay neighbor.
  • the connectivity status of the relay neighbors can be determined by comparing the corresponding entries in the neighbor list.
  • the connectivity status of the relay neighbors can be all connected (meaning that the relay neighbors are also immediate neighbors of each other) or partially connected (meaning that there are at least two relay neighbors not directly connected) .
  • the CRN continuously receives relay-state messages and can continuously update its neighbor list.
  • the CRN can adjust its relay state (turn on or turn off its relay function) (operation 1008) .
  • the CRN can execute a relay-decision operation to determine an expected relay state ( “relay-on” or “relay-off” ) and can then adjust its relay state accordingly. For example, if the expected relay state is “on” and the CRN is currently off, then the CRN can turn on its relay function, and vice versa. If the expected relay state and the current relay state are the same, the CRN can maintain its current relay state. Because the relay neighbors and their connectivity status are dynamic, the CRN dynamically adjusts its relay state to meet the traffic demand of the network.
  • the CRN can receive a data message from the network (operation 1010) and determines whether it is the intended recipient (operation 1012) . If so, the CRN processes the message (operation 1014) . If not, the CRN can determine whether it is active (or in the relay-on state) (operation 1016) . If so, the CRN relays the message (operation 1018) . For example, the CRN may re-broadcast the message to the network to allow its neighbors to receive the message. If the CRN is inactive, it is not able to relay the message and will discard the message (operation 1020) .
  • all operations can be performed by the CRN, including receiving relay-state messages (operation 1002) , identifying the relay neighbors (operation 1004) , determining their connectivity status (operation 1006) , and adjusting the relay state (operation 1008) .
  • these operations can be performed by a centralized controller, which receives relay-state messages from all CRNs (operation 1002) .
  • the centralized controller can identify its relay neighbors (operation 1004) , determine the connectivity status of these relay neighbors (1006) , and then adjust the relay state of the CRN (operation 1008) .
  • FIG. 11 illustrates a block diagram of an exemplary controllable relay node (CRN) , according to one embodiment.
  • a CRN 1100 can include a transmitting module 1102, a receiving module 1104, a relay-state-message-processing module 1106, a neighbor-list database 1108, a neighbor-list-updating module 1110, a relay-state-adjusting module 1112, a flood-monitoring module 1114, and a configuration module 1116.
  • CRN 1100 can be a node in a wireless network that is capable of relaying messages received from other nodes in the network.
  • the wireless network is a Bluetooth Mesh network and CRN 1100 is a Bluetooth node that supports the Bluetooth Mesh standards.
  • Transmitting module 1102 is responsible for transmitting packets/messages to the network.
  • Receiving module 1104 is responsible for receiving packets/messages from the network.
  • transmitting module 1102 and receiving module 1104 can be part of a Bluetooth radio and can transmit/receive messages according to various Bluetooth standards.
  • the transmitted and received messages can include both data messages and control messages. Examples of the control messages can include relay-state messages, state-request messages, relay-configuration messages, relay-configuration-request messages, relay-configuration-response messages, etc.
  • Relay-state-message-processing module 1106 can be responsible for processing received relay-state messages.
  • the TTL value of the relay-state messages is configured such that relay-state messages can only be received by the neighbors (e.g., one-hop neighbors) of the sending CRN.
  • Relay-state-message-processing module 1106 can timestamp and parse each received relay-state message to obtain relay-state information as well as relay-neighbor information associated with the sender of the relay-state message.
  • Neighbor-list database 1108 stores a neighbor list, with each entry in the list corresponding to a current relay neighbor of CRN 1100. More specifically, a neighbor-list entry can include a neighbor identifier, a timestamp, and a list of relay neighbors of the corresponding neighbor. Information in the neighbor list can be obtained from relay-state-message-processing module 1106.
  • Neighbor-list-updating module 1110 can be responsible for updating the neighbor list in neighbor-list database 1108. More specifically, neighbor-list-updating module 1110 can update entries in the neighbor list based on information provided by relay-state-message-processing module 1106. For example, relay-state-message-processing module 1106 may determine that the relay state of a previous relay neighbor has changed from “on” to “off. ” Accordingly, neighbor-list-updating module 1110 can delete the corresponding entry. Moreover, neighbor-list-updating module 1110 can periodically check the validity of entries in the neighbor list to determine whether to delete an entry or request that the entry be updated by the corresponding neighbor.
  • Relay-state-adjusting module 1112 can be responsible for making relay-state decisions.
  • relay-state-adjusting module 1112 can execute a relay-decision operation based on information included in the neighbor list. More specifically, relay-state-adjusting module 1112 can compare the count of relay neighbors with a threshold and can determine a connectivity status of the relay neighbors. Based on the count and the connectivity status, relay-state-adjusting module 1112 can adjust (e.g., turn “on” or “off” ) the relay state of CRN 1100.
  • relay-state-adjusting module 1112 When centralized control is used, relay-state-adjusting module 1112 does not need to execute the relay-decision operation; instead, relay-state-adjusting module 1112 can adjust the relay state of CRN 1100 based on a relay-configuration message sent from a centralized controller.
  • Flood-monitoring module 1114 can be responsible for monitoring flooding events in the network.
  • flood-monitoring module 1114 can monitor the relay buffer (not shown in FIG. 11) to determine whether flooding occurs in the network based on the counts and intervals of relay-buffer-overflow events.
  • relay-state-adjusting module 1112 can turn off the relay state of CRN 1100 to reduce the number of relay messages in the network.
  • flood-monitoring module 1114 detects frequent flooding, it can instruct relay-state-adjusting module 1112 to adjust certain parameters used during the relay-decision operation (e.g., decrementing the relay neighbor threshold) .
  • Configuration module 1116 can be responsible for configuring CRN 1100. For example, configuration module 1116 can receive, from the centralized controller, relay-configuration messages, which specify a number of parameters pertaining to the relay function. Alternatively, configuration module 1116 can also receive the relay-configuration parameters from users. If CRN 1110 includes a user input module (e.g., a touchscreen or a keyboard) , the user can directly send the relay-configuration parameters. If CRN 1110 does not include a user input module, a user may need to interact with configuration module 1116 via a controller device (e.g., a smartphone or a tablet computer) capable of receiving use input. In addition to receiving relay-configuration messages, configuration module 1116 can also receive relay-configuration-request messages that request the relay-configuration parameters implemented by CRN 1100. In response, configuration module 1116 can also send relay-configuration-response messages.
  • relay-configuration-response messages e.
  • FIG. 12 illustrates an exemplary computer and communication system that facilitates relaying messages in a wireless network, according to one embodiment.
  • Computer system 1200 includes a processor 1202, a memory 1204, and a storage device 1206.
  • computer system 1200 can be coupled to peripheral input/output (I/O) user devices 1210, e.g., a display device 1212, a keyboard 1214, and a pointing device 1216.
  • I/O peripheral input/output
  • Storage device 1206 can store an operating system 1218, a message-relay system 1220, and data 1240.
  • Computer system 1200 can be a node in a wireless network comprising a plurality of nodes.
  • Message-relay system 1220 can include instructions, which when executed by computer system 1200, can cause computer system 1200 or processor 1202 to perform methods and/or processes described in this disclosure.
  • message-relay system 1220 can include instructions for transmitting and receiving messages (transmitting/receiving module 1222) , instructions for processing received relay-state messages (relay-state-message-processing module 1224) , instructions for updating a neighbor list (neighbor-list-updating module 1226) , instructions for adjusting the relay state (relay-state-adjusting module 1228) , instructions for monitoring flooding events in the network (flood-monitoring module 1230) , and instructions for configuring the relay function (configuration module 1232) .
  • Data 1240 can include a neighbor list 1242.
  • each CRN in the network can periodically send relay-state messages to its neighbors and receive relay-state messages from its neighbors. Based on the received relay-state messages, each CRN can maintain a local neighbor list storing information associated with its relay neighbors. Based on information in the neighbor list, the CRN can determine whether its relay function is redundant, and if so, the CRN can turn off its relay function. This way, at any given time, the network has a minimum but sufficient number of active CRNs, thus reducing the number of unnecessary relay messages/packets in the network without negatively affecting connectivity.
  • the CRNs can dynamically adjust their relay state according to changes in the network.
  • the proposed system has a built-in fault tolerance mechanism such that, when a CRN is no longer available (e.g., due to device failure) , one or more different CRNs can be quickly activated to replace the relay function provided by the failure node, thus ensuring continuous connectivity and stability of the network.
  • the methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above.
  • a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.
  • the methods and processes described above can be included in hardware modules or apparatus.
  • the hardware modules or apparatus can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs) , dedicated or shared processors that execute a particular software module or a piece of code at a particular time, and other programmable-logic devices now known or later developed.
  • ASIC application-specific integrated circuit
  • FPGAs field-programmable gate arrays
  • dedicated or shared processors that execute a particular software module or a piece of code at a particular time
  • other programmable-logic devices now known or later developed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
PCT/CN2022/080399 2021-03-12 2022-03-11 System and method for implementing relay nodes in a wireless network WO2022188869A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202110272327.4A CN115086923A (zh) 2021-03-12 2021-03-12 蓝牙网络及其通信方法、设备和存储介质
CN202110272327.4 2021-03-12
US17/690,798 US20220295240A1 (en) 2021-03-12 2022-03-09 System and method for implementing relay nodes in a wireless network
US17/690,798 2022-03-09

Publications (1)

Publication Number Publication Date
WO2022188869A1 true WO2022188869A1 (en) 2022-09-15

Family

ID=83194183

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/080399 WO2022188869A1 (en) 2021-03-12 2022-03-11 System and method for implementing relay nodes in a wireless network

Country Status (3)

Country Link
US (1) US20220295240A1 (zh)
CN (1) CN115086923A (zh)
WO (1) WO2022188869A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115529647A (zh) * 2022-09-28 2022-12-27 南通大学 一种基于路径质量的负载均衡路由选择算法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105391483A (zh) * 2014-09-01 2016-03-09 佳能株式会社 通信装置及通信装置的控制方法
WO2020057730A1 (en) * 2018-09-18 2020-03-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods of and device for autonomous configuration of a relay node device in mesh network
CN111492622A (zh) * 2017-12-21 2020-08-04 皇家Kpn公司 确定何时在蜂窝通信网络中中继数据单元
CN112055343A (zh) * 2020-08-21 2020-12-08 北京小米移动软件有限公司 蓝牙Mesh网络泛洪方法、装置及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105391483A (zh) * 2014-09-01 2016-03-09 佳能株式会社 通信装置及通信装置的控制方法
CN111492622A (zh) * 2017-12-21 2020-08-04 皇家Kpn公司 确定何时在蜂窝通信网络中中继数据单元
WO2020057730A1 (en) * 2018-09-18 2020-03-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods of and device for autonomous configuration of a relay node device in mesh network
CN112055343A (zh) * 2020-08-21 2020-12-08 北京小米移动软件有限公司 蓝牙Mesh网络泛洪方法、装置及存储介质

Also Published As

Publication number Publication date
CN115086923A (zh) 2022-09-20
US20220295240A1 (en) 2022-09-15

Similar Documents

Publication Publication Date Title
US8064416B2 (en) Route selection in wireless networks
US9788257B2 (en) Method and system for dynamically forming service aware bluetooth low energy (BLE) mesh network
TWI487329B (zh) 在異質網路的操作方法及其閘道器與無線通信裝置
US9495326B2 (en) Providing communication path information in a hybrid communication network
US11290942B2 (en) System and method for independent dominating set (IDS) based routing in mobile AD hoc networks (MANET)
US20130003654A1 (en) Mesh Node Role Discovery and Automatic Recovery
KR20040097368A (ko) 애드-혹 네트워킹된 센서들 및 프로토콜들을 제공하기위한 방법 및 장치
US8089912B2 (en) Multicast communication method, accompanied with the relay node and wireless network system design
JP4976557B2 (ja) 無線通信ネットワークのノード及びルーティングテーブル更新間隔を調整する方法
JP2006287565A (ja) ワイヤレスセンサネットワークにおけるデータ送信方法
JP2009296435A (ja) 無線通信接続制御方法
WO2024001190A1 (zh) 消息发送方法、设备智能互联系统、相关设备及存储介质
WO2022188869A1 (en) System and method for implementing relay nodes in a wireless network
CN112423253A (zh) 应用于无线电子体温计的窄带自组网通信协议
TW202110266A (zh) 在網狀網路中之裝置之間共享之定向轉遞資訊
US10624017B2 (en) Method for operating a communication apparatus and communication apparatus
US11044771B2 (en) Method and device for sharing an established connection between a primary device and one of a plurality of secondary devices in a network
US20210051460A1 (en) Method for Discovering Device in Mesh Network
JP2014068203A (ja) 無線メッシュネットワークシステムおよび無線通信装置
WO2019120188A1 (zh) 一种自动切换通信方式的方法、终端及智能设备
WO2021146879A1 (zh) 消息传输的方法、ble设备和ble芯片
CN102595552B (zh) 基于自适应动态机制的无线分组网按需路由维护方法
JP7326230B2 (ja) 通信システム、ノード、通信方法及びプログラム
TWI689183B (zh) 適用於網狀網路之中繼器
US10932195B1 (en) Parent device shadow execution for a sleeping low power and lossy network child network device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22766391

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22766391

Country of ref document: EP

Kind code of ref document: A1