Providing a connection to a core network

Abstract

There is provided a first relay network node (200) comprising a first wireless device (210) and a first radio access network (RAN) node (220). The first wireless device (210) and the first RAN node (220) are interconnected through internet protocol (IP) connectivity and the first wireless device (210) is configured to establish a connection (242) between the first wireless device (210) and a second RAN node (230) to provide a backhaul connection for the first RAN node (220) to a core network (236) via the first wireless device (210) and the second RAN node (230).

Description

[0001] PROVIDING A CONNECTION TO A CORE NETWORK

[0002] Technical Field

[0003] The disclosure relates to methods for providing a connection to a core network and nodes configured to operate in accordance with those methods.

[0004] Background

[0005] The world is becoming increasingly interconnected through the use of wireless connectivity, such as fifth generation (5G) wireless connectivity. However, bringing wireless connectivity to remote, isolated, and emergency areas (or regions) presents a profound technological challenge. These areas are often known by their geographical remoteness, their lack of communication infrastructure, and / or their vulnerability to ‘force majeure’ events or natural disasters. Overcoming these challenges is not only beneficial in terms of the economic prospect of these areas but it also important to enable swift and efficient (e.g. 5G) communication to end users. This is especially important during emergencies. For example, emergency services rely on high-speed connectivity to effectively carry out their duties. The efficiency of communication may make a significant difference in this regard and can even lead to saving human lives.

[0006] Microwave transmission enables an exchange of data and information across long distances. However, microwave transmission faces notable challenges and limitations. One of the key challenges is that it relies on line-of-sight (LOS) communication and specific equipment including relays and towers or repeaters, making it expensive and challenging to deploy in remote or emergency areas. Satellite communication has been long used as a possible transmission option in remote areas. However, satellite communication faces unique challenges related to its deployment cost, the extra equipment needed to deploy it, and its high latency and low performance. Moreover, both microwave and satellite technologies often require dedicated frequency bands, which may not be easy to obtain or may not fulfil requirements in terms of performance and quality of service (QoS), especially in the case of an emergency response.

[0007] Thus, conventional backhauling methods, such as microwave or satellite links, are often unsuitable for expanding communication coverage due to their inherent limitations and cost-prohibitive nature.

[0008] A related technology called Integrated Access and Backhaul (IAB) has been proposed by the Third Generation Partnership Project (3GPP) Releases 16, 17 and 18. IAB refers to a network architecture that combines the functionalities of both access and backhaul in a unified system. IAB is often used in the wireless communication, particularly in 5G networks.

[0009] Figure 1 shows an example IAB architecture. In the example illustrated in Figure 1 , the IAB architecture comprises a first radio access network (RAN) node 100 and a second RAN node 130. IAB requires a central unit (CU) / distributed unit (DU) split architecture. In more detail, the first RAN node 100 comprises a mobile terminal (MT) and a DU, whereas the second RAN node 130 comprises a CU and a DU. The CU of the second RAN node 130 controls the DU of the first RAN node 100 and the DU of the second RAN node 130.

[0010] The first RAN node 100 has a first coverage area 124. The second RAN node 130 has a second coverage area 132. The second RAN node 130 is connected to a 5G core (5GC) network 136. As illustrated by arrow 138, a user equipment (UE) 134 in the second coverage area 132 can connect to the 5GC network 136 via the second RAN node 130. As illustrated by arrow 142, the first RAN node 100 is backhauled to the second RAN node 130. Thus, as illustrated by arrows 140 and 142, a UE 122 in the first coverage area 124 can connect to the 5GC network 136 via the first RAN node 100 and the second RAN node 130.

[0011] However, the IAB architecture has also been shown to have limitations. Specifically, it requires new features to be developed such as CU / DU split interfaces (F1 / E5), a protocol extension Backhaul Adaptation Protocol (BAP), and an MT to be implemented in the first RAN node 100. As such, the development of an IAB architecture is complex and costly. The IAB architecture has thus never gained commercial interest.

[0012] As such, expanding (e.g. 5G) communication coverage to remote, isolated, and emergency areas still presents a significant challenge due to infrastructure constraints and / or logistical complexities. Therefore, as described above, there currently exist certain challenge(s).

[0013] Summary

[0014] It is an object of the disclosure to obviate or eliminate at least some of the abovedescribed challenge(s) associated with existing techniques.

[0015] Therefore, according to an aspect of the disclosure, there is provided a first relay network node comprising a first wireless device and a first radio access network (RAN) node. The first wireless device and the first RAN node are interconnected through internet protocol (IP) connectivity and the first wireless device is configured to establish a connection between the first wireless device and a second RAN node to provide a backhaul connection for the first RAN node to a core network via the first wireless device and the second RAN node.

[0016] According to another aspect of the disclosure, there is provided a system comprising the first relay network node and the core network.

[0017] According to another aspect of the disclosure, there is provided a method for providing a connection to a core network. The method is performed by a first relay network node comprising a first wireless device and a first RAN node. The method comprises establishing, by the first wireless device, a connection between the first wireless device and a second RAN node. The first wireless device and the first RAN node are interconnected through IP connectivity and the first wireless device establishes the connection between the first wireless device and the second RAN node to provide a backhaul connection for the first RAN node to the core network via the first wireless device and the second RAN node.

[0018] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method described in respect of the first relay network node.

[0019] According to another aspect of the disclosure, there is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method described in respect of the first relay network node.

[0020] Therefore, there is provided an improved technique for providing a connection to a core network.

[0021] Brief description of the drawings

[0022] For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0023] Figure 1 shows an example IAB architecture;

[0024] Figure 2 shows a relay network node according to an embodiment;

[0025] Figure 3 shows a method in accordance with an embodiment;

[0026] Figures 4 and 5 show a system according to some embodiments;

[0027] Figure 6 shows an example use case for the RAB architecture;

[0028] Figure 7 shows a system according to an embodiment;

[0029] Figure 8 shows a 5GC for a RAB according to an embodiment;

[0030] Figures 9 to 13 show a RAB implementation according to some embodiments;

[0031] Figure 14 shows a signalling diagram illustrating a method according to an embodiment;

[0032] Figure 15 shows a RAB configuration according to an embodiment;

[0033] Figure 16 shows fragmentation handling in RAB according to an embodiment; Figure 17 shows a maximum segment size calculation according to an embodiment;

[0034] Figures 18 to 20 show a RAB deployment according to some embodiments;

[0035] Figure 21 shows a signalling diagram illustrating a method according to an embodiment;

[0036] Figure 22 shows a RAB latency measurement; and

[0037] Figure 23 shows an example use case for RAB.

[0038] Detailed Description

[0039] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0040] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject-matter to those skilled in the art.

[0041] The techniques described herein can be used in respect of any type of network. For example, the network be a communications or telecommunications network, e.g. a cellular network. In some embodiments, the network can be a mobile network, such as a fifth generation (5G) mobile network, a sixth generation (6G) mobile network, or any other generation mobile network. The network can comprise a radio access network (RAN). The network can comprise a core network (CN), such as a 5G core (5GC) network. In some embodiments, the network can be at least partially virtualised. Although some examples have been provided for the type of network to which the disclosure may apply, it will be understood that the network referred to herein can be any other type of network.

[0042] The techniques described herein are implemented by a relay network node. Herein, a relay network node may also be referred to as a Radio Access Backhauling (RAB) node. Thus, these terms can be used interchangeably.

[0043] Figure 2 illustrates a relay network node 200 in accordance with an embodiment. The relay network node 200 can be for providing a connection to a core network, such as a 5GC network or any other core network. As illustrated in Figure 2, the relay network node comprises a wireless device 210 and a radio access network (RAN) node 220. The wireless device 210 can, for example, be a mobile device (e.g. a mobile terminal (MT)), a user equipment (UE), an access point, a router, or any other type of wireless device. The RAN node 220 can, for example, be a base station (e.g. a New Radio (NR) base station (gNB)), or any other type of RAN node.

[0044] As illustrated in Figure 2, advantageously, the wireless device 210 and the RAN node 220 are interconnected through internet protocol (IP) connectivity 212. The wireless device 210 can refer to equipment capable, configured, arranged and / or operable to communicate with the RAN node 220 and optionally also any other nodes referred to herein (e.g. another RAN node referred to herein, or any other node referred to herein) to enable and / or to perform the functionality described herein. The RAN node 220 can refer to equipment capable, configured, arranged and / or operable to communicate with the wireless device 210 and optionally also any other nodes referred to herein (e.g. another wireless device referred to herein, or any other node referred to herein) to enable and / or to perform the functionality described herein. As illustrated in Figure 2, the wireless device 210 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the wireless device 210 and can implement the method described herein in respect of the wireless device 210. The processing circuitry 12 can be configured or programmed to control the wireless device 210 in the manner described herein. The processing circuitry 12 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the wireless device 210. In some embodiments, the processing circuitry 12 can be configured to run software to perform the method described herein in respect of the wireless device 210. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of the wireless device 210.

[0045] As illustrated in Figure 2, in some embodiments, the wireless device 210 may optionally comprise a memory 14. The memory 14 of the wireless device 210 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 14 of the wireless device 210 may comprise a non-transitory media. Examples of the memory 14 of the wireless device 210 include, but are not limited to, a random-access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0046] The processing circuitry 12 of the wireless device 210 can be communicatively coupled (e.g. connected) to the memory 14 of the wireless device 210. In some embodiments, the memory 14 of the wireless device 210 may be for storing program code or instructions which, when executed by the processing circuitry 12 of the wireless device 210, cause the wireless device 210 to operate in the manner described herein in respect of the wireless device 210. For example, in some embodiments, the memory 14 of the wireless device 210 may be configured to store program code or instructions that can be executed by the processing circuitry 12 of the wireless device 210 to cause the wireless device 210 to operate in accordance with the method described herein in respect of the wireless device 210. Alternatively or in addition, the memory 14 of the wireless device 210 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 of the wireless device 210 may be configured to control the memory 14 of the wireless device 210 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0047] In some embodiments, as illustrated in Figure 2, the wireless device 210 may optionally comprise a communications interface 16. The communications interface 16 of the wireless device 210 can be communicatively coupled (e.g. connected) to the processing circuitry 12 of the wireless device 210 and / or the memory 14 of the wireless device 210. The communications interface 16 of the wireless device 210 may be operable to allow the processing circuitry 12 of the wireless device 210 to communicate with the memory 14 of the wireless device 210 and / or vice versa. Similarly, the communications interface 16 of the wireless device 210 may be operable to allow the processing circuitry 12 of the wireless device 210 to communicate with any one or more other nodes, e.g. the RAN node 220 (such as via a communications interface 26 of the RAN node 220) of Figure 2, another RAN node referred to herein, and / or any other node. The communications interface 16 of the wireless device 210 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 12 of the wireless device 210 may be configured to control the communications interface 16 of the wireless device 210 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0048] As illustrated in Figure 2, the RAN node 220 comprises processing circuitry (or logic) 22. The processing circuitry 12 controls the operation of the RAN node 220 and can implement the method described herein in respect of the RAN node 220. The processing circuitry 22 can be configured or programmed to control the RAN node 220 in the manner described herein. The processing circuitry 22 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the RAN node 220. In some embodiments, the processing circuitry 22 can be configured to run software to perform the method described herein in respect of the RAN node 220. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 22 may be configured to run a container to perform the method described herein in respect of the RAN node 220.

