Patent Description:
In a cellular telecommunications network, overall capacity may be improved by increasing the density of base station deployment. However, there is an associated capital expense in providing both the additional base station equipment and the wired links connecting the additional base stations with the core network (the "backhaul"). To reduce the backhaul expenditure, access connections may be provided by relay nodes which utilise a wireless backhaul link to the core network (via a "donor" base station). Such relay nodes have become part of the <NUM> standards. One limitation of these <NUM> relay nodes is that there may only be a single relay node between the User Equipment (UE) and the donor base station (i.e. they are "single-hop").

In <NUM>, relay nodes are called "Integrated Access and Backhaul" (IAB) nodes and the donor base station is called the donor lAB. <NUM> networks may also employ multi-hop architectures so that multiple IAB nodes may exist between the UE and the donor lAB.

Collectively, any form of networking node that may provide an access connection in a cellular telecommunications network may be known as an Access Point (AP). This term includes the base station, donor base station, relay node, IAB node and donor lAB described above.

Cellular telecommunications networks also utilise inter-AP messaging protocols, such as X2 in <NUM> and Xn in <NUM>. These protocols allow connections to be established between APs (directly or indirectly) in order to exchange messages concerning mobility management, load management and various configuration parameters. The donor base station in <NUM> networks or the donor lAB in <NUM> networks are responsible for routing the inter-AP messages (or have a connection to a gateway node providing such functionality), including for inter-AP messages originating from any relay node or IAB node that they serve.

<CIT> provides a method and an apparatus for establishing a connection between evolved Node Bs (eNBs).

According to a first aspect of the invention, there is provided a method as claimed in Claim <NUM>.

The second neighbouring AP may be the destination of the inter-AP message or a first neighbour of the second neighbouring AP.

The method may further comprise the steps of discovering the second neighbouring AP; identifying the first neighbour of the second neighbouring AP; recording an association between the second neighbouring AP and the first neighbour of the second neighbouring AP, wherein the step of identifying the second neighbouring AP based on the destination of the inter-AP message utilises the recorded association between the second neighbouring AP and the first neighbour of the second neighbouring AP.

The method may further comprise the steps of: detecting a termination of an inter-AP connection between the second neighbouring AP and a second neighbour of the second neighbouring AP; and responsive to the detection, updating a recorded association between the second neighbouring AP and the second neighbour of the second neighbouring AP.

According to a second aspect of the invention, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the first of the invention. The computer program may be stored on a computer readable carrier medium.

According to a third aspect of the invention, there is provided an Access Point, AP, in a cellular telecommunications network having a transceiver, memory and a processor configured to cooperate to carry out the steps of the first aspect of the invention.

A first embodiment of a cellular telecommunications network <NUM> of the present invention will now be described with reference to <FIG>. <FIG> illustrates a cellular telecommunications network <NUM> including a plurality of User Equipment (UE) 110a. 110e, a plurality of Integrated Access and Backhaul (IAB) nodes 120a. 120d, a donor lAB <NUM> and a core network <NUM>, all operating according to the <NUM>th Generation (<NUM>) cellular telecommunications protocol as standardised by the <NUM>rd Generation Partnership Project (3GPP). The IAB nodes 120a. 120d are connected in a multi-hop relay architecture so that a first IAB node 120a and second IAB node 120b communicate with the donor lAB <NUM> via intermediate IAB nodes (the third IAB node 120c and fourth IAB node 120d).

The donor lAB <NUM> is shown in more detail in <FIG>. The donor lAB <NUM> includes a first communications interface <NUM> for wired communications (e.g. via optical fibre) to the core network <NUM>, a processor <NUM>, memory <NUM>, and a second communications interface <NUM> for wireless communications (e.g. via an antenna), all connected via bus <NUM>. The second communications interface <NUM> is for providing an access connection to one or more UE (such as a fifth UE 110e of the plurality of UE), and for providing a wireless backhaul connection to one or more IAB nodes (such as the fourth lAB node 120d). As shown in <FIG>, the processor <NUM> of the donor lAB <NUM> includes both a Centralised Unit (CU) (providing Radio Resource Control (RRC) and Packet Data Convergence (PDC) functionality) and a Distributed Unit (DU) (providing Radio Link Control (RLC) and Medium Access Control (MAC) functionality) for processing packets communicated via the first or second communications interfaces <NUM>, <NUM>.

