GB2586261A - Improvements in and relating to routing in an integrated access and backhaul network - Google Patents

Abstract

A method of routing a data packet in an Integrated Access and Backhaul (IAB) node 10 in a telecommunication network (e.g. a 5G or New Radio network), comprises: receiving a data packet with a header comprising a routing identifier (A1+P1), whereby the routing identifier comprises an address (A1) and a path identifier (P1); deriving, from a routing table, an egress link for the packet with the routing identifier (A1+P1); and routing the data packet via the egress link, wherein the routing identifier corresponds to a unique entry in the routing table, and whereby the path identifier may be used in one or more other routing identifiers (A1+P1, A2+P1) in the routing table. The header may be a Backhaul Adaptation Layer (BAP) header. The path identifier may identify either a full path to the address or a next hop node or link, based on signalling load in expected or historic frequency of Radio Link Failure, degree of flexibility required, or processing capabilities of IAB nodes. The path identifier may have a reserved value indicative of a certain action such as assigning high/low priority, QoS status or redundancy status to the packet, or randomising packet flow.

Description

Improvements in and relating to routing in an Integrated Access and Backhaul Network The present invention relates to routing of data packets in an Integrated Access and Backhaul (IAB) network, such as is used in Fifth Generation (5G) or New Radio (NR) networks. Other types of network may also benefit from such arrangements and so the example of a 5G network used here is to be considered as exemplary only.

Such an IAB configuration is shown in Figure 1. Here, nodes are used as relay nodes (rTRP) for the extension of wireless backhaul links up to a node which has a fibre/wired backhaul connection.

In Figure 1, there are three nodes 10, 20, 30, each connected to one or more UEs 50. Node 10 is provided with a fibre connection 40 to the core network. Nodes 20, 30 do not have such a wired connection and make use of the access spectrum to provide backhaul connections to the wired base station 10, which then transmits/receives the required data to/from the core network.

By means of such a configuration, it is possible to install nodes without the necessity of providing a fibre data connection, thereby allowing speedy and simple roll out of network coverage to locations where no such data connection is available or possible.

In standardisation discussions, a new protocol layer has been defined, known as the Backhaul Adaptation Layer (BAP). Its relationship with other, known, layers is shown in Figure 2.

Figure 2 shows the relative interconnections between an IAB Donor gNB 100, a first IAB node 110 and a second IAB node 120. The Backhaul RLC channel is shown between the donor gNB100 and node 1 110, and also between node 1 110 and node 2 120.

Figure 3 shows a gNB 200. In a gNB, two main functional units may be categorised as a central unit (CU) 210 and a distributed unit (DU) 220. A gNB may have more than one DU associated with a given CU, located relatively distant from the CU. The interface between the CU and a respective DU is known as the Fl interface. The Fl interface may be subdivided into Fl-U 230 and Fl-C 240, based on User plane and Control plane functionalities, respectively.

The primary purpose of the BAP is to transport the Fl-U interface across the wireless backhaul.

Routing of data requires the delivery of a packet to a destination node by selecting a next backhaul link from among several possible backhaul links at an IAB node and an IAB donor node as a baseline In principle certain parameters which are carried in the BAP, are possible route identifiers for routing at the adaptation layer BAP. These parameters are unique within an IAB donor CU. However, it is necessary to define the egress link (or next hop link) in a routing table.

As currently agreed, each IAB node includes a routing table for use in routing data packets.

The routing table specifies which outgoing (egress) backhaul (BH) RLC channel an incoming data packet should be sent to for onward transmission.

In order to facilitate this arrangement, the BAP header includes BAP routing-id which consists of a BAP address and a BAP path id. Each BAP address can have one or more entries in the routing table to enable local route selection, with one for each different BAP path id.

Embodiments of the present invention aim to address issues connected with BAP routing and with the BAP routing id in particular.

According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

According to a first aspect of the present invention, there is provided a method of routing a data packet in an Integrated Access and Backhaul node in a telecommunication network, comprising the steps of: receiving a data packet with a header comprising a routing identifier (Al +P1), whereby the routing identifier comprises an address (Al) and a path identifier (P1); deriving, from a routing table, an egress link (Link_1) for the packet with the routing identifier (A1+P1); and routing the data packet via the egress link, wherein the routing identifier corresponds to a unique entry in the routing table, whereby the path identifier (P1) may be used in one or more other routing identifiers (Al +Pl, A2+P1) in the routing table.

In an embodiment, the path identifier either identifies a) a full path to the address or b) a next hop node or next hop link In an embodiment, for a) the path identifier is unique with respect to the address.

In an embodiment, for b) the path identifier is unique with respect to the node receiving the packet.