[0049] As illustrated in Figure 2, in some embodiments, the RAN node 220 may optionally comprise a memory 24. The memory 24 of the RAN node 220 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 24 of the RAN node 220 may comprise a non-transitory media. Examples of the memory 24 of the RAN node 220 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0050] The processing circuitry 22 of the RAN node 220 can be communicatively coupled (e.g. connected) to the memory 24 of the RAN node 220. In some embodiments, the memory 24 of the RAN node 220 may be for storing program code or instructions which, when executed by the processing circuitry 22 of the RAN node 220, cause the RAN node 220 to operate in the manner described herein in respect of the RAN node 220. For example, in some embodiments, the memory 24 of the RAN node 220 may be configured to store program code or instructions that can be executed by the processing circuitry 22 of the RAN node 220 to cause the RAN node 220 to operate in accordance with the method described herein in respect of the RAN node 220. Alternatively or in addition, the memory 24 of the RAN node 220 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 22 of the RAN node 220 may be configured to control the memory 24 of the RAN node 220 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0051] In some embodiments, as illustrated in Figure 2, the RAN node 220 may optionally comprise a communications interface 26. The communications interface 26 of the RAN node 220 can be communicatively coupled (e.g. connected) to the processing circuitry 22 of the RAN node 220 and / or the memory 24 of the RAN node 220. The communications interface 26 of the RAN node 220 may be operable to allow the processing circuitry 22 of the RAN node 220 to communicate with the memory 24 of the RAN node 220 and / or vice versa. Similarly, the communications interface 26 of the RAN node 220 may be operable to allow the processing circuitry 22 of the RAN node 220 to communicate with any one or more other nodes, e.g. the wireless device 210 (such as via a communications interface 16 of the wireless device 210) of Figure 2, another wireless device referred to herein, and / or any other node. The communications interface 26 of the RAN node 220 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 22 of the RAN node 220 may be configured to control the communications interface 26 of the RAN node 220 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0052] Thus, a RAB node can comprise a RAN node (e.g. a 5G RAN node, such as a gNB, or any other RAN node) 220 and a wireless device (e.g. an MT or any other wireless device) 210. In some embodiments, the RAN node 220 may comprise any one or more of a baseband (e.g. baseband radio, such as a radio processor), a radio node, and an antenna. The wireless device 210 can be connected to (e.g. a baseband of) the RAN node 220 from one end and use a (e.g. 5G) radio access interface from another end.

[0053] It will be appreciated that Figure 2 only shows the components required to illustrate an embodiment of the relay network node 200 and, in practical implementations, the relay network node 200 may comprise other numbers of each of the components to those shown, and / or additional or alternative components to those shown.

[0054] Figure 3 illustrates a method performed by a first relay network node 200 in accordance with an embodiment. The method is for providing a connection to a core network, such as a 5GC network or any other core network. As described earlier, the first relay network node 200 comprises a wireless device 210 and a RAN node 220, which are referred to herein as the first wireless device 210 and the first RAN node 220 respectively. The first relay network node 200 or, more specifically, the first wireless device 210 of the first relay network node 200 described earlier with reference to Figure 2 can be configured to operate in accordance with the method of Figure 3. For example, the method of Figure 3 can be performed by or under the control of the processing circuitry 12 of the first wireless device 210 according to some embodiments. With reference to Figure 3, as illustrated at block 400, a connection is established between the first wireless device 210 and a second RAN node. More specifically, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) establishes the connection. The first wireless device 210 and the first RAN node 220 are interconnected through IP connectivity 212 and the first wireless device 210 establishes the connection between the first wireless device 210 and the second RAN node to provide a backhaul connection for the first RAN node 220 to the core network via the first wireless device 210 and the second RAN node.

[0055] In some embodiments, the first wireless device 210 and the first RAN node 220 may be connected to each other via a wired connection.

[0056] Although not illustrated in Figure 3, in some embodiments, the method may comprise assigning, by the first wireless device 210, an IP address to the first RAN node 220. For example, in some embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to assign an IP address to the first RAN node 220. In some embodiments, the IP address is associated with Layer 3.

[0057] Although also not illustrated in Figure 3, in some embodiments, the method may comprise assigning, by the first wireless device 210, a default route to the first RAN node 220 via which the first RAN node 220 is to transmit backhaul data. For example, in some embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to assign the default route to the first RAN node 220. In these embodiments, the default route is from the first RAN node 220 to the core network via the first wireless device 210 and the second RAN node.

[0058] Although also not illustrated in Figure 3, in some embodiments, the method may comprise transmitting, by the first RAN node 220, backhaul data to the core network via the first wireless device 210 and the second RAN node. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to transmit backhaul data to the core network via the first wireless device 210 and the second RAN node.

[0059] Although also not illustrated in Figure 3, in some embodiments, the method may comprise transmitting, by the first RAN node 220, backhaul data via one or both of an N2 interface of the first RAN node 220 and an N3 interface of the first RAN node 220. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to transmit backhaul data via one or both of an N2 interface of the first RAN node 220 and an N3 interface of the first RAN node 220.

[0060] Although also not illustrated in Figure 3, in some embodiments (such as that described later with reference to Figure 11), the method may comprise establishing, by the first RAN node 220, a first internet protocol security, IPsec, tunnel for backhaul data transmission. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to establish the first IPsec tunnel.

[0061] In some embodiments, establishing the first IPsec tunnel may comprise establishing the first IPsec tunnel from the first RAN node 220 to a gateway via the first wireless device 210 and the second RAN node. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to establish the first IPsec tunnel from the first RAN node to the gateway via the first wireless device 210 and the second RAN node. In these embodiments, establishing the connection provides the backhaul connection for the first RAN node 220 to the core network via the first wireless device 210, the second RAN node, and the gateway. For example, in these embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to establish the connection to provide the backhaul connection for the first RAN node 220 to the core network via the first wireless device 210, the second RAN node, and the gateway.

[0062] In some embodiments, transmitting backhaul data may comprise transmitting backhaul data via the first IPsec tunnel. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to transmit backhaul data via the first IPsec tunnel.

[0063] Although not illustrated in Figure 3, in some embodiments (such as that described later with reference to Figure 11), the method may comprise establishing, by the first RAN node 220, a second IPsec tunnel for operation and maintenance (O&M) of the first RAN node 220. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to establish the second IPsec tunnel (904).

[0064] In some of these embodiments, establishing the second IPsec tunnel may comprise establishing the second IPsec tunnel from the first RAN node 220 to a gateway via the first wireless device 210 and the second RAN node. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to establish the second IPsec tunnel from the first RAN node 220 to a gateway via the first wireless device 210 and the second RAN node.

[0065] Although not illustrated in Figure 3, in some embodiments (such as that described later with reference to Figure 12), the method may comprise encapsulating, by the first RAN node 220, backhaul data in a PDU session for the first wireless device 210. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to encapsulate backhaul data in a PDU session for the first wireless device 210.

[0066] Although not illustrated in Figure 3, in some embodiments, the method may comprise assigning, by the first wireless device 210, a single IP address to the first RAN node 220 for backhaul data transmitted via an N2 interface of the first RAN node 220 and an N3 interface of the first RAN node 220. For example, in these embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to assign the single IP address to the first RAN node 220.

[0067] In some embodiments, assigning the single IP address may comprise assigning the single IP address during establishment of the PDU session for the first wireless device 210. For example, in these embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to assign the single IP address during establishment of the PDU session for the first wireless device 210.

[0068] In some embodiments, the first wireless device 210 may operate (e.g. may be configured to operate) in an internet protocol passthrough (IPPT) mode.

[0069] Although not illustrated in Figure 3, in some embodiments, the method may comprise assigning, by the first wireless device 210, a data network name (DNN) subscriber IP address to the first RAN node 220. For example, in these embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to assign the DNN subscriber IP address to the first RAN node 220.

[0070] In some embodiments (such as that described later with reference to Figure 13), the first wireless device 210 may operate (e.g. may be configured to operate) as a router for an IP network behind the first wireless device 210.

[0071] In some embodiments, the IP network may have an IP address range for which the first wireless device 210 is allowed to operate as a router.

[0072] In some embodiments, the IP address range may be provided from (e.g. acquired from) a Remote Authentication Dial-In User Service (RADIUS). For example, in some embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to acquire the IP address range, such as from a RADIUS.

[0073] In some embodiments, the IP address range may be associated with an evolved packet system (EPS) bearer for the first wireless device 210 or a PDU session for the first wireless device 210.

[0074] In some embodiments, the IP address range may be provided (or acquired) at creation of the EPS bearer or at creation of the PDU session.

[0075] In some embodiments, the IP network may be an IP version 4 (IPv4) network.

[0076] In some embodiments, the first RAN node may comprise a first central unit (CU) and a first distributed unit (DU). In these embodiments, the first CU may control (e.g. be configured to control) the first DU. In some embodiments, the first RAN node (or the first DU of the first RAN node) may operate independently of the second RAN node (or a CU of the second RAN node).

[0077] Although not illustrated in Figure 3, in some embodiments, the method may comprise using, by the first RAN node 220, the backhaul connection to establish a connection between the core network and a first user equipment, which is in a first coverage area of the first RAN node 220 and outside a second coverage area of the second RAN node. For example, in some embodiments, the first RAN node 220 (or the processing circuitry 22 of the first RAN node 220) may be configured to use the backhaul connection to establish the connection between the core network and the first user equipment.

[0078] In some embodiments, the first relay network node 200 may be a first mobile relay network node.

[0079] In some embodiments, the first relay network node 200 may be moveable around a second coverage area of the second RAN node 230.

[0080] In some embodiments, the first relay network node 200 is placed (or located) on or in a vehicle. For example, in some embodiments, the first relay network node 200 may be configured to be placed on or in a vehicle.

[0081] Although not illustrated in Figure 3, in some embodiments (such as that described later with reference to Figure 5), the method may comprise establishing the connection between the first wireless device 210 and the second RAN node to provide the backhaul connection for the first RAN node 220 to the core network via the first wireless device 210, a second relay network node, and the second RAN node. For example, in some embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to establish the connection between the first wireless device 210 and the second RAN node to provide the backhaul connection for the first RAN node 220 to the core network via the first wireless device 210, a second relay network node, and the second RAN node.

[0082] In some embodiments, establishing the connection between the first wireless device 210 and the second RAN node may comprise establishing a first connection between the first wireless device 210 and a third RAN node of the second relay network node and a second connection may be established between a second wireless device of the second relay network node and the second RAN node. For example, in some embodiments, the first wireless device 210 (or the processing circuitry 12 of the first wireless device 210) may be configured to establish the connection between the first wireless device 210 and the second RAN node by being configured to establish the first connection. In these embodiments, the second wireless device and the third RAN node may be interconnected through IP connectivity.

[0083] The wireless device 210 described herein may also be referred to as a customerpremises equipment (CPE), a mobile device, a router, a modem, or a mobile terminal (MT). Thus, these terms can be used interchangeably herein. A wireless device can refer to a device capable of connecting to a mobile communication network. It can encompass any type of wireless communication devices.

[0084] The second RAN node described herein may also be referred to as a donor node. A donor node can typically refer to a network element or entity that provides resources, support, and / or connectivity to another network or system. A donor node can serve as a primary source of connectivity for subsequent nodes (or hops).

[0085] Each node in a RAB network can be referred to as a “hop”. The number of hops determines the distance and coverage of the network. A multi-hop network involves multiple intermediate nodes between the donor node and the end user. Each hop represents a node that relays the signal further, extending the overall coverage area. Herein, the terms relay network node, relay node, relay, RAB node, and hop can be used interchangeably.

[0086] Figure 4 shows a system, namely a RAB architecture (or network), according to an embodiment. The system comprises a first relay network node 200. The first relay network node 200 can be as described earlier with reference to Figures 2 and 3. The first relay network node 200 comprises a first wireless device 210 and a first (or “parent”) RAN node 220. The system also comprises a core (e.g. 5GC) network 236 and a second (or “donor”) RAN node 230.

