WO2023108328A1

WO2023108328A1 - Packet routing in a layer 2 mesh network

Info

Publication number: WO2023108328A1
Application number: PCT/CN2021/137394
Authority: WO
Inventors: Nathan Edward Tenny; Xuelong Wang; Guan-Yu Lin; Chia-Hao Yu; Ming-Yuan Cheng
Original assignee: Mediatek Singapore Pte. Ltd.
Priority date: 2021-12-13
Filing date: 2021-12-13
Publication date: 2023-06-22
Also published as: CN116264724A

Abstract

This disclosure describes methods of routing packets in a mesh network that relies on relaying functionality in layer 2 of a protocol stack. In the described methods, a relay node in the mesh network (that is, a node with the ability to deliver packets for other nodes) receives a packet from an upstream node for a destination node, determines a next hop for delivery of the packet towards the destination node, and forwards the packet to the next hop, which may, for example, be another relay node in the mesh network. Criteria for determining the next hop based on network topology and link quality are discussed, along with procedures for handling delivery failures that may occur, for example, based on changes in the network topology.

Description

PACKET ROUTING IN A LAYER 2 MESH NETWORK

TECHNICAL FIELD

This disclosure relates to wireless communications, and more specifically to a procedure for routing packets in a mesh network that relies on relaying functionality in layer 2 of a protocol stack.

BACKGROUND

In a network of devices communicating wirelessly, it may be challenging for static network nodes to offer coverage to all devices requiring service from the network. This problem is exacerbated by communication at high frequencies, such as millimetre wave (mmW) and sub-terahertz (sub-THz) frequencies, where propagation characteristics are poor. In 3GPP Rel-17, this coverage problem is partially addressed through the introduction of sidelink UE-to-network relaying, in which certain “relay” mobile devices extend network coverage to other “remote” mobile devices using a sidelink (PC5) interface. Relaying is supported using both layer 2 and layer 3 architectures, but in both cases it is limited to a single hop (i.e., a relay device in coverage serves a remote device that may be out of coverage) .

Future cellular systems may introduce more flexible topologies for coverage extension, such as a mesh network in which peer devices communicate freely among themselves. This concept resembles an extension of the relay model, in which multiple hops are supported (a communication may traverse more than one relay on the way to its destination) , multiple paths are supported (the network may offer a diversity of routes from a particular source to a particular destination) , and the endpoints may be either network nodes or mobile devices. A mesh network introduces routing problems that are more complex than those raised by a basic relaying architecture, since delivery of a packet may use a variety of routes and interfaces. This disclosure describes an approach to packet routing in a mesh network.

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 packet routing in a relay node is provided. The relay node receives, at a first protocol layer of the relay node, a packet from a previous-hop node, the packet comprising at least an indication of a source node, and indication of a destination node, and a packet body. If the destination node and the relay node are one and the same, the relay node delivers the packet to upper layers for processing. The relay node determines at least one next-hop node from a routing table, wherein determining the at least one next-hop node comprises, if the packet contains a path ID, selecting at least one next-hop node associated with the path ID in a routing table, and if the packet does not comprise a path ID or if the packet comprises a path ID and no next-hop node is associated with the path ID in the routing table, selecting at least one next-hop node from a set of next-hop nodes associated with the destination node in the routing table.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

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 of UEs and gNBs connected to a CN.

FIG. 3 is a diagram illustrating an example of protocol stacks for a layer 2 mesh network.

FIG. 4 illustrates an example of a mesh of UEs including a routing table for one of the UEs.

FIG. 5 illustrates an example of a flowchart for delivery of a packet.

FIG. 6 illustrates an example of a reliable delivery mechanism using SRAP ACKs.

FIG. 7 illustrates an example of a cluster-head topology with a well-connected gateway node.

FIG. 8 illustrates an example of a mesh network that may induce a routing loop.

DETAILED DESCRIPTION

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 of potentially mobile devices, a well-defined routing behaviour is required to deliver packets from source nodes to destination nodes in the mesh. The routing functionality should deliver packets efficiently according to the current conditions of the mesh, which may be subject to dynamic change, and should be resistant to delivery failures due to topology changes and to loops that interfere with packet delivery.