A third IAB node 120c of the plurality of IAB nodes is shown in more detail in <FIG>. The third IAB node 120c includes a first communications interface 121c for wireless communications (e.g. via an antenna), a processor 123c, memory 125c, and a second communications interface 127c for wireless communications (e.g. via an antenna), all connected via bus 129c. The first communications interface 121c is for providing a wireless backhaul connection to the fourth IAB node 120d. The second communications interface 127c is for providing a wireless access connection to one or more UE (such as the third UE 110c of the plurality of UE) and for providing a wireless backhaul connection to the first and second IAB nodes 120a, 120b. As both the first and second communications interfaces may be utilised for wireless backhaul connections but in opposing directions, the first communications interface 121c to a wireless backhaul connection to the fourth IAB node 120d shall hereinafter be referred to as an upstream wireless backhaul connection (as it is for communications from the third IAB node 120c to upstream network nodes such as the fourth IAB node 120d or the core network <NUM>) and the second communications interface 127c to a wireless backhaul connection to the first and second IAB nodes 120a, 120b shall hereinafter be referred to as a downstream wireless backhaul connection (as it is for communications from the third IAB node 120c to downstream network nodes such as the first and second IAB nodes 120a, 120b).

The processor 123c of the third IAB node 120c includes a Distributed Unit (DU) (providing Radio Link Control (RLC) and Medium Access Control (MAC) functionality) for processing packets communicated via the first or second communications interfaces 121c, 127c, and further includes a Mobile Termination (MT) part for communications via the upstream wireless backhaul connection (to the DU part of the fourth lAB node 120d).

The first, second and fourth IAB nodes 120a, 120b, 120d are substantially the same as the third IAB node 120c, and the terms upstream/downstream wireless backhaul connections for these IAB nodes refer to the upstream/downstream directions from the perspective of each IAB node (that is, the upstream wireless backhaul connection for the first IAB node 120a is towards the third IAB node 120c, the upstream wireless backhaul connection for the second IAB node 120b is towards the third IAB node 120c, the upstream wireless backhaul connection for the fourth IAB node 120d is towards the IAB donor <NUM>, and the downstream wireless backhaul connection for the fourth IAB node 120d is towards the third lAB node 120c).

The donor lAB <NUM> and the IAB nodes 120a. 120d are all configured to establish an inter-Access Point (inter-AP) connection (in this embodiment, an Xn connection) with any other donor IAB or IAB node that they may connect with (directly or indirectly). Furthermore, the donor lAB <NUM> and each lAB node of the plurality of IAB nodes 120a. 120d store (in their respective memory modules) a routing table listing each neighbouring node it has an established inter-AP connection with (i.e. an established Xn connection). For each of these neighbouring nodes, the routing table further identifies an Internet Protocol (IP) address for the neighbouring node, an identifier for the parent node of the neighbouring node, and an identifier for each child node of the neighbouring node. In this context, a parent node is either a donor lAB or IAB node that the neighbouring node is directly connected to via its upstream wireless backhaul connection, whilst a child node is either a donor lAB or IAB node that the neighbouring node is directly connected to via its downstream wireless backhaul connection. The process of updating the routing table will be described in more detail below.

An embodiment of a method of the present invention will now be described. This method includes several processes, including a message transport process and a routing table update process. The message transport process will now be described with reference to <FIG> and <FIG>.

The cellular telecommunications network <NUM> is initially in the state as shown in <FIG> and Xn connections have been established between:.

The routing table of the first IAB node 120a includes the following data (following the update process described below):.

The routing table of the third IAB node 120c includes the following data (following the update process described below):.

In a first step of the message transport process (S201), as shown in the flow diagram of <FIG>, the first IAB node 120a generates an Xn message destined for the second IAB node 120b. In step S203, the first IAB node 120a performs a lookup on its routing table to determine whether the first IAB node 120a has an established Xn connection with the second IAB node 120b (that is, it is listed as a neighbouring node in the routing table) or whether the second IAB node 120b is a parent or child node of a neighbouring node listed in the routing table. In this embodiment, the first IAB node 120a does not have an established Xn connection with the second IAB node 120b but the second IAB node 120b is identified as a child node of the third IAB node 120b. In response (in step S207), the first IAB node 120a transmits the Xn message to the third IAB node 120c.

On receipt of the Xn message from the first IAB node 120a (step S202), the third IAB node 120c similarly performs step S203 to perform a lookup on its routing table to determine whether it has an established Xn connection with the second IAB node 120b or, if not, whether the second IAB node 120b is a parent or child node of a neighbouring node listed in the routing table. As the third IAB node 120c does have an established Xn connection with the second IAB node 120b, the third IAB node 120c responds (in step S205) by transmitting the Xn message to the second IAB node 120b.

The second IAB node 120b therefore receives the Xn message and processes it in its normal way.

The above process enables IAB nodes to route inter-AP messages towards their destination. Without this functionality, the IAB node generating the Xn message (the first IAB node 120a) must forward it to the donor lAB <NUM> so that the Xn message may be forwarded to the destination node (the second IAB node 120b). In this example, the Xn message would have had to be forwarded via the constituent wireless backhaul connections between the first IAB node 120a and the IAB donor <NUM> (that is, between the first IAB node 120a and the third IAB node 120c, between the third IAB node 120c and fourth IAB node 120d, and between the fourth IAB node 120d and the donor lAB <NUM>). However, by implementing the above process, the Xn message may be forwarded by the third IAB node 120c to the second IAB node 120b, without any interaction of the fourth IAB node 120d or donor lAB <NUM> and without using the respective wireless backhaul connections between the third IAB node 120c, fourth IAB node 120d and donor lAB <NUM>. The above process therefore frees up capacity on these wireless backhaul connections which would otherwise be wasted forwarding these Xn messages to the donor lAB <NUM>. Furthermore, as these multi-hop architectures may result in a tree structure with further IAB node branches (such as if the third and/or fourth IAB node 120c, 120d had one or more other child lAB nodes) and Xn messages originating within these IAB node branches must also be forwarded up to the IAB donor <NUM>, then any wireless backhaul connection that serves multiple IAB node branches will be significantly burdened. The above process therefore has a more significant benefit for wireless backhaul connections serving multiple IAB node branches.