[0087] As illustrated in Figure 4, a connection 242 is established between the first wireless device 210 and the second RAN node 230. More specifically, the first wireless device 210 (or the processing circuitry 12 of the wireless device 210) establishes the connection 242. The first wireless device 210 and the first RAN node 220 are interconnected through IP connectivity and the first wireless device 210 establishes the connection 242 between the first wireless device 210 and the second RAN node 230 to provide a backhaul connection for the first RAN node 220 to the core network 236 via the first wireless device 210 and the second RAN node 230. Thus, the IP connectivity and the connection 242 provide the backhaul connection.

[0088] The first RAN node 220 has a first coverage area 222. The second RAN node 230 has a second coverage area 232. The second RAN node 230 is connected to the core network 236. As illustrated by arrow 235, a UE (or end user device) 234 in the second coverage area 232 can connect to the core network 236 via the second RAN node 230. In the manner described earlier and as illustrated by arrow 242, the first RAN node 220 is backhauled to the second RAN node 230 via the first wireless device 210 and the second RAN node 230. Thus, as illustrated by arrows 240 and 242, a UE (or end user device) 224 in the first coverage area 222 can connect to the core network 236 via the first RAN node 220, the first wireless device 210, and the second RAN node 230.

[0089] Figure 5 shows a system, namely a RAB architecture (or network), according to another embodiment. The system comprises a first relay network node 200 and a second relay network node 300. Although two relay network nodes 200, 300 are illustrated for the purpose of this embodiment, it will be understood that the system may comprise any other number (such as one or at least two, e.g. three, four, five or more) relay network nodes and the same principles can apply to each. The first relay network node 200 and the second relay network node 300 can be as described earlier with reference to Figures 2 and 3.

[0090] The first relay network node 200 comprises a first wireless device 210 and a first RAN node 220. The first relay network node 200 (or, more specifically, the first wireless device 210) establishes a connection 244, 246 between the first wireless device 210 and a second (or “donor”) RAN node 230 via the second relay network node 300. The first wireless device 210 and the first RAN node 220 are interconnected through IP connectivity and the first wireless device 210 establishes the connection 244, 246 between the first wireless device 210 and the second RAN node 230 to provide a backhaul connection for the first RAN node 220 to the core network 236 via the first wireless device 210, the second relay network node 300, and the second RAN node 230. The second relay network node 300 comprises a second wireless device 310 and a third RAN node 320. The system also comprises a core (e.g. 5GC) network 236. The second RAN node 230 is connected to the core network 236. In more detail, as illustrated in Figure 5, the first relay network node 200 (or, more specifically, the first wireless device 210) establishes the connection 244, 246 between the first wireless device 210 and the second RAN node 230 by establishing a first connection 244 between the first wireless device 210 and the third RAN node 320 of the second relay network node 300, and a second connection 246 is established between the second wireless device 310 of the second relay network node 300 and the second RAN node 230. The second wireless device 310 and the third RAN node 320 are interconnected through IP connectivity. The second connection 246 may be established by the second relay network node 300 (or, more specifically, the second wireless device 310). In some embodiments, establishment of the second connection 246 may be initiated in response to establishment of the first connection 244. In other embodiments, the second connection 246 may already have been established when the first connection 244 is established.

[0091] As illustrated in Figure 5, the first RAN node 220 has a first coverage area 222. The second RAN node 230 has a second coverage area 232. The third RAN node 320 has a third coverage area 322. The second RAN node 230 is connected to the core network 236. A UE (or end user device) 234 in the second coverage area 232 can connect to the core network 236 via the second RAN node 230. A UE (or end user device) 224 in the first coverage area 222 can connect to the core network 236 via the first relay network node 200 (or, more specifically, via the first RAN node 220 and the first wireless device 210), the second relay network node 300 (or, more specifically, via the third RAN node 320 and the second wireless device 310), and the second RAN node 230. A UE (or end user device) 324 in the third coverage area 322 can connect to the core network 236 via the second relay network node 300 (or, more specifically, via the third RAN node 320 and the second wireless device 310), and the second RAN node 230.

[0092] Thus, the disclosure provides an innovative and flexible technological solution called RAB. RAB can be used in networks to extend communication coverage. For example, RAB can be used in a 5G network to extend 5G communication coverage. The coverage can, for example, be extended to remote or underserved regions where traditional fixed backhaul connections prove challenging or cost prohibitive. RAB tackles the challenges in these areas, making advanced network features more widely accessible. RAB enhances response capabilities (such as emergency response capabilities, in under- served areas). Moreover, these advantages are achieved without the complex product development of the existing techniques described earlier.

[0093] The RAB technical area can cover an End-to-End (E2E) solution. It can include a RAN, a transport network, and a core network. RAB is a new technology that utilizes a RAN to extend, or that operates as a reach back for extending, coverage (e.g. 5G coverage) such as to remote and isolated areas. It eliminates the need for traditional backhauling methods such as fiber, microwave, or satellite links. It also eliminates the need for IAB. It is a less-complex alternative to IAB, and provides greater flexibility and costeffectiveness.

[0094] RAB advantageously combines the radio access and backhaul functions into a single system. This means that the RAB node, which combines a RAN node (e.g. a gNB) with a wireless device (e.g. an MT), not only provides wireless access to end user devices but also serves as a relay for connecting other RAB nodes to the core network.

[0095] The integrated approach eliminates the need for dedicated backhaul connections or another dedicated core network, reducing the complexity and cost of network deployment. It also increases network capacity by enabling more RAN nodes (e.g. gNBs) to connect to the core network without the need for dedicated backhaul connections.

[0096] This disclosure demonstrates the feasibility of the RAB solution that can be served in remote and / or emergency areas where connectivity is (e.g. urgently) needed. A goal of RAB is to swiftly extend (e.g. 5G) coverage for service (or temporary service) in remote and / or emergency areas, such as those areas where connectivity may be most crucial. This can be vital for mission-critical users, such as first responders, who require connectivity during emergencies beyond the reach of existing network coverage.

[0097] In some embodiments, the RAB node described herein can be located on the ground. In other embodiments, the RAB node described herein can be located on or in a vehicle, such as a motor vehicle (e.g. car, truck, bus, or any other motor vehicle), a railed vehicle (e.g. train, tram, or any other railed vehicle), a watercraft vehicle (e.g. ship, boat, underwater vehicle, or any other watercraft vehicle), an aircraft vehicle (e.g. plane, helicopter, or any other aircraft vehicle), or any other vehicle. The RAB node described herein can thus be referred to as a temporary network. For example, the RAB node can be referred to as a mobile system or, more specifically a mobile cell (e.g. a “cell-on- wheels”) system.

[0098] There is a challenge in connecting such a mobile system back to an (e.g. existing) available network, where microwave and satellite technologies are not the best options due to their implementation time, their cost and other different technical reasons. This challenge is addressed by the use of RAB. For example, a RAB node can be placed at the edge of an available donor network cell and use its wireless device to connect the local RAN node with the available donor network. The connection of the RAB node to the donor cell can be performed quickly, such as using the same user access frequencies. The RAB node may move around, if needed, and the RAB node can do so without losing backhaul connectivity, since it does not require line-of-sight communication. In case coverage needs to be extended even further, e.g. due to distance or obstacles, at least one second RAB node can be placed in the same manner (e.g. as described earlier with reference to Figure 5). Thus, each RAB node may be referred to as a “hop”.

[0099] Some benefits of using RAB include that it is faster to setup than a microwave or satellite connection, it is flexible (e.g. the RAB node can move around the coverage area of the available network, if needed), and multiple hops can be deployed depending on how much coverage is needed. RAB is also driven by simplicity and is less complex than IAB, since it can reuse existing network (e.g. 5G) components.

[0100] Compared to non-NR technology, such as satellite and microwave, RAB is flexible and faster to setup. For instance, RAB can operate in nomad and / or tactical operations. As mentioned earlier, the RAB node can be used as mobile system that can move around a donor coverage area of an available network. Moreover, multiple hops can be deployed depending on how much coverage is needed. Compared to NR technology such IAB, RAB is driven by simplicity, e.g. by enabling reuse of existing network components (e.g. 5G components or, more specifically, Release 15 5G components). Thus, the RAB approach described herein can provide several advantages.

[0101] In summary, the RAB approach described herein can provide any one or more of the following advantages: • Flexibility: The RAB node can be used as a temporary network, such as a mobile (e.g. cell-on-wheels) system, which allows it to adapt to the coverage needs of the (e.g. existing) network. This is also possible without the requirement of the line-of-sight communication.

[0102] • Scalability: If further coverage expansion is necessary, e.g. due to distance or obstacles, additional RAB nodes can be deployed. This enables multiple hops to extend coverage as needed. The deployment may, for example, be in a daisy-chain topology, a tree topology, or both.

[0103] • Simplicity: IAB requires new features to be developed such as CU / Dll split interfaces (F1 / E5), protocol extension (BAP), and onboard MT development. RAB is a less complex solution compared to IAB, since can leverage existing (e.g. 5G) components without additional complex product development. Besides, compared to satellite and microwave, RAB does not need to use additional and / or specific back-hauling hardware. A connection between RAB nodes (or hops, like in the mobile system embodiment) and the donor network cell can be swiftly established, e.g. using either the same access frequencies or a dedicated backhauling frequency.

[0104] Certain embodiments described herein may provide one or more of the above-described technical advantages.

[0105] The RAB architecture can use a dual-mode core (e.g. 5GC) solution. The core (e.g. 5GC) solution can be based on cloud native principles, e.g. with software architecture such as software architecture based on microservice technology and / or Containerized Network Functions (CNFs). The core (e.g. 5GC) solution can be verified with specific product versions in an E2E setup, including a RAN with real Mobile Broadband (MBB) calls of UE devices. A test case description can be focused on an E2E working demonstration and use cases related to extending the (e.g. 5G) coverage with optimum performance.

[0106] Figure 6 shows an example use case for a RAB architecture (or network). The RAB architecture comprises a first relay network node 200 and a second relay network node 300. The first relay network node 200 comprises a first wireless device and a first RAN node (not illustrated in Figure 6). In the manner described earlier, the first relay network node 200 establishes a connection with a second RAN node 230 via the second relay network node 300. The second relay network node 300 comprises a second wireless device and a third RAN node (not illustrated in Figure 6). The second RAN node 230 is connected to a core network 236.

[0107] The first RAN node 220 has a first coverage area, the second RAN node 230 has a second coverage area, and the third RAN node 320 has a third coverage area (not illustrated in Figure 6). A UE (or end user device) 234 in the second coverage area can connect to the core network 236 via the second RAN node 230. A UE (or end user device) 224 in the first coverage area can connect to the core network 236 via the first relay network node 200 (or, more specifically, via the first RAN node and the first wireless device), the second relay network node 300 (or, more specifically, via the third RAN node and the second wireless device), and the second RAN node 230. A UE (or end user device) 324 in the third coverage area can connect to the core network 236 via the second relay network node 300 (or, more specifically, via the third RAN node and the second wireless device), and the second RAN node 230.

[0108] The RAB architecture can encompass a specific network topology according to some embodiments, such as that illustrated in Figure 6. It can, for example, comprise the establishment of a chain topology, primarily designed for a (e.g. 5G) stand-alone technology deployment. In an example implementation, a RAB architecture (or network) can comprise one donor network, followed by two hops, separated by a maximum distance of (i.e. a distance of not more than) 10 kilometres. The access coverage may span approximately 5 kilometres around each RAB node (or hop). The RAB architecture may operate on a mid-band frequency range. The RAB architecture may utilise the same access frequency.

[0109] That is, according to an example implementation, the RAB architecture may comprise any one or more of the following features:

[0110] One 5G donor node;

[0111] Two radio nodes as hops (or relays);

