Method for multi-channel discovery with partially disjoint paths

Abstract

A method for multi-channel path discovery between a first node and a second node in a wireless mesh network, the method being performed by an intermediate node and comprising: the intermediate node receiving a path request for establishing a path between the first node and the second node, wherein the path request includes node count information related to the path between the first node and the second node; the intermediate node determining that the received node count information is less than or equal to node count information stored in a discovery table of the intermediate node corresponding to the path between the first node and the second node; and the intermediate node updating the stored node count information with the received node count information.

Description

[0001] This application is a divisional application of patent application filed on January 11, 2019, with application number 201980077462.4 and invention title "Method for Discovering Multi-Channel Paths with Partially Disjoint Paths". Technical Field

[0002] This invention generally relates to wireless communication networks, and more specifically to improvements in the forwarding of data messages in mesh networks such as Bluetooth mesh networks. Background Technology

[0003] Bluetooth TM Bluetooth typically refers to a standardized technology group that enables the exchange of data between devices over short distances using radio transmission and reception in the 2.4-GHz Industrial, Scientific, and Medical (ISM) band. The Bluetooth SIG oversees the development and management of standards through its various committees, and has over 30,000 member companies.

[0004] Bluetooth Low Energy (LE) is a specific version of Bluetooth technology first standardized by the Bluetooth Special Interest Group (SIG) in 2010. Bluetooth LE is typically targeted at low-power applications that allow for communication at lower speeds than, for example, more traditional Bluetooth applications. Furthermore, Bluetooth LE is suitable for inexpensive devices with limited memory and computing resources.

[0005] Even so, Bluetooth LE utilizes a robust frequency-hopping spread spectrum approach to transmit data on 40 channels. Furthermore, Bluetooth LE-compatible radios include multiple physical layer (PHY) options supporting data rates from 125 kb / s to 2 Mb / s, multiple power levels from 1 mW to 100 mW, and multiple security options.

[0006] Bluetooth LE also supports multiple network topologies, including a standard point-to-point topology for establishing one-to-one (1:1) communication between two devices. Additionally, Bluetooth LE supports broadcast (one-to-many, or 1:m) device communication. Broadcast topologies can be used for local information sharing and for location services such as retail points of interest information, indoor navigation and wayfinding, and item / asset tracking.

[0007] Finally, Bluetooth LE supports mesh topologies that can be used to establish many-to-many (m:m) device communication. Bluetooth LE-based mesh topologies enable the creation of large-scale device networks, such as control, monitoring, and automation systems where dozens, hundreds, or thousands of devices need to communicate reliably and securely with each other. In a Bluetooth LE mesh topology, each device in the mesh network can potentially communicate with every other device in the mesh network. Communication is implemented using messages, and devices can relay messages to other devices, extending end-to-end communication range far beyond the radio range of each individual device.

[0008] Devices part of a Bluetooth LE mesh network are often referred to as "nodes," while other devices not part of the mesh (e.g., even within mesh range) are often referred to as "unprovisioned devices." The process of converting an unprovisioned device into a node is often called "provisioning," and the device responsible for adding nodes to the network and configuring their behavior is often called the "provisioner." Provisioning is the secure process that causes unprovisioned devices to process a set of encryption keys known to the provisioner, such as tablets or smartphones.

[0009] As mentioned above, communication in a Bluetooth mesh network is "message-oriented" and various message types are defined. For example, a node can send an appropriate message type when it needs to query the status of other nodes or needs to control other nodes in some way. A node can also send an appropriate message type if it needs to report its status to other nodes. Messages must be sent from one address to another. Bluetooth mesh topology supports three different types of addresses. Unicast addresses uniquely identify a single element (e.g., a device may include one or more elements), and unicast addresses are assigned to devices during the configuration process. Group addresses are multicast addresses that represent one or more elements. Virtual addresses can be assigned to one or more elements across one or more nodes.

[0010] To further promote the use of Bluetooth LE in mesh topologies, the Bluetooth SIG released the Mesh Protocol Specification in July 2017. Figure 1 An exemplary layered mesh architecture based on Bluetooth LE, as illustrated by the Bluetooth SIG, is shown. At the top is the Model Layer, which defines models for standardizing operation in typical user scenarios, such as models for lighting and sensors. The Model Layer is further defined in other Bluetooth specifications, including the Bluetooth Mesh Model Specification. The Base Model Layer defines the states, messages, and models required for configuring and managing the mesh network. The Access Layer defines how higher-layer applications can use the upper transport layer. It defines the format of application data; it defines and controls the encryption and decryption of application data performed in the upper transport layer; and it checks whether incoming application data has been received in the correct network and application key context before forwarding it to higher layers.

[0011] The transport layer is further divided into the upper transport layer and the lower transport layer. The upper transport layer encrypts, decrypts, and verifies application data and is designed to provide confidentiality for access messages. It also defines how control messages transmitted between nodes are used to manage the upper transport layer, including when they are used by the "friend" feature. The lower transport layer defines how upper transport layer messages are segmented and reassembled into multiple lower transport protocol data units (PDUs) to deliver large upper transport layer messages to other nodes. It also defines the management of individual control messages that are segmented and reassembled.

[0012] The network layer defines how transmitted messages are addressed to one or more components. Its definition allows for the format of network messages transmitted by the bearer layer, including PDUs. The network layer decides whether to relay / forward messages, accept them for further processing, or reject them. It also defines how network messages are encrypted and authenticated. The bearer layer defines how network messages are transmitted between nodes. Two bearers are defined: the advertising bearer and the GATT bearer.