In another example of the above process in which the first IAB node 120a generates a message destined for a destination IAB node which is not identified in either the first IAB node's routing table or third IAB node's routing table (either as a neighbouring node with which they have an established Xn connection or a parent/child node of such a neighbouring node), then the first IAB node 120a and third IAB node 120c forward the Xn message towards the IAB donor <NUM> (step S209). If the fourth IAB node's routing table identifies this destination IAB node, then it may process it according to the steps of the above process. If not, then the Xn message is eventually received and processed by the IAB donor <NUM>.

A process of updating the routing table will now be described with reference to <FIG>, <FIG> and <FIG>.

The cellular telecommunications network <NUM> is initially in the state as shown in <FIG>. At a subsequent time, a fifth IAB node 120e is added to the network and is connected directly to the donor lAB <NUM> as shown in <FIG>. The third UE 110c (connected to the third lAB node 120c) is within the coverage area of the fifth IAB node 120e. In a first step of this routing table update process (S301), the third IAB node 120c receives a measurement report from the third UE 110c identifying the fifth IAB node 120e. In step S303, the third IAB node 120c determines whether or not it has an established Xn connection with the fifth IAB node 120e by consulting its routing table. In this example, the third IAB node 120c and fifth IAB node 120e do not have an established Xn connection. In response, the third IAB node 120c begins an Xn connection establishment process with the fifth IAB node 120e (step S305). Once established, the third IAB node 120c has identified the fifth IAB node 120e and has received the fifth IAB node's IP address. Similarly, the fifth IAB node 120e has identified the third IAB node 120c and has received the third IAB node's IP address.

In step S307, the third IAB node 120c sends a routing table update message (encapsulated in an Xn message) to the fifth IAB node 120e. This routing table update message identifies the parent node for the third IAB node 120c (in this example, the fourth lAB node 120d) and all child nodes for the third IAB node 120c (in this example, the first and second IAB nodes 120a, 120b).

On receipt, the fifth IAB node 120e stores this data in its routing table. Accordingly, the fifth IAB node's routing table includes the following data:.

The fifth IAB node 120e also sends a routing table update response message (encapsulated in an Xn message) to the third IAB node 120c, identifying the parent node for the fifth IAB node 120e and all child nodes for the fifth IAB node 120e. In this example, the donor lAB <NUM> is the parent node of the fifth IAB node 120e and there are no child nodes for the fifth IAB node 120e. On receipt, in step S309, the third IAB node 130c stores this data in its routing table. Accordingly, the third IAB node's routing table includes the following data:.

Furthermore, in step S311, the fifth IAB node 120e sends a routing table update message (encapsulated in an Xn message) to all other neighbouring nodes identified in its routing table to identify any new parent/child relationships. There are no new relationships in this example so no such message is required.

The above process provides a mechanism for the routing tables to be updated with information on a newly added IAB node, so that the newly added IAB node may be utilised in the message transport process. Additionally, the process provides for updating routing tables following termination of an Xn connection between IAB nodes from the network (e.g. if an IAB node is removed from the network, powered down, or the Xn connection is otherwise lost). Following detection of a termination, the detecting node sends a message to all other nodes identified in its routing table to inform the other nodes of the termination. The other nodes may then update their routing tables.

Claim 1:
A method of operating an Access Point, AP, (120c) in a cellular telecommunications network (<NUM>), the cellular telecommunications network (<NUM>) having a plurality of APs (<NUM>) and a core network (<NUM>), wherein the AP (120c) is connected to a first subset of the plurality of APs (<NUM>) via a wireless upstream connection towards the core network (<NUM>) and is further connected to a second subset of the plurality of APs (<NUM>) via a wireless downstream connection away from the core network (<NUM>), the method comprising the steps of:
receiving an inter-AP message in a first wireless communication from a first AP (120a) of the second subset of the plurality of APs (<NUM>), the inter-AP message comprising a destination identifier; and
identifying a second AP (120b) based on the destination identifier of the inter-AP message; characterised in that:
the second AP (120b) is a member of the second subset of the plurality of APs (<NUM>); and the method is characterised by:
sending the inter-AP message to the second AP (120b) of the second subset of the plurality of APs (<NUM>) in a second wireless communication via the wireless downstream connection.