[0112] 5G stand-alone technology; • Expected radio access coverage: Around 5 Km;

[0113] • Expected Inter-Nodes distance: Less than 10 Km;

[0114] • Focus only on chain topology (e.g. in Figure 6, the chain topology is that illustrated by the arrow between Node Donor 230 and Nodel 300, and the arrow between Nodel 300 and Node2 200, and can optionally also include the arrows between those nodes 230, 300, 200 and the respective wireless devices 234, 324, 224 in their coverage areas); and

[0115] • Usage of mid-band Frequency.

[0116] Although an example of chain topology has been mentioned (and described with reference to Figure 6), it will be understood that the techniques described herein can equally be used with a tree topology (such as the tree topology that is also illustrated in Figure 6). Moreover, although the disclosure focuses on two hops (i.e. two RAB nodes) in addition to a donor RAN node for simplicity, it will be understood that it is not limited to two tops and any other number of hops (one hop or at least two hopes, e.g. three hops, four hops, five hops, etc.) can be used, such as depending on the coverage needed. The traffic transmitted using the RAB described herein can comprise MBB traffic, voice over IP (VoIP) traffic (e.g. using an IP Multimedia Service (IMS)), or any other traffic. The traffic transmitted can be referred to as backhaul traffic. The I P protocol used for the IP connectivity can be any IP protocol version, such as IP Version 4 (IPv4) or any other version. Although not described in detail, QoS may also be considered.

[0117] Figure 7 shows a system, namely a RAB architecture (or network), according to an embodiment. The RAB architecture is an E2E architecture. The system comprises a first relay network node 200 and a second relay network node 300. The first relay network node 200 comprises a first wireless device 210 and a first RAN node 220. In the manner described earlier, the first relay network node 200 establishes a connection with a second RAN node 230 via the second relay network node 300. The second relay network node 300 comprises a second wireless device 310 and a third RAN node 320. The second RAN node 230 is connected to a core network 236.

[0118] The first RAN node 220 has a first coverage area 222, the second RAN node 230 has a second coverage area 232, and the third RAN node 320 has a third coverage area 322. A UE (or end user device) 234 in the second coverage area 232 can connect to the core network 236 via the second RAN node 230. A UE (or end user device) 224 in the first coverage area 222 can connect to the core network 236 via the first relay network node 200 (or, more specifically, via the first RAN node 220 and the first wireless device 210), the second relay network node 300 (or, more specifically, via the third RAN node 320 and the second wireless device 310), and the second RAN node 230. A UE (or end user device) 324 in the third coverage area 324 can connect to the core network 236 via the second relay network node 300 (or, more specifically, via the third RAN node 320 and the second wireless device 310), and the second RAN node 230.

[0119] Figure 8 shows a 5GC for RAB according to an embodiment. More specifically, Figure 8 shows a setup that uses a dual-mode 5GC Cloud Native Infrastructure Solution (CNIS). The dual-mode 5GC CNIS can be used to provide core functionality. As illustrated in Figure 8, the RAB solution can use a 5GC with any one or more of the following Cloud Native Function (CNF) products (and any relevant components):

[0120] • A 5G Stand-Alone (SA) central control plane Network Function (NF), such as any one or more of the following:

[0121] A Packet Core Controller (PCC), such as an Access & Mobility Management Function (AMF) and / or a Session Management Function (SMF). a Cloud Core Resource Controller (CCRC), such as a Network Repository Function (NRF). a Cloud Core Subscription Manager (CCSM), such as a Unified Data Management (UDM) and / or an Authentication Server Function (AUSF).

[0122] • A 5G SA central unified data management function, such as any one or more of the following:

[0123] A Cloud Core Data-Storage Manager (CCDM), such as a Unified Data Repository (UDR) and / or Provisioning.

[0124] • An edge-based User Plane Function (UPF), such as any one or more of the following:

[0125] A local packet gateway LPG (UPF). For example, a single server (e.g. bare metal) cloud native solution may host a dual mode Packet Core Gateway (PCG) CNF. An LPG is a simple, fast, and more cost-effective footprint deployment for edge sites. More details are provided later with reference to the description of the Cell Site Router (CSR). An LPG is a small form factor UPF. It is based on a single server deployment for a distributed edge UPF.

[0126] The RAB solution uses a transport network between a donor node 230 and a core network (e.g. 5GC) 236. The transport network can comprise a CSR on the donor node 230. In an implementation example, an Ericsson Router R6675 may be used as the CSR.

[0127] The RAB solution also has a RAN part. The RAN part can comprise the donor node 230 and one or more relay network nodes (which provide one or more hops) 200, 300. Any one or more of the donor node 230 and the one or more relay network nodes 200, 300 can be a 3GPP radio node or a RAN node. In an implementation example, one donor node 230 may be used with a collocated LPG(UPF) and two relay network nodes (or two hops) 200, 300. Any one or more of (e.g. all) of the relay network nodes 200, 300 may use indoor radio products.

[0128] The wireless device 210, 310 referred to herein can be used as a relay between a parent node and a child node. Specifically, with reference to Figure 4, the first wireless device 210 can be used as a relay between the first RAN node 220 and the second RAN node 230. Similarly, with reference to Figure 5, the first wireless device 210 can be used as a relay between the first RAN node 220 and the third RAN node 320, and the second wireless device 310 can be used as a relay between the third RAN node 320 and the second RAN node 230. The wireless device 210, 310 may use a 3GPP air interface (Uu) to connect different nodes. The second (donor) RAN node 230 can have its own (e.g. Mobile Broadband (MBB)) end user devices 234. Similarly, the one or more relay nodes (or hops) 200, 300 can have their own (e.g. Mobile Broadband (MBB)) end user devices 224, 324.

[0129] In an implementation example, a two cradle-point R1900 may be used as the wireless device 210, 310 of a relay network node 200, 300. For the end user devices 224, 234, 324, a commercial UE (and iWNC) device may be used. The RAB solution may use and / or involve a variety of network elements. For example, the E2E architecture can involve the core (e.g. 5GC) network, the RAN network (which comprises the donor node and the relay network node (s)), the wireless device(s) (or CPE(s)), and the end user devices.

[0130] Figure 9 shows a RAB implementation according to an embodiment. More specifically, Figure 9 shows RAB with PDU Nested Tunnels. The RAB implementation involves a first RAB node 200 (comprising a first wireless device 210 and a first RAN node 220), a second (“donor”) RAN node 230, and a second RAB node 300 (comprising a second wireless device 310 and a third RAN node 320).

[0131] As illustrated in Figure 9, in some embodiments, the backhaul (e.g. the backhaul of the baseband) of a RAB node 200, 300 can be encapsulated within a Packet Data Unit (PDU) session 702, 704 of the associated wireless devices 210, 310. For example, the backhaul (e.g. the backhaul of the baseband) of the first RAB node 200 can be encapsulated within the first PDU session 702 of the associated first wireless device 210. Similarly, the backhaul (e.g. the backhaul of the baseband) of the second RAB node 300 can be encapsulated within the second PDU session 704 of the associated second wireless device 310

[0132] Figure 10 shows a RAB implementation according to another embodiment. More specifically, Figure 10 shows RAB with PDU Nested Tunnels. The RAB implementation involves a first RAB node 200 (comprising a first wireless device 210 and a first RAN node 220), a second (“donor”) RAN node 230, and a second RAB node 300 (comprising a second wireless device 310 and a third RAN node 320).

[0133] As described with reference to Figure 9 and as illustrated in Figure 10, in some embodiments, the backhaul (e.g. the backhaul of the baseband) of a RAB node 200, 300 can be encapsulated within a PDU session 702, 704 of the associated wireless device 210, 310. As also illustrated in Figure 10, in some embodiments, the second (donor) RAN node 230 can transmit the RAB (or backhaul) traffic over an N3 tunnel 706 towards the core network 236 or, more specifically, towards a Local Packet Gateway (LPG), such as User Plane Function (UPF), 238. A more detailed description of the RAB nodes 200, 300 of the embodiment illustrated in Figure 10 will now be provided. With reference to the second RAB node 300, the second wireless device 310 linked to the third RAN node 320 connects to the second (donor) RAN node 230 through an over the air (llu) interface. The second wireless device 310 performs a registration procedure on the core (5GC) network 236, e.g. based on subscription profiles in UDM. As a result, the third RAN node 320 is authorised to establish a Next-Generation Application Protocol (NGAP) association with the core network 236 or, more specifically, an AMF of the core network 236.

[0134] Upon a PDU establishment procedure, an IP address can be assigned to the second wireless device 310 from a backhauling IP pool of the second RAB node (i.e. the first hop) 300. After a successful PDU session establishment, to establish the PDU session 704 of the second wireless device 310, the third RAN node 320 may initiate the NGAP, e.g. over a Stream Control Transmission Protocol (SCTP) association, towards the core network 236 or, more specifically, an AMF of the core network 236. The NGAP messages sent by the third RAN node 320 can be encapsulated by the second (donor) RAN node 230, e.g. in the General Packet Radio Services Tunnelling Protocol (GTP) User Plane (GTP-U) tunnel associated to the PDU session of the second wireless device 310. The LPG (e.g. UPF) 238, terminating the N3 GTP tunnel 706 of the second (donor) RAN node 230, can decapsulate the GTP-U header and route the message to a router, such as a Cell Site Router (CSR). The router can then relay the message to the AMF, since the destination IP is the IP address of the N2 interface of the AMF.

[0135] With reference to the first RAB node 200, the first wireless device 210 linked to the first RAN node 220 connects to the third RAN node 320 through a Uu interface. The first wireless device 210 performs the registration procedure and the PDU session establishment procedure, to establish the PDU session 702 of the first wireless device 210. The N2 signalling messages sent by the first RAN node 220 can be encapsulated in the N3 tunnel 708 associated to the PDU session 702 of the first wireless device 210. The encapsulated N2 messages may then be nested within the N3 tunnel 706 of the donor RAN node 230.

[0136] Upon receiving the GTP-U messages, the LPG (e.g. UPF) 238 may perform a user session lookup. Once the session for the second wireless device 310 is found, the LPG may decapsulate the GTP headers and route the message to the router (e.g. CSR). The router (e.g. CSR) may send the message back to the LPG 238, which can identify the session for the first wireless device 210. The LPG 238 may then decapsulate the GTP headers and route the message again to the router (e.g. CSR). The router (e.g. CSR) may then send the message to the AMF, since the destination IP is the IP address of the N2 interface of the AMF.

[0137] In an example, RAB can comprise one or more of the following characteristics:

[0138] RAB can support multi-hop backhauling, e.g. two or more backhaul hops.

[0139] RAB can perform relaying at an application layer. For example, a II PF may be used to decapsulate the GTP encapsulated RAN node (e.g. gNB) traffic. RAB can support a dynamic topology update.

[0140] The authorisation process during (e.g. 5G) registration can (implicitly) authorise the RAB node.

[0141] It may be that E2E Adjustments of the Maximum Transmission Unit (MTU) and Maximum Segment Size (MSS) are used to manage additional overhead caused by encapsulating RAB nodes 200, 300. These adjustments can prevent fragmentation between the wireless devices 210, 310 and the LPG (e.g. UPF) 238.

[0142] Figure 11 shows a RAB implementation according to another embodiment. More specifically, Figure 11 shows RAB with an Internet Protocol Security (IPsec)-based solution or, more specifically, a one hop RAB IPsec-based solution. The RAB IPsecbased solution offers enhanced security requirements. Specifically, it allows the backhaul between the RAN node(s) 220 of the RAB node(s) 200 and the router (e.g. CSR router) to be secured. As illustrated in Figure 11 , in some embodiments, a Security / Serving Gateway (SeGW, such as an R6K) 900 can be used and therefore two I Psec Tunnels 902, 904 can be created for each RAB node 200.