[0013] exist Figure 1 The bottom of the exemplary architecture shown is the Bluetooth LE radio layer. Figure 2 Bluetooth mesh network and Figure 1 The illustration shows an exemplary integration of the Bluetooth LE architecture. Figure 2 In the diagram, the shading indicates a box or layer that is part of the Bluetooth LE specification. At the bottom are the Bluetooth LE Physical (PHY) and Link layers, which are typically implemented in the Bluetooth controller. The layers above the Link layer are typically implemented on the Bluetooth host device. Figure 2 To the left is a higher layer of Bluetooth LE that can be used independently of mesh networking functionality. The unshaded box on the right above the link layer corresponds to... Figure 1 The mesh network architecture shown (plus distribution network). In this way, (in Figure 2 The application shown at the topmost layer can use both mesh and non-mesh functions of the underlying Bluetooth LE technology.

[0014] Currently, Bluetooth mesh networks are based on a "flooding" of broadcasts using a shared set of channels—advertising channels. Nodes acting as relay nodes in the Bluetooth mesh network scan for mesh messages. When a message is detected and received, the node checks if it is the message's destination. The message can be forwarded through the mesh network by retransmitting it so that the node's neighbors can receive it. Through this distributed mechanism, messages are forwarded from one node to one or more nodes in the network, enabling the message to reach its destination.

[0015] As described in version 1.0 of the Bluetooth Mesh specification, flooding has several drawbacks, including increased interference and power consumption, particularly as traffic levels in the network increase. Therefore, subsequent versions of the Bluetooth Mesh specification were intended to implement mechanisms that restrict packet forwarding to occur only along specific paths toward one or more intended receivers. This was expected to reduce traffic in directions where forwarding does not help improve the probability of successful delivery (and thus mitigate the aforementioned exemplary drawbacks).

[0016] Figure 3 The diagram illustrates a flooded message in an exemplary mesh network (e.g., a Bluetooth mesh network) comprising a source node (S), a destination node (D), and multiple relay nodes. (See also...) Figure 3 As can be seen, there are multiple copies of the message that arrives at the destination (D), thereby increasing the chance of successful reception by D through this redundancy.

[0017] One known technique for constructing forwarding paths between a source and one or more destinations is path discovery based on "ad hoc on-demand distance vectors (AODV)," as described in Request for Comment RFC 3561, published by the Internet Engineering Task Force (IETF). AODV can rapidly adapt to dynamic link conditions to determine unicast routes to destinations within an ad hoc network, while requiring relatively low processing and memory overhead and low network utilization. Furthermore, AODV uses destination sequence numbers to facilitate loop avoidance, even after the aberration delivery of routing control messages.

[0018] More specifically, the AODV method establishes paths using path request (also known as "route request") messages flooded by the originator and path response (also known as "route response") messages unicast back by the destination. Intermediate relays receiving the path response messages store the path information in a forwarding table and are eligible to forward packets. Sequence numbers (also known as "forwarding numbers") increment with each new path request message, and thus can be used to distinguish new path request messages from copies of path request messages already forwarded in the network.

[0019] Figure 4 An exemplary format of the Route Request (RREQ) message used in the AODV routing protocol described in RFC 3561 is shown. Figure 4 In the format shown, the source node generates a new sequence number and inserts it into the "Originator Sequence Number" field of the path request message, then uses relevant values ​​to populate other message fields as needed. Note that... Figure 4 The top 32-bit word shown includes a jump count field and a reserved field. Similarly, Figure 5 An exemplary format of the Route Response (RREP) message used in the AODV routing protocol as described in RFC 3561 is shown. Figure 5 In the format shown, the "destination sequence number" can correspond to the sequence number of the path request message. Note that... Figure 5 The top 32-bit word in the format shown also includes a jump count field and a reserved field.

[0020] Ultimately, AODV selects a single path between the source node and the destination node, such as... Figure 6 The exemplary mesh network shown is illustrated. However, due to the inherently lossy medium access technology and the low duty cycle (for reduced power consumption) of the underlying Bluetooth LE radio used in Bluetooth meshes, a single path may be insufficient to maintain a guaranteed success rate of reception. In other words, multiple paths may be required between the source and the destination, and these paths are at least partially disjoint and / or independent. Various challenges, problems, and / or drawbacks exist related to establishing multiple paths to meet these requirements. Summary of the Invention

[0021] Embodiments of this disclosure provide specific improvements to communication between nodes in a wireless mesh network, such as by providing novel techniques for establishing multiple (or redundant) independent paths between a source node and a destination node via multiple intermediate nodes in the mesh network. In this way, when used in a mesh network (e.g., a Bluetooth mesh network), embodiments can increase redundancy and / or reliability (e.g., compared to existing single-path AODV discovery), thereby improving the likelihood of successful message delivery to the destination in a wider range of deployment scenarios.

[0022] Some exemplary embodiments of this disclosure include methods and / or processes for multi-channel path discovery between a first node and a second node in a wireless mesh network. Exemplary methods and / or processes may be performed by intermediate nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, etc., or components thereof) in a wireless mesh network (e.g., a Bluetooth mesh network).

[0023] Exemplary methods and / or processes may include: receiving a path request for establishing a path between a first node and a second node, wherein the path request includes node count information related to the path between the first node and the second node. For example, the path request may be an Adaptive On-Demand Distance Vector (AODV) Route Request (RREQ) message. Exemplary methods and / or processes may further include: determining whether the received node count information is less than or equal to the node count information corresponding to the path between the first node and the second node stored in a discovery table of an intermediate node.

[0024] Exemplary methods and / or processes may further include performing further operations if it is determined that the received node count information is less than or equal to the stored node count information. In various embodiments, the further operations may include updating the stored node count information using the received node count information, determining whether the forwarding table of the intermediate node includes an entry corresponding to the path between the first node and the second node, and / or modifying the node count information in the path request based on whether the forwarding table includes an entry.

[0025] Other exemplary embodiments of this disclosure include other methods and / or processes for multi-channel path discovery between a first node and a second node in a wireless mesh network. Exemplary methods and / or processes may be performed by intermediate nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, etc., or components thereof) in a wireless mesh network (e.g., a Bluetooth mesh network).

[0026] These exemplary methods and / or processes may include: receiving a channel request for establishing a channel for a path between a first node and a second node, wherein the channel request includes a source address associated with the first node and a destination address associated with the second node. The exemplary methods and / or processes may further include: determining, based on the source address and destination address, whether a forwarding table stored by an intermediate node includes an entry corresponding to a path between the first node and the second node via the intermediate node. The exemplary methods and / or processes may further include: if it is determined that the forwarding table includes an entry, incrementing a value indicating the number of channels between the first node and the second node via the intermediate node.

[0027] In some embodiments, the exemplary method and / or process may further include: if it is determined that the forwarding table does not contain an entry, adding an entry to the forwarding table, wherein the added entry includes a source address, a destination address, and a value indicating that the number of channels between the first node and the second node via intermediate nodes is equal to one. In some embodiments, the exemplary method and / or process may further include: forwarding a channel request to one or more other nodes in the wireless mesh network. In some embodiments, the channel request may include an Adaptive On-Demand Distance Vector (AODV) Route Request (RREQ) message.

[0028] Other exemplary embodiments include wireless mesh network nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, or components thereof) configured to perform operations corresponding to the exemplary methods and / or processes described above. Other exemplary embodiments include a non-transitory computer-readable medium storing program instructions that, when executed by at least one processor, configure such a node to perform operations corresponding to the exemplary methods and / or processes described above.

[0029] These and other objectives, features, and advantages of the exemplary embodiments of this disclosure will become clear after reading the following detailed description of the exemplary embodiments of this disclosure. Attached Figure Description