In an embodiment, the path identifier is configured as either option a) or b) based on one or more of: signalling load incurred; expected frequency of Radio Link Failure, RLF; historic frequency of RLF; degree of routing flexibility required; and the processing capabilities of any IAB nodes in question.

In an embodiment, for option b) the path identifier is updated at each node in the path in real 10 time.

In an embodiment, the path identifier comprises a reserved value which is indicative of a certain action to be taken in connection with the associated data packet.

In an embodiment, the certain action to be taken is one or more of: assigning a high priority to the packet; assigning a low priority to the packet; assigning a certain Quality of Service (QoS) class to the packet; randomising flow for the packet; and assigning a redundancy status to the packet.

In an embodiment, the reserved value is indicative of the action and path information.

In an embodiment, the reserved value is decoded to provide the action and the path information by means of a look up table or a mathematical operation.

In an embodiment, a decision to use a reserved value which is indicative of a certain action to be taken in connection with the associated data packet is based on one or more of: a saving in signalling overhead; load on one or more specific paths; a reduction in useful path identifier space; and a reduction in QoS granularity.

In an embodiment, each egress link for a given routing identifier is associated with a priority level.

In an embodiment, the address is one of a destination address, a source address or an identity of a next hop node.

According to a second aspect of the present invention, there is provided apparatus arranged to perform the method of the first aspect.

Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows a representation of part of a network employing IAB; Figure 2 shows a protocol stack illustrating BAP; Figure 3 shows a gNB having a CU and DU; Figure 4 shows a hardware implementation of an embodiment of the invention.

Embodiments of the present invention relate to methods and apparatus associated with the efficient routing of packets in an IAB environment and in the particular context of BAP.

In the prior art, a path id is defined which is an absolute path id, unique per donor DU. Since there are a potentially large number of nodes and links between the nodes, this could potentially represent a large amount of data in the BAP header. Embodiments of the present invention provide a scheme which reduces this data so as to minimise control data and so improve data throughput and overall efficiency. An absolute path id may potentially detail every path from every possible source to every possible destination and so can require a large amount of data in the header.

The destination address for a packet is unique i.e. it is only destined to arrive at one node.

However, the destination address and the path id should combine to provide a unique combination which defines a path to the destination. In other words, the path id only makes sense when combined with the destination address, since together they define a unique id, known as the BAP routing id.

In an embodiment of the invention, in the downlink case (i.e. gNB to UE), this can save a considerable number of bits for the path id since path id can be reused for several different destinations. Note that only the combination of destination address and path id needs to be unique, thereby enabling reuse of the path id for different destination addresses.

It is this combination of destination address in combination with the path id, which underlies embodiments of the present invention. Since only the combination of destination address and path id is required to be unique, the path id can be shorter than in the prior art and since it is not, in itself, required to be unique, it can be re-used in association with different destination address to still yield a unique BAP routing id.

Therefore, in a first embodiment of the present invention, there is provided a routing procedure whereby the next hop link is identified from the routing table based on a destination address On DL case) or source address (in UL case) and a path id which is unique per destination or source address, but which may be re-used for other destination or source addresses.

Note that in the following, where destination address is used in the DL case, then this should be taken to include source address in the UL case, since the two are complementary and the skilled person will understand accordingly.

This is illustrated in the following exemplary routing table.

BAP routing Id Egress link Priority value Al + P1 Link_l 5 Al + P2 Link_2 3 Al + P3 Link_3 1 A2 +101 Link_2 2 A2 + P4 Link_3 I This table has a column indicating the BAP routing id, which is formed from a destination address (e.g. Al) and path id (e.g. P1). Each BAP routing id is associated with an egress link to the next node. The egress link is associated with the next hop to the next node.

Each BAP routing id is further associated with a priority value. Since each routing id can only appear once in the routing table, but there may be multiple paths (e.g. P1, P2, P3) associated with the same destination address (e.g. Al), the priority value can be used to assign different priorities to respective paths. In this way, the CU is able to prioritise its preferred path(s) to support local decision making if, for instance, one or more of the alternate possible paths has failed.

From the above table, it can be seen that the destination address Al appears in the table with three possible path ids (P1, P2, P3). Each of these is associated, respectively, with Egress links Link_1, Link_2 and Link_3. Each of these defines a different path from the current node to the destination Al. A different path may be used to assist with e.g. load balancing or rerouting in the event of Radio Link Failure (RLF). The priority value referred to above may be used in selecting an alternative path, if required.

As noted previously, the same path id can be reused in different BAP routing ids, even if they represent different physical routes. Note that P1 is used in "Al +Pl" and reused in "A2+Pl", even though the path in each case may be different. However, the overall route "Al +P1" is different to "A2+Pl", giving a unique BAP routing id, which is required in the routing table.

In a second embodiment of the present invention, there is provided a method whereby the next hop link is included in the BAP header, rather than the path id as included in the first embodiment above.