A mesh network comprises a set of nodes, any of which may potentially be mobile or stationary, in communication using device-to-device links in such a way that a first node of the mesh can deliver a communication (for instance, a data packet) to a second node of the mesh, even though the first node and the second node may not be in direct radio contact with one another. The communication may be forwarded by one or more additional nodes of the mesh operating as relays between the first node and the second node. An example may be a set of devices operating according to 3GPP specifications, potentially comprising a mix of user equipments (UEs) and base stations (such as eNBs, gNBs, base stations of a future wireless technology, and the like) and communicating on radio interfaces (for example, a sidelink or PC5 interface between pairs of UEs, a Uu interface between a UE and a base station, and so on) . A packet may be generated by a first node, addressed to a second node, and delivered according to a routing protocol from the first node to the second node via one or more intervening relay nodes. An example is shown in Figure 1, in which the mesh network comprises a collection of UEs and a packet is delivered from UE A to UE F.

In the environment of Figure 1, all the mesh nodes are UEs, communicating with one another via a device-to-device interface (for example, a sidelink or PC5 interface) . UE A generates a packet for transmission to UE F, but there is no direct radio link between UE A and UE F. In the absence of such a direct link, UE A transmits the packet to UE B (with which UE A has a direct link) , which transmits the packet to UE D (with which UE B has a direct link) , which transmits the packet to UE F (with which UE D has a direct link) , as shown by the red arrows in the figure. Upon reception of the packet, UE F recognises that it is the addressee of the communication (for instance, based on a destination identity in a header of the communication) and processes the packet.

In some cases, a mesh may comprise network nodes in addition to UEs. The network nodes may be viewed only as termination points that can deliver packets to and from a core network (CN) , or the network nodes may be in direct communication with one another. Figure 2 shows a mesh environment with a mixture of network nodes (for example, gNode Bs) and UEs.

In the situation shown in Figure 2, there are at least two types of radio links:

1. UE-to-UE links (e.g., between UE A and UE B) , which may use a device-to-device interface such as PC5;

2. UE-to-gNB links (e.g., between UE B and gNB X) , which may use a Uu interface.

In addition, the gNB-to-gNB links (e.g., between gNB X and gNB Y) may rely on wireless transport over a radio link, which may, for instance, rely on a device-to-device interface such as PC5. Similarly, the backhaul links from gNBs to the CN may be wired or wireless. A packet may traverse any combination of these wired and/or wireless links in transit from its source to its destination. For example:

1. A packet generated at UE A for transmission to the core network may go from UE A to UE B to gNB X to the CN;

2. A packet generated at UE C for UE A may go directly from UE C to UE A;

3. A packet generated at UE C for UE B may go from UE C to UE A to UE B, and/or from UE C to gNB Y to gNB X to UE B.

As the third example shows, a packet in the mesh may have multiple routes to its destination. Selecting an appropriate route for a packet is the role of a routing protocol, which may be embodied at any of the mesh nodes. The routing protocol may take into account many different factors in selecting a route for a packet, such as the quality of individual links between nodes in the mesh, the size of the packet, the length of the route (e.g., in number of hops) , the quality-of-service (QoS) requirements of the packet, and so on.

A mesh network may be realised with different protocol stacks, depending on the functionality of the devices involved and the architectural assumptions of the network design. Figure 3 shows an exemplary set of protocol stacks for use in a mesh network, in the context of communication from a source node to a destination node via two relay nodes. The protocol stacks of Figure 3 contain the following layers:

● Internet protocol (IP) layer, responsible for carrying packets between the endpoints and delivering them to and from upper layers;

● Service data application protocol (SDAP) layer, responsible for QoS flow management;

● Packet data convergence protocol (PDCP) layer, responsible for a variety of functions at the packet level, such as in-order delivery, security, and so on;

● Sidelink relay adaptation protocol (SRAP) layer, responsible for mediating between the upper layers (terminated end-to-end between the source and destination) and the lower layers (terminated hop-by-hop between consecutive nodes in the data path) , source and destination identification, bearer mapping, and routing;

● Radio link control (RLC) layer, responsible for reliable delivery on each hop of the data path;

● Medium access control (MAC) layer, responsible for scheduling and management of the communication interface on each hop of the data path;

● Physical (PHY) layer, responsible for the transfer of symbol-level data on each hop of the data path.

Other protocol stacks are conceivable; the stacks of Figure 3 are modelled on the layer 2 relaying functionality specified in 3GPP Rel-17, and the protocol names and functions reflect the design of this relaying functionality. A protocol layering similar to Figure 3 will be assumed in the rest of this description, but it should be appreciated that the described concepts can be applied to alternative protocol stacks embodying similar relaying functionality.