[0030] Figure 1 An exemplary hierarchical mesh architecture based on Bluetooth LE, as illustrated by the Bluetooth SIG, is shown.

[0031] Figure 2 Bluetooth mesh network and Figure 1 An exemplary integration of the Bluetooth LE architecture is shown.

[0032] Figure 3 The diagram illustrates a flooded message in an exemplary mesh network, including a source node (S), a destination node (D), and multiple relay nodes.

[0033] Figure 4 An exemplary format of the Route Request (RREQ) message used in the AODV routing protocol as described in RFC 3561 is shown.

[0034] Figure 5 An exemplary format of the Route Response (RREP) message used in the AODV routing protocol as described in RFC 3561 is shown.

[0035] Figure 6 It shows Figure 3 A single source-destination path is established in the exemplary mesh network shown.

[0036] Figure 7-8 Two exemplary wireless mesh deployment scenarios are shown.

[0037] Figure 9-10 Flowcharts are shown of various exemplary methods and / or processes for establishing multiple channels (e.g., redundant paths) between a source node and a destination node in a wireless mesh network, according to various exemplary embodiments.

[0038] Figure 11-12 Flowcharts are shown of various exemplary methods and / or processes for multi-channel path discovery between a first node and a second node in a wireless mesh network, according to various exemplary embodiments.

[0039] Figure 13 Block diagrams of exemplary wireless mesh network devices and / or nodes according to various embodiments of the present disclosure are shown. Detailed Implementation

[0040] As briefly mentioned above, existing techniques for selecting a single path between the source and destination nodes (e.g., AODV) present various problems when used in Bluetooth mesh networks. For example, due to the inherently lossy medium access technology in Bluetooth meshes and the low duty cycle of the underlying Bluetooth LE radios (used to reduce power consumption), the selection of a single path may be insufficient to maintain the guaranteed success rate of reception. For example, redundancy in the number of available paths between the source and destination pairs can be useful. However, existing mechanisms for establishing multiple redundant paths have various drawbacks when applied to certain situations encountered in Bluetooth mesh networks.

[0041] As mentioned above, AODV uses RREQ and RREP messages to establish paths through the wireless mesh network for forwarding messages from source nodes to destination nodes. Initially, the path originator node (PO, also referred to as the "source node" in this document) that needs to establish the first path to the destination node sends an RREQ with a newly generated forwarding or sequence number. This can happen, for example, if the destination node was previously unknown to the source node. RREQ is a single-hop broadcast message sent to neighboring nodes. Any relay and / or intermediate node that receives this message will generate a new RREQ using its own device address as the new RREQ network source address. RREQ message propagation continues until the RREQ is received by the path destination node (PD), and each intermediate node that receives and forwards the RREQ also increments the hop count field in the message. Therefore, when the RREQ reaches the PD node, the hop count represents the distance between the PO and the PD (in "hops").

[0042] When a PD node receives an RREQ message, it selects the "best" relay to establish a path. Router selection can be based on hop count metrics and random path selection, or average received signal strength indicator (RSSI). In the first case, the intermediate node sending the RREQ with the lowest hop count is selected as the best intermediate node. If more than one intermediate node is sending an RREQ with the same hop count, the next-hop relay is randomly selected from among these intermediate nodes. In the second case, the intermediate node sending the lowest hop count and the highest average RSSI is selected as the next hop for forwarding the RREQ message.

[0043] The PD node then sends a unicast path response (RREP) message to the selected intermediate node. Once the selected intermediate node receives the RREP message, it repeats the same process and generates a new RREP message until the RREP message reaches the path originator node (PO). When intermediate nodes in the "best path" receive the path response, they store the corresponding path information in their respective forwarding tables. Each path can be uniquely identified in the forwarding table through entries that may include, for example, the following information:

[0044] ·PO: The network address of the originator of the path.

[0045] •PD: The network address of the destination path.

[0046] • OFN: The sequence number of the path request session. (Number)

[0047] • NTO: The network address of the node that originates the path.

[0048] • NTD: The network address of the node leading to the destination of the path.

[0049] • Subscription list: A list of multicast addresses that need to be supported by the current path.

[0050] After the forwarding table is established in the intermediate node and the node receives an application (e.g., data) message, the node checks the source (SRC) and destination (DST) fields of the message against the forwarding table (e.g., against the PO and PD fields, respectively). If a match is found, the intermediate node forwards the message to the next hop toward the path destination node PD (e.g., as identified by the NTD field in the forwarding table entry).

[0051] One technique already used to establish multiple paths in ad hoc networks is the Equal Cost Multipath (ECMP) algorithm. In ECMP, forwarding next-hop packets to a single destination can occur on multiple "best paths" that are ranked at the top in the routing metric calculation. However, ECMP introduces complex operations at intermediate nodes.

[0052] ECMP also has another drawback that makes it unsuitable for Bluetooth mesh networks. A key characteristic of Bluetooth mesh is that data messages do not contain explicit next-hop instructions. As mentioned above, paths are identified by the address of the originator and the address of the destination. Thus, multiple nodes that receive a message and belong to that path can forward it. Because ECMP requires explicit next-hop instructions, it is incompatible with use with Bluetooth mesh networks.

[0053] Another possibility for establishing multiple paths for Bluetooth mesh is to allow the destination to send multiple path response messages for a single path request. However, building independent paths is not easy because information about the established paths is not available at each node in the network. It is likely that intermediate relay nodes receiving multiple path response messages will forward these messages to the same relay to minimize the cost from the originator. Thus, any multiple paths established will very likely share the same intermediate links. The risk is that redundant paths can become extremely long in terms of hop count if the relay nodes do not choose the relay with the lowest cost for forwarding.

[0054] As mentioned above, a path is identified by a combination of the addresses of the path originator and the path destination, enabling multiple nodes that receive the message and belong to the path to forward it. Even so, network topology and propagation conditions in wireless mesh networks can limit the availability of redundancy mechanisms. One technique for adding redundant nodes to the main path is disclosed in U.S. Provisional Application No. 62 / 662,312, which is incorporated herein by reference and shares the same applicant. This technique introduces auxiliary relay nodes for local path repair of the main path, but is limited to cases where the auxiliary relay node is a neighbor of a node in the main path.

[0055] In other words, the technique may not always provide the necessary and / or desired redundancy when alternative paths do not intersect and / or intermediate nodes cannot hear each other. Figure 7 An exemplary wireless mesh deployment scenario involving nodes labeled 0-7 is illustrated. Each circle indicates the reception range for a specific node located at the center of the circle. In this scenario, an initial main path exists through nodes 0-3-4-5-7. However, intermediate nodes 2 and 4 cannot hear each other, as indicated by their respective circles that do not extend to cover the other node. In such a case, adding node 4 as an "auxiliary relay node" for node 2 would be impractical.