In this embodiment, the routing table differs from that described for the first embodiment, and an example is shown below: BAP routing Id Egress link Priority value New egress link (for next node) Al + PI Link_l 5 P"1 (-PI) Al + P'2 Link _2 _ 3 P"2 Al + P'3 Link _3 _ 1 P"3 A2 + P'l Link_2 2 A2 + P'4 Link_3 1 In this table, P'1 indicates the next hop link only, rather than the complete path as in the first embodiment. The next hop link is then updated at every IAB based on the information in the "New Egress Link" column (e.g. P"1).

This routing table only relates to local routing to the next hop node and so must be updated at each next node in the path As a packet passes from node to node, the BAP header is updated to reflect the information on the next hop link. For instance, in the above table, the BAP header is updated from "Al +P'1" to "Al +P"1" upon leaving the node in question (i.e. the one having the above routing table).

This approach can reduce the overall size of the BAP header since, compared to the first embodiment, the BAP header includes fewer bits as it only needs to include details of the next hop link. There is no need to encode the entire egress backhaul link identifier (e.g. C-RNTI, BAP address). Instead, it is possible to use, as path id, a local identifier referring to links entering and exiting each node and identifying these links with respect to the node in question, while being able to reuse the local identifiers.

In a variant of the second embodiment, there is provided a method whereby the next hop node ID is included in the BAP header, rather than the exact next hop link. The node receiving this packet chooses the specific link e.g. at random or based on congestion at egress link to this next hop node or a link which matches QoS requirements.

The second embodiment provides a quicker reaction to RLF, since alternative next hop nodes or links can be more quickly identified from the routing table. Preferred next hop nodes may be identified by use of the priority value.

In the first embodiment, if a path (e.g. Fl) fails, then a new path must be configured for each IAB along the path, although this is a one-off configuration.

However, in the second embodiment, in the event of RLF, the new path is configured only for the node or nodes whose next hop is changed as a result of the RLF.

As such, a difference between the first and second embodiments is that in the first embodiment, a relatively large BAP header is required to include the full path information, although this is still smaller than an absolute path as known in the prior art.

In the second embodiment, node processing load is relatively increased, since each IAB node is required to update the path id of the BAP header in real time, which places a relatively small, but finite, processing load on the node in question. Note that in this context, path id refers to the link to the next hop node only, rather than the entire path. Depending on the context and the particular embodiment, path id refers to at least a part of the overall path. Thus, path id may be taken to be e.g. P1 in the first embodiment which includes full path information and P'1 in the second embodiment which includes only detail on the next hop node.

In a further embodiment of the present invention, there is a provided a technique to select between use of the first and second embodiments described above. In practice, the use of either the first or second embodiment will result in a functioning routing system, but with consequential changes to e.g. BAP header length and/or node processing load.

The choice of the method of the first or second embodiment may be based on one or more parameters such as: signalling load incurred; expected frequency of RLF; historic frequency of RLF; degree of routing flexibility required (e.g. is it necessary to reconfigure a path by altering next hop node(s) only for those nodes affected by RLF); and the processing capabilities of the IAB nodes in question (e.g. the limitations of the MT (Mobile Termination) part of the IAB node).

The CU of the IAB donor may make the decision which embodiment to implement. The decision may be based on feedback from the nodes involved which may include one or more of: information on present and past link status and processing capability of nodes involved, including details of current load (which would otherwise not typically be known to the CU).

The first and second embodiments may be further configured to make use of one or more reserved values embedded in the path id part (e.g. P1 or P'1) of the BAP header. The reserved value(s) can be used to indicate a certain action to be undertaken in connection with the associated packet. The reserved value(s) are agreed in advance and known to the nodes involved. For instance a reserved value of FFFF (hex) can be used to indicate one or more of the following actions: a high priority, where the packet in question is given a relatively higher priority (e.g. in the case of congestion); a low priority, where the packet in question can, if necessary, be dropped or discarded; a certain Quality of Service (QoS) class is assigned to the packet, indicating a certain level of treatment; randomising flow, indicating that the packet in question may be routed via any available path to the specified destination (e.g. Al); and redundancy, whereby the packet in question is deemed important and so duplicated and sent either multiple times on the same path or via one or more other paths than the one indicated in the BAP header.

A further refinement of the technique referred to above combines some form of coding to define an action, together with information concerning the path id. This may be done by assigning a set of reserved values which are not to be used themselves as path ids but which allow the path id to be inferred or extracted based on a rule known to the donor and the intermediate nodes.

As an example, the path id space may be regarded as a set of code points. Some of these are defined not to be used for routing and so are reserved. In an ideal case, there is a simple and 1:1 relationship between the path ids which are to be used for routing and those that are not.

In a basic illustrative example, only path ids which have an even value are to be used for routing and those having an odd value are indicative of an embedded action instruction.

If the path id is odd, the node firstly subtracts 1 from the value to give an even number which defines the actual path, just as if the even number so derived was directly received. Secondly, the node performs the action indicated (e.g. high priority, redundancy etc as per the list given above). In this simple example, the degree of implied coding is limited and so this is to demonstrate the idea only.

In practice, only a relatively small sub-set of possible paths are likely to be overloaded or will need frequent updates and so these may be linked 1:1 to a set of reserved values, possibly by means of a manual mapping or lookup table, or by means of a mathematical rule, such as a cyclic shift by m in binary representation. In the event of a mapping table, this must be shared between all relevant nodes. Similarly, if a mathematical rule is used, it must be known to all relevant nodes.

In order to decide whether to make use of a BAP header including reserved values or some form of encoding, as described, to indicate both a path id and an action, account may be taken of one or more of the following: possible saving in signalling overhead; the load on one or more specific paths (e.g. is it acceptable to randomise the flow); a reduction in the useful path id space due to the use of reserved values; and a reduction in QoS granularity. With regard to the reduction in QoS granularity, if a reserved value is used to indicate both the path and the action to be taken, then there may be limits to the number of QoS levels which can be indicated by this means, simply due to the limited number of reserved values available. In the case of binary actions (e.g. prioritise this packet or duplicate this packet), then the problem does not arise, since a single bit can be used. However, for actions which may require many possible options, then a limit in the number of bits available can reduce granularity accordingly, since it is necessary to be more selective in the range of values provided.

Embodiments of the invention may be performed in a network node, as described. The schematic of Figure 4, which illustrates, conceptually, certain features of the node.

A node 300 receives data packets on ingress link 310. If node 300 is a donor node, then data packets will be sourced elsewhere.

Received packets are decoded by a BAP packet decoder, which extracts the destination address and path id from the BAP routing id. Reference is made to a routing table 330 to determine an egress link for onward transmission of the data. The data is then encoded as required in the BAP packet encoder 340 and transmitted to the next hop node via egress link 350 determined by reference to the routing table 330.

At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as 'component', 'module' or 'unit' used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term "comprising" or "comprises" means including the component(s) specified but not to the exclusion of the presence of others.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims (14)

1. CLAIMS1. A method of routing a data packet in an Integrated Access and Backhaul node in a telecommunication network, comprising the steps of.receiving a data packet with a header comprising a routing identifier (A1+101), whereby the routing identifier comprises an address (Al) and a path identifier (P1); deriving, from a routing table, an egress link (Link_1) for the packet with the routing identifier (Al +P1); and routing the data packet via the egress link, wherein the routing identifier corresponds to a unique entry in the routing table, whereby the path identifier (P1) may be used in one or more other routing identifiers (Al +Pl, A2+P1) in the routing table.
2. 2. The method of claim 1 wherein the path identifier either identifies a) a full path to the address or b) a next hop node or next hop link.
3. 3. The method of claim 2 wherein for a) the path identifier is unique with respect to the 20 address.
4. 4. The method of claim 2 wherein for b) the path identifier is unique with respect to the node receiving the packet.
5. 5. The method of any of claims 2 to 4 wherein the path identifier is configured as either option a) or b) based on one or more of: signalling load incurred; expected frequency of Radio Link Failure, RLF; historic frequency of RLF; degree of routing flexibility required; and the processing capabilities of any IAB nodes in question.
6. 6. The method of any of claims 2 to 5 wherein for option b) the path identifier is updated at each node in the path in real time.
7. 7. The method of any preceding claim wherein the path identifier comprises a reserved value which is indicative of a certain action to be taken in connection with the associated data packet.
8. 8 The method of claim 7 wherein the certain action to be taken is one or more of: assigning a high priority to the packet; assigning a low priority to the packet; assigning a certain Quality of Service (QoS) class to the packet; randomising flow for the packet; and assigning a redundancy status to the packet.
9. 9. The method of claim 7 or 8 wherein the reserved value is indicative of the action and path information.
10. 10. The method of claim 9 wherein the reserved value is decoded to provide the action and the path information by means of a look up table or a mathematical operation.
11. 11. The method of any of claims 7 to 10 wherein a decision to use a reserved value which is indicative of a certain action to be taken in connection with the associated data packet is based on one or more of: a saving in signalling overhead; load on one or more specific paths; a reduction in useful path identifier space; and a reduction in QoS granularity.
12. 12. The method of any preceding claim wherein each egress link for a given routing identifier is associated with a priority level.
13. 13. The method of any preceding claim wherein the address is one of a destination address, a source address or an identity of a next hop node.
14. 14. Apparatus arranged to perform the method of any preceding claim.