[0143] For example, the following two I Psec Tunnels 902, 904 can be created for the RAB node 200 illustrated in Figure 11 :

[0144] • A first I Psec tunnel 902 for the interfaces N2 / N3 traffic encryption.

[0145] • A second I Psec tunnel 904 for Operation and Maintenance (O&M) of the RAN node 220, e.g. through a centralized O&M management system.

[0146] This solution enables remote access and operations for O&M users to the RAN node

[0147] 220, hence facilitating node management. A secure and monitored authentication and authorisation for O&M users can be provided through a network manager-based centralised management platform. The network manager capability can be used in terms of Fault, Performance and Configuration Management (FCAPS). Further details on the IPsec-based solution are described later with reference to Figure 15.

[0148] Figure 12 shows a RAB implementation according to another embodiment. More specifically, Figure 12 shows RAB with a merged IP-Based Solution (No O&M). That is, Figure 12 shows RAB without IPsec-Based (no O&M). This merged IP-based solution is flexible and easy to deploy as it does not require an IPsec tunnel between the RAN nodes and a router (e.g. CSR router). Compared to the IPsec based solution, the merged-IP-based solution offers better performance but less security since no IPsec overhead is added.

[0149] The RAB implementation of Figure 12 involves a first RAB node 200 (comprising a first wireless device 210 and a first RAN node 220), a second (“donor”) RAN node 230, and a second RAB node 300 (comprising a second wireless device 310 and a third RAN node 320).

[0150] According to the embodiment illustrated in Figure 12, each RAN node 200, 300, except the donor RAN node 230, is assigned only one IP address for N2 and N3 traffic. Furthermore, the O&M interface is not configured. The IP address for the N2 / N3 interface is allocated from a backhauling IP pool during establishment of a PDU session for the respective wireless device 210, 310.

[0151] A feature bridge IP Passthrough (IPPT) mode, as also known as a “bridge mode”, may be enabled on the wireless device 210, 310. It can have a Dynamic Host Configuration Protocol (DHCP) server and assign the Data Network Name (DNN) subscriber IP address to the RAN nodes 220, 320 of the two hops 200, 300. The DHCP client functionality can be enabled on the traffic interface of the RAN nodes 220, 320.

[0152] As the RAB nodes 200, 300 require local connectivity for RAN node operations and maintenance, remote O&M connection to the RAN nodes 220, 320 is not permitted according to this embodiment. However, local management of baseband, e.g. via Local Maintenance Terminal (LMT), may be possible. According to the embodiment illustrated in Figure 12, the N2 / N3 traffic sent by a RAB node 200, 300 is encapsulated within a first PDU session 1202 for the first wireless device 210. After decapsulating the GTP-ll header, the LPG (e.g. UPF) 238 may route the message to a router (e.g. R6K router). The router may perform one or more of the following actions:

[0153] Send the message back to the LPG for traffic generated by RAB node2.

[0154] Route the message to an AMF if the destination IP corresponds to the N2 interface of the AMF.

[0155] Route the message to the internet or an application function (AF) for UE access to internet or AF services.

[0156] Figure 13 shows a RAB implementation according to another embodiment. More specifically, Figure 13 shows RAB with a Remote Authentication Dial-In User Service (RADIUS)-based solution. That is, Figure 13 shows a RAB solution that uses routing behind a Mobile Station (MS). The RADIUS-based solution can use the function of routing behind MS in 5GC, which is the functionality implemented by a Policy and Charging Control (PCC) node. Routing behind MS is also known as framed routing. It allows a wireless device 210, 310 to act as a router for an IP (e.g. IPv4) network behind the wireless device 210, 310.

[0157] The RAB implementation of Figure 13 involves a first RAB node 200 (comprising a first wireless device 210 and a first RAN node 220), a second (“donor”) RAN node 230, and a second RAB node 300 (comprising a second wireless device 310 and a third RAN node 320).

[0158] Routing behind MS is enabled in the embodiment illustrated in Figure 13. The UPF 238 can allow payload with a source IP (e.g. IPv4) address (uplink) or destination IP (e.g. IPv4) address (downlink) different from the associated UE IP address. The allowed IP (e.g. IPv4) address range for the network can be connected to the Evolved Packet System (EPS) bearer or the PDU session of the UE device. The allowed IP (e.g. IPv4) address range for the network can be provided at EPS bearer or PDU session creation, e.g. from RADIUS such as in a Framed-Route attribute. Each RAB implementation (or deployment) method described above has certain advantages. The advantages of each implementation method is summarised in the following tables, where Table 1 compares RAB to IAB and Table 2 compares the three different implementations of RAB.

[0159] Table 1 - Comparison of RAB to I AB

[0160] Table 2 - Comparison of three RAB implementations There may be a RAB requirement on the core network, e.g. 5GC network. In this respect, a mapping between Data Network Name (DNN) and Network-Instance (Nl) will now be described and more details will be provided about DNN design in the 5GC.

[0161] In PCC, three DNNs are configured as listed below. PCC includes the DNN information in Packet Forwarding Control Protocol (PFCP) session establishment:

[0162] CPE1 for backhauling: BH1. static CPE2 for backhauling: BH2. static Internet for the end users: internets Internets DNN has a usual MBB subscription with dynamic DNN IP poll allocation. The use of Backhaul DNNs may be driven by one or more criteria. For example, the criteria can comprise any one or more of the following:

[0163] The mobile backhaul traffic may have the requirement to increase GTP Maximum Transmission Units (MTUs) size to effectively manage overhead at each hop.

[0164] Backhaul DNNs can have higher QoS, or QoS Flow Identifier (QFI), assigned to prioritize RAN node Hop #1 and #2 traffic over MBB traffic.

[0165] For IPsec in the IPsec solution, static subscriber DNN IP allocation may be configured.

[0166] The following table shows an example mapping between DNNs and Nl configuration:

[0167] Table 3 - 5GC DNN Configuration

[0168] Two other NIs may be configured in the LPG (e.g. UPF) to handle the N4 interface signalling and RAN N3 interface user plane. The SMF may manage PDU sessions by provisioning PFCP sessions with Packet Detection Rules (PDRs) mapping to Forwarding Action Rules (FARs) in the LPG. PDRs are packet inspection filters that match incoming packets by source interface, UE IP address, Fully Qualified Tunnel End Point Identifier (F-TEID), Service Data Flow (SDF) filters, and Application IDs. When the LPG receives a user plane packet, a look-up of the allocated PDR can be performed.

[0169] Any one or more of the following actions may follow:

[0170] - The LPG identifies the first PFCP session to which the packet corresponds.

[0171] - The LPG finds the first PDR matching the incoming packet. As a result, each packet received in the RAN network-instance can be forwarded to the toExt_open network-instance and vice versa. In the (e.g. R6K) router, there may be two contexts defined: RAN_context for handling RAN traffic and toExt_open for managing internet traffic. These contexts can be respectively connected to the RAN and toExt_open network-instances in the LPG.

[0172] When the (e.g. R6K) router receives a packet in the toExt_open context, it may perform any one or more of the following actions:

[0173] Route the packet to the internet or AF if the destination IP address is an internet or AF subnet.

[0174] Route the packet to LPG if the destination IP is the UE or MT#1 or MT#2 IP addresses.

[0175] Perform inter-context routing to RAN context if the destination IP address is the N3 interface IP address.

[0176] When the (e.g. R6K) router receives a packet in the RAN context, it may perform one or more of the following actions:

[0177] Route the packet to the donor node if the destination IP address is the N2 or N3 interface of the donor node.

[0178] Route the packet to the AMF if the destination IP address is the N2 interface of the AMF.

[0179] Route the packet to the LPG if the destination IP address is the N3 interface IP address.

[0180] Perform inter-context routing to the toExt_open context if the destination IP address is the gNB#1 or gNB#2 IP addresses.

[0181] Figure 14 shows a signalling diagram illustrating a method according to an embodiment. More specifically, Figure 14 shows an interaction between LPG Nl and R6K context. It illustrates the concept of the nested PDU session and the interaction between LPG Nl and R6K context. The GTP2, GTP1 , and GTPD refer to the GTP-U header information (IP / User Datagram Protocol (UDP) / GTP) added by gNB#2220, gNB#1 320, and the gNB donor 230 respectively.

[0182] There may be an edge PCG Software Requirement. In this respect, when it comes to the routing behind MS-based implementation, the frame route may have a limitation of IP range. For example, it may be that only the range / 24 to / 26 is allowed. The PCG may be upgraded so that more or all of the IP range can be used. This PCG software (SW) requirement is not relevant for other RAB implementations, such as the IPsecbased or merged IP-based solution.

[0183] An example of user plane handling will now be described. This will be described in relation to a local or edge setup - IPsec-Based Solution. In an implementation example, a RAB with edge setup may be used. This means that the UPF is local and co-located with the donor node all together with a router (e.g. CSR). The local UPF can be called an LPG product.

[0184] Figure 15 shows a RAB IPsec-Based configuration. More specifically, Figure 15 illustrates how the different GTP and IPsec tunnel are encapsulations and their termination points for the end user traffic. The operations and management (GAM) I Psec tunnel for hop#1 and hop#2 is not shown.

[0185] In terms of hardware, the LPG product (local / edge UPF) can address the challenge of distributing a user plane to an edge site with a small footprint. LPG can be a single server deployment with fixed server and fixed Network Interface Cards (NICs).

[0186] In terms of architecture, the LPG architecture can be built around microservices running in containers provided by the PCG. Each microservice in the LPG may be mapped to a pod type. In the LPG, K3s Container as a Service (CaaS) can be used as a lightweight Kubernetes distribution to manage and deploy containerised microservices. K3s may run on the underlying operating system and the hardware. In a 5GC network, LPG can be used as the UPF specified by 3GPP. In the RAB solution, it can be an NR SA environment. The UPF may be deployed at an edge site which is close to Next Generation Radio Access Network (NG-RAN) nodes for user data handling.

[0187] In terms of networking, in an application layer, the LPG may share the services and features with the PCG. For external networking, the two application services / pods are Routing Engine (RE) and Packet Core User Plane Data Plane (PC UP DP). The term RE and cloud RE (cRE) can be used interchangeably in LPG / PCG documentation. The RE performs routing functions. The RE announces routes, using a Boarder Gateway Protocol (BGP), allowing a Data Center Gateway (DCGW) router to steer user traffic toward the LPG. However, the RE may not learn BGP routes that are advertised from DCGWs. Thus, instead, static routes can be configured to DCGWs for egress traffic. The PC UP DP can handle the (e.g. high-speed, real-time) forwarding of user packets in the uplink and downlink directions. In the RAB solution, it can refer to the N3 and N6 traffic. To provide high availability, the LPG may run two instances of the RE microservices and two instances of DP services. The two instances may work in active or standby mode to handle pod level failure.

[0188] With regard to the implementation in the RAB solution, the LPG network instances used in RAB may be any one or more of the following:

[0189] • Signalling: Carry control plane traffic. That is, N4 towards SMF which is implemented by PCC which is in central 5GC site.

[0190] • RAN: Carry the traffic between RAN and Core. That is, N3 between LPG and Donor / gNB.

[0191] • Internet: Carry the traffic between LPG and internet network, N6 traffic.

[0192] It is to be noted that the network instance name may be different but the purpose can be the same to handle the traffic for different interfaces.

[0193] The RAB solution can use a GTP-in-GTP tunnel to connect a donor node baseband. N3 / N6 may be looped once the inner GTP tunnel is encapsulated.