[0056] Another technique for adding fully independent redundant paths is disclosed in U.S. Provisional Application No. 62 / 719,247, which is incorporated herein by reference and also shares the same applicant. This technique creates and / or establishes multiple independent paths between two nodes in a Bluetooth mesh network by reusing messages and actions already defined for single path discovery. This is based on hop count metrics (e.g., as described above regarding...). Figure 3-4 As described, this technique requires nodes already included in the path to relinquish their participation in subsequent channel discovery.

[0057] However, in network topologies where disjoint end-to-end paths are unavailable, this technique may not always provide the necessary and / or desired redundancy. Figure 8 Another exemplary wireless mesh deployment scenario is shown, comprising nodes labeled 0-6, where circles indicate... Figure 7 The receiving range of the nodes is defined in this scenario. Nodes 1 and 4 cannot hear each other, and nodes 2 and 5 cannot hear each other. Therefore, the two paths between nodes 0 and 6 must pass through node 3, making the two paths non-intersecting. For example, adverse conditions at node 3 (e.g., faults, motion, poor radio conditions, high traffic, etc.) could prohibit and / or inhibit the two paths between nodes 0 and 6, which is highly undesirable.

[0058] Therefore, exemplary embodiments of this disclosure provide novel techniques for creating and / or establishing multiple independent paths between two nodes in a Bluetooth mesh network based on a new path metric for multi-channel path discovery that incorporates both hop counts in existing channels and the presence of nodes. For example, these novel path metrics can combine hop counts with information about the number of overlapping nodes already present in the path, balancing the number of hops involved in message forwarding with the expected level of redundant nodes participating in message forwarding. For example, this new metric may be referred to as a "node count".

[0059] In this way, by combining and / or balancing hop counts and required message forwarding redundancy, such exemplary embodiments can provide an easily implementable multi-channel discovery technique that facilitates node differentiation of partially disjoint paths. Moreover, such a technique can be implemented in existing wireless mesh networks (e.g., Bluetooth mesh networks) without introducing additional overhead or complexity, such as new control messages or information that would otherwise need to be distributed through the mesh network, compared to single-channel discovery mechanisms as described above.

[0060] In various exemplary embodiments, an exemplary path metric may include the following two elements, fields, and / or variables:

[0061] • A hop count, which is initialized to zero (0) by the initiator of the discovery process and incremented (e.g., 1) at each node that receives (and potentially forwards) a discovery message sent by the initiator.

[0062] • The overlap number is initialized to zero (0) by the initiator of the discovery process and is increased (e.g., 1) at each node that receives (and potentially forwards) a discovery message sent by the initiator, provided that the forwarding table of the receiving / forwarding node already includes an entry associated with that particular discovery process.

[0063] The combination of these two elements, fields, and / or variables can be referred to as a "node count" path metric. In various embodiments, the combination can include an unweighted sum of the counts in the respective elements to form a node count metric. The two elements can also be combined via a weighted sum and through various other types of combination operations.

[0064] Furthermore, exemplary mesh nodes using such path metrics may include in their respective forwarding tables a field indicating the number of channels established through that particular node for a given source-destination path. For example, this field may be referred to as the "Number of Channels" (or simply NL). In contrast to the multi-channel path discovery technique disclosed in U.S. Provisional Application No. 62 / 719,247, nodes already part of a channel in a path are allowed to participate in subsequent channel discovery operations for the same path.

[0065] Figure 9 A flowchart is shown of an exemplary method and / or process for establishing multiple channels (e.g., redundant paths) between a source node and a destination node in a wireless mesh network. Figure 9 The exemplary methods and / or processes shown may be performed by intermediate nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, etc., or components thereof) in a wireless mesh network (e.g., a Bluetooth mesh network). For example, Figure 9 The exemplary methods and / or processes shown can, for example, be implemented according to (as described below) Figure 13 Implemented in the configured nodes. Although Figure 9 The operations in the code are given numerical labels, but these are only for the purpose of facilitating the following interpretation and should not be construed as requiring anything unless explicitly stated otherwise. Figure 9 The operations within it can be performed in any particular order.

[0066] In the Figure 9 In the exemplary embodiment shown, the hop count and overlap count are combined into a node count path metric, such that each additional hop is weighted the same as the inclusion of a node already included in another channel. This method has the advantage that it allows the path metric to be passed as a single value, while maintaining control messages used for path establishment (e.g., Figure 3-4 The existing size of the RREQ and RREP messages shown still promotes adding redundancy to the paths where some intermediate nodes act as single points of failure.

[0067] Intermediate nodes are assumed to maintain both discovery tables and forwarding tables related to the routing between source-destination pairs of nodes in a mesh network to which the intermediate node is a part. The description will begin first. Figure 9 The left side shows the operations related to maintaining the discovery table. In operation 910, the intermediate node receives a discovery message (e.g., RREQ) from a neighboring node, where the message includes a source address, a destination address, and a node count field with a specific value. In operation 920, the intermediate node determines whether the value of the received node count is less than the value of the entry in the discovery table associated with the source-destination pair identified by the received address. If the current discovery table node count value is greater than or equal to the received node count value (“No”), the operation proceeds to box 930, where the node ignores the discovery message.

[0068] Otherwise (e.g., if the current discovery table node count is less than the received node count, or if no discovery table entry exists), the operation proceeds to box 940, where the node uses the received node count to update (or create) the discovery table entry associated with the source-destination pair. The operation then proceeds to box 950, where the node determines whether the forwarding table includes a path entry associated with the source-destination pair. If no entry exists in the table (“No”), the operation proceeds to box 960, where the node increments the node count in the received discovery message by one (1). Otherwise, if an entry exists in the table (“Yes”), the operation proceeds to box 970, where the node increments the node count in the received discovery message by channel number + 1. In either case, the operation then proceeds to box 980, where the node forwards the discovery message to neighboring nodes in the mesh network.

[0069] Figure 9 The operations related to maintaining the forwarding table, shown on the right, are described below. In operation 905, the intermediate node receives a channel establishment message from a neighboring node, where the channel establishment message includes the source address and destination address. In operation 915, the node determines whether the forwarding table includes a path entry associated with the source-destination pair. If no entry exists in the table (“No”), the operation proceeds to box 935, where the node adds an entry with a channel number of 1, along with any other relevant information as described above, to the forwarding table. Otherwise (“Yes”), the operation proceeds to box 925, where the node increments the channel number value of the forwarding table entry associated with the source-destination pair. In either case, the operation then proceeds to box 945, where the node forwards the channel establishment message to neighboring nodes in the mesh network.

[0070] Figure 10 Flowcharts are shown of other exemplary methods and / or processes for establishing multiple channels (e.g., redundant paths) between a source node and a destination node in a wireless mesh network. Figure 10 The exemplary methods and / or processes shown may be performed by intermediate nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, etc., or components thereof) in a wireless mesh network (e.g., a Bluetooth mesh network). For example, Figure 10 The exemplary methods and / or processes shown can, for example, be implemented according to (as described below) Figure 13 Implemented in the configured nodes. Although Figure 10 The operations described are given numerical labels, but these are only for the purpose of facilitating the following interpretation and should not be construed as requiring anything unless explicitly stated otherwise. Figure 10 The operations within it can be performed in any particular order.