It should be noted that in some mesh networks, every node may be capable of functioning as a relay, while in other mesh networks, only certain nodes may be capable of functioning as relays. In the latter case, nodes that cannot function as relays may have restricted functionality of the routing layer (for example, the SRAP layer in the stacks of Figure 3) ; for example, the SRAP entity in a non-relay node may be capable of addressing a generated packet from the non-relay node and determining a next hop to handle the generated packet, but it may not be capable of evaluating a received packet to determine a next hop to handle the received packet. Rather, the SRAP entity may expect that any packet received by the non-relay node is destined for the non-relay node itself. The SRAP entity may, for example, discard any packet received at the non-relay node with an address in the header that does not match the non-relay node.

In order to deliver a packet in the mesh, each node that handles the packet must have a method for determining where to send the packet next, i.e., a routing protocol. There are multiple ways to approach routing. At one extreme, the mesh may be assumed to be static or nearly static, and routes can be pre-defined and distributed to all nodes. This approach is similar to the use of path IDs in the integrated access and backhaul (IAB) feature in 3GPP new radio (NR) , in which a path ID corresponds to a sequence of nodes and each packet is delivered to the next node along the path. At the opposite extreme, the mesh may be able to change dynamically, meaning that no one node necessarily knows the topology of the whole mesh at a given moment; in such an environment, source routing such as the use of a path ID is inefficient or impractical, and each node may need to make a substantive decision to identify the next hop on a packet’s route. This disclosure describes a hybrid approach that allows the use of path IDs as well as dynamic route generation.

The source node that generates a packet is assumed to populate the SRAP header with at least a destination, and optionally a path ID. The source node may also indicate its own identity as the source of the transmission (alternatively, the source could be populated in the SRAP header by the first relay node that handles the packet) . The path ID may be included, for example, if the source node has been informed of a reliable static route to the destination. The source node then determines at least one first hop for the packet, which may be determined in various ways. As one example, if the source node is connected to only one other node, it may deliver the packet to the one other node for routing. As another example, if the source node has a routing table that provides one or more next hops associated with the destination, it may determine the at least one first hop based on looking up the destination in the routing table. As a third example, the source node may provide an intermediate destination as well as a final destination, with the intention that subsequent relay nodes will at first route the packet to the intermediate destination, and the intermediate destination will secondly be responsible for routing the packet to the final destination. The intermediate destination may be a distinguished relay node, e.g., a relay node with enhanced routing capabilities or broad connectivity. (The third example may be useful in a so-called “cluster-head” topology, where certain distinguished nodes consider themselves as reliable routes to a “cluster” of other nodes. ) These examples will be further explored below.

In general, the behaviour of a relay node that receives a packet can be described as follows:

1. If the destination of the packet (e.g., as indicated by a destination field in the SRAP header) is the identity of the relay node, deliver the packet to upper layers (e.g., to a PDCP sublayer) and terminate processing.

2. If a termination criterion is met, initiate delivery failure handling.

3. If the SRAP header contains a path ID, consult the relay node’s routing table for a next hop associated with the path ID. If such a next hop is found, deliver the packet to the next hop and terminate processing.

4. If the SRAP header contains an intermediate destination, consult the routing table for a next hop associated with the intermediate destination. If exactly one next hop is found, deliver the packet to the next hop and terminate processing; if more than one next hop is found, select one or more based on a set of routing criteria, deliver the packet to the selected next hop(s) , and terminate processing.

5. Consult the routing table for a next hop associated with the (final) destination. If no next hop is found, initiate delivery failure handling. If exactly one next hop is found, deliver the packet to the next hop and terminate processing. (The path ID, if present, may also be removed from the header in this step, since this step occurs only if the relay node was unable to route the packet according to the path ID. )

6. From the available set of next hop candidates, select one or more based on a set of hop selection criteria, deliver the packet to the selected next hop (s) , and terminate processing.

Figure 5 shows a flowchart for a possible implementation of these steps at a relay node. The details of some steps are not included; for example, delivery failure handling and selection of one or more next hops are shown as atomic processes in the flowchart, although, as described below, each of these steps may comprise multiple decisions and procedures.

The delivery failure handling may comprise multiple steps, separately or in combination. For example, the relay node may discard the problematic packet, send a delivery failure notification to the node from which it received the packet, send a delivery failure notification to the source of the packet, return the packet to the node from which it received the packet (back-propagation) , proactively request a route to the destination from other nodes, forward the packet to a “candidate next hop” node that may be able to determine a route to the destination, and so on.

