WO2023123083A1 - Route discovery in a mesh network - Google Patents
Route discovery in a mesh network Download PDFInfo
- Publication number
- WO2023123083A1 WO2023123083A1 PCT/CN2021/142595 CN2021142595W WO2023123083A1 WO 2023123083 A1 WO2023123083 A1 WO 2023123083A1 CN 2021142595 W CN2021142595 W CN 2021142595W WO 2023123083 A1 WO2023123083 A1 WO 2023123083A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- route
- discovery
- network
- mesh network
- Prior art date
Links
- 238000000034 method Methods 0.000 claims abstract description 76
- 230000004044 response Effects 0.000 claims abstract description 67
- 230000001413 cellular effect Effects 0.000 claims abstract description 13
- 235000008694 Humulus lupulus Nutrition 0.000 description 29
- 230000005540 biological transmission Effects 0.000 description 21
- 230000011664 signaling Effects 0.000 description 15
- 238000004891 communication Methods 0.000 description 10
- 238000012544 monitoring process Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 230000006399 behavior Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 210000004027 cell Anatomy 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 210000002925 A-like Anatomy 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000001404 mediated effect Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000002250 progressing effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 238000001303 quality assessment method Methods 0.000 description 1
- 238000013442 quality metrics Methods 0.000 description 1
Images
Classifications
-
- 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
-
- 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
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/246—Connectivity information discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/34—Modification of an existing route
Definitions
- This disclosure relates to wireless communications, and specifically to a procedure for establishing routes between nodes during discovery in a mesh network that relies on relaying functionality in the nodes of the mesh.
- the procedure is illustrated with reference to relaying functionality embodied in layer 2 of a protocol stack, but it may also be applied to other settings such as a mesh with relaying at layer 3.
- Model A also described as “I am here”
- UE user equipment
- Model B also described as “Who is there?
- a first UE also described as a discoverer UE, transmits a solicitation indicating that it seeks a particular service
- a second UE also described as a discoveree UE, may transmit a response indicating that it offers the requested service.
- UEs In direct device-to-device communication, or in single-hop UE-to-network relaying (as supported for the NR sidelink in 3GPP Rel-17) , UEs only need to discover other UEs with which they will communicate directly.
- a first device may have a need to discover a second device that is distant from the first device in terms of the network topology. For example, a first UE W may seek communication with a second UE Z, but the network path from W to Z may pass through relay UEs X and Y.
- UEs W and Z may need to carry out a discovery procedure mediated by UEs X and Y.
- UEs W and Z should learn not only of each other’s existence and availability to communicate, but also of the network route connecting them. For example, UE W may determine that to deliver a packet to UE Z, it should first send the packet to UE X, with additional routing information indicating that the ultimate destination of the packet is UE Z.
- SRAP Sidelink Relay Adaptation Protocol
- a header format of the SRAP protocol may contain a field identifying the involved remote UE. In UE-to-network relaying, this field is used in the downlink direction to identify which remote UE should receive a packet from the network.
- a relay UE receives the packet from the network, consults the SRAP header to determine which remote UE is the destination, and forwards the packet to the remote UE (while also applying additional functions such as bearer mapping) .
- the existing SRAP behaviour is not designed for a multi-hop or mesh environment; the protocol assumes that the relay UE has a unique connection directly to the destination remote UE. (In the uplink direction, the same or an analogous field may identify which remote UE is the source of the packet. In the existing design for single-hop UE-to-network relaying, the relay UE does not depend on this information for packet routing, since in the uplink direction the relay UE always forwards packets to the network, but the receiving network node relies on this field to distinguish which UE context the received packet should be associated with. )
- a method of discovery in a first node receives, from a first neighbour node, a first discovery request comprising at least a request for a route to a destination node. If a routing table of the first node contains at least one route to the destination node, the first node sends, to the first neighbour node, a discovery response comprising information about the at least one route. If the routing table of the first node does not contain at least one route to the destination node, the first node sends, to a second neighbour node, a second discovery request comprising a request for a route to the destination node.
- a method of discovery in a first node receives, from a first neighbour node, a first discovery message comprising first information about at least one route to a destination node.
- the first node updates a routing table of the first node by adding the at least one route.
- the first node transmits, to a second neighbour node, a second discovery response message comprising second information about the at least one route.
- a method of discovery in a first node has a radio connection to a second node.
- the first node transmits, to a third node, a discovery announcement comprising the information that the first node has a radio connection to the second node, wherein the second node is a node of a cellular network.
- a method of connection management in a source node receives, from a neighbour node, a discovery message comprising at least a first route to a destination node.
- the source node adds the at least a first route to a routing table of the source node.
- the source node selects, based on information in the routing table, at least a second route to the destination node.
- the source node transmits, to the destination node via the at least a second route, a first control message of a protocol.
- the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims.
- the following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.
- FIG. 1 is a diagram illustrating an example of delivery of a packet in a mesh network of UEs.
- FIG. 2 is a diagram illustrating an example of a mesh in which a distinguished UE can operate as a gateway to a network node.
- FIG. 3 illustrates an example of a discovery procedure in which an announcing node informs a monitoring node that the announcing node has a connection to the network.
- FIG. 4 illustrates an example of a discovery procedure in which a discoverer node requests from a discoveree node a route to a destination node.
- FIG. 5 illustrates an example of a discovery procedure in a mesh network comprising the maintenance of routing tables at a plurality of nodes and the delivery of a packet.
- FIG. 6 illustrates an example of a user-plane protocol stack for a layer 2 mesh network.
- FIG. 7 illustrates an example of a discovery protocol stack for a mesh network.
- FIG. 8 is a diagram illustrating an example of a mesh network topology.
- FIG. 9 illustrates an example of a discovery procedure in a mesh network where a distinguished node has a link to a cellular network.
- FIG. 10 illustrates an example of a discovery procedure in a mesh network where a source node is provided with a plurality of routes to a node of a cellular network.
- FIG. 11 illustrates an example of a discovery procedure in a mesh network where a source node is provided with at least one route to a destination node.
- a plurality of nodes communicate as peers, with a packet of data potentially handled by many peer devices on its way from a source device to a destination device.
- the “next hop” taken by the packet may be determined by consulting a routing table stored at the peer device.
- Various methods of determining a next hop from a routing table may be applied; for instance, a simple routing table may consist only of a list of destinations, each with a single associated next hop, and the peer device may perform routing by looking up a packet’s destination in the routing table and passing the packet to the associated next hop.
- a more sophisticated routing table may contain additional information, such as, for example, multiple candidate next hops for a given destination, information about the complete path between the peer node and the destination, measures of link quality for the link to a next-hop candidate, and so on. This additional information may be needed, for instance, to adapt to a changing network topology, to select a route with good link quality to the destination, or to prevent routing loops in which a packet revisits the same node repeatedly rather than progressing towards its destination.
- a “mesh” or “mesh network” which may comprise a mixture of cellular network nodes and mobile devices
- a “network” or “cellular network” which comprises the network nodes of a conventional cellular system, such as base stations, core network nodes, and so on.
- network refers to a cellular network.
- Figure 1 shows a mesh network of UEs, with the route taken by a particular packet shown in red.
- the packet originates at UE A and is delivered to UE F.
- UE A determines from its routing table that its best (in this case, only) next hop towards UE F is UE B, so it delivers the packet to UE B.
- UE B upon receiving the packet, recognises that it is intended for UE F, and consults its own routing table.
- UE B may have both UE C and UE D available as next hops towards UE F.
- the route through UE D may be preferred to the route through UE C (for example, due to requiring a smaller number of hops: B->D->F requires two hops, while B->C->D->F requires three hops) , and accordingly, UE B delivers the packet to UE D.
- UE D may have multiple candidates for a next hop to UE F; as shown, one such candidate may be UE F itself, while another may be UE E.
- UE D determines that the direct route to UE F is preferred, and delivers the packet to UE F.
- UE F receives the packet, recognises that it is the destination node, and processes the packet accordingly (for example, by passing it to upper layers) .
- the criteria used by a UE in the mesh to determine the preferred next hop for a packet may be specified or implementation-dependent.
- a first node in the mesh network may maintain a direct connection to a network node (for example, a base station) .
- the first node may act as a gateway to the cellular network for other nodes in the mesh.
- the first node acting as an announcing node, may announce its ability to serve as a gateway with a first discovery message.
- the first discovery message is functionally similar to the discovery announcement in Model A in LTE or NR sidelink discovery, but has the special semantics “I have a link to the network” .
- Neighbouring UEs acting as monitoring nodes may receive the discovery message and record the information that UE A has a connection to the network. This information may be recorded, for instance, in a routing table. In some embodiments, the information may be further propagated to other nodes in the mesh. As an example, UE B may inform UE D that UE A has a link to the network. Subsequently, UE D may record the routing information involving UE B and/or UE A in its routing table, and if UE D needs to transmit a packet to the network, UE D may consider UE A as an intermediate destination on the packet’s route.
- Figure 3 shows a discovery procedure with route information with some similarities to discovery Model A.
- the announcing node transmits a discovery announcement, indicating that the announcing node has connectivity to a network (for instance, to a base station or a cell of an operator’s cellular network) . Within the discovery announcement, the identity of a base station or a cell may be included.
- the monitoring node performs a discovery match and determines that it has an interest in communication with the network via the announcing node.
- the monitoring node updates its routing table with information from the message in step 1, e.g., the information that the announcing node can be used as a next hop or an intermediate destination for transmission of packets towards the network.
- step 4 the monitoring and announcing nodes establish a connection; this step may, for instance, use signalling of a PC5 signalling (PC5-S) protocol and/or a PC5 radio resource control (PC5-RRC) protocol.
- PC5-S PC5 signalling
- PC5-RRC PC5 radio resource control
- step 5 the monitoring node transmits a packet to the announcing node for forwarding to the network.
- step 6 the announcing node forwards the packet towards the network.
- a flow similar to that of Figure 3 may be suitable for announcing routes to other nodes in the mesh.
- an announcing node may transmit in its discovery signalling a list of all the nodes with which it has direct links, a list of all the nodes in the mesh to which it knows a route, or a list of selective nodes which it has links.
- the size of such an announcement message may be problematic, especially if many nodes announce their routing information at once. Such signalling in a mesh with many nodes could be expected to cause a high level of congestion and consume a large amount of bandwidth.
- UE A announces that it has a link with UE B
- UE B also announces that it has a link with UE A.
- the model of Figure 3 may be most suitable for the specific case of announcing links to the network, rather than as a general solution to distributing routing table information in a mesh network.
- Figure 4 shows a discovery procedure with route information with some similarities to discovery Model B.
- the procedure of Figure 4 may be seen as complementary to the procedure of Figure 3, and it is reasonable for both procedures to coexist in a mesh.
- the procedure of Figure 3 may be used to announce links to the network, and the procedure of Figure 4 may be used to determine links between devices.
- the discoverer node In step 1 of Figure 4, the discoverer node generates traffic to be transmitted to node X (not shown) , to which the discoverer node does not know a route.
- the discoverer node transmits (for instance, by broadcast) a first discovery message comprising a request for a route to node X, and the first discovery message is received by one or a plurality of discoveree nodes.
- Step 3 the discoveree node consults its routing table and finds that it knows at least one route to node X.
- Step 3 may comprise a selection by the discoveree node of a preferred route from among a plurality of known routes to node X; alternatively, step 3 may identify a plurality of routes to node X instead of selecting a single preferred route.
- each discoveree node finds at least one route towards node X independently; a single discoveree node is shown in the figure, but the same steps may be carried out by any additional discoveree nodes.
- the discoveree node sends a second discovery message to the discoverer node, comprising an indication of at least one route to node X.
- the indication in the second discovery message may comprise detailed information about the route (for example, a number of hops, a weighting or quality measurement of the route, a list of all nodes on the route, etc. ) , or it may only indicate that a route to X through the discoveree node exists.
- the message of step 4 may be sent using any “cast type” ; that is, the message may be sent by unicast (to the discoverer node only) , by broadcast (to any node that can receive it) , or by groupcast (to an identified set of nodes including the discoverer node) .
- the discoverer node may receive multiple discovery responses (i.e., the second discovery message) from a plurality of discoveree nodes.
- the discoverer node receives the second discovery message and updates its routing table with the information that the discoveree node is a potential next hop for a route to node X.
- the information in the routing table may take various forms.
- the update to the routing table may comprise storing only the information that the discoveree node can be used as a next hop for delivery to X; alternatively, the update to the routing table may comprise storing further information about at least one route from the discoveree node to node X, such as a number of hops, a weighting or quality assessment of the route, a list of all nodes on the route, etc.
- the information stored in the routing table may comprise information extracted from the second discovery message, and/or it may comprise information determined by the discoverer node; for example, the discoverer node may infer a quality of the route from itself to node X based on a combination of information about its link to the discoveree node and any information provided by the discoveree node about the quality of the route from the discoveree node to node X.
- the discoverer node may also store the information that it now knows at least one route to node X, so that a subsequent discovery procedure initiated by a different node in the role of the discoverer node may cause this node to act as the discoveree node for a route to node X.
- step 6 the discoverer node establishes a connection (for example, a PC5 unicast link and/or a PC5-RRC connection) with the discoveree node.
- step 7 the discoverer node transmits a packet of data to the discoveree node for delivery to node X.
- the transmission of step 7 may comprise routing information, such as an identification of a preferred route to node X, an intermediate destination to be used in the route to node X, a maximum number of hops or time-to-live (TTL) for the packet, and so on.
- step 8 the discoveree node forwards the packet along an identified route towards node X.
- the forwarding in step 8 may comprise establishment of a connection by the discoveree UE with a node included in the route to X.
- the transmission of step 8 may comprise routing information, such as an identification of a preferred route to node X, an intermediate destination to be used in the route to node X, a maximum number of hops or TTL for the packet, and so on; in such a case, the routing information may be derived from routing information provided by the discoverer node in step 7 (for example, information in a header of the packet that was transmitted at step 8) and/or from information known to the discoveree node.
- Step 2 of Figure 4 is an example of a discovery request for X
- step 4 of Figure 4 is an example of a discovery response for X.
- Figure 5 shows an example of route discovery in a mesh network, involving multiple hops between the source and destination of a data packet.
- the mesh network of Figure 5 comprises (at least) four nodes W, X, Y, and Z, connected in a linear fashion (W ⁇ ->X ⁇ ->Y ⁇ ->Z) , where each node initially knows only the routes to its immediate neighbours. Accordingly, in step 0 of the figure, the initial condition of the routing tables is that node W knows the (single-hop) route to X, node X knows the (single-hop) routes to W and Y, node Y knows the (single-hop) routes to X and Z, and node Z knows the (single-hop) route to Y.
- node W determines that it has traffic (in the broadest sense, comprising any data to transmit, such as service establishment information, control signalling, user data, or any other information) to deliver to node Z.
- traffic in the broadest sense, comprising any data to transmit, such as service establishment information, control signalling, user data, or any other information
- node W consults its routing table and determines that it does not know a route to Z; accordingly, it initiates discovery to find a neighbour node in the mesh with a route to Z.
- node W transmits a first discovery request for Z.
- the discovery request may be sent by unicast to node X (the only neighbour to which node W knows a route) , by groupcast to a group address for a group that includes node X, by broadcast to any node that can receive the message, and so on.
- step 4 node X receives the discovery request, consults its own routing table, and determines that it does not know a route to Z.
- node X transmits a second discovery request for Z; this message may comprise a forwarded copy of the first discovery request from step 3, or it may be a new message generated by node X, with or without information copied from the message in step 3.
- node Y receives the second discovery request, consults its routing table, and determines that it knows a route to Z, specifically the direct route Y->Z.
- node Y sends a first discovery response for Z, comprising information about the route to Z; this message may comprise an explicit description of the route, partial information about the route such as a hop count and/or a quality metric, or only the information that a route exists.
- the first discovery response may comprise identifying information, such as a transaction identifier and/or a sequence number, that associates it with the second discovery request.
- node X receives the first discovery response and updates its routing table with the information that Y is a valid next hop or intermediate destination for a route to Z; any information derived from the first discovery response may, at this stage, be stored in the routing table at X.
- X determines that it now knows a route to Z, and it responds to the first discovery request by transmitting to W a second discovery response for Z.
- the second discovery response may comprise any information about the route to Z.
- the second discovery response may comprise identifying information, such as a transaction identifier and/or a sequence number, that associates it with the first discovery request.
- node W receives the second discovery response and updates its routing table to include at least a route to Z.
- node W may populate its routing table with additional information, such as a route to Y, as well as any available information about the route from X to Z.
- node W Since node W now knows a route through the mesh to node Z, it can begin preparations for transmitting its data to Z. In step 11, any necessary connection establishment between nodes takes place; this step is further discussed in the next paragraph.
- node W transmits to node X (in accordance with its stored route to Z) a packet of data for node Z.
- the packet of data may comprise a PDU of a protocol layer responsible for handling packet data, such as a packet data convergence protocol (PDCP) layer.
- PDCP packet data convergence protocol
- the contents of the packet of data may comprise user data, control signalling, service establishment information, or any other information.
- node X forwards to node Y (in accordance with its own stored route to Z) the packet of data for node Z.
- step 14 node Y forwards to node Z (in accordance with its own stored route to Z) the packet of data for node Z, completing the delivery of the data packet. Subsequent data packets exchanged between nodes W and Z may follow a similar procedure.
- connection establishment in step 11 of Figure 5 may comprise multiple steps. For example, it may be necessary for nodes W and Z to establish a logical connection (such as a PC5 unicast link and/or a PC5-RRC connection) in order to handle transmissions of application data between the two nodes. In addition or instead, it may be necessary for pairs of adjacent nodes in the mesh (for example, W and X, X and Y, Y and Z) to establish logical connections (such as PC5 unicast links, RRC connections, and/or PC5-RRC connections) in order to handle communication over the direct interface, reception and forwarding of data packets, control signalling, and so on.
- a logical connection such as a PC5 unicast link and/or a PC5-RRC connection
- pairs of adjacent nodes in the mesh for example, W and X, X and Y, Y and Z
- logical connections such as PC5 unicast links, RRC connections, and/or PC5-RRC connections
- connection establishment is shown in the figure as a single step, it may be broken up into multiple steps that may occur at different stages of the procedure.
- node X may establish a connection with node Y after step 7, when node X learns that node Y has a route to node Z.
- node X may establish a connection with node Y after step 12, when node X receives a data packet that needs to be forwarded to node Z (and hence requires connectivity between X and Y for the forwarding) .
- a logical connection established between the endpoint nodes (e.g., nodes W and Z) for the purpose of end-to-end data transmission may be associated with a different protocol structure from a logical connection established between adjacent nodes (e.g., nodes W and X) for the purpose of data forwarding; for example, the logical connection between the endpoints may be associated with higher-layer protocol entities that are not needed for the logical connection between the adjacent nodes.
- This protocol structure is discussed further in the context of Figure 6.
- Figure 6 shows an exemplary set of user-plane protocol stacks for a multi-hop connection in a mesh network in which the packet forwarding functionality is embodied in layer 2 of the protocol stack (a “layer 2 mesh network” ) , using the same node nomenclature and network topology as Figure 5.
- Nodes W and Z exchange data belonging to an upper layer, such as an internet protocol (IP) layer.
- IP internet protocol
- One or more layers of the protocol stacks below this upper layer may be terminated end-to-end between W and Z; the figure shows end-to-end termination of a service data adaptation protocol (SDAP) layer and a PDCP layer.
- SDAP service data adaptation protocol
- a layer of the protocol stacks may support relaying operation, through which transmissions from a first node can be forwarded to a second node that may not be topologically adjacent to the first node; the figure shows relaying operation in an SRAP layer.
- One or more layers of the protocol stacks may be terminated hop-by-hop between adjacent pairs of nodes in the mesh, such as between W and X, between X and Y, or between Y and Z; the figure shows hop-by-hop termination of a radio link protocol (RLC) layer, a medium access control (MAC) layer, and a physical (PHY) layer.
- RLC radio link protocol
- MAC medium access control
- PHY physical
- the IP and SDAP layers may be replaced by one or more control protocol layers, such as a PC5-RRC layer and/or a PC5-Slayer.
- control protocol layers such as a PC5-RRC layer and/or a PC5-Slayer.
- These user-plane and/or control-plane protocol stacks may allow, for example, the maintenance and use of end-to-end radio bearers between nodes W and Z for the transport of data (including user data and/or control signalling) .
- Some functions, such as security may be necessary to terminate end-to-end between nodes W and Z, so that intermediate nodes such as X and Y do not have access to the cleartext contents of packets exchanged between W and Z.
- Security may, for example, be maintained as a function of the PDCP layer. In some embodiments, security may be maintained in a higher layer (not shown in the figure) , such as an IPsec layer above or in place of the IP layer.
- protocol stacks can be considered for mesh network operation without substantially affecting the discovery procedures and related route-finding functionality.
- a “layer 3 mesh network” in which the packet forwarding functionality is embodied in a higher layer of the protocol stack (for example, an IP layer) may employ the discovery procedures described herein.
- FIG. 7 shows an example of discovery protocol stacks, in which discovery is controlled by a PC5-Sprotocol.
- PC5-Sprotocol (Other upper-layer protocols comprising discovery signalling may be substituted for PC5-Sin Figure 7. )
- a PC5-Slayer, a PDCP layer, an RLC layer, a MAC layer, and a PHY layer are all terminated hop-by-hop between adjacent nodes in the mesh. In other words, there is no exchange of discovery signalling between non-adjacent nodes.
- the endpoint nodes may terminate an entity of a control protocol such as PC5-Sfor other purposes besides discovery; for example, W and Z may establish end-to-end termination of a PC5-Sprotocol layer for maintenance of a PC5 unicast link, while also maintaining hop-by-hop termination of separate PC5-Sprotocol entities with their adjacent peer nodes (as shown in the figure) for discovery signalling.
- a control protocol such as PC5-Sfor other purposes besides discovery
- W and Z may establish end-to-end termination of a PC5-Sprotocol layer for maintenance of a PC5 unicast link, while also maintaining hop-by-hop termination of separate PC5-Sprotocol entities with their adjacent peer nodes (as shown in the figure) for discovery signalling.
- FIG 8 shows an exemplary mesh network, comprising both network nodes and mobile devices, that will be used to clarify subsequent descriptions of procedures.
- the mesh network contains two network nodes (Y and Z) and ten mobile nodes (A, B, C, D, E, F, G, H, J, and K-the letter I is omitted for readability) , variously connected with one another as shown in the figure.
- Each node has a routing table (not shown in the figure) that contains, at minimum, knowledge of its direct links to adjacent peer nodes.
- node H has a packet to transmit to the network, but H does not initially know a route to the network; it only knows the direct routes to its immediate peers C, F, and J. Accordingly, node H may transmit to its peers (by broadcast, groupcast, or unicast) one or more discovery messages soliciting a route to the network.
- the peer nodes that receive the discovery message (s) may apply the procedures previously described, together with various heuristics related to the topology of the network and the contents of their routing tables, to determine their responses.
- exemplary behaviours As exemplary behaviours:
- Node J has only one connection, to H itself; thus it may be unable to offer any useful routing information to H, and it may not respond to the discovery message (s) .
- node J may have information in its routing table concerning other nodes in the mesh, and although J itself is not a useful destination on a route to the network from H, J may respond with routing information about other nodes (for example, it may send a response indicating that node A has previously been indicated as having a connection to the network) .
- Node F has one connection other than its connection to H, to node D. Depending on the information in its routing table, F may apply any of several behaviours:
- F may respond with that information.
- F may send a response to the discovery message (s) with the information that F can serve as a next hop in a route to the network.
- the response may contain further information about the route (s) to the network, such as a number of hops (which, depending on the numbering convention, may be considered as two hops corresponding to intervening nodes D and A, or as three hops corresponding to the links F->D, D->A, and A->network) , information on the quality of the route, a full list of the hops constituting the route, etc.
- F may transmit a discovery message (either by forwarding the discovery message from H, or by originating a new discovery message of its own) to its other connection at node D. This transmission may eventually result in a multi-hop cascade of discovery messaging similar to the flow shown in Figure 5 and previously discussed, culminating in H learning a route to the network through F (for example, H->F->D->A->network and/or H->F->D->B->network) .
- Node C has one connection other than its connection to H, to node A. C may show similar behaviour to the alternatives described above for F.
- Node D if it receives a discovery message from F (as described in item 2c above) , may be aware based on information in its routing table that it has at least two possible links to the network, via node A and via node B. If D is not initially aware of these routes, it may learn one or both of them through transmitting discovery signalling to its neighbours A, B, and G according to the procedures previously described.
- Node D may be capable of evaluating the route (s) through G and determining that they are suboptimal when populating its own routing table.
- D may record the route G->E->B->network in its routing table, with the information that the route is four hops long, while also recording other, shorter routes with their own hop count information. This information in the routing table may be useful, for example, in case a shorter route to the network breaks, such as the case of link failure between D and B and/or between D and A.
- the shortest route may not be the best route. For example, if the link D->B is of poor quality but the links D->G, G->E, and E->B are all of good quality, it may be reasonable to deliver a packet via the longer path D->G->E->B->network rather than via the shorter (but potentially less reliable) path D->B->network. This longer path may be especially useful if a service has a high reliability requirement but can tolerate the latency of the additional hops.
- nodes with a connection to the network may employ a distinct “Model A-like” discovery procedure to advertise their availability.
- a and B may advertise to their neighbours that they are connected to the network, meaning that C, D, and E learn routes to the network.
- nodes C, D, and E may proceed to advertise themselves as having connectivity to the network; for example, if A advertises “I have a 1-hop link to the network” , C may subsequently advertise “I have a 2-hop link to the network” (or “I have a 2-hop link to the network via A” ) , potentially leading H to advertise “I have a 3-hop link to the network” (or “I have a 3-hop link to the network via C and A” ) .
- This propagation of network routes may reduce the need for discovery solicitations, at the cost of increased traffic in the network from the route advertisements.
- Figure 9 shows an exemplary message flow for the transmission of a packet to the network from node H in the network of Figure 8, presuming that node A proactively advertises its connection to the network and that other nodes subsequently advertise a route to the network via A. Not all nodes of the network are shown in the diagram, for space reasons, but the principles of the flow could be applied throughout the network as described herein.
- Step 0 of the figure comprises node A starting the procedure with awareness of its link to the network.
- step 1 node A transmits to its neighbour nodes (for example, by broadcast or groupcast) an announcement of its link to the network, which may, for instance, indicate that A has a 0-hop route to the network (using the convention that hops are counted based on intervening nodes-a direct connection is zero hops, a singly relayed connection is one hop, and so on) .
- the announcement of step 1 is received by the neighbour nodes C and D.
- step 2 C and D update their routing tables and announce their availability for routes toward the network.
- the announcements from nodes C and D may, for instance, indicate that C and D have 1-hop routes to the network.
- the announcement from node C is received by its neighbours A and H, and the announcement from node D is received by its neighbours A and F.
- Node A may discard the announcements from nodes C and D without updating its routing table, since the routes being advertised go through A itself. Alternatively, nodes C and D may avoid “re-advertising” the announcement to node A because node A appears in the route.
- H and F which received announcements in step 2, update their routing tables and announce their availability for routes toward the network. The announcement from node F is received by its neighbours D and H, and the announcement from H is received by its neighbours C, F, and J. Similar to the redundant routing information provided to node A in step 2, the information sent in step 3 to nodes C and D may be discarded or omitted, because the route being advertised by H goes through C, and the route being advertised by F goes through D.
- nodes F and H may each be aware of two distinct routes to the network: Node F knows the routes F->D->A->network and F->H->C->A->network, while node H knows the routes H->C->A->network and H->F->D->A->network.
- node H acquires (for example, from an application protocol layer) a packet for delivery to the network.
- node H consults its routing table to determine at least one next hop for transmission of the packet towards the network; in this instance, it selects node C as the next hop (this may, for example, be the result of preferring the route with the fewest hops) .
- H transmits the packet to C, the selected next hop.
- C consults its routing table, selects A as the next hop to the network, and transmits the packet to A.
- A delivers the packet to the network.
- a transmitting node may select more than one next hop, resulting in multiple transmissions of a particular packet towards the same ultimate destination. For example, in the flow of Figure 9, node H could select both C and F as valid next hops towards the network, resulting in transmitting two copies of the packet in step 6. Such packet duplication could be useful, for example, for high-reliability services where redundant transmission would help to meet a reliability requirement.
- a transmitting node may select different next hops for different packets, resulting in a diversity of routes towards the destination node for the packets.
- routing diversity could be useful, for example, in achieving higher data rates by transmitting on multiple links in parallel, or in increasing the chances that at least some packets of a particular flow reach the destination (in case the service can benefit from partial data reception, e.g., by allowing lost packets to be wholly or partially reconstructed through techniques like upper-layer coding) .
- connection establishment procedures are omitted from Figure 9, but they may be required before transmission of the packet in steps 6-8.
- H may avail itself of the advertised routes to establish a logical connection (for example, an RRC connection) with the network after step 3 of the figure (when a route to the network is available) or after step 4 (when the packet needs to be sent) .
- pairs of adjacent nodes in the mesh may establish connections with one another after exchanging discovery messaging and/or when a packet needs to be delivered.
- node H may establish a connection (for example, a PC5 unicast link and/or a PC5-RRC connection) with node C after step 2 (when it learns that C is a valid next hop to the network) or after step 5 (when it selects C as a next hop for transmission of a packet to the network) ; similarly, node C may establish a connection with node A after step 1 or after step 6, and node A may establish a connection with the network (for example, an RRC connection) at the beginning of the procedure or after step 7.
- a connection for example, a PC5 unicast link and/or a PC5-RRC connection
- node H When node H transmits its packet in step 6, it may include various pieces of routing information, such as an indication that the network is the destination, an indication of a preferred or required route to the network, a maximum number of hops or TTL, and so on. This information may be used by subsequent nodes (such as C and A in the example) for routing. In some embodiments, C may consult its routing table to select a next hop to the network after step 6 and before step 7, for example.
- Figure 10 using the same example network, shows a procedure in which a node is offered routes to different network nodes via a plurality of intermediary nodes.
- nodes A and B are aware of their direct links to the network nodes (Y and Z, respectively) .
- node A sends to its neighbours, C and D, an announcement of its link to the network
- node B sends to its neighbours, D and E, an announcement of its link to the network.
- the receiving nodes C, D, and E are assumed not to forward the announcement to their own neighbours (as described previously, such forwarding is technically possible, resulting in more nodes in the network having their routing tables populated with information about one or more routes to the network) .
- step 2 nodes C, D, and E all update their routing tables according to the announcements they received in step 1.
- step 3 node G generates a packet to be delivered to the network; since G has no route to the network, it needs to request a route from its neighbours.
- step 4 transmits to its neighbours, D, E, and K, a request for a route to the network, i.e., a discovery request for the network.
- the request in step 4 may comprise criteria for a desired route (e.g., a maximum hop count, quality-of-service criteria, etc. ) .
- the request may comprise information about a preferred network node, or it may be node-agnostic, i.e., it may indicate only that a route to some network node is needed.
- nodes D, E, and K consult their routing tables, with varying results: D determines that it has two routes to the network (via nodes A and B) , E determines that it has one route to the network (via B) , and K determines that it has no known route to the network.
- step 6 these nodes proceed according to the outcomes of step 5: D responds to G with an indication of at least one route to the network; E responds to G with an indication of a route to the network; and K does not respond to G, but instead sends to its own neighbour, E, a request for a route to the network, i.e., a discovery request for the network.
- the response from D in step 6 may contain an indication of multiple routes, detailed information about one or more of the routes, or only the information that at least one route exists.
- G updates its routing table according to the responses received from D and E in step 5, and E responds to K with an indication of a route to the network (the route via B) .
- G determines to send its packet to both D and E for routing to the network; this determination may reflect a reliability requirement of the underlying service, a throughput requirement of the underlying service, and so on. (In other examples, G might determine to send its packet to only one of D and E at this stage. )
- G consults its updated routing table to determine the next hop (s) for transmission of its packet towards the network, and K updates its routing table according to the response received from E in step 7.
- step 9 transmits its packet to D and E, which it selected as next hops in step 8, and K transmits to G an indication of a route to the network (the route via E that was indicated to K in step 7) .
- step 10 D and E consult their routing tables to determine respective next hops for the packet of which they received copies in step 9, and G updates its routing table according to the route received from K in step 9.
- different nodes D, E and K
- different nodes independently handle the route request from G and then may independently respond by sending corresponding route information back to G.
- the route information received from node K comes a bit late compared to the route information from nodes D and E, as node K needs to exchange with other nodes before the feedback.
- node G’s perspective it will update the routing table in case of valid route information received.
- node G can proceed to route the packet according to its own decision.
- This decision may be governed, for instance, by the availability of the discovered route (s) , by a supervisory timer determining when the packet needs to be transmitted, by taking into account the allowable latency for the packet, by considering the quality of the available routes, and so on.
- G determines to transmit an additional copy of its packet to K for forwarding to the network; in other examples, G may determine that the packet has already been transmitted into the mesh and another copy does not need to be sent.
- D forwards the packet to its neighbours A and B
- E forwards the packet to its neighbour B
- G transmits the additional copy of the packet to K.
- step 12 B recognises that it has received a duplicate copy of the packet in step 11 (i.e., it has received copies from both D and E) and may discard a copy of the packet, and K consults its routing table to determine a next hop for transmission of the packet. In accordance with the route received by K in step 7, K selects E as the next hop towards the network.
- the duplicate detection at B in this step may be carried out in an SRAP layer or a similar protocol layer responsible for routing functionality in the mesh.
- B may not perform duplicate detection, and subsequent steps may involve transmission of additional copies of the packet as a result, with the assumption that duplicates will be handled in other stages of the procedure (for instance, in an upper protocol layer after copies of the packet are received by the network) .
- step 13 A and B consult their routing tables to determine respective next hops for transmission of the packet, and K forwards the packet to E in accordance with the selection in step 12.
- step 14 A and B forward the packet to network nodes Y and Z respectively, and E recognises that it has previously forwarded this packet and may discard it as a duplicate. In some embodiments, E may continue to transmit the packet at this stage instead of discarding it, as a reliability measure in case previous copies of the packet have been lost.
- step 14 the packet has been successfully delivered to the network (twice) , no further copies of the packet are circulating in the mesh, and the procedure is complete.
- the network may subsequently handle the duplicated packet according to various well-known techniques to prevent duplicate data from being delivered to an application layer; for example, a protocol layer, such as a PDCP layer, may be shared between the two network nodes Y and Z, and such a layer may perform duplicate detection.
- a protocol layer such as a PDCP layer
- Node G which wishes to exchange data with the network, may need to establish a connection, such as an RRC connection, with the network during the process (for example, after step 6, when G first learns a route to the network) , and it may use the routing facilities of the mesh network to exchange control signalling with the network to establish such a connection before transmitting a user data packet. If G establishes a connection with a specific network node-for instance, node Y-at this stage, G may select one or more next hops for transmission of its packet based on their ability to route to node Y specifically.
- a connection such as an RRC connection
- G establishes a connection with a plurality of network nodes-for instance, dual connectivity with nodes Y and Z-then G may transmit its packet to neighbour nodes that can offer a route to any of the network nodes with which G has a connection.
- a connection for example, a PC5-RRC connection
- nodes D and E may establish connections with nodes D and E during the procedure (for example, after step 8, when G has determined that it will transmit its packet to both D and E) .
- such adjacent pairs of nodes may terminate one or more protocol layers between them (such as a PC5-RRC protocol, a PC5-Sprotocol, and so on
- Figure 11 shows a procedure in which a first mobile node, using a discovery procedure similar to Model B as described previously, determines a route to a second mobile node.
- node E wishes to transmit a packet of data to node H.
- each node has no routing information other than the direct links to its neighbours in the mesh.
- Each route request and response is shown with a sequence number, to help distinguish which messages are responsive to one another.
- step 1 of the figure node E generates a packet for transmission to node H, and since E does not have H in its routing table, it starts a discovery procedure to determine a route to H.
- E sends a route request to its neighbours, B, G, and K.
- the three route requests of step 2 may comprise a single message sent by broadcast or unicast, but they are shown separately in the flow diagram and given separate sequence numbers (1, 2, and 3 respectively) , to help associate them with their separate responses.
- the nodes respond to step 2: B determines that it does not have H in its routing table, so it sends a route request to its neighbour, D. (B may omit sending a route request to E, since it just received the route request from E in step 2; alternatively, if the route request is sent by broadcast/groupcast, for instance, E may receive the route request, recognise that it already has a discovery operation in progress for the same target node, and discard the route request.
- step 4 G determines that it does not have H in its routing table, so it sends route requests to its neighbours, D and K; and K determines that it does not have H in its routing table, so it sends a route request to its neighbour, G.
- nodes G and K which received route requests in step 3, may recognise that they have no constructive way to respond to these requests (each node has already sent a route request to all its neighbours) , so they may take no action, while node D, which received two route requests from B and G in step 4, sends route requests to its remaining neighbours, A and F.
- step 5 a breakthrough occurs, in that F determines that it knows a route to H; accordingly, F sends a route response to D (closing transaction number 8 in the figure) , while A, which does not know a route to H, sends a route request to its neighbour, C.
- step 6 C, which does know a route to H, sends a route response to A (closing transaction number 10) , while D, which has learned from the response in step 5 a route to H via F, sends route responses to both B and G (closing transactions 4 and 5) .
- step 7 the responses continue: B has now learned a route to H (via D and F) , so B sends a route response to E (closing transaction number 1) ; G has now learned a route to H (via D and F) , so G sends a route response to E (closing transaction number 2) ; and A has now learned a route to H (via C) , so A sends a route response to D (closing transaction number 9) .
- node E has been informed of two routes to the destination H, so E may now opt to transmit its packet on one route or both (not shown in the figure) , or it may delay transmission while waiting for further route responses; this decision may be governed, for instance, by a supervisory timer determining when the packet needs to be transmitted, by taking into account the allowable latency for the packet, by considering the quality of the available routes, and so on.
- step 8 D has learned an additional route to H via A and C, so D may send a route response to G; however, since D previously sent a route response to G in step 6, D may determine that a second route response is unwarranted (e.g., because the new route via A and C contains more hops than the previously indicated route via F) and omit sending the additional route response. If D sends a route response in step 8, G learns an additional route to H (G->D->A->C->H) , and in step 9, G may send a route response to E.
- G may determine whether to send (an additional copy of) the packet on this new route (not shown in the figure) . This determination may be governed by the reliability and/or latency requirements of an underlying service for the packet, for example.
- a first exemplary algorithm concerns the handling of route requests, as follows:
- a first route request for a destination node X is received from a neighbour node Y for a source node Z, record the reception of the route request (potentially including metadata such as a sequence number, a transaction identifier, and so on) , consult the routing table for a route to X, and proceed to step 2.
- route response to Y indicating information about the route (potentially including quality information for the route, a number of hops in the route, a list or sequence of the nodes in the route, etc., and potentially including more than one route in the response) .
- the second route request of step 3 may be omitted, for example, if the first route request contains a hop count limit or TTL that would be exceeded by the second route request, or if the quality of the link to Y is below a threshold, where link quality may be defined, for example, by a reference signal received power (RSRP) or a reference signal received quality (RSRQ) .
- RSRP reference signal received power
- RSRQ reference signal received quality
- a second exemplary algorithm concerns the handling of route responses, as follows:
- the first route response of step 2 may be omitted, for example, if any second route response for destination node X was previously sent to V; if a second route response for destination node X was previously sent to V, and the route in the second route response is considered as a better route than the route in the first response, based on various criteria such as one or more link qualities (e.g., RSRP/RSRQ) , one or more link weights, a hop count, etc.; if the quality of the route in the first route response is below a threshold, where route quality may be defined by various metrics such as one or more link qualities (e.g., RSRP/RSRQ) , one or more link weights, etc.; if the hop count of the route in the first route response exceeds a threshold; and so on.
- link qualities e.g., RSRP/RSRQ
- link weights e.g., a hop count, etc.
- a discovery procedure (comprising, for example, an exchange of discovery messages as described herein, including information for managing routes between nodes in the mesh) may be accompanied or followed by the establishment of one or more connections between nodes.
- a discovery procedure comprising, for example, an exchange of discovery messages as described herein, including information for managing routes between nodes in the mesh
- E may initiate a procedure to establish a connection (for example, a PC5-RRC connection) with H.
- E may initiate a procedure to establish one or more connections with neighbouring nodes for the purpose of communication via the mesh with H.
- Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C.
- combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
This disclosure describes methods of discovery and connection management in a mesh network. In the described methods, a first node in the mesh network responds to a discovery request for a destination node by either sending a discovery response to the requesting node if the first node has a route to the destination node, or sending a discovery request for the destination node to at least one neighbour node if the first node does not have a route to the destination node. A node in the mesh network responds to a discovery response or discovery announcement by updating its routing table, and potentially by sending the discovery response or discovery announcement onward to its neighbour nodes. After determining a route to a destination node, for example, from a discovery response or discovery announcement, a node in the mesh network may establish a connection with the destination node and/or one or more neighbour nodes. A node in the mesh network that has a direct connection to a node of a cellular network may announce to other nodes in the mesh network that it has such a direct connection.
Description
This disclosure relates to wireless communications, and specifically to a procedure for establishing routes between nodes during discovery in a mesh network that relies on relaying functionality in the nodes of the mesh. The procedure is illustrated with reference to relaying functionality embodied in layer 2 of a protocol stack, but it may also be applied to other settings such as a mesh with relaying at layer 3.
In the existing art for direct device-to-device communication using the LTE and NR “sidelink” technology, two discovery models are provided for devices in proximity to discover one another’s existence and interest in establishing communication. In Model A (also described as “I am here” ) , a first user equipment (UE) , also described as an announcing UE, transmits an announcement indicating that it offers a particular service, and a second UE, also described as a monitoring UE, receives the announcement and may determine to establish a connection for communication with the announcing node. In Model B (also described as “Who is there? ” ) , a first UE, also described as a discoverer UE, transmits a solicitation indicating that it seeks a particular service, and a second UE, also described as a discoveree UE, may transmit a response indicating that it offers the requested service.
In direct device-to-device communication, or in single-hop UE-to-network relaying (as supported for the NR sidelink in 3GPP Rel-17) , UEs only need to discover other UEs with which they will communicate directly. However, in a multi-hop relaying scenario wherein devices communicate via a plurality of intermediary relay devices, or in a mesh network where devices communicate as peers via packet forwarding through a path established among multiple peer devices, a first device may have a need to discover a second device that is distant from the first device in terms of the network topology. For example, a first UE W may seek communication with a second UE Z, but the network path from W to Z may pass through relay UEs X and Y. In such a situation, UEs W and Z may need to carry out a discovery procedure mediated by UEs X and Y. As a result of this discovery procedure, UEs W and Z should learn not only of each other’s existence and availability to communicate, but also of the network route connecting them. For example, UE W may determine that to deliver a packet to UE Z, it should first send the packet to UE X, with additional routing information indicating that the ultimate destination of the packet is UE Z.
In Rel-17 layer 2 UE-to-network relaying, a protocol layer, called Sidelink Relay Adaptation Protocol (SRAP) , carries out certain routing and mapping functions, including identifying the destination of a packet. A header format of the SRAP protocol may contain a field identifying the involved remote UE. In UE-to-network relaying, this field is used in the downlink direction to identify which remote UE should receive a packet from the network. A relay UE receives the packet from the network, consults the SRAP header to determine which remote UE is the destination, and forwards the packet to the remote UE (while also applying additional functions such as bearer mapping) . The existing SRAP behaviour is not designed for a multi-hop or mesh environment; the protocol assumes that the relay UE has a unique connection directly to the destination remote UE. (In the uplink direction, the same or an analogous field may identify which remote UE is the source of the packet. In the existing design for single-hop UE-to-network relaying, the relay UE does not depend on this information for packet routing, since in the uplink direction the relay UE always forwards packets to the network, but the receiving network node relies on this field to distinguish which UE context the received packet should be associated with. )
SUMMARY
The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
In an aspect of the disclosure, a method of discovery in a first node is provided. The first node receives, from a first neighbour node, a first discovery request comprising at least a request for a route to a destination node. If a routing table of the first node contains at least one route to the destination node, the first node sends, to the first neighbour node, a discovery response comprising information about the at least one route. If the routing table of the first node does not contain at least one route to the destination node, the first node sends, to a second neighbour node, a second discovery request comprising a request for a route to the destination node.
In another aspect of the disclosure, a method of discovery in a first node is provided. The first node receives, from a first neighbour node, a first discovery message comprising first information about at least one route to a destination node. The first node updates a routing table of the first node by adding the at least one route. The first node transmits, to a second neighbour node, a second discovery response message comprising second information about the at least one route.
In another aspect of the disclosure, a method of discovery in a first node is provided. The first node has a radio connection to a second node. The first node transmits, to a third node, a discovery announcement comprising the information that the first node has a radio connection to the second node, wherein the second node is a node of a cellular network.
In another aspect of the disclosure, a method of connection management in a source node is provided. The source node receives, from a neighbour node, a discovery message comprising at least a first route to a destination node. The source node adds the at least a first route to a routing table of the source node. The source node selects, based on information in the routing table, at least a second route to the destination node. The source node transmits, to the destination node via the at least a second route, a first control message of a protocol.
To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.
FIG. 1 is a diagram illustrating an example of delivery of a packet in a mesh network of UEs.
FIG. 2 is a diagram illustrating an example of a mesh in which a distinguished UE can operate as a gateway to a network node.
FIG. 3 illustrates an example of a discovery procedure in which an announcing node informs a monitoring node that the announcing node has a connection to the network.
FIG. 4 illustrates an example of a discovery procedure in which a discoverer node requests from a discoveree node a route to a destination node.
FIG. 5 illustrates an example of a discovery procedure in a mesh network comprising the maintenance of routing tables at a plurality of nodes and the delivery of a packet.
FIG. 6 illustrates an example of a user-plane protocol stack for a layer 2 mesh network.
FIG. 7 illustrates an example of a discovery protocol stack for a mesh network.
FIG. 8 is a diagram illustrating an example of a mesh network topology.
FIG. 9 illustrates an example of a discovery procedure in a mesh network where a distinguished node has a link to a cellular network.
FIG. 10 illustrates an example of a discovery procedure in a mesh network where a source node is provided with a plurality of routes to a node of a cellular network.
FIG. 11 illustrates an example of a discovery procedure in a mesh network where a source node is provided with at least one route to a destination node.
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
In a mesh network, a plurality of nodes communicate as peers, with a packet of data potentially handled by many peer devices on its way from a source device to a destination device. At each peer device, the “next hop” taken by the packet may be determined by consulting a routing table stored at the peer device. Various methods of determining a next hop from a routing table may be applied; for instance, a simple routing table may consist only of a list of destinations, each with a single associated next hop, and the peer device may perform routing by looking up a packet’s destination in the routing table and passing the packet to the associated next hop. A more sophisticated routing table may contain additional information, such as, for example, multiple candidate next hops for a given destination, information about the complete path between the peer node and the destination, measures of link quality for the link to a next-hop candidate, and so on. This additional information may be needed, for instance, to adapt to a changing network topology, to select a route with good link quality to the destination, or to prevent routing loops in which a packet revisits the same node repeatedly rather than progressing towards its destination.
Throughout this disclosure, we distinguish between a “mesh” or “mesh network” , which may comprise a mixture of cellular network nodes and mobile devices, and a “network” or “cellular network” , which comprises the network nodes of a conventional cellular system, such as base stations, core network nodes, and so on. When the term “network” is used without qualification, it refers to a cellular network.
Figure 1 shows a mesh network of UEs, with the route taken by a particular packet shown in red. The packet originates at UE A and is delivered to UE F. UE A determines from its routing table that its best (in this case, only) next hop towards UE F is UE B, so it delivers the packet to UE B. UE B, upon receiving the packet, recognises that it is intended for UE F, and consults its own routing table. Considering the mesh network topology shown in the figure, UE B may have both UE C and UE D available as next hops towards UE F. However, the route through UE D may be preferred to the route through UE C (for example, due to requiring a smaller number of hops: B->D->F requires two hops, while B->C->D->F requires three hops) , and accordingly, UE B delivers the packet to UE D. Similarly, UE D may have multiple candidates for a next hop to UE F; as shown, one such candidate may be UE F itself, while another may be UE E. UE D determines that the direct route to UE F is preferred, and delivers the packet to UE F. UE F receives the packet, recognises that it is the destination node, and processes the packet accordingly (for example, by passing it to upper layers) . The criteria used by a UE in the mesh to determine the preferred next hop for a packet may be specified or implementation-dependent.
As shown in Figure 2, a first node in the mesh network (such as UE A in the figure) may maintain a direct connection to a network node (for example, a base station) . In such a case, the first node may act as a gateway to the cellular network for other nodes in the mesh. The first node, acting as an announcing node, may announce its ability to serve as a gateway with a first discovery message. The first discovery message is functionally similar to the discovery announcement in Model A in LTE or NR sidelink discovery, but has the special semantics “I have a link to the network” . Neighbouring UEs acting as monitoring nodes, such as UEs B and C in the figure, may receive the discovery message and record the information that UE A has a connection to the network. This information may be recorded, for instance, in a routing table. In some embodiments, the information may be further propagated to other nodes in the mesh. As an example, UE B may inform UE D that UE A has a link to the network. Subsequently, UE D may record the routing information involving UE B and/or UE A in its routing table, and if UE D needs to transmit a packet to the network, UE D may consider UE A as an intermediate destination on the packet’s route.
Figure 3 shows a discovery procedure with route information with some similarities to discovery Model A. In step 1, the announcing node transmits a discovery announcement, indicating that the announcing node has connectivity to a network (for instance, to a base station or a cell of an operator’s cellular network) . Within the discovery announcement, the identity of a base station or a cell may be included. In step 2, the monitoring node performs a discovery match and determines that it has an interest in communication with the network via the announcing node. In step 3, the monitoring node updates its routing table with information from the message in step 1, e.g., the information that the announcing node can be used as a next hop or an intermediate destination for transmission of packets towards the network. In step 4, the monitoring and announcing nodes establish a connection; this step may, for instance, use signalling of a PC5 signalling (PC5-S) protocol and/or a PC5 radio resource control (PC5-RRC) protocol. In step 5, the monitoring node transmits a packet to the announcing node for forwarding to the network. In step 6, the announcing node forwards the packet towards the network.
In a mesh network with a small number of nodes, a flow similar to that of Figure 3 may be suitable for announcing routes to other nodes in the mesh. For example, an announcing node may transmit in its discovery signalling a list of all the nodes with which it has direct links, a list of all the nodes in the mesh to which it knows a route, or a list of selective nodes which it has links. However, in a larger mesh, the size of such an announcement message may be problematic, especially if many nodes announce their routing information at once. Such signalling in a mesh with many nodes could be expected to cause a high level of congestion and consume a large amount of bandwidth. In addition, much of the discovery signalling in such a scenario may be redundant: For example, UE A announces that it has a link with UE B, and UE B also announces that it has a link with UE A. Thus, it is considered that the model of Figure 3 may be most suitable for the specific case of announcing links to the network, rather than as a general solution to distributing routing table information in a mesh network.
Figure 4 shows a discovery procedure with route information with some similarities to discovery Model B. The procedure of Figure 4 may be seen as complementary to the procedure of Figure 3, and it is reasonable for both procedures to coexist in a mesh. For example, the procedure of Figure 3 may be used to announce links to the network, and the procedure of Figure 4 may be used to determine links between devices. In step 1 of Figure 4, the discoverer node generates traffic to be transmitted to node X (not shown) , to which the discoverer node does not know a route. In step 2, the discoverer node transmits (for instance, by broadcast) a first discovery message comprising a request for a route to node X, and the first discovery message is received by one or a plurality of discoveree nodes. (Figure 4 shows only a single discoveree node, but it should be appreciated that the same or similar steps may be carried out by multiple discoveree nodes independently. ) In step 3, the discoveree node consults its routing table and finds that it knows at least one route to node X. Step 3 may comprise a selection by the discoveree node of a preferred route from among a plurality of known routes to node X; alternatively, step 3 may identify a plurality of routes to node X instead of selecting a single preferred route. There may be multiple discoveree nodes involved within step 3, and as a consequence, each discoveree node finds at least one route towards node X independently; a single discoveree node is shown in the figure, but the same steps may be carried out by any additional discoveree nodes. (Other nodes may also receive the first discovery message, but find that they do not know any route to node X; such other nodes may determine not to respond to the first discovery message, and hence they may not function as discoveree nodes. ) In step 4, the discoveree node sends a second discovery message to the discoverer node, comprising an indication of at least one route to node X. The indication in the second discovery message may comprise detailed information about the route (for example, a number of hops, a weighting or quality measurement of the route, a list of all nodes on the route, etc. ) , or it may only indicate that a route to X through the discoveree node exists. The message of step 4 may be sent using any “cast type” ; that is, the message may be sent by unicast (to the discoverer node only) , by broadcast (to any node that can receive it) , or by groupcast (to an identified set of nodes including the discoverer node) . In step 4, the discoverer node may receive multiple discovery responses (i.e., the second discovery message) from a plurality of discoveree nodes. In step 5, the discoverer node receives the second discovery message and updates its routing table with the information that the discoveree node is a potential next hop for a route to node X. The information in the routing table may take various forms. The update to the routing table may comprise storing only the information that the discoveree node can be used as a next hop for delivery to X; alternatively, the update to the routing table may comprise storing further information about at least one route from the discoveree node to node X, such as a number of hops, a weighting or quality assessment of the route, a list of all nodes on the route, etc. The information stored in the routing table may comprise information extracted from the second discovery message, and/or it may comprise information determined by the discoverer node; for example, the discoverer node may infer a quality of the route from itself to node X based on a combination of information about its link to the discoveree node and any information provided by the discoveree node about the quality of the route from the discoveree node to node X. The discoverer node may also store the information that it now knows at least one route to node X, so that a subsequent discovery procedure initiated by a different node in the role of the discoverer node may cause this node to act as the discoveree node for a route to node X. In step 6, the discoverer node establishes a connection (for example, a PC5 unicast link and/or a PC5-RRC connection) with the discoveree node. In step 7, the discoverer node transmits a packet of data to the discoveree node for delivery to node X. In addition to the data packet itself, the transmission of step 7 may comprise routing information, such as an identification of a preferred route to node X, an intermediate destination to be used in the route to node X, a maximum number of hops or time-to-live (TTL) for the packet, and so on. In step 8, the discoveree node forwards the packet along an identified route towards node X. The forwarding in step 8 may comprise establishment of a connection by the discoveree UE with a node included in the route to X. The transmission of step 8 may comprise routing information, such as an identification of a preferred route to node X, an intermediate destination to be used in the route to node X, a maximum number of hops or TTL for the packet, and so on; in such a case, the routing information may be derived from routing information provided by the discoverer node in step 7 (for example, information in a header of the packet that was transmitted at step 8) and/or from information known to the discoveree node.
In the description of the subsequent figures, for succinctness, we use the phrases “discovery request for X” and/or “route request for X” to mean “discovery request comprising a request for a route to node X” , and “discovery response for X” and/or “route response for X” to mean “discovery response comprising information on a route to node X” . Step 2 of Figure 4 is an example of a discovery request for X, and step 4 of Figure 4 is an example of a discovery response for X.
Figure 5 shows an example of route discovery in a mesh network, involving multiple hops between the source and destination of a data packet. The mesh network of Figure 5 comprises (at least) four nodes W, X, Y, and Z, connected in a linear fashion (W<->X<->Y<->Z) , where each node initially knows only the routes to its immediate neighbours. Accordingly, in step 0 of the figure, the initial condition of the routing tables is that node W knows the (single-hop) route to X, node X knows the (single-hop) routes to W and Y, node Y knows the (single-hop) routes to X and Z, and node Z knows the (single-hop) route to Y. In step 1 of Figure 5, node W determines that it has traffic (in the broadest sense, comprising any data to transmit, such as service establishment information, control signalling, user data, or any other information) to deliver to node Z. In step 2, node W consults its routing table and determines that it does not know a route to Z; accordingly, it initiates discovery to find a neighbour node in the mesh with a route to Z. In step 3, node W transmits a first discovery request for Z. The discovery request may be sent by unicast to node X (the only neighbour to which node W knows a route) , by groupcast to a group address for a group that includes node X, by broadcast to any node that can receive the message, and so on. In step 4, node X receives the discovery request, consults its own routing table, and determines that it does not know a route to Z. In step 5, node X transmits a second discovery request for Z; this message may comprise a forwarded copy of the first discovery request from step 3, or it may be a new message generated by node X, with or without information copied from the message in step 3. In step 6, node Y receives the second discovery request, consults its routing table, and determines that it knows a route to Z, specifically the direct route Y->Z. In step 7, node Y sends a first discovery response for Z, comprising information about the route to Z; this message may comprise an explicit description of the route, partial information about the route such as a hop count and/or a quality metric, or only the information that a route exists. The first discovery response may comprise identifying information, such as a transaction identifier and/or a sequence number, that associates it with the second discovery request. In step 8, node X receives the first discovery response and updates its routing table with the information that Y is a valid next hop or intermediate destination for a route to Z; any information derived from the first discovery response may, at this stage, be stored in the routing table at X. In step 9, X determines that it now knows a route to Z, and it responds to the first discovery request by transmitting to W a second discovery response for Z. The second discovery response may comprise any information about the route to Z. The second discovery response may comprise identifying information, such as a transaction identifier and/or a sequence number, that associates it with the first discovery request. In step 10, node W receives the second discovery response and updates its routing table to include at least a route to Z. Depending on the information provided in the second discovery response in step 9, node W may populate its routing table with additional information, such as a route to Y, as well as any available information about the route from X to Z. Since node W now knows a route through the mesh to node Z, it can begin preparations for transmitting its data to Z. In step 11, any necessary connection establishment between nodes takes place; this step is further discussed in the next paragraph. In step 12, node W transmits to node X (in accordance with its stored route to Z) a packet of data for node Z. The packet of data may comprise a PDU of a protocol layer responsible for handling packet data, such as a packet data convergence protocol (PDCP) layer. The contents of the packet of data may comprise user data, control signalling, service establishment information, or any other information. ) In step 13, node X forwards to node Y (in accordance with its own stored route to Z) the packet of data for node Z. In step 14, node Y forwards to node Z (in accordance with its own stored route to Z) the packet of data for node Z, completing the delivery of the data packet. Subsequent data packets exchanged between nodes W and Z may follow a similar procedure.
The connection establishment in step 11 of Figure 5 may comprise multiple steps. For example, it may be necessary for nodes W and Z to establish a logical connection (such as a PC5 unicast link and/or a PC5-RRC connection) in order to handle transmissions of application data between the two nodes. In addition or instead, it may be necessary for pairs of adjacent nodes in the mesh (for example, W and X, X and Y, Y and Z) to establish logical connections (such as PC5 unicast links, RRC connections, and/or PC5-RRC connections) in order to handle communication over the direct interface, reception and forwarding of data packets, control signalling, and so on. Although connection establishment is shown in the figure as a single step, it may be broken up into multiple steps that may occur at different stages of the procedure. For example, node X may establish a connection with node Y after step 7, when node X learns that node Y has a route to node Z. Alternatively, node X may establish a connection with node Y after step 12, when node X receives a data packet that needs to be forwarded to node Z (and hence requires connectivity between X and Y for the forwarding) . It is noted that, with the exception of the “endpoint” nodes W and Z, it may not be necessary to establish logical connections between non-adjacent nodes of the mesh (for instance, between W and Y, or between X and Z) . A logical connection established between the endpoint nodes (e.g., nodes W and Z) for the purpose of end-to-end data transmission may be associated with a different protocol structure from a logical connection established between adjacent nodes (e.g., nodes W and X) for the purpose of data forwarding; for example, the logical connection between the endpoints may be associated with higher-layer protocol entities that are not needed for the logical connection between the adjacent nodes. This protocol structure is discussed further in the context of Figure 6.
Figure 6 shows an exemplary set of user-plane protocol stacks for a multi-hop connection in a mesh network in which the packet forwarding functionality is embodied in layer 2 of the protocol stack (a “layer 2 mesh network” ) , using the same node nomenclature and network topology as Figure 5. Nodes W and Z exchange data belonging to an upper layer, such as an internet protocol (IP) layer. One or more layers of the protocol stacks below this upper layer may be terminated end-to-end between W and Z; the figure shows end-to-end termination of a service data adaptation protocol (SDAP) layer and a PDCP layer. A layer of the protocol stacks may support relaying operation, through which transmissions from a first node can be forwarded to a second node that may not be topologically adjacent to the first node; the figure shows relaying operation in an SRAP layer. One or more layers of the protocol stacks may be terminated hop-by-hop between adjacent pairs of nodes in the mesh, such as between W and X, between X and Y, or between Y and Z; the figure shows hop-by-hop termination of a radio link protocol (RLC) layer, a medium access control (MAC) layer, and a physical (PHY) layer. In an analogous control-plane protocol stack (not shown) , the IP and SDAP layers may be replaced by one or more control protocol layers, such as a PC5-RRC layer and/or a PC5-Slayer. These user-plane and/or control-plane protocol stacks may allow, for example, the maintenance and use of end-to-end radio bearers between nodes W and Z for the transport of data (including user data and/or control signalling) . Some functions, such as security, may be necessary to terminate end-to-end between nodes W and Z, so that intermediate nodes such as X and Y do not have access to the cleartext contents of packets exchanged between W and Z. Security may, for example, be maintained as a function of the PDCP layer. In some embodiments, security may be maintained in a higher layer (not shown in the figure) , such as an IPsec layer above or in place of the IP layer.
Other forms of protocol stacks can be considered for mesh network operation without substantially affecting the discovery procedures and related route-finding functionality. For example, a “layer 3 mesh network” in which the packet forwarding functionality is embodied in a higher layer of the protocol stack (for example, an IP layer) may employ the discovery procedures described herein.
It should be noted that discovery operations between nodes in a mesh network may employ different protocol stacks compared to data communication. Figure 7 shows an example of discovery protocol stacks, in which discovery is controlled by a PC5-Sprotocol. (Other upper-layer protocols comprising discovery signalling may be substituted for PC5-Sin Figure 7. ) In the figure, a PC5-Slayer, a PDCP layer, an RLC layer, a MAC layer, and a PHY layer are all terminated hop-by-hop between adjacent nodes in the mesh. In other words, there is no exchange of discovery signalling between non-adjacent nodes. In some embodiments, the endpoint nodes (in this example, W and Z) may terminate an entity of a control protocol such as PC5-Sfor other purposes besides discovery; for example, W and Z may establish end-to-end termination of a PC5-Sprotocol layer for maintenance of a PC5 unicast link, while also maintaining hop-by-hop termination of separate PC5-Sprotocol entities with their adjacent peer nodes (as shown in the figure) for discovery signalling.
Figure 8 shows an exemplary mesh network, comprising both network nodes and mobile devices, that will be used to clarify subsequent descriptions of procedures. The mesh network contains two network nodes (Y and Z) and ten mobile nodes (A, B, C, D, E, F, G, H, J, and K-the letter I is omitted for readability) , variously connected with one another as shown in the figure. Each node has a routing table (not shown in the figure) that contains, at minimum, knowledge of its direct links to adjacent peer nodes.
Suppose that, in the mesh network of Figure 8, node H has a packet to transmit to the network, but H does not initially know a route to the network; it only knows the direct routes to its immediate peers C, F, and J. Accordingly, node H may transmit to its peers (by broadcast, groupcast, or unicast) one or more discovery messages soliciting a route to the network. The peer nodes that receive the discovery message (s) may apply the procedures previously described, together with various heuristics related to the topology of the network and the contents of their routing tables, to determine their responses. As exemplary behaviours:
1. Node J has only one connection, to H itself; thus it may be unable to offer any useful routing information to H, and it may not respond to the discovery message (s) . Alternatively, node J may have information in its routing table concerning other nodes in the mesh, and although J itself is not a useful destination on a route to the network from H, J may respond with routing information about other nodes (for example, it may send a response indicating that node A has previously been indicated as having a connection to the network) .
2. Node F has one connection other than its connection to H, to node D. Depending on the information in its routing table, F may apply any of several behaviours:
2a. If F’s routing table contains the information that A has a route to the network (but not an actual route to A) , F may respond with that information.
2b. If F’s routing table contains the information that A has a route to the network (for example, the route F->D->A->network) , together with routing information to reach A, F may send a response to the discovery message (s) with the information that F can serve as a next hop in a route to the network. In this case the response may contain further information about the route (s) to the network, such as a number of hops (which, depending on the numbering convention, may be considered as two hops corresponding to intervening nodes D and A, or as three hops corresponding to the links F->D, D->A, and A->network) , information on the quality of the route, a full list of the hops constituting the route, etc.
2c. If F’s routing table does not contain information on a route to the network, F may transmit a discovery message (either by forwarding the discovery message from H, or by originating a new discovery message of its own) to its other connection at node D. This transmission may eventually result in a multi-hop cascade of discovery messaging similar to the flow shown in Figure 5 and previously discussed, culminating in H learning a route to the network through F (for example, H->F->D->A->network and/or H->F->D->B->network) .
3. Node C has one connection other than its connection to H, to node A. C may show similar behaviour to the alternatives described above for F.
4. Node D, if it receives a discovery message from F (as described in item 2c above) , may be aware based on information in its routing table that it has at least two possible links to the network, via node A and via node B. If D is not initially aware of these routes, it may learn one or both of them through transmitting discovery signalling to its neighbours A, B, and G according to the procedures previously described.
5. The possibility of discovery signalling being transmitted from D to G is of interest, because G has routes to the network that do not pass through D (G->E->B->network and G->K->E->B->network) . Accordingly, if D solicits a route to the network, G may respond to the solicitation. It may appear that from D’s perspective, the routes to the network through G are suboptimal, since they all involve extra hops compared to the more direct route D->B->network. However, the following issues should be noted.
5a. Node D may be capable of evaluating the route (s) through G and determining that they are suboptimal when populating its own routing table. As one example, D may record the route G->E->B->network in its routing table, with the information that the route is four hops long, while also recording other, shorter routes with their own hop count information. This information in the routing table may be useful, for example, in case a shorter route to the network breaks, such as the case of link failure between D and B and/or between D and A.
5b. If other criteria besides route length (for example, the quality of radio links) are considered in the evaluation of routes, the shortest route may not be the best route. For example, if the link D->B is of poor quality but the links D->G, G->E, and E->B are all of good quality, it may be reasonable to deliver a packet via the longer path D->G->E->B->network rather than via the shorter (but potentially less reliable) path D->B->network. This longer path may be especially useful if a service has a high reliability requirement but can tolerate the latency of the additional hops.
6. As previously described, nodes with a connection to the network, such as A and B in the figure, may employ a distinct “Model A-like” discovery procedure to advertise their availability. Thus, for instance, A and B may advertise to their neighbours that they are connected to the network, meaning that C, D, and E learn routes to the network. In some embodiments, nodes C, D, and E may proceed to advertise themselves as having connectivity to the network; for example, if A advertises “I have a 1-hop link to the network” , C may subsequently advertise “I have a 2-hop link to the network” (or “I have a 2-hop link to the network via A” ) , potentially leading H to advertise “I have a 3-hop link to the network” (or “I have a 3-hop link to the network via C and A” ) . This propagation of network routes may reduce the need for discovery solicitations, at the cost of increased traffic in the network from the route advertisements.
Figure 9 shows an exemplary message flow for the transmission of a packet to the network from node H in the network of Figure 8, presuming that node A proactively advertises its connection to the network and that other nodes subsequently advertise a route to the network via A. Not all nodes of the network are shown in the diagram, for space reasons, but the principles of the flow could be applied throughout the network as described herein. Step 0 of the figure comprises node A starting the procedure with awareness of its link to the network. In step 1, node A transmits to its neighbour nodes (for example, by broadcast or groupcast) an announcement of its link to the network, which may, for instance, indicate that A has a 0-hop route to the network (using the convention that hops are counted based on intervening nodes-a direct connection is zero hops, a singly relayed connection is one hop, and so on) . The announcement of step 1 is received by the neighbour nodes C and D. In step 2, C and D update their routing tables and announce their availability for routes toward the network. The announcements from nodes C and D may, for instance, indicate that C and D have 1-hop routes to the network. The announcement from node C is received by its neighbours A and H, and the announcement from node D is received by its neighbours A and F. Node A may discard the announcements from nodes C and D without updating its routing table, since the routes being advertised go through A itself. Alternatively, nodes C and D may avoid “re-advertising” the announcement to node A because node A appears in the route. In step 3, H and F, which received announcements in step 2, update their routing tables and announce their availability for routes toward the network. The announcement from node F is received by its neighbours D and H, and the announcement from H is received by its neighbours C, F, and J. Similar to the redundant routing information provided to node A in step 2, the information sent in step 3 to nodes C and D may be discarded or omitted, because the route being advertised by H goes through C, and the route being advertised by F goes through D. It is noted that after step 3, nodes F and H may each be aware of two distinct routes to the network: Node F knows the routes F->D->A->network and F->H->C->A->network, while node H knows the routes H->C->A->network and H->F->D->A->network. In step 4, node H acquires (for example, from an application protocol layer) a packet for delivery to the network. In step 5, node H consults its routing table to determine at least one next hop for transmission of the packet towards the network; in this instance, it selects node C as the next hop (this may, for example, be the result of preferring the route with the fewest hops) . In step 6, H transmits the packet to C, the selected next hop. In step 7, C consults its routing table, selects A as the next hop to the network, and transmits the packet to A. In step 8, A delivers the packet to the network.
In some embodiments, a transmitting node may select more than one next hop, resulting in multiple transmissions of a particular packet towards the same ultimate destination. For example, in the flow of Figure 9, node H could select both C and F as valid next hops towards the network, resulting in transmitting two copies of the packet in step 6. Such packet duplication could be useful, for example, for high-reliability services where redundant transmission would help to meet a reliability requirement.
In some embodiments, a transmitting node may select different next hops for different packets, resulting in a diversity of routes towards the destination node for the packets. Such routing diversity could be useful, for example, in achieving higher data rates by transmitting on multiple links in parallel, or in increasing the chances that at least some packets of a particular flow reach the destination (in case the service can benefit from partial data reception, e.g., by allowing lost packets to be wholly or partially reconstructed through techniques like upper-layer coding) .
It is noted that connection establishment procedures are omitted from Figure 9, but they may be required before transmission of the packet in steps 6-8. For example, H may avail itself of the advertised routes to establish a logical connection (for example, an RRC connection) with the network after step 3 of the figure (when a route to the network is available) or after step 4 (when the packet needs to be sent) . Similarly, pairs of adjacent nodes in the mesh may establish connections with one another after exchanging discovery messaging and/or when a packet needs to be delivered. In the flow shown in the figure, node H may establish a connection (for example, a PC5 unicast link and/or a PC5-RRC connection) with node C after step 2 (when it learns that C is a valid next hop to the network) or after step 5 (when it selects C as a next hop for transmission of a packet to the network) ; similarly, node C may establish a connection with node A after step 1 or after step 6, and node A may establish a connection with the network (for example, an RRC connection) at the beginning of the procedure or after step 7.
The full details of routing procedures in the nodes of the mesh are not shown in Figure 9. When node H transmits its packet in step 6, it may include various pieces of routing information, such as an indication that the network is the destination, an indication of a preferred or required route to the network, a maximum number of hops or TTL, and so on. This information may be used by subsequent nodes (such as C and A in the example) for routing. In some embodiments, C may consult its routing table to select a next hop to the network after step 6 and before step 7, for example.
Figure 10, using the same example network, shows a procedure in which a node is offered routes to different network nodes via a plurality of intermediary nodes. At step 0 of the figure, nodes A and B are aware of their direct links to the network nodes (Y and Z, respectively) . In step 1, node A sends to its neighbours, C and D, an announcement of its link to the network, and node B sends to its neighbours, D and E, an announcement of its link to the network. In this example, the receiving nodes C, D, and E are assumed not to forward the announcement to their own neighbours (as described previously, such forwarding is technically possible, resulting in more nodes in the network having their routing tables populated with information about one or more routes to the network) . In step 2, nodes C, D, and E all update their routing tables according to the announcements they received in step 1. In step 3, node G generates a packet to be delivered to the network; since G has no route to the network, it needs to request a route from its neighbours. In step 4, G transmits to its neighbours, D, E, and K, a request for a route to the network, i.e., a discovery request for the network. The request in step 4 may comprise criteria for a desired route (e.g., a maximum hop count, quality-of-service criteria, etc. ) . The request may comprise information about a preferred network node, or it may be node-agnostic, i.e., it may indicate only that a route to some network node is needed. In step 5, nodes D, E, and K consult their routing tables, with varying results: D determines that it has two routes to the network (via nodes A and B) , E determines that it has one route to the network (via B) , and K determines that it has no known route to the network. In step 6, these nodes proceed according to the outcomes of step 5: D responds to G with an indication of at least one route to the network; E responds to G with an indication of a route to the network; and K does not respond to G, but instead sends to its own neighbour, E, a request for a route to the network, i.e., a discovery request for the network. The response from D in step 6 may contain an indication of multiple routes, detailed information about one or more of the routes, or only the information that at least one route exists. In step 7, G updates its routing table according to the responses received from D and E in step 5, and E responds to K with an indication of a route to the network (the route via B) . In this example, G determines to send its packet to both D and E for routing to the network; this determination may reflect a reliability requirement of the underlying service, a throughput requirement of the underlying service, and so on. (In other examples, G might determine to send its packet to only one of D and E at this stage. ) In step 8, G consults its updated routing table to determine the next hop (s) for transmission of its packet towards the network, and K updates its routing table according to the response received from E in step 7. In step 9, G transmits its packet to D and E, which it selected as next hops in step 8, and K transmits to G an indication of a route to the network (the route via E that was indicated to K in step 7) . In step 10, D and E consult their routing tables to determine respective next hops for the packet of which they received copies in step 9, and G updates its routing table according to the route received from K in step 9. From step 6 to step 10, different nodes (D, E and K) independently handle the route request from G and then may independently respond by sending corresponding route information back to G. In this example, the route information received from node K comes a bit late compared to the route information from nodes D and E, as node K needs to exchange with other nodes before the feedback. From node G’s perspective, it will update the routing table in case of valid route information received. However, node G can proceed to route the packet according to its own decision. This decision may be governed, for instance, by the availability of the discovered route (s) , by a supervisory timer determining when the packet needs to be transmitted, by taking into account the allowable latency for the packet, by considering the quality of the available routes, and so on. In this example, G determines to transmit an additional copy of its packet to K for forwarding to the network; in other examples, G may determine that the packet has already been transmitted into the mesh and another copy does not need to be sent. In step 11, D forwards the packet to its neighbours A and B, E forwards the packet to its neighbour B, and G transmits the additional copy of the packet to K. In step 12, B recognises that it has received a duplicate copy of the packet in step 11 (i.e., it has received copies from both D and E) and may discard a copy of the packet, and K consults its routing table to determine a next hop for transmission of the packet. In accordance with the route received by K in step 7, K selects E as the next hop towards the network. In some embodiments, the duplicate detection at B in this step may be carried out in an SRAP layer or a similar protocol layer responsible for routing functionality in the mesh. In other embodiments, B may not perform duplicate detection, and subsequent steps may involve transmission of additional copies of the packet as a result, with the assumption that duplicates will be handled in other stages of the procedure (for instance, in an upper protocol layer after copies of the packet are received by the network) . In step 13, A and B consult their routing tables to determine respective next hops for transmission of the packet, and K forwards the packet to E in accordance with the selection in step 12. In step 14, A and B forward the packet to network nodes Y and Z respectively, and E recognises that it has previously forwarded this packet and may discard it as a duplicate. In some embodiments, E may continue to transmit the packet at this stage instead of discarding it, as a reliability measure in case previous copies of the packet have been lost. After step 14, the packet has been successfully delivered to the network (twice) , no further copies of the packet are circulating in the mesh, and the procedure is complete. The network may subsequently handle the duplicated packet according to various well-known techniques to prevent duplicate data from being delivered to an application layer; for example, a protocol layer, such as a PDCP layer, may be shared between the two network nodes Y and Z, and such a layer may perform duplicate detection.
As with previous examples, the establishment of connections between various pairs of nodes in the mesh is not shown in Figure 10. Node G, which wishes to exchange data with the network, may need to establish a connection, such as an RRC connection, with the network during the process (for example, after step 6, when G first learns a route to the network) , and it may use the routing facilities of the mesh network to exchange control signalling with the network to establish such a connection before transmitting a user data packet. If G establishes a connection with a specific network node-for instance, node Y-at this stage, G may select one or more next hops for transmission of its packet based on their ability to route to node Y specifically. If G establishes a connection with a plurality of network nodes-for instance, dual connectivity with nodes Y and Z-then G may transmit its packet to neighbour nodes that can offer a route to any of the network nodes with which G has a connection. There may further be a requirement for adjacent pairs of nodes in the mesh to establish a connection (for example, a PC5-RRC connection) to support data transmission between the nodes, so that, for instance, node G may establish connections with nodes D and E during the procedure (for example, after step 8, when G has determined that it will transmit its packet to both D and E) . Accordingly, such adjacent pairs of nodes may terminate one or more protocol layers between them (such as a PC5-RRC protocol, a PC5-Sprotocol, and so on) to manage such connections.
Figure 11, using the same example network, shows a procedure in which a first mobile node, using a discovery procedure similar to Model B as described previously, determines a route to a second mobile node. In this example, node E wishes to transmit a packet of data to node H. Initially, we assume that each node has no routing information other than the direct links to its neighbours in the mesh. Each route request and response is shown with a sequence number, to help distinguish which messages are responsive to one another. In step 1 of the figure, node E generates a packet for transmission to node H, and since E does not have H in its routing table, it starts a discovery procedure to determine a route to H. In step 2, E sends a route request to its neighbours, B, G, and K. The three route requests of step 2 may comprise a single message sent by broadcast or unicast, but they are shown separately in the flow diagram and given separate sequence numbers (1, 2, and 3 respectively) , to help associate them with their separate responses. In step 3, the nodes respond to step 2: B determines that it does not have H in its routing table, so it sends a route request to its neighbour, D. (B may omit sending a route request to E, since it just received the route request from E in step 2; alternatively, if the route request is sent by broadcast/groupcast, for instance, E may receive the route request, recognise that it already has a discovery operation in progress for the same target node, and discard the route request. For the duration of this example, we do not show route requests as being forwarded back to the requesting node. ) Similarly (still in step 3) , G determines that it does not have H in its routing table, so it sends route requests to its neighbours, D and K; and K determines that it does not have H in its routing table, so it sends a route request to its neighbour, G. In step 4, nodes G and K, which received route requests in step 3, may recognise that they have no constructive way to respond to these requests (each node has already sent a route request to all its neighbours) , so they may take no action, while node D, which received two route requests from B and G in step 4, sends route requests to its remaining neighbours, A and F. In step 5, a breakthrough occurs, in that F determines that it knows a route to H; accordingly, F sends a route response to D (closing transaction number 8 in the figure) , while A, which does not know a route to H, sends a route request to its neighbour, C. In step 6, C, which does know a route to H, sends a route response to A (closing transaction number 10) , while D, which has learned from the response in step 5 a route to H via F, sends route responses to both B and G (closing transactions 4 and 5) . In step 7, the responses continue: B has now learned a route to H (via D and F) , so B sends a route response to E (closing transaction number 1) ; G has now learned a route to H (via D and F) , so G sends a route response to E (closing transaction number 2) ; and A has now learned a route to H (via C) , so A sends a route response to D (closing transaction number 9) . At this stage, node E has been informed of two routes to the destination H, so E may now opt to transmit its packet on one route or both (not shown in the figure) , or it may delay transmission while waiting for further route responses; this decision may be governed, for instance, by a supervisory timer determining when the packet needs to be transmitted, by taking into account the allowable latency for the packet, by considering the quality of the available routes, and so on. In step 8, D has learned an additional route to H via A and C, so D may send a route response to G; however, since D previously sent a route response to G in step 6, D may determine that a second route response is unwarranted (e.g., because the new route via A and C contains more hops than the previously indicated route via F) and omit sending the additional route response. If D sends a route response in step 8, G learns an additional route to H (G->D->A->C->H) , and in step 9, G may send a route response to E. If G sends a route response to E in step 9, E learns an additional route to H (E->G->D->A->C->H) , and as discussed previously, G may determine whether to send (an additional copy of) the packet on this new route (not shown in the figure) . This determination may be governed by the reliability and/or latency requirements of an underlying service for the packet, for example.
To carry out the foregoing example, each node in the mesh needs to instantiate two algorithms similar to the following ones. A first exemplary algorithm concerns the handling of route requests, as follows:
1. When a first route request for a destination node X is received from a neighbour node Y for a source node Z, record the reception of the route request (potentially including metadata such as a sequence number, a transaction identifier, and so on) , consult the routing table for a route to X, and proceed to step 2.
2. If at least one route to X is present in the routing table, send a route response to Y indicating information about the route (potentially including quality information for the route, a number of hops in the route, a list or sequence of the nodes in the route, etc., and potentially including more than one route in the response) .
3. Otherwise (no route to X is present in the routing table) , send a second route request for destination node X to all neighbours that are neither Y nor Z, with potential exceptions as noted in step 4 below.
4. The second route request of step 3 may be omitted, for example, if the first route request contains a hop count limit or TTL that would be exceeded by the second route request, or if the quality of the link to Y is below a threshold, where link quality may be defined, for example, by a reference signal received power (RSRP) or a reference signal received quality (RSRQ) .
A second exemplary algorithm concerns the handling of route responses, as follows:
1. When a route response for a destination node X is received from a neighbour node W, add the indicated route to the routing table and proceed to step 2.
2. If a route request for destination node X was previously received from a neighbour node V, send a first route response to V indicating the route, with potential exceptions as noted in step 3 below.
3. The first route response of step 2 may be omitted, for example, if any second route response for destination node X was previously sent to V; if a second route response for destination node X was previously sent to V, and the route in the second route response is considered as a better route than the route in the first response, based on various criteria such as one or more link qualities (e.g., RSRP/RSRQ) , one or more link weights, a hop count, etc.; if the quality of the route in the first route response is below a threshold, where route quality may be defined by various metrics such as one or more link qualities (e.g., RSRP/RSRQ) , one or more link weights, etc.; if the hop count of the route in the first route response exceeds a threshold; and so on.
Throughout the example of Figure 11, and in the associated algorithms described in the preceding paragraphs, a discovery procedure (comprising, for example, an exchange of discovery messages as described herein, including information for managing routes between nodes in the mesh) may be accompanied or followed by the establishment of one or more connections between nodes. For example, in the flow of Figure 11, after node E receives route responses (step 7) and determines a route to H, E may initiate a procedure to establish a connection (for example, a PC5-RRC connection) with H. Similarly, E may initiate a procedure to establish one or more connections with neighbouring nodes for the purpose of communication via the mesh with H.
It is understood that the specific order or hierarchy of blocks in the processes /flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes /flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”
Claims (19)
- A method of discovery operable by a first node in a mesh network, comprising:receiving, from a first neighbour node in the mesh network, a first discovery request comprising a request for a route to a destination node in the mesh network;if a routing table of the first node contains at least one route to the destination node, sending, to the first neighbour node, a discovery response comprising information about the at least one route;if the routing table does not contain at least one route to the destination node, sending, to a second neighbour node, a second discovery request comprising a request for a route to the destination node.
- The method of claim 1, wherein the first and second discovery requests and the discovery response are messages of a PC5-S protocol.
- The method of claim 1, wherein the information about the at least one route comprises at least one of a hop count, a measure of route quality, and an enumeration of nodes comprising the route.
- The method of claim 1, wherein the first discovery request contains a sequence number, and wherein the discovery response contains the sequence number.
- The method of claim 1, wherein the first discovery request contains a maximum hop count, and wherein the second discovery request is not sent if it would exceed the maximum hop count.
- A method of discovery operable by a first node in a mesh network, comprising:receiving, from a first neighbour node in the mesh network, a first discovery response message comprising first information about at least one route to a destination node;updating a routing table of the first node by adding the at least one route; andtransmitting, to a second neighbour node in the mesh network, a second discovery response message comprising second information about the at least one route.
- The method of claim 6, wherein the second neighbour node previously transmitted to the first node a discovery request comprising a request for a route to the destination node.
- The method of claim 7, wherein the discovery request contains at least one criterion, the first discovery response contains a plurality of routes, and the second discovery response omits at least one route from the first discovery response based on the at least one route failing to meet the at least one criterion.
- The method of claim 8, wherein the at least one criterion comprises at least one of a maximum hop count and a minimum route quality threshold.
- [Network connection announcement] A method of discovery operable by a first node in a mesh network having a radio connection to a second node in the mesh network, comprising:transmitting, to a third node in the mesh network, a discovery announcement comprising the information that the first node has a radio connection to the second node, wherein the second node is a node of a cellular network.
- The method of claim 10, wherein the discovery announcement further comprises information about the link quality of the radio connection to the second node.
- A method of connection management operable by a source node in a mesh network, comprising:receiving, from a neighbour node in the mesh network, a discovery message comprising at least a first route to a destination node in the mesh network;adding the at least a first route to a routing table of the source node;selecting, based on information in the routing table, at least a second route to the destination node; andtransmitting, to the destination node via the at least a second route, a first control message of a protocol.
- The method of claim 12, wherein the first control message initiates the establishment of a connection.
- The method of claim 12, wherein the first control message is a message of a PC5-S protocol or a PC5-RRC protocol.
- The method of claim 12, wherein the destination node is a node of a cellular network, and the first control message is a message of an RRC protocol.
- The method of claim 12, further comprising sending, to a peer node in the mesh network, a second control message of a protocol, wherein the at least a second route comprises the peer node, and wherein the source node communicates via a direct radio link with the peer node.
- The method of claim 16, wherein the second control message initiates the establishment of a connection.
- The method of claim 16, wherein the second control message is a message of a PC5-S protocol or a PC5-RRC protocol.
- The method of claim 16, wherein the peer node is a node of a cellular network, and the second control message is a message of an RRC protocol.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2021/142595 WO2023123083A1 (en) | 2021-12-29 | 2021-12-29 | Route discovery in a mesh network |
CN202211603273.6A CN116367259A (en) | 2021-12-29 | 2022-12-13 | Method and device for discovering route in mesh network |
TW111150372A TWI838049B (en) | 2021-12-29 | 2022-12-28 | Method and apparatus for route discovery in a mesh network |
US18/090,615 US20230209439A1 (en) | 2021-12-29 | 2022-12-29 | Route discovery in a mesh network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2021/142595 WO2023123083A1 (en) | 2021-12-29 | 2021-12-29 | Route discovery in a mesh network |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023123083A1 true WO2023123083A1 (en) | 2023-07-06 |
Family
ID=86940465
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2021/142595 WO2023123083A1 (en) | 2021-12-29 | 2021-12-29 | Route discovery in a mesh network |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN116367259A (en) |
WO (1) | WO2023123083A1 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080137580A1 (en) * | 2004-04-05 | 2008-06-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, Communication Device and System For Address Resolution Mapping In a Wireless Multihop Ad Hoc Network |
US20210160956A1 (en) * | 2019-11-22 | 2021-05-27 | Mediatek Singapore Pte. Ltd. | Packet Routing for Layer-2-Based Sidelink Relay |
WO2021102782A1 (en) * | 2019-11-28 | 2021-06-03 | Apple Inc. | Access control at a relay user equipment |
-
2021
- 2021-12-29 WO PCT/CN2021/142595 patent/WO2023123083A1/en unknown
-
2022
- 2022-12-13 CN CN202211603273.6A patent/CN116367259A/en active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080137580A1 (en) * | 2004-04-05 | 2008-06-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, Communication Device and System For Address Resolution Mapping In a Wireless Multihop Ad Hoc Network |
US20210160956A1 (en) * | 2019-11-22 | 2021-05-27 | Mediatek Singapore Pte. Ltd. | Packet Routing for Layer-2-Based Sidelink Relay |
WO2021102782A1 (en) * | 2019-11-28 | 2021-06-03 | Apple Inc. | Access control at a relay user equipment |
Non-Patent Citations (1)
Title |
---|
MEDIATEK INC.: "Initiation of relaying operation", 3GPP TSG-RAN WG2 MEETING #111 ELECTRONIC R2-2006573, 7 August 2020 (2020-08-07), XP051911516 * |
Also Published As
Publication number | Publication date |
---|---|
CN116367259A (en) | 2023-06-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111543080B (en) | System and method for network topology management | |
US8422939B2 (en) | Efficient multicast control processing for a wireless network | |
CN112217716B (en) | Method and equipment for routing data packets, and method and equipment for controlling data packet transmission | |
JP4961434B2 (en) | Communication method for multi-hop packet transfer | |
WO2019242748A1 (en) | Information transmission method and device | |
US7899495B2 (en) | Methods and apparatus for supporting multiple connections | |
US20090213779A1 (en) | Multi-hop wireless relay communication system and downlink data transmitting method and device | |
US8498292B2 (en) | Network node and method for establishing network path and sending data | |
US20060002350A1 (en) | Access point control of client roaming | |
JPH08307446A (en) | Application of network system | |
KR20040102085A (en) | System and method for identifying potential hidden node problems in multi-hop wireless ad-hoc networks | |
TW200818776A (en) | PN code based addressing methods and apparatus for airlink communications | |
JP2001500342A (en) | Method and apparatus for rerouting a connection in a telecommunications network connection including a plurality of network elements | |
JP2022517696A (en) | Dynamic attribution of admission control to integrated access backhaul nodes, computer software, and computer-readable non-temporary recording media | |
US20100020740A1 (en) | Wireless Communication System, Wireless Communication Device, Wireless Communication Method, and Program | |
JP3010157B1 (en) | Wireless packet transfer method and wireless base station using the method | |
JP3727309B2 (en) | Packet communication system | |
JP2004260262A (en) | Radio base station apparatus and inter-network interface apparatus | |
KR20050104409A (en) | Method and base station for the transmission of information in a cellular radio communication system extended by means of ad-hoc connections | |
US20040233847A1 (en) | Routing system for establishing optimal route in wireless personal area network (WPAN) and method thereof | |
US20230209439A1 (en) | Route discovery in a mesh network | |
JP2005223697A (en) | Route update method for multi-hop radio network and radio terminal | |
JP2006505186A (en) | Method for use in an ad hoc mode WLAN system | |
CN111294271B (en) | Device and method for establishing hybrid mesh network applied to multiple links | |
CN116711379A (en) | Wireless communication method, communication device and communication system |
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: 21969452 Country of ref document: EP Kind code of ref document: A1 |