[0071] In the Figure 10In the exemplary embodiment shown, within the node counting path metric, hop count and overlap count are stored as two separate values ​​or fields. The node performing path selection can then select a path first based on the overlap count and secondly based on the hop count. For example, among candidate paths, the candidate path with the lowest number of overlapping nodes and the candidate path with the lowest hop count can be selected. This technique has the advantage and / or effect of penalizing and / or preventing paths with many overlapping nodes, as these are more susceptible to single-node failures and / or unavailability.

[0072] Similar to Figure 9 In the illustrated embodiment, intermediate nodes are assumed to maintain both a discovery table and a forwarding table related to the routing between source-destination pairs of nodes in the mesh network to which the intermediate node is a part. The description will begin first. Figure 10 The left side shows the operations related to maintaining the discovery table. In operation 1010, the intermediate node receives a discovery message (e.g., RREQ) from its neighboring nodes, where the message includes a source address, a destination address, and a node count field including hop count and overlap number subfields, each with specific values. In operation 1020, the intermediate node determines whether one of the following conditions is met:

[0073] • The value of the received overlap number is less than the corresponding value in the discovery table associated with the source-destination pair identified by the received address; or

[0074] • The received overlap count is equal to the corresponding value of the entry in the discovery table, but the received jump count is less than the corresponding value of the entry in the discovery table.

[0075] If none of these conditions are met ("No"), the operation proceeds to box 1030, where the node ignores the discovery message.

[0076] Otherwise (e.g., if one of the conditions is met, or no discovery table entry exists), the operation proceeds to box 1040, where the node updates the discovery table entry associated with the source-destination pair using the received hop count and overlap value. The operation then proceeds to box 1050, where the node determines whether the forwarding table includes a path entry associated with the source-destination pair. If no entry exists in the table (“No”), the operation proceeds to box 1060, where the node increments the hop count value in the received discovery message by one (1). Otherwise, if an entry exists in the forwarding table (“Yes”), the operation proceeds to box 1070, where the node increments the hop count value in the received discovery message by 1 and increments the overlap value in the received discovery message by the channel number. In either case, the operation then proceeds to box 1080, where the node forwards the discovery message to neighboring nodes in the mesh network.

[0077] Figure 10 The operations related to maintaining the forwarding table, shown on the right, are described below. In operation 1005, an intermediate node receives a channel establishment message from a neighboring node, where the channel establishment message includes the source address and destination address. In operation 1015, the node determines whether the forwarding table includes a path entry associated with the source-destination pair. If no entry exists in the table (“No”), the operation proceeds to box 1035, where the node adds an entry with a channel count of 1 to the forwarding table. Otherwise (“Yes”), the operation proceeds to box 1025, where the node increments the channel count value of the forwarding table entry associated with the source-destination pair. In either case, the operation then proceeds to box 1045, where the node forwards the channel establishment message to neighboring nodes in the mesh network.

[0078] In various embodiments, intermediate nodes may also use the channel number value of the forwarding table entry associated with the source-destination pair to configure the network layer retransmission number of messages forwarded by the node along the path between the source-destination pair. For example, if a node uses N0 as the default retransmission number for any network layer message, the retransmission number Nret for a specific network layer message between the source-destination pair can be determined based on N0 + k0 * channel number + k1, where k0 is an integer constant greater than or equal to one, and k1 is an integer constant greater than or equal to zero. For example, k0 = 1 and k1 = 0.

[0079] Figure 11 A flowchart illustrating an exemplary method and / or process for multi-channel path discovery between a first node and a second node in a wireless mesh network is provided. The exemplary method and / or process may be performed by intermediate nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, etc., or components thereof) in the wireless mesh network (e.g., a Bluetooth mesh network). For example, Figure 11 The exemplary methods and / or processes shown can, for example, be implemented according to (as described below) Figure 13 Implemented in the configured nodes. Furthermore, Figure 11 The exemplary methods and / or processes shown can be used collaboratively with the exemplary methods and / or processes shown in other figures to provide the various exemplary benefits described herein. Additionally, although... Figure 11 The boxes are shown in a specific order; however, this order is merely exemplary, and the operation of the exemplary methods and / or processes can be varied in relation to... Figure 11 The different sequences shown can be executed and / or divided into boxes with different functions. Optional boxes or operations are indicated by dashed lines.

[0080] Figure 11An exemplary embodiment of the method and / or process shown may include the operation of block 1110, wherein an intermediate node may receive a path request for establishing a path between a first node and a second node, wherein the path request includes node count information related to the path between the first node and the second node. For example, the path request may be an Adaptive On-Demand Distance Vector (AODV) Route Request (RREQ) message. The exemplary method and / or process may also include the operation of block 1120, wherein the intermediate node may determine whether the received node count information is less than or equal to the node count information corresponding to the path between the first node and the second node stored in the intermediate node's discovery table.

[0081] The exemplary method and / or process may also include the operation at block 1130, wherein if it is determined that the received node count information is less than or equal to the stored node count information, the intermediate node may perform further operations. For example, the intermediate node may update the stored node count information using the received node count information. In some embodiments, further operations may include the operation at block 1132, wherein the intermediate node may determine whether its forwarding table includes an entry corresponding to the path between the first node and the second node. Additionally, further operations may include the operation at block 1134, wherein the intermediate node may modify the node count information in the path request based on whether the forwarding table includes an entry.

[0082] In some embodiments, the node count information may include the sum of the hop count from the first node and the number of overlapping nodes between the path and one or more other paths between the first node and the second node. In such an embodiment, if it is determined that the forwarding table includes an entry corresponding to the path between the first node and the second node, the operation of block 1134 may include incrementing the node count by one plus the number of channels between the first node and the second node via intermediate nodes. In such an embodiment, if it is determined that the forwarding table does not include an entry, the operation of block 1134 may include incrementing the node count information by one.