The termination criterion mentioned in step 2 may be any of several criteria. For instance, the packet may include a maximum hop count or “time to live” (TTL) , which when exceeded causes the relay node to consider the packet as undeliverable. As another example, the packet may be identified as having been previously handled at the same relay node, i.e., the packet is experiencing a routing loop. (A packet previously handled at the same relay node may be processed differently if it is being delivered for back-propagation as described above, however. For instance, if node X delivers a packet to node Y that is ultimately destined for node Z, and node Y then returns the packet as undeliverable, node X may look for an alternative route to node Z and retransmit the packet on the alternative route. ) As a third example, the packet may have QoS criteria that cannot be met, such as a packet delay budget that the relay node cannot comply with.

When multiple next hops are available to a given destination, the hop selection criteria for selecting one or more of them may take various forms. As one example, the selection may be left purely to the implementation of the relay node, on the assumption that any next hop that appears in the routing table will be valid. As another example, the relay node may select one or more next hops with a minimum anticipated hop count to the destination (assuming that a hop count is advertised as part of the maintenance of the routing tables) . 1 As a third example, the relay UE may derive an aggregate link quality metric to the destination (the mechanics of such a derivation are

discussed further below) . These criteria may also be combined; for example, the relay node could select the next hop offering the maximum link quality among all paths with fewer than a critical number of hops.

The derivation of link quality, which may be used as a criterion for selecting one or more next hops, may depend on the information that is available in the mesh network. For instance, when nodes advertise routing information, they may include link quality information, such as a metric Q (X, Y) that represents the anticipated quality of the path from X to Y. For cases where X and Y have a direct radio link, Q _direct (X, Y) may be defined to be a function of the radio link, such as a value based on a measured reference signal received power (RSRP) , a value based on a measured reference signal received quality (RSRQ) , or any other measure of the quality of the radio link. Then a recursive definition is possible, in which a relay node A considers the quality Q (A, B) of its path to a destination node B to be the maximum of all advertised path qualities from other nodes; for example,

(meaning that the quality of each path is the average of the direct link qualities along the path, and the quality that can be offered as a route from A to B is the maximum of such path qualities) .

The options for delivery failure handling as described above contain certain tradeoffs. The simplest approach is for the relay node to simply drop an undeliverable packet, assuming that upper layers will handle any needed retransmission, and/or that other paths to the destination will be able to deliver the packet. However, if no path to the destination is available, waiting for an upper-layer timeout to trigger retransmission may delay the ultimate delivery of the packet, and more sophisticated failure handling may provide a more efficient delivery process.

As one such approach, the relay node could send a simple delivery failure indication to the “upstream” node, i.e., the node from which it received the packet. The delivery failure indication may be a control protocol data unit (PDU) of the SRAP layer. This indication informs the upstream node that the packet may need to be redelivered, allowing it to attempt delivery through a different route to the destination. For this mechanism to work, the upstream node must retain the packet after transmitting it to the relay node. However, the upstream node has no way to know when or if the packet is finally delivered to its destination. In the example protocol stacks shown above, reliable delivery is ensured by the RLC layer on a hop-by-hop basis; that is, the upstream node knows that it successfully delivered the packet to the relay node, but it is not informed when the relay node successfully delivers the packet onward. One solution would be for a protocol layer (for example, the SRAP layer) to propagate acknowledgements back from the final destination to the sending nodes, so that each node in the path is informed of the successful delivery, allowing it to delete any stored copy of the concerned packet. However, this approach increases traffic in the mesh due to the potential flood of acknowledgements, and it requires that the destination node know all the nodes in the path that the packet took, which may involve, for example, storing more information in the SRAP header during the transmission process. An exemplary flow of information for this functionality is shown in Figure 6, using SRAP acknowledgements (ACKs) as a reliable delivery mechanism.