[0194] In terms of the router or CSR, an Ericsson R6675 router may be used. It can have connectivity towards a (e.g. remotely located) 5GC data center for N2 and N4 service interfaces, remote RAN Network Operation Center and provides internet connectivity. The site located to the CSR may be the 5G UPF function, realised on an LPG. A Content Server may be (e.g. directly) connected to the CSR, such as for E2E throughput tests. This Edge Computing approach secures short user plan latency and guaranties the best end user performance.

[0195] On CSR, there may be several Virtual Routing Functions (VRFs) configured, such as any one or more of the following:

[0196] OM_RAN, connectivity towards:

[0197] - Remote NOC Donor gNB

[0198] Hop#1 and Hop#2 gNB via IPsec tunnel

[0199] • Sig_CN, connectivity for N4 service interface towards:

[0200] - remote 5GC SMF

[0201] - Packet Gateway (PGW)

[0202] • RAN, connectivity for N3 service interface towards

[0203] - Donor gNB

[0204] - Hop#1 and Hop#2 gNB via IPsec tunnel

[0205] - PGW

[0206] • RAN, connectivity for N2 service interface towards

[0207] - Remote 5GC AM F

[0208] - Donor gNB

[0209] - Hop#1 and Hop#2 gNB via IPsec tunnel

[0210] • toExt_open, user plane connectivity

[0211] - PGW N6 interface

[0212] - Internet

[0213] - Content Server

[0214] In respect of the Hop#1 and Hop#2 gNB IP address, the gNB on Hop#1 and Hop#2 outer IP address can be the endpoints for two IPsec tunnels. These can be terminated on CSR VRF RAN. Two loopback IP addresses can be configured on the CSR as IPsec endpoints, such as one for gNB GAM and the other for N2 / N3 traffic. Within the gNB can be two inner VRFs, such as one for N2 / N3 traffic and one for 0AM with different service IP addresses. The CPE devices on Hop#1 and Hop#2 may be configured in IPPT (or bridge) mode. The CPE may assign the DNN subscriber IP address, e.g. via DHCP, towards the end user device. In the RAB scenario, the end user device is the gNB. Therefore, the gNB is configured as the DHCP client for the outer IP address interface. IPsec tunnels can be established between gNB Hop#1 and Hop#2 and CSR loopback IP addresses in VRF RAN. Static IP address can be allocated to the subscriber profile of the CPE Subscriber Identity Module (SIM) card. This can avoid an unnecessary number of IPsec Tunnel configurations on the CSR. Alternatively, each possible IP DNN pool address can be one statically configured IPsec tunnel on the CSR.

[0215] With regard to CSR-PGW “Traffic Loops”, the N2 / N3 IP address of a UPF function can reside within VRF RAN on the CSR and PGW. The N6 IP address of a UPF can be within VRF toExt_open on the CSR and PGW. The outer IP address of Hop#1 and Hop#2 (VPN tunnel encapsulated traffic) can be a subscriber IP address and from Donor gNB GTP encapsulated. It can be received in VRF toExt_open as N6 traffic. The next protocol payload header can either be Internet Security Association and Key Management Protocol (ISAKMP) Internet Key Exchange (IKE) traffic or encapsulated IPsec Enhanced Service Provider (ESP) traffic.

[0216] The IPsec endpoint can be configured as a VRF RAN loopback IP address. Therefore, the traffic may be routed towards the VRF RAN. This can be archived with “inter-context” routing. “Inter-context” enables CSR internally (without an external loop cable) to redirect traffic via a static configured route, to route traffic between two different VRF’s Routing Information Bases (RIBs). The IPsec traffic can be decapsulated. The next protocol header can be the gNB N3 service IP address of the PGW or the N2 traffic is router the 5GC AMF. GTP can again be encapsulated and sent via N6 to VRF toExt_open. Either it is again IPsec encapsulated from gNB Hop#2 and routed again to VRF RAN IPsec loopback IP or further to the desired application server as usual payload within VRF toExt_open. For Example, Hop#2 end-user traffic may pass the PGW three times.

[0217] Traffic towards the end user may be IPsec / GTP encapsulated in the same manner, but in the opposite direction. As with inter-context, routing from the VRF RAN toward VRF toExt_open may be used.

[0218] The same approach may be used with looping GTP / IPsec traffic within the R6k router and the PGW is used Hop#1 and #2 gNB GAM Traffic.

[0219] To minimise the round-trip time, the Router and PGW may be collocated at the same site. Alternatively, a longer round-trip time (RTT) can be accepted and additional link bandwidth between the Router and PGW site can be consumed. Beside the basic router functionality, any one or more of the following features may be supported by RAB:

[0220] Inter-Context routing, or the ability to route traffic internally between VRFs. Policy-based IPsec VPN tunnels, e.g. on Ericsson Router 6000.

[0221] 10 Gigabit Ethernet (GE) interfaces, to donor gNB, e.g. on Ericsson Router 6000.

[0222] 5x 10GE / 25GE interfaces to PGW, e.g. on Ericsson Router 6000.

[0223] An example of MSS handling will now be described. If an end user client has internet connectivity and creates a Transmission Control Protocol (TCP) session towards an application server, the TCP MTU size can be determined from the smaller interface MTU size of the client / server. If the network element between the two endpoints has a smaller MTU interface size as the TCP determined, fragmentation can occur and the E2E throughput decreases.

[0224] Figure 16 shows Fragmentation Handling in RAB according to an embodiment. In IPv4 example, the TCP header is 40 bytes. In an IPv6 example, the TCP header is a minimum of 60 bytes. To avoid fragmentation, the TCP MSS adjustment value is changed during the TCP handshake. This mechanism is called MSS Clamping. The configured TCP MSS adjustment value is applicable for both uplink and downlink traffic. LPG has no default MSS value and can be set explicitly. IPv6 has Path MTU Discovery (PMTUD) in the protocol. Problems can occur if the Internet Control Message Protocol (ICMP) messages are filtered, or the ESP does not generate any ICMP Packet Too Big (Type 2) messages.

[0225] Figure 17 shows an MSS size calculation according to an embodiment involving two hops. It illustrates the detailed calculation of the used MSS size in an example network. It can be individually adapted, as it depends on the IPsec encryption algorithm and systems MTU sizes. To determine the optimal MSS size, Iperf3 (with --set-mss option) and Wireshark are used to analyse LPG traffic. IperfS in the UDP mode can use the negotiated MTU size, that is in LPG MSS clamped to determine the length of UDP payload packages. Ping with “Don’t Fragment” bit set gives non-valid results to determine the maximum MTU size. ESP encapsulate ICMP packages in fragments, without sending error message type 3 code 4 messages "fragmentation needed but don't fragment set" back to the source. In an implementation example, a local / edge user plane may be used. The local / edge approach setup uses a local UPF and CSR at donor level. It is advantageous as it secures low user plane latency and guarantees the best end user performance. However, a central / remote UPF setup is also possible. The UPF can be co-located or part of the remote central 5GC. The router can also be close to the remote central UPF. The same RAB design and configuration above apply in the case of central / remote setup.

[0226] The RAB described herein is agnostic to radio products. For the IPsec-based RAB solution, the baseband supports IPsec. RAN has been setup to support 5G system Stand-alone Mid-Band (5G SA MB). An example RAB RAN Hardware (HW) setup is summarised in the following table:

[0227] Table 4 - Example RAB RAN HW

[0228] Figure 18 shows an overall RAB setup according to an embodiment. Both Donor, Nodel , and Node2 are composed of one Baseband 6630, one IRU 8846, and one RD 4489 B78L. IRU 8846 is connected to Baseband 6630 via a 10 CPRI link on RiPort. RD 4489 is connected to IRU8846 through a shielded CAT6a cable or hybrid cable carrying IQ streams, proprietary control link, and power over Ethernet for the Radio DOT. Four external coaxial cables are used between RD 4489 and the MT (i.e. CPE) to isolate the interference in the environment, ensure the performance, and provide the capability to enable 4x4 MIMO.

[0229] The Baseband in the donor is connected to the transport network (i.e. R6K) via the 10G fiber cable on TN_A or TN_B port to provide maximum throughput for the whole chain, as well as the OAM accessibility, and Precision Time Protocol (PTP) is used as the source of synchronisation for the TDD cell from this port. In an example, PTP may be used in the Donor node because the Donor node is assumed to be in a fixed position. In the case that Donor also requires some mobility, the Global Positioning System (GPS) signal can also be an option for a synchronisation source. The Discontinuous Reception (DRX) feature is disabled, and prescheduling is configured to minimise the latency for the whole chain.

[0230] The Donor node provides the service to CPE1 , and end-user as shown in Figure 18.

[0231] With regard to Nodel - Hop#1 , the Baseband in the Donor node is connected to the backhaul (i.e. CPE1) via the 1G ethernet cable on the TN_C (or TN_D) port. The GPS signal is used as the source of synchronization for the TDD cell, so it is possible to have the capability of mobility for Nodel and expand the possibility for different use cases.

[0232] The DRX feature is disabled, and prescheduling is configured to minimise the latency for the whole chain. Furthermore, the IPsec tunnel is configured in the Nodel to establish I Psec toward the R6K router. The IP network assigned to the CPE1 is used as the Outer IP in the baseband. Traffic IP and OAM IP are configured as Inner IP to set up N2 / N6 connection and OAM access.

[0233] The Nodel provides the service to CPE2, and the end users as shown in Figure 18.

[0234] With regard to Node2 - Hop#2, a similar setup with Nodel applies to Node2 besides that it only provides service to the end users.

[0235] With regard to the end devices, two example types of devices that can be used are the following:

[0236] • Cradlepoint R1900 Routers. This device supports 5G SA and has 4 external 4G / 5G antenna ports which can connect the coaxial cable directly from Radio DoT to minimise the signal loss, 4 gigabit ethernet ports (1 WAN + 3 LANs port), external WiFi connection, and embedded NetCloud manager software which allow the user to manage the device flexibly (in-band & out-band).

[0237] • Industrial WNC Packet Router. This type of device supports 5G SA and has 6 external antenna ports to support a variety of bands in Long-Term Evolution (LTE) & 5G. One ethernet LAN port to manage locally and have a user- friendly interface.

[0238] • One Laptop with OS Linux installed is used for performance verification. With regard to the MT / CPE, two CPEs may be used, which both act as a bridge to the Baseband connected to them (i.e. Nodel and Node2) and also as the backhauling infrastructure. Below shows an example setting that can be used within each CPE:

[0239] • CPE1 (Cradlepoint R1900 Router)

[0240] - Connected to Donor node via SA NR n78 signal.

[0241] - Registered to 5GC with DNN “BH1 .static” predefined.

[0242] - Bridge mode (IPTT) is configured.

[0243] - DHCP feature is enabled on the LAN port Baseband connected.

[0244] - Nodel Baseband is connected to its LAN port.

[0245] • CPE2 (Cradlepoint R1900 Router)

[0246] - Connected to Nodel via SA NR n78 signal.

[0247] - Registered to 5GC with DNN “BH2. static” predefined.

[0248] - Bridge mode (IPTT) is configured.

[0249] - DHCP feature is enabled on the LAN port Baseband connected.

[0250] - Nodel Baseband is connected to its LAN port.

[0251] One or both of the following concepts may be used to configure the CPEs:

[0252] • Static IP. The unique DNN configuration per subscriber in UDM provides a static environment as a stable backhaul to the baseband. This simplifies the routing rule in the R6K router, and both the configuration and establishment of the IPsec tunnel derive benefits from this setup.

[0253] • I PTT (or Bridge) Mode. I PTT allows the CPE to bring the I P network assigned to it to the baseband. Hence, the baseband can be assigned this unique IP via DHCP and build the IPsec tunnel upon it. In the RAB Routing behind MS- Based solution, a standard routing mode may be used instead of IPTT.