[0083] In other embodiments, the node count information may include a hop count from the first node and the number of overlapping nodes between the path and one or more other paths between the first and second nodes. In such an embodiment, if it is determined that the forwarding table includes an entry corresponding to the path between the first and second nodes, the operation of box 1134 may include incrementing the hop count by one and increasing the number of overlapping nodes by the number of channels between the first and second nodes via intermediate nodes. In such an embodiment, if it is determined that the forwarding table does not include an entry, the operation of box 1134 may include incrementing the hop count by one.

[0084] In some embodiments, the exemplary method and / or process may further include the operation of block 1140, wherein an intermediate node may forward a path request to one or more other nodes in the wireless mesh network. In some embodiments, the exemplary method and / or process may further include the operation of block 1150, wherein an intermediate node may receive a data message originating at a first node and destined for a second node. In such embodiments, the exemplary method and / or process may further include the operation of block 1160, wherein an intermediate node may determine a retransmission count for forwarding data messages based on a forwarding table entry corresponding to the path between the first and second nodes. In such embodiments, the exemplary method and / or process may further include the operation of block 1170, wherein an intermediate node may retransmit data messages a number of times less than or equal to the retransmission count. In some embodiments, the retransmission count may be determined based on a field including a forwarding table entry indicating the number of channels between the first and second nodes via the intermediate node.

[0085] In some embodiments, the exemplary method and / or process may further include: receiving another path request for establishing a path between a first node and a second node, wherein the other path request includes another node count information relating to the path between the first node and the second node. In such embodiments, the exemplary method and / or process may further include: selecting one of the path request and the other path request for forwarding to one or more other intermediate nodes based on the node count information and the other node count information.

[0086] In some embodiments, selecting based on node count information and another node count information may include: selecting a path request if the node count information is less than the other node count information; selecting another path request if the node count information is greater than the other node count information; and selecting one of the path request and another path request based on at least one of the following criteria if the node count information is equal to the other node count information: random selection; and Received Signal Strength Indication (RSSI) associated with the path request and the other path request.

[0087] Figure 12 A flowchart is shown for another exemplary method and / or process for multi-channel path discovery between a first node and a second node in a wireless mesh network. The exemplary method and / or process may be performed by intermediate nodes (e.g., user equipment, wireless devices, IoT devices, Bluetooth Low Energy devices, etc., or components thereof) in a wireless mesh network (e.g., a Bluetooth mesh network). For example, Figure 12 The exemplary methods and / or processes shown can be implemented according to (as described below) Figure 13 Implemented in the configured nodes. Furthermore, Figure 12The exemplary methods and / or processes shown can be used in conjunction with the exemplary methods and / or processes shown in other figures to provide the various exemplary benefits described herein. Additionally, although... Figure 12 The boxes are shown in a specific order; however, this order is merely exemplary, and the operation of the exemplary methods and / or processes can be varied in relation to... Figure 12 The different sequences shown can be executed and / or divided into boxes with different functions. Optional boxes or operations are indicated by dashed lines.

[0088] Figure 12 An exemplary embodiment of the illustrated method and / or process may include the operation of block 1210, wherein an intermediate node may receive a channel request for establishing a channel for a path between a first node and a second node, wherein the channel request includes a source address associated with the first node and a destination address associated with the second node. The exemplary method and / or process may also include the operation of block 1020, wherein the intermediate node may determine, based on the source and destination addresses, whether a forwarding table stored by the intermediate node includes an entry corresponding to a path between the first node and the second node via the intermediate node. The exemplary method and / or process may also include the operation of block 1030, wherein if it is determined that the forwarding table includes an entry, the intermediate node may increment a value indicating the number of channels between the first node and the second node via the intermediate node.

[0089] In some embodiments, the exemplary method and / or process may further include the operation of block 1040, wherein if it is determined that the forwarding table does not contain an entry, the intermediate node may add an entry to the forwarding table, wherein the added entry includes a source address, a destination address, and a value indicating that the number of channels between the first node and the second node via the intermediate node is equal to one. In some embodiments, the exemplary method and / or process may further include the operation of block 1050, wherein the intermediate node may forward a channel request to one or more other nodes in the wireless mesh network. In some embodiments, the channel request may include an Adaptive On-Demand Distance Vector (AODV) Route Request (RREQ) message.

[0090] Although various embodiments have been described above in relation to methods, apparatuses, devices, computer-readable media, and receivers, those skilled in the art will readily understand that such methods can be implemented by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, etc. Figure 13 Block diagrams of exemplary wireless mesh network devices and / or nodes 1300 according to various embodiments of the present disclosure are shown. For example, exemplary node 1300 can be configured to perform one or more operations corresponding to the exemplary methods and / or processes described above by executing instructions stored on a computer-readable medium.

[0091] Exemplary node 1300 may include one or more processors 1310 that are operatively connected to one or more memories 1320 via address and data buses, serial ports, or other methods and / or structures known to those skilled in the art. The memories 1320 include software code or programs that are executed by the processors 1310 that facilitate, cause, and / or program the exemplary node 1300 to perform various operations.

[0092] like Figure 13 As shown, memory(s) 1320 may include application 1360 (e.g., application code) and mesh network protocol stack 1370, which may also include middle and upper layers 1372 and lower layers 1374. For example, protocol stack 1370 may include a Bluetooth mesh network protocol stack, such as... Figure 1 and 2 As shown and described in more detail above. In this case, the lower layer 1374 may include the Bluetooth LE PHY and link layer, wherein the remainder of the Bluetooth mesh network protocol stack includes the middle and upper layers 1372. Furthermore, the protocol stack 1370 may include configuring node 1300 to perform operations including, when executed by processor(s) 1310. Figure 9-12 The software code of any of the exemplary methods and / or processes described above.

[0093] In some embodiments, the memory(s) 1320 and processor(s) 1310 may be further divided into multiple processors and memories, such that a particular memory stores lower-level 1374 code executed by a particular processor, and other memories store intermediate and upper-level 1372 code executed by other processors. For example, in a Bluetooth mesh network embodiment, a particular memory and a particular processor may operate as a Bluetooth device or controller, while other memories and other processors may operate as Bluetooth hosts, with a host-controller interface (HCI) between them.