In step 1 of Figure 6, node A transmits a packet to node B for delivery to node D. The header of the packet indicates the source (A) , the destination (D) , and a serial number (SN) (X) . The header of the packet may further indicate the path taken by the packet in its travels through the mesh; at this step the path comprises only node A. Node A retains the packet in case it needs to retransmit it later. Node B receives the packet and applies a forwarding procedure, in the vein of the procedure described above, to determine the next hop. In step 2, node B forwards the packet to node C for delivery to node D. The header of the packet indicates the source (A) , the destination (D) , and the SN (X) . The header of the packet may further indicate the path taken by the packet; at this step the path comprises nodes A and B (indicated as A->B in the figure) . Node B retains the packet in case it needs to retransmit it later. Node C receives the packet and applies a forwarding procedure (which may or may not be identical to the forwarding procedure used by node B in the previous step) to determine the next hop. In step 3, node C forwards the packet to node D, completing the delivery process. The header of the packet indicates the source (A) , the destination (D) , and the SN (X) . The header of the packet may further indicate the path taken by the packet; at this step the path comprises nodes A, B, and C (indicated as A->B->C in the figure) . Node D receives the packet, recognises that it is the final destination of the packet, and delivers the packet to upper layers for processing. Note that node C may not need to retain the packet for future retransmission, because lower layers (e.g., an RLC layer) may indicate to node C that the packet was successfully delivered to node D, which is the final destination of the packet.

At this stage, different behaviours from node D are possible. In the behaviour shown in the figure, the SRAP ACK is propagated hop by hop through the mesh, such that each node propagates an ACK to its predecessor node in the path. In step 4, node D sends an SRAP ACK to node C. The SRAP ACK may comprise a control PDU of the SRAP layer. The header of the ACK indicates the source (D) , the destination (C) , and optionally an SN (Y) . The ACK further indicates that it comprises an ACK for the packet with SN X (this indication may be considered as part of the header of the ACK or as the body of the ACK) . Node C receives the ACK, confirming that the packet has been successfully received by node D. If node C retained the packet at the end of step 3, node C may delete the stored packet.

It is noted that step 4 of the figure may not be necessary, because node C may already be aware of the successful delivery of the packet to node D. As a result, step 4 may be omitted, and the subsequent step 5 may be triggered based on node C detecting successful delivery of the packet to node D (for example, reception of an RLC ACK for the packet) . However, this behaviour may comprise a layering violation, in which a function of the SRAP layer is triggered based on an event in the RLC layer.

In step 5, node C sends an SRAP ACK to node B. The header of the ACK indicates the source (C) , the destination (B) , and an SN. (In this example, the SN of the ACK in step 5 is shown as being the same as the SN of the SN in step 4; alternatively, the SNs on the link between B and C may be assigned independently of the SNs on the link between C and D, potentially resulting in different SNs for the ACKs in the different steps. ) Node B receives the ACK, confirming that the packet has been successfully received by node D. (Although the source of the ACK is node C, the semantics of the ACK indicate that the packet was delivered to its final destination, in this case node D. ) Node B may delete the stored packet.

In step 6, node B sends an SRAP ACK to node A. The header of the ACK indicates the source (B) , the destination (A) , and an SN (which, similar to the previous step, may be the same as or different from the SNs of previous SRAP ACKs in the procedure) . Node A receives the ACK, confirming that the packet has been successfully received by node D. Node A may delete the stored packet. Since node A was the original source of the packet, no further ACKs are necessary, and the procedure is complete.

It is noted that the procedure of Figure 6 does not depend on the contents of the path shown in the packet header in steps 1-3. However, it requires that each relay node, when it stores the packet for potential future retransmission, must also store information on which node it received the packet from.

As an alternative approach to the flow shown in Figure 6, node D may separately send SRAP ACKs to all nodes in the path. Instead of steps 4-6 as shown in the figure, node D may consult the path from the header of the packet it receives in step 3, and learn that nodes A, B, and C all transmitted copies of this packet. Accordingly, node D may send SRAP ACKs separately to nodes A, B, and C. In this case, each SRAP ACK may indicate D as its source, and a different node (respectively A, B, or C) as its destination, while also indicating an acknowledgement for the packet with SN X. The SRAP ACK for node C may be delivered directly from node D to node C. The SRAP ACK for node B may be forwarded by node C. The SRAP ACK for node A may be forwarded by nodes C and B. Alternatively, each SRAP ACK may take a different route through the mesh, according to the most expedient routing at the moment the ACK is transmitted-that is, the path of the ACK may not be the same as the reversed path of the original packet.

It is noted that the procedure of Figure 6 assumes an SRAP-packet-based SRAP acknowledgement mechanism. In some cases, multiple-SRAP-packet-based SRAP acknowledgement can be performed. In this case, SRAP header of the SRAP control PDU carrying ACK or the ACK message body comprises a plurality of SNs for a plurality of packets received by the destination. In this case, the source and the intermediate nodes along the transmission route from source to destination need to retain the plurality of SRAP packets before receiving such an SRAP ACK.