[0254] With regard to the end user equipments, the industrial WNC Packet Router may be used as a user equipment to provide a Packet Switching (PS) service to its consumer. DNN “internets” can be predefined in the router. A laptop can be connected to it to execute a performance test.

[0255] Figure 19 shows a RAB deployment according to an embodiment. More specifically, Figure 19 shows an example of RAB with Out-of-Band Backhaul (BH). The access frequency may be separated from the BH frequency, e.g. if there are enough frequency carriers. One frequency serves only for BH between the parent node and the MT (either from Donor to MT#1 or from Hop#1 to MT#2). This naturally reduces the selfinterference and improves the BH capacity.

[0256] In another embodiment, as shown in figure 20, RAB with In-Band Backhaul (BH) is possible. For example, when two distinct frequencies are lacking for BH and 5G access, RAB can provide the flexibility to implement an independent radio configuration at each node (hop). Each node can have its own unique configuration, including frequency carrier and bandwidth allocation. To address this scenario, either a single frequency can be split into multiple sub-frequencies, e.g. based on specific needs, or the same frequency can be maintained for both access and BH.

[0257] That is, the following options are possible:

[0258] • Frequency-Split: A single frequency is divided into multiple sub-frequencies, e.g. multiple Absolute Radio Frequency Channel Numbers (ARFCNs). This technique allows the segregation of BH and 5G access traffic and reduces interference.

[0259] • Shared frequency: This approach is particularly useful in scenarios where spectrum resources are limited, and obtaining additional frequencies is not feasible. However, using a single frequency can bring some uplink or downlink self-interference especially if nodes (hops) are close to each other.

[0260] Other radio considerations that may be considered when deploying RAB can comprise one or more of the following:

[0261] • Parent Selection: MT / CPE may always be connected to the parent node. It may be forbidden for the MT / CPE to connect to the co-located node since this would have a strong signal strength. A different tracking area code (TAC) can, for example, be used for such a purpose. Figure 20 shows a Parent Selection in RAB according to an embodiment.

[0262] • Radio Capacity: When it comes to the radio resources capacity, in case of in-band BH, the allocation of frequency bandwidth between BH and access (CPE vs normal UEs) can be adjusted dynamically, e.g. based on some radio features such as radio resources partitioning (RRP), to adapt to the evolving needs of the network. Figure 21 shows a signalling diagram illustrating a method according to an embodiment. More specifically, Figure 21 shows an example of a call flow using the RAB IPsec-Based solution described earlier. For the purpose of this description, the UE that belongs to the Hop#2 will be the focus. The end users belonging to Hop#1 or to the donor node are not highlighted in the graph below. Figure 21 summarises, on a high level, the E2E call flow registration and connection of the end user of Hop#2.

[0263] At step 2100, the MT1 310 requests to register itself with the core network 236. At step 2102, the Donor node 230 registers the MT1 310 with the core network 236. At step 2104, connection establishment is performed from the Donor node 230 to the core network 236 (e.g. 5GC, such as via a legacy connection) before the MT1 310 establishes a PDU session and gets IP connectivity. At step 2106, the MT1 310 establishes a PDU session.

[0264] At step 2108, the Hop#1 node 300 establishes a connection to the Donor node 230 through the MT1 310 (bridge mode) before the MT2 210 establishes a PDU session and gets IP connectivity to the core network 236. The same scenario can be repeated for Hop#2 before the end UE 224 gets the IP connectivity from the core network 236.

[0265] In more detail, at step 2110, the MT2 210 requests to register itself with the core network 236. At step 2112, the Hop#1 node 300 registers the MT2 210 with the core network 236 through the MT1 310 (bridge mode). At step 2114, the Hop#1 node 300 establishes a connection to a local UPF through the MT1 310. At step 2116, the MT2210 establishes a PDU session. At step 2118, the Hop#2 node 200 establishes a connection to a (R6K) router through the MT2 210.

[0266] At step 2120, the UE 224 requests to register itself with the core network 236. At step 2122, the Hop#2 node 200 registers the UE 224 with the core network 236 through the MT2 210 (bridge mode). At step 2124, the Hop#2 node 200 establishes a connection to the local UPF through the MT2 210 (bridge mode). At step 2126, the UE establishes a PDU session.

[0267] The performance of RAB has been evaluated through measuring some metrics and test case in a controlled laboratory environment. The assessment specifically emphasises the Hop#2 end user, with a focus on measuring throughput and latency. Furthermore, one additional operational test case related to hop fail-over has been conducted to provide a comprehensive evaluation of RAB in some scenarios.

[0268] The resulting throughput measurements are shown in Tables 5 and 6, where Table 5 shows the results for the IPsec-Based Solution and Table 6 shows the results for the merged IP-Based Solution (with no O&M).

[0269] The results in Table 5 were acquired using an iWNC UE connected to Hop#2 and employing a content server(iPerf) for payload server. For conducting downlink and uplink throughput measurement, the following considerations were made:

[0270] - Radio BW: 100 Mhz in the donor, node#1 and node#2

[0271] - 5G Band: n78A in all nodes

[0272] - 5G UE: iWNC connected to Hop#2

[0273] - Protocols: TCP and UDP

[0274] - Optimized MSS parameter at PCG level: 1274 Bytes

[0275] Table 5 - Throughput measurement in 2 hops for IPsec-Based Solution

[0276] The results in Table 6 were acquired using the same protocol to test RAB throughput measurement.

[0277] Table 6 - Throughput measurement in 2 hops for Merged IP-Based Solution

[0278] While the IPsec-Based Solution, provides and enhances security, it introduces more overhead for the IPsec tunnel. This explains the slight difference observed in throughput performance compared to the Merged IP-Based Solution. Figure 22 shows the resulting latency measurement in 2 hops. The 5G network offers extremely low latency, with delays typically in the range of tens of milliseconds depending on the frequency band used. Latency is the delay or time duration between the sending and receiving information. It includes RAN delay, which is the delay in the radio access network, and 5GC delay, which is the delay in the 5GC network. Since RAB is about extending 5G coverage through radio nodes or hops, each hop is expected to add to the cumulative RAN latency. In the implementation example, the expected delay from the UE belonging to the Hop#2 was measured and the results are shown in Figure 22. The results showed a delay of less than 30ms. The local UPF(LPG) was used in the edge with radio access. This setup brings a better improvement on latency value.

[0279] Figure 23 shows a Hop Fail-Over test case. The objective of the test case is to assess whether Hop#2 can establish a direct connection to the donor if Hop#1 is unavailable for any reason, without requiring human intervention for manual configuration. The answer is affirmative. The test systematically deactivated Hop#1 and placed CPE2 within the donor coverage. Hop#2 successfully established a connection to the donor and 5GC. As a result, the UE belonging to Hop#2 can establish a PDU session and obtain IP connectivity, without the need for additional manual configuration of the system.

[0280] RAB can be realised through configuration only of existing (e.g. 5G) nodes. RAB is agnostic to the existing products. E2E configuration using an IPSEC-Based Solution can include configuration of a gNB, Router, UPF, SMF, UDR, and UDM. Even though the RAB solution is agnostic to the products, RAB can be enhanced by bringing intelligence or a feature into the UPF, such as a reading mechanism of GTP-in-GTP headers, without doing inter-context looping at Router level. Adding only a wireless device to the RAN node, compared to adding a full core, microwave system, or satellite system can save energy.

[0281] As used herein, the term wireless device can refer to a device capable, configured, arranged and / or operable to communicate wirelessly with one or more other nodes. Communicating wirelessly may involve transmitting and / or receiving wireless signals, such as by using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information through air. In some embodiments, a wireless device may be configured to transmit and / or receive information without direct human interaction. For instance, a wireless device may be designed to transmit information on a predetermined schedule, when triggered by an internal or external event, or in response to requests. In some embodiments, a wireless device referred to herein may be registered to and / or operated by a user or an end user (Ell). Thus, unless otherwise noted, the term wireless device can be used interchangeably herein with user device, end user device, or user equipment (UE).

[0282] Examples of a wireless device as referred to herein include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE), a vehicle-mounted wireless terminal device, etc. A wireless device as referred to herein may support device-to-device (D2D) communication, for example, by implementing a third generation partnership project (3GPP) standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device.

[0283] As yet another specific example, in an Internet of Things (loT) scenario, a wireless device as referred to herein may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another wireless device and / or a network node. A wireless device as referred to herein may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine type communication (MTC) device. As one particular example, a wireless device as referred to herein may be implementing the 3GPP narrow band internet of things (NB-loT) standard. Particular examples of such wireless devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc), personal wearables (e.g. watches, fitness trackers, etc). In other scenarios, a wireless device as referred to herein may represent a vehicle or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. A wireless device as referred to herein may represent the endpoint of a wireless connection, in which case the wireless device may be referred to as a wireless terminal. Furthermore, a wireless device as referred to herein may be mobile, in which case it may be referred to as a mobile device or a mobile terminal (MT).

[0284] As used herein, a RAN node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with one or more other nodes. Examples of a RAN node as referred to herein include, but are not limited to, a radio access point or a radio base station, such as a Node B, an evolved Node B (eNB), or a New Radio (NR) NodeB (gNB). A base station may be categorized based on the amount of coverage it provides (or, stated differently, its transmit power level) and so, depending on the provided amount of coverage, may be referred to as a femto base station, a pico base station, a micro base station, or a macro base station.

[0285] There is also provided a system comprising the first relay network node 200 described herein. The system can comprise the core network 236 described herein and / or at least one second relay network node 300 as described herein.

[0286] There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the first wireless device 210 described earlier, and / or the processing circuitry 22 of the first RAN node 220 described earlier), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non- transitory machine-readable medium, comprising instructions which are executable by processing circuitry (such as the processing circuitry 12 of the first wireless device 210 described earlier, and / or the processing circuitry 22 of the first RAN node 220 described earlier) to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry (such as the processing circuitry 12 of the first wireless device 210 described earlier, and / or the processing circuitry 22 of the first RAN node 220 described earlier) to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0287] In some embodiments, the functionality described herein can be performed by hardware. Thus, in some embodiments, one or more of the first wireless device 210 described herein, the first RAN node 220 described herein, the second wireless device 310 described herein, the third RAN node 320 described herein, and any other node described herein can be a hardware node. However, it will also be understood that optionally at least part or all of the functionality described herein can be virtualized. For example, the functions performed by one or more of the first wireless device 210 described herein, the first RAN node 220 described herein, the second wireless device 310 described herein, the third RAN node 320 described herein, and any other node described herein can be implemented in software running on generic hardware that is configured to orchestrate the functionality. Thus, in some embodiments, one or more of the first wireless device 210 described herein, the first RAN node 220 described herein, the second wireless device 310 described herein, the third RAN node 320 described herein, and any other node described herein can be a virtual node. In some embodiments, at least part of the functionality described herein is performed in a network enabled cloud. At least some of the functionality is distributed.

[0288] It will be understood that at least some or all of the method steps described herein can be automated in some embodiments. That is, in some embodiments, at least some or all of the method steps described herein can be performed automatically. The method described herein can be a computer-implemented method.

[0289] It should be noted that the above-mentioned embodiments illustrate rather than limit the idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1. A first relay network node (200) comprising: a first wireless device (210); and a first radio access network, RAN, node (220), wherein the first wireless device (210) and the first RAN node (220) are interconnected through internet protocol, IP, connectivity and the first wireless device (210) is configured to establish a connection (242, 244, 246) between the first wireless device (210) and a second RAN node (230) to provide a backhaul connection for the first RAN node (220) to a core network (236) via the first wireless device (210) and the second RAN node (230).

2. The first relay network node (200) as claimed in claim 1 , wherein: the first wireless device (210) and the first RAN node (220) are connected to each other via a wired connection.