[0094] Exemplary node 1300 also includes a radio transceiver 1340 coupled to and communicating with processor 1310. Radio transceiver 1340 includes a transmitter and receiver operable to (e.g., in conjunction with processor 1310) transmit and receive wireless signals at a specific frequency or band. In a Bluetooth mesh network embodiment, radio transceiver 1340 may be configured to transmit and receive in the 2.4-GHz ISM band according to the Bluetooth LE standard. In some embodiments, radio transceiver 1340 may include a portion of lower layer 1374, such as... Figure 13As shown. For example, in a Bluetooth mesh network embodiment, the Bluetooth LE physical layer may be implemented by a radio transceiver 1340 in combination with software code executed by a processor 1310. Furthermore, although not shown, the radio transceiver 1340 may include one or more antennas to facilitate transmission and reception in an appropriate frequency band.

[0095] In some embodiments, node 1300 may also include one or more elements 1350a, 1350b, 1350c, etc., that provide an interface to the physical environment in which node 1300 is located. For example, element(s) 1350(s) may monitor and / or collect data relating to the operation of a physical process or machine. As another example, element(s) 1350(s) may control one or more aspects of such a physical process. Thus, it may be desirable to transmit collected data to a remote source and / or receive control commands from a remote source via the mesh networking capabilities of node 1300.

[0096] This can be accomplished, for example, through an application 1360 that can communicate with both the mesh network stack 1370 and (one or more) elements 1350. This logical communication between application 1360 and (one or more) elements 1350... Figure 13 The lines are shown as dashed lines. In some embodiments, however, physical communication (shown as solid lines) between application 1360 and one or more elements 1350 may be performed via interface circuitry 1330 inserted between one or more elements 1350 and one or more processors 1310.

[0097] As described herein, devices, nodes, and / or apparatuses can be represented by semiconductor chips, chipsets, or (hardware) modules comprising such chips or chipsets; however, this does not preclude the possibility that the functionality of a device, node, or apparatus is not implemented in hardware but rather as a software module (such as a computer program or computer program product comprising executable software code for execution or execution on a processor). Furthermore, the functionality of a device, node, or apparatus can be implemented by any combination of hardware and software. Devices, nodes, or apparatuses can also be considered as components of multiple devices and / or apparatuses, whether functionally cooperative or independent of each other. Moreover, devices, nodes, and apparatuses can be implemented in a distributed manner throughout the system, provided that the functionality of the devices or apparatuses is preserved. Such and similar principles are considered to be known to those skilled in the art.

[0098] The foregoing only illustrates the principles of this disclosure. Various modifications and variations of the described embodiments will be apparent to those skilled in the art in light of the teachings herein. Therefore, it will be understood that those skilled in the art will be able to design numerous systems, arrangements, and programs that implement the principles of this disclosure and can therefore be within the spirit and scope of this disclosure, although not explicitly shown or described herein. Various different exemplary embodiments may be used together and interchangeably with each other, as should be understood by those skilled in the art. Additionally, in some instances, certain terms used in this disclosure, including the specification, drawings, and exemplary embodiments thereof, may be used synonymously, including, for example, data and information. It should be understood that while these words and / or other words that may be synonymous with each other may be used synonymously herein, instances may exist where such words may be intended to be used differently. Moreover, prior art knowledge, to the extent that it has not been expressly incorporated herein by reference in its entirety, is expressly incorporated herein by reference. All cited disclosures are incorporated herein by reference in their entirety.

[0099] Exemplary embodiments of the technologies and apparatuses described herein include, but are not limited to, the following enumerated embodiments:

[0100] Exemplary embodiments

[0101] 1. A method for multi-channel path discovery between a first node and a second node in a wireless mesh network, the method being performed by an intermediate node and comprising:

[0102] Receive a path request for establishing a path between a first node and a second node, wherein the path request includes node count information related to the path between the first node and the second node;

[0103] Determine whether the received node count information is less than or equal to the node count information corresponding to the path between the first and second nodes stored in the discovery table of the intermediate nodes; and

[0104] If it is determined that the received node count information is less than or equal to the stored node count information, then the stored node count information is updated using the received node count information.

[0105] In other words, the method can be described as a method for supporting the establishment of a path between a source node (which is a first node) and a destination node (which is a second node) in a wireless mesh network, the path including one or more intermediate nodes, wherein each intermediate node in the network is arranged to maintain a forwarding table identifying the path in the wireless mesh network and a discovery table arranged to maintain a path metric indicating a predefined metric of the path, the method comprising the following steps:

[0106] - The intermediate node receives a path discovery message, which includes a path metric;

[0107] - The intermediate node determines that the path metric is less than the path metric already stored and available in the discovery table at the intermediate node;

[0108] - The intermediate node updates the path metric in the discovery table with the received path metric value;

[0109] - The path metric is updated by the intermediate node to obtain the updated path metric when the determination step is completed;

[0110] - The intermediate node forwards the path discovery message with the updated path metric, thereby supporting the establishment of the path between the source node and the destination node in the wireless mesh network.

[0111] 2. The method according to Embodiment 1 further includes: if it is determined that the received node count information is less than or equal to the stored node count information:

[0112] Determine whether the forwarding table of intermediate nodes includes entries corresponding to the path between the first and second nodes; and

[0113] Modify the node count information in the path request based on whether the forwarding table includes entries.

[0114] 3. The method according to Example 2, wherein:

[0115] Node counting information includes the hop count from the first node and the sum of the number of overlapping nodes between the path and one or more other paths between the first and second nodes; and

[0116] If the forwarding table is determined to include entries corresponding to the path between the first node and the second node, then modifying the node count information includes increasing the node count by the number of channels between the first node and the second node via intermediate nodes.

[0117] 4. The method according to embodiment 3 further includes: if it is determined that the forwarding table does not include entries, modifying the node count information includes increasing the node count information by one.

[0118] 5. The method according to Example 2, wherein:

[0119] Node counting information includes the hop count from the first node and the number of overlapping nodes between the path and one or more other paths between the first and second nodes; and

[0120] If the forwarding table is determined to include entries corresponding to the path between the first and second nodes, then the node count information is modified as follows:

[0121] Increment the jump count by one; and

[0122] Increase the number of overlapping nodes by increasing the number of channels between the first and second nodes via intermediate nodes.

[0123] 6. The method according to embodiment 5 further includes: if it is determined that the forwarding table does not include an entry, modifying the node count information includes increasing the jump count by one.

[0124] 7. The method according to any one of embodiments 1 to 6 further includes: forwarding the path request to one or more other nodes in the wireless mesh network.

[0125] 8. The method according to any one of embodiments 1 to 7, further comprising:

[0126] Receive another path request for establishing a path between the first node and the second node, wherein the other path request includes another node count information related to the path between the first node and the second node;

[0127] Based on node count information and another node count information, one of the path request and another path request is selected for forwarding to one or more other intermediate nodes.

[0128] 9. The method according to embodiment 8, wherein the selection based on node count information and another node count information includes:

[0129] If the node count is less than the other node count, then a path request is selected.

[0130] If the node count is greater than the node count of another node, then another path is requested; and

[0131] If the node count information is equal to the other node count information, then one of the path request and the other path request is selected based on at least one of the following criteria:

[0132] Random selection; and

[0133] Received Signal Strength Indication (RSSI) associated with path request and another path request.

[0134] 10. The method according to any one of embodiments 2 to 9, further comprising:

[0135] Receive data messages originating at the first node and destined for the second node;

[0136] The retransmission count for forwarding data messages is determined based on the forwarding table corresponding to the path between the first and second nodes; and

[0137] Retransmit the data message a number of times less than or equal to the retransmission count.

[0138] 11. The method according to embodiment 10, wherein the retransmission count is determined based on a field including a forwarding table entry, the field indicating the number of channels between the first node and the second node via an intermediate node.

[0139] 12. The method according to any one of embodiments 1 to 11, wherein the path request includes an Adaptive On-Demand Distance Vector (AODV) Route Request (RREQ) message.

[0140] 13. The method according to any one of embodiments 1 to 12, wherein the wireless mesh network is a Bluetooth mesh network, and the method is performed by a Bluetooth Low Energy node.

[0141] 14. A method for multi-channel path discovery between a first node and a second node in a wireless mesh network, the method being performed by an intermediate node and comprising:

[0142] Receive a channel request for establishing a channel for a path between a first node and a second node, wherein the channel request includes a source address associated with the first node and a destination address associated with the second node;

[0143] Based on the source address and destination address, determine whether the forwarding table stored by the intermediate node includes an entry corresponding to the path between the first node and the second node via the intermediate node;

[0144] If it is determined that the forwarding table includes an entry, then the value of the included entry is increased, which indicates the number of channels between the first node and the second node via intermediate nodes.

[0145] 15. The method according to embodiment 14 further includes: if it is determined that the forwarding table does not contain an entry, then adding an entry to the forwarding table, wherein the added entry includes a source address, a destination address, and a value indicating that the number of channels between the first node and the second node via intermediate nodes is equal to one.

[0146] 16. The method according to any one of embodiments 14 to 15 further includes: forwarding the channel request to one or more other nodes in the wireless mesh network.

[0147] 17. The method according to any one of embodiments 14 to 16, wherein the channel request includes a self-organizing on-demand distance vector (AODV) routing request (RREQ) message.

[0148] 18. The method according to any one of embodiments 14 to 17, wherein the wireless mesh network is a Bluetooth mesh network, and the method is performed by a Bluetooth Low Energy node.

[0149] 19. A method for discovering multiple channels of a path through a wireless mesh network, wherein path metrics, including hop counts and information about the number of overlapping nodes, are used in path selection.

[0150] 20. The method according to embodiment 19, wherein the path metric is incremented by 1 at each hop through the wireless mesh network and also by 1 at each node belonging to an existing channel in the path.

[0151] 21. The method according to any one of embodiments 19 to 20, wherein path metrics are compared by first selecting the path with the minimum number of nodes and then selecting the path with the minimum number of hops for the same number of overlapping nodes.

[0152] 22. The method according to any one of embodiments 19 to 21 further includes: comparing multiple paths and selecting the optimal path based on the path metric.

[0153] 23. A method for selecting the number of retransmissions of a data message by an intermediate node in a wireless network based on a stored value in the node’s forwarding table, the stored value indicating the number of channels between the source node and the destination node via the intermediate node.

[0154] 24. A node in a wireless mesh network, the wireless mesh network comprising one or more source nodes, one or more destination nodes, and multiple intermediate nodes, wherein the node comprises:

[0155] Wireless transceivers; and

[0156] The processing circuitry, operatively coupled to the wireless transceiver, is configured to perform operations corresponding to any of the methods described in Embodiments 1 to 23.

[0157] 25. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by processing circuitry including nodes in a wireless mesh network, configure the nodes to perform operations corresponding to the method described in any one of embodiments 1 to 23.

[0158] 26. A wireless mesh network, comprising:

[0159] One or more source nodes, each source node including a wireless transceiver and processing circuitry operatively coupled to and configured to generate path requests and channel requests;

[0160] One or more destination nodes, each destination node including a wireless transceiver and processing circuitry operatively coupled and configured to generate path acknowledgments and channel acknowledgments; and

[0161] Multiple intermediate nodes are interconnected in a mesh topology and configured to forward messages between source and destination nodes, and are also configured to perform operations corresponding to any of the methods described in Embodiments 1 to 23.

[0162] Significantly, those skilled in the art will conceive of modifications and other embodiments of the disclosed embodiments upon the aid of the foregoing description and the associated drawings. Therefore, it should be understood that the scope of this disclosure is not limited to the specific embodiments disclosed, and modifications and other variations are intended to be included within the scope. While specific terminology may be used herein, it is used in a general and descriptive sense only and not for limiting purposes.

Claims

1. A method for multi-channel path discovery between a first node and a second node in a wireless mesh network, the method being performed by an intermediate node and comprising the following steps related to maintaining a forwarding table: - The intermediate node receives a channel request for establishing a channel for a path between the first node and the second node, wherein, The channel request includes a source address associated with the first node and a destination address associated with the second node; - The intermediate node determines, based on the received source and destination addresses, that the forwarding table stored by the intermediate node includes entries corresponding to the path between the first node and the second node via the intermediate node; - The intermediate node increments the value of the entry, which indicates the number of channels between the first node and the second node via the intermediate node; In multi-channel path selection, path metrics including hop counts and information about the number of overlapping nodes are used.

2. The method according to claim 1, further comprising: The channel request is forwarded to one or more other nodes in the wireless mesh network.

3. The method according to any one of claims 1 to 2, wherein, The channel request includes a Self-Organizing On-Demand Distance Vector (AODV) Route Request (RREQ) message.

4. The method according to any one of claims 1 to 2, wherein, The wireless mesh network is a Bluetooth mesh network, and the method is performed by a Bluetooth Low Energy node.

5. A method for selecting the number of retransmissions of a data message by an intermediate node in a wireless network based on a stored value in a node’s forwarding table, the stored value indicating the number of channels between a source node and a destination node via the intermediate node; in, Use path metrics that include hop counts and information about the number of overlapping nodes in path selection for multi-channel paths; Wherein, if the node uses N0 as the default number of retransmissions for any network layer message, the number of retransmissions Nret for a specific network layer message between the source node and the destination node is determined based on N0 + k0 * the number of channels + k1, where k0 is an integer constant greater than or equal to one, and k1 is an integer constant greater than or equal to zero.

Images