The alternative behaviour described above is clearly less efficient in a static mesh than hop-by-hop acknowledgement, since it results in a separate transmission through the mesh for each node in the path. It also requires the additional information of the path in the packet header in steps 1-3. Thus, it may appear to be an inferior approach compared to the hop-by-hop ACKs of Figure 6. However, this alternative behaviour is also robust against changes in the mesh topology. For example, if the link between nodes B and C breaks while the ACK procedure is in progress, node C may be unable to send its ACK directly to node B, and finding a new path from C to B may require extra hops and retransmissions. By contrast, if the ACK for node B is sent from node D when the packet is received by node D, the ACK for node B may be expected to take the “best” route through the mesh (for some definition of “best” , as embodied in the choice of routing algorithm) from D to B.

As an additional alternative, simpler but less robust than either the procedure of Figure 6 or the alternative behaviour described above, each node may retain the transmitted packet for an amount of time controlled by a timer. If a delivery failure indication for this packet arrives while the packet is still stored at the node, the node may determine a new next hop towards the packet’s destination node and retransmit the packet to the new next hop. If a delivery failure indication for the packet arrives after the packet has been discarded (for instance, after the timer has expired) , the packet may be considered undeliverable, which may, for example, result in propagating the delivery failure notification to the upstream node from which the packet was received. Eventually, these repeated delivery failure notifications will reach the source node of the packet, which can then indicate the delivery failure to upper layers.

As yet another behaviour in the face of a delivery failure, the node that experienced the failure can transmit the packet to the upstream node to be retransmitted. This procedure may be described as a back-propagation process. Using the simple network of Figure 6 as an example, if node C is unable to transmit the packet to node D (step 3 of Figure 6) , it may instead return the packet to node B with a delivery failure indication. Node B may then attempt to find a new route to node D; if it succeeds, it may attempt to transmit the packet to node D by the new route, and if it is unable to find such a route, node B may back-propagate the packet to node A for potential retransmission. The back-propagation mechanism may have higher overhead than the previously described mechanisms in which intermediate nodes cache the packet for potential retransmission, but it may place a lower burden on the intermediate nodes in terms of storage requirements and implementation complexity.

A further option for delivery failure handling comprises blind forward transmission, in which the relay node selects a “candidate next hop” node in the hope that it will be able to find a route to the destination. This approach may allow successful routing even for nodes that do not have completely updated routing tables. For example, if node A needs to transmit a packet to node Z and node A does not have an entry for Z in its routing table, but it has an expectation that a neighbouring node B is well-connected to the mesh, node A may transmit the packet to node B and rely on B to find a route to Z. Certain topologies may benefit from such a behaviour, and it may reduce the need to propagate detailed topological information to all nodes in the network. For example, in a “cluster-head” topology, where certain nodes are stably connected to the mesh and act as gateways for changing clusters of nearby nodes, a cluster-head node may advertise itself as being well-connected, without distributing full details of its routes to individual nodes in the network.

In one example, the SRAP ACKs mentioned in the above options may further include the source (A) and/or the destination (Z) of the packet to be acknowledged, together with its sequence number (X) , for identifying the packet-to-be-acknowledged.

A simple example of a cluster-head topology is shown in Figure 7. Nodes A, B, C, and D form a cluster with D at its head, functioning as a gateway node to a larger mesh network (shown as a cloud in the figure) . Node D is considered to be stably connected to the wider mesh, and advertises itself to its cluster members (A, B, and C) as a gateway node. The figure shows routing tables stored by nodes A and D. Nodes A, B, and C have routing information only for nodes within the cluster, which can be updated dynamically with relatively low latency, allowing these local routing tables to be maintained accurately. They also store the information that node D is a gateway node, meaning that it can be used as a transfer point for routing to nodes that do not appear in the local routing tables, such as node Z in the figure.