3. The first relay network node (200) as claimed in claim 1 or 2, wherein: the first wireless device (210) is configured to assign an IP address to the first RAN node (220).

4. The first relay network node (200) as claimed in claim 3, wherein: the IP address is associated with Layer 3.

5. The first relay network node (200) as claimed in any preceding claim, wherein: the first wireless device (210) is configured to assign a default route to the firstRAN node (220) via which the first RAN node (220) is to transmit backhaul data, wherein the default route is from the first RAN node (220) to the core network (236) via the first wireless device (210) and the second RAN node (230).

6. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first RAN node (220) is configured to transmit backhaul data to the core network (236) via the first wireless device (210) and the second RAN node (230).

7. The first relay network node (200) as claimed in claim 6, wherein:the first RAN node (220) is configured to transmit backhaul data via one or both of an N2 interface of the first RAN node (220) and an N3 interface of the first RAN node (220).

8. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first RAN node (220) is configured to establish a first internet protocol security, IPsec, tunnel (902) for backhaul data transmission.

9. The first relay network node (200) as claimed in claim 8, wherein: the first RAN node (220) is configured to establish the first IPsec tunnel (902) from the first RAN node (220) to a gateway (900) via the first wireless device (210) and the second RAN node (230), wherein the first wireless device (210) is configured to establish the connection (242) to provide the backhaul connection for the first RAN node (220) to the core network (236) via the first wireless device (210), the second RAN node (230), and the gateway (900).

10. The first relay network node (200) as claimed in claim 8 or 9, when claim 8 is dependent on claim 6 or 7, wherein: the first RAN node (220) is configured to transmit backhaul data via the first IPsec tunnel (902).

11. The first relay network node (200) as claimed in any of claims 8 to 10, wherein: the first RAN node (220) is configured to establish a second internet protocol security, IPsec, tunnel (904) for operation and maintenance, O&M, of the first RAN node (220).

12. The first relay network node (200) as claimed in claim 11, wherein: the first RAN node (220) is configured to establish the second IPsec tunnel (904) from the first RAN node (220) to a gateway (900) via the first wireless device (210) and the second RAN node (230).

13. The first relay network node (200) as claimed in any of claims 1 to 7, wherein: the first RAN node (220) is configured to encapsulate backhaul data in a PDUsession (1202) for the first wireless device (210).

14. The first relay network node (200) as claimed in claim 13, wherein: the first wireless device (210) is configured to assign a single IP address to the first RAN node (220) for backhaul data transmitted via an N2 interface of the first RAN node (220) and an N3 interface of the first RAN node (220).

15. The first relay network node (200) as claimed in claim 14, wherein: the first wireless device (210) is configured to assign the single IP address during establishment of the packet data unit, PDU, session (1202) for the first wireless device (210).

16. The first relay network node (200) as claimed in any of claims 13 to 15, wherein: the first wireless device (210) is configured to operate in an internet protocol passthrough, IPPT, mode.

17. The first relay network node (200) as claimed in any of claims 13 to 16, wherein: the first wireless device (210) is configured to assign a data network name, DNN, subscriber IP address to the first RAN node (220).

18. The first relay network node (200) as claimed in any of claims 1 to 7, wherein: the first wireless device (210) is configured to operate as a router for an IP network behind the first wireless device (210).

19. The first relay network node (200) as claimed in claim 18, wherein: the IP network has an IP address range for which the first wireless device (210) is allowed to operate as a router.

20. The first relay network node (200) as claimed in claim 19, wherein: the IP address range is provided from a Remote Authentication Dial-In User Service, RADIUS.

21. The first relay network node (200) as claimed in claim 19 or 20, wherein: the IP address range is associated with an evolved packet system, EPS, bearer for the first wireless device (210) or a packet data unit, PDU, session (1302) for the firstwireless device (210).

22. The first relay network node (200) as claimed in claim 21, wherein: the IP address range is provided at creation of the EPS bearer or at creation of the PDU session (1302).

23. The first relay network node (200) as claimed in any of claims 18 to 22, wherein: the IP network is an IP version 4, IPv4, network.

24. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first RAN node (220) comprises a first central unit and a first distributed unit; and the first central unit is configured to control the first distributed unit.

25. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first RAN node (220) is configured to use the backhaul connection to establish a connection between the core network (236) and a first user equipment (224), which is in a first coverage area (222) of the first RAN node (220) and outside a second coverage area (232) of the second RAN node (230).

26. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first relay network node (200) is a first mobile relay network node.

27. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first relay network node (200) is moveable around a second coverage area (232) of the second RAN node (230).

28. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first relay network node (200) is configured to be placed on or in a vehicle.

29. The first relay network node (200) as claimed in any of the preceding claims, wherein: the first wireless device (210) is configured to establish the connection (244, 246) between the first wireless device (210) and the second RAN node (230) to provide the backhaul connection for the first RAN node (220) to the core network (236) via the first wireless device (210), a second relay network node (300), and the second RAN node (230).

30. The first relay network node (200) as claimed in claim 29, wherein: the first wireless device (210) is configured to establish the connection (244, 246) between the first wireless device (210) and the second RAN node (230) by being configured to: establish a first connection (244) between the first wireless device (210) and a third RAN node (320) of the second relay network node (300), wherein a second connection (246) is established between a second wireless device (310) of the second relay network node (300) and the second RAN node (230), and wherein the second wireless device (310) and the third RAN node (320) are interconnected through IP connectivity.

31. A system comprising: the first relay network node (200) as claimed in any of the preceding claims; and the core network (236).

32. The system as claimed in claim 31 , comprising: the first relay network node (200) as claimed in claim 29 or 30; and the second relay network node (300).

33. A method for providing a connection to a core network (236), wherein the method is performed by a first relay network node (200) comprising a first wireless device (210) and a first radio access network, RAN, node (220), the method comprising: establishing (400), by the first wireless device (210), a connection (242, 244, 246) between the first wireless device (210) and a second RAN node (230), wherein the first wireless device (210) and the first RAN node (220) are interconnected through internet protocol, IP, connectivity and the first wireless device(210) establishes the connection (242, 244, 246) between the first wireless device(210) and the second RAN node (230) to provide a backhaul connection for the first RAN node (220) to the core network (236) via the first wireless device (210) and the second RAN node (230).

34. The method as claimed in claim 33, wherein: the first wireless device (210) and the first RAN node (220) are connected to each other via a wired connection.

35. The method as claimed in claim 33 or 34, the method comprising: assigning, by the first wireless device (210), an IP address to the first RAN node (220).

36. The method as claimed in claim 35, wherein: the IP address is associated with Layer 3.

37. The method as claimed in any of claims 33 to 36, the method comprising: assigning, by the first wireless device (210), a default route to the first RAN node(220) via which the first RAN node (220) is to transmit backhaul data, wherein the default route is from the first RAN node (220) to the core network (236) via the first wireless device (210) and the second RAN node (230).

38. The method as claimed in any of claims 33 to 37, the method comprising: transmitting, by the first RAN node (220), backhaul data to the core network (236) via the first wireless device (210) and the second RAN node (230).

39. The method as claimed in claim 38, the method comprising: transmitting, by the first RAN node (220), backhaul data via one or both of an N2 interface of the first RAN node (220) and an N3 interface of the first RAN node (220).

40. The method as claimed in any of claims 33 to 39, the method comprising: establishing, by the first RAN node (220), a first internet protocol security, IPsec, tunnel (902) for backhaul data transmission.

41. The method as claimed in claim 40, wherein:establishing the first IPsec tunnel (902) comprises establishing the first IPsec tunnel (902) from the first RAN node (220) to a gateway (900) via the first wireless device (210) and the second RAN node (230); and wherein establishing the connection (242) provides the backhaul connection for the first RAN node (220) to the core network (236) via the first wireless device (210), the second RAN node (230), and the gateway (900).

42. The method as claimed in claim 40 or 41 , when claim 40 is dependent on claim 38 or 39, wherein: transmitting backhaul data comprises transmitting backhaul data via the first IPsec tunnel (902).

43. The method as claimed in any of claims 40 to 42, the method comprising: establishing, by the first RAN node (220), a second internet protocol security,IPsec, tunnel (904) for operation and maintenance, O&M, of the first RAN node (220).

44. The method as claimed in claim 43, wherein: establishing the second IPsec tunnel (904) comprises establishing the second IPsec tunnel (904) from the first RAN node (220) to a gateway (900) via the first wireless device (210) and the second RAN node (230).

45. The method as claimed in any of claims 33 to 39, the method comprising: encapsulating, by the first RAN node (220), backhaul data in a PDU session(1202) for the first wireless device (210).

46. The method as claimed in claim 45, the method comprising: assigning, by the first wireless device (210), a single IP address to the first RAN node (220) for backhaul data transmitted via an N2 interface of the first RAN node (220) and an N3 interface of the first RAN node (220).

47. The method as claimed in claim 46, wherein: assigning the single IP address comprises assigning the single IP address during establishment of the packet data unit, PDU, session (1202) for the first wireless device (210).

48. The method as claimed in any of claims 45 to 47, wherein: the first wireless device (210) operates in an internet protocol passthrough, IPPT, mode.

49. The method as claimed in any of claims 45 to 48, the method comprising: assigning, by the first wireless device (210), a data network name, DNN, subscriber IP address to the first RAN node (220).

50. The method as claimed in any of claims 33 to 39, wherein: the first wireless device (210) operates as a router for an IP network behind the first wireless device (210).

51. The method as claimed in claim 50, wherein: the IP network has an IP address range for which the first wireless device (210) is allowed to operate as a router.

52. The method as claimed in claim 51 , wherein: the IP address range is provided from a Remote Authentication Dial-In User Service, RADIUS.

53. The method as claimed in claim 51 or 52, wherein: the IP address range is associated with an evolved packet system, EPS, bearer for the first wireless device (210) or a packet data unit, PDU, session (1302) for the first wireless device (210).

54. The method as claimed in claim 53, wherein: the IP address range is provided at creation of the EPS bearer or at creation of the PDU session (1302).

55. The method as claimed in any of claims 50 to 54, wherein: the IP network is an IP version 4, IPv4, network.

56. The method as claimed in any claims 33 to 55, wherein: the first RAN node (220) comprises a first central unit and a first distributed unit; andthe first central unit controls the first distributed unit.

57. The method as claimed in any of claims 33 to 56, the method comprising: using, by the first RAN node (220), the backhaul connection to establish a connection between the core network (236) and a first user equipment (224), which is in a first coverage area (222) of the first RAN node (220) and outside a second coverage area (232) of the second RAN node (230).

58. The method as claimed in any of claims 33 to 57, wherein: the first relay network node (200) is a first mobile relay network node.

59. The method as claimed in any of claims 33 to 58, wherein: the first relay network node (200) is moveable around a second coverage area (232) of the second RAN node (230).

60. The method as claimed in any of claims 33 to 59, wherein: the first relay network node (200) is placed on or in a vehicle.

61. The method as claimed in any of claims 33 to 60, the method comprising: establishing the connection (244, 246) between the first wireless device (210) and the second RAN node (230) to provide the backhaul connection for the first RAN node (220) to the core network (236) via the first wireless device (210), a second relay network node (300), and the second RAN node (230).

62. The method as claimed in claim 61 , wherein: establishing the connection (244, 246) between the first wireless device (210) and the second RAN node (230) comprises: establishing a first connection (244) between the first wireless device (210) and a third RAN node (320) of the second relay network node (300), wherein a second connection (246) is established between a second wireless device (310) of the second relay network node (300) and the second RAN node (230), and wherein the second wireless device (310) and the third RAN node (320) are interconnected through IP connectivity.

63. A computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any of claims 33 to 62.

64. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method according to any of claims 33 to 62.

Images