If node A has a packet that needs to be delivered to node Z, node A first consults its routing table to find an entry for Z. Since Z is not a member of the local cluster, A does not find such an entry; it does, however, find the information that D is a gateway node. Accordingly, A may deliver the packet to a next hop towards D, with Z as its ultimate destination. Based on the routing table shown in the figure, A delivers the packet to C (since C is shown as the next hop for reaching D) . The packet may comprise information indicating node D as an intermediate destination. Alternatively, the packet may only indicate that node Z is its ultimate destination, and rely on the routing table at node C to determine an appropriate behaviour for reaching Z. In either case, node C would be expected to deliver the packet to node D, in its role as a gateway node. Node D receives the packet and performs its routing procedure, but because of its gateway function, D has an entry in its routing table for node Z, which indicates that the next hop is some node outside the cluster (located inside the “wider mesh” cloud in the figure) . Accordingly, D delivers the packet to the next hop in the mesh, which places the packet on a route through the cloud to node Z. Note that this procedure depends on D having stable connectivity to the wider-area mesh network, so that it can accurately advertise itself as a well-connected node with the ability to reach nodes outside the local cluster.

In one example, routes to gateways may be planned so that a reliable route to gateway (s) for a node is semi-static and can be identified by a path ID. When a packet is generated from a source node, if a destination node cannot be found on its routing table, the route to one gateway (intermediate node) may be identified by a path ID, in addition to the destination node ID. The hop (s) after the gateway (intermediate node) may be determined by consulting the routing table of the gateway and may be in a hop-by-hop routing or a path-based routing, while the route to the gateway from the source node is based on the path ID. In a complementary example, the route to the gateway may be determined dynamically based on a hop-by-hop routing approach, while the route from the gateway to the destination node (or to a further intermediate destination, such as another gateway) may be semi-static and identified by a path ID.

A special case of the well-connected node is a node that can offer gateway functionality to a cellular network. For services offered by a cellular operator’s core network, or that need to be routed through the core, a node originating traffic may need to deliver its packets to any node in the mesh that has access to the core (for instance, a base station that functions as a mesh node) . It may be impractical for every base station of the operator’s network to advertise itself as a separate mesh destination, especially since the service typically has no dependency on which base station routes traffic to the core-the originating node may simply look for routing to any node that reports it has a network connection. Thus, a node with a connection to the operator’s network (for example, a relay UE in cellular coverage with a connection over a Uu interface to one or more base stations) may advertise itself as a gateway for network connectivity. This advertisement may take the form of a control PDU of the SRAP layer, for instance.

As mentioned above in the discussion of termination criteria, packets in a mesh may under certain circumstances experience routing loops. A simple example of a two-hop loop is shown in Figure 8. In the figure, node A has a link only to node B, nodes B and C have a good-quality link to each other, and each of nodes B and C has a poor-quality link to node D. Suppose A generates a packet for D. Since A has a link only to B, A must transmit the packet first to B. B knows two routes to D: the direct route B->D through a poor-quality link, or the indirect route B->C->D, in which the next hop (B->C) is a good-quality link. Accordingly, B may prefer to transmit the packet on the good-quality next hop, i.e., B may transmit the packet to C for delivery to D. D also knows two routes to D: the direct route C->D through a poor-quality link, or the indirect route C->B->D, in which the next hop (C->B) is a good-quality link. Accordingly, C may prefer to transmit the packet on the good-quality next hop, i.e., C may transmit the packet to B for delivery to D. Thus a loop may be induced between nodes B and C. In the example, the loop behaviour is due to an excessively “greedy” routing behaviour that favours the best next hop and fails to give enough weight to a poor-quality second hop.

As noted previously, loops can often be detected; for example, node B may store the information that it has previously forwarded a particular packet (which may be identified, for instance, by an SN) , and if it sees the same packet again, it may discard the packet as undeliverable. Alternatively, node B may store not only the information that it previously handled the packet, but also knowledge of which links it forwarded the packet on, and if it sees a previously handled packet return, it may select a different link to forward the packet on. For example, if node B implements such an algorithm, the packet described above might travel on the route A->B->C->B->D, instead of looping perpetually between B and C; node B, when it receives the packet from node C, recognises that the packet is in a loop, and chooses an alternative egress route-in this case, the direct path to D-for the next transmission of the packet. Finally, loops may be terminated by mechanisms such as a TTL or hop count limit, a delivery deadline for the packet, and so on. When a packet fails to be delivered because of a loop, the delivery failure handling mechanisms described above may apply.

The foregoing description applies to the handling of packets by relay nodes (which may also function as traffic destinations themselves) . Certain nodes in the network may not operate as relay nodes, for example, because of restricted functionality; a node may be only capable of operating as a remote node, where traffic can terminate but not be forwarded. Such nodes may host an entity of the routing protocol layer (e.g., an SRAP entity) , but the functionality of this entity may be limited to processing packets for the remote node itself. A remote node may have no routing table or a limited routing table, and it may handle only incoming packets that are addressed to the remote node itself; the arrival of a packet addressed to another node may be treated as an error condition. For example, if a remote node receives a packet from a relay node whose destination is different from the remote node, the remote node may send an error indication to the relay node. The error indication may, for example, be a control PDU of the SRAP layer. Alternatively or in addition, the remote node may indicate the error to upper layers for handling according to a higher-layer protocol.

A remote node may also originate traffic to be transmitted to other nodes in the network. Accordingly, even a remote-only node may require some routing functionality, to deliver traffic originated by the remote node itself towards destination nodes in the mesh. In some embodiments, a remote node may be singly connected to the mesh, i.e., it may be connected to only one relay node; in such a case, the remote node may not need a routing table, because all outbound packets will be delivered to the relay node. In other embodiments, a remote node may be multiply connected to the mesh, i.e., it may be connected to a plurality of relay nodes; such a remote node may maintain a routing table that allows it to determine which relay node (s) represent (s) the best first hop (s) to the destination of a packet. Alternatively, a multiply-connected remote node may send an outgoing packet to all the relay nodes with which it has connections, allowing multiple attempts for the packet to reach its destination; this approach may, for instance, allow transmission of a packet with higher reliability than the use of a single link would support.

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

A method of packet routing operable in a relay node of a wireless mesh network, comprising:

receiving, at a first protocol layer of the relay node, a packet from a previous-hop node, the packet comprising at least an indication of a source node, an indication of a destination node, and a packet body;

if the destination node and the relay node are one and the same, delivering the packet to upper layers for processing;

determining at least one next-hop node from a routing table, wherein determining the at least one next-hop node comprises, if the packet contains a path ID, selecting at least one next-hop node associated with the path ID in a routing table, and if the packet does not comprise a path ID or if the packet comprises a path ID and no next-hop node is associated with the path ID in the routing table, selecting at least one next-hop node from a set of next-hop nodes associated with the destination node in the routing table.
The method of claim 1, wherein the determining the at least one next-hop node further comprises, if the packet contains an indication of an intermediate destination node, selecting at least one next-hop node associated with the intermediate destination node in the routing table.
The method of claim 1, further comprising, if the destination node and the relay node are one and the same, sending an acknowledgement to the source node.
The method of claim 3, wherein the acknowledgement is a control PDU of a routing protocol.
The method of claim 4, wherein the routing protocol is an SRAP protocol.
The method of claim 1, further comprising, if a termination condition is met, discarding the packet.
The method of claim 6, wherein the termination condition comprises a failure to determine a next-hop node from the routing table.
The method of claim 6, wherein the termination condition comprises determining that the packet has exceeded a maximum hop count.
The method of claim 6, wherein the termination condition comprises determining that the packet has exceeded a maximum TTL.
The method of claim 6, wherein the termination condition comprises determining that the packet has been previously processed at the relay node.
The method of claim 6, further comprising sending a failure indication to the source node.
The method of claim 6, further comprising sending a failure indication to the previous-hop node.
The method of claim 11 or 12, wherein the failure indication is a control PDU of a routing protocol.
The method of claim 12, wherein the failure indication comprises a copy of the packet.
The method of claim 1, further comprising, if a failure condition is met, determining a candidate-next-hop node and transmitting the packet to the candidate-next-hop node.
The method of claim 15, wherein the candidate-next-hop node is determined based on a previously valid entry in the routing table.
The method of claim 15, wherein the candidate-next-hop node is distinguished as a gateway node.
The method of claim 17, wherein the gateway node is distinguished by having connectivity to a cellular network.
The method of claim 18, wherein the connectivity to the cellular network is provided by a Uu interface from the gateway node to a base station of the cellular network.
The method of claim 1, wherein the selecting at least one next-hop node from a set of next-hop nodes associated with the destination node in the routing table comprises selecting a next-hop node with a minimum hop count to the destination node.
The method of claim 1, wherein the selecting at least one next-hop node from a set of next-hop nodes associated with the destination node in the routing table comprises selecting a next-hop node with a maximum anticipated link quality to the destination node.
The method of claim 21, wherein the anticipated link quality is a function of the measured radio link qualities of a plurality of intermediate nodes, the plurality of intermediate nodes comprising a path to the destination node.