PCI collision detection in 5G mobile IAB

Abstract

A method of avoiding a Physical Cell Identity, PCI, conflict at a radio access network, RAN, node of a wireless network, the RAN node comprising a Distributed Unit, DU, managed by a first RAN node Cen

Description

Field of the Invention The present invention generally relates to methods for use in a process for mitigating signals interference involving Integrated Access and Backhaul, IAB, nodes. Background Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging ...) over a radio access network (RAN) through one or more base stations. The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH). Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems-based IEEE 802.11 standards, such as WiFi. The demand for network densification increases due to the rising number of users and higher throughput requirement. Facing the issues of high deployment costs and time of the wired backhaul networks with network densification, 3GPP has proposed, in recent release 16 for5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications (between base stations) may use the same radio resources as access communications (between a base station and UEs). IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations. IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. However, millimeter waves are known to be subject to strong attenuations of signal strength in some weather conditions (rain, fog), and to blockage in case of obstacles located in the path between the emitter and the receiver. Based upon the fixed IAB foundations laid off in releases 16 and 17, 3GPP is now considering Mobile IAB systems and architecture, as a part of the release 18 framework, in order to address scenarios focusing on mobile lAB-nodes mounted on vehicles. In such scenarios, mobile lAB-nodes can be referred to as Vehicle Mounted Relays (VMR), providing 5G coverage / capacity to on-board and / or surrounding UEs. The technical benefits of using vehicle relays include, among others, the ability of the relay vehicle to get better macro coverage than the nearby UE, thanks to better RF / antenna capabilities, thus providing the UE with a better link to the macro network. Additionally, a vehicle relay is expected to have less stringent power / battery constraints than the UEs. Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public / private passengers transportation, goods delivery, food trucks ...). The speed of some of the vehicles may be pretty low or at least similar to pedestrian speed and some of these vehicles may even be temporarily stationary. Some of these vehicles (e.g. buses, trains or trams), may have predictable routes and I or limited mobility areas (e.g. some vehicles, such as food trucks or promotional vehicles, may be located outside stadiums or show venues) while others may have predictable stationary locations (e.g. taxis). 3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as relays. These relays would rely on 5G wireless backhaul (typically IAB, or Integrated Access &Backhaul) for connecting to a fixed donor device. Thus, based upon the fixed IAB foundations set out in Release 16 and 17, 3GPP is now considering Mobile IAB systems and architecture, as a part of the Release 18 framework, in order to address scenarios focusing on mobile lAB-nodes mounted on vehicles (for example, a bus, a train, a taxi). In such scenarios, mobile lAB-nodes can also be referred to as Vehicle Mounted Relays (VMR), providing 5G coverage / capacity to on-board and / or surrounding UEs. The technical benefits of using vehicle relays include, among others, the ability of the relay vehicle to get better coverage than the nearby UE, thanks to better RF / antenna capabilities, thus providing the UE with a better link to the macro network. Additionally, a vehicle relay is expected to have less stringent power / battery constraints than the UEs. As a legacy base station, a mobile lAB-node manages one or several cell(s) in which UEs may camp and may connect to the network. Usually, a UE is configured to regularly perform measurements on cells in the neighborhood. Those measurements are performed at the initialization of the UE to search for candidate cells for the first connection to the network, but also when the UE is connected or in idle / inactive state to search for a cell with a better connection quality. Once a candidate cell has been found, the UE measures one or more parameters of signals received from the candidate cell. The parameters may include the reference signal received power (RSRP), or reference signal received quality (RSRQ). Typically, the UE measures RSRP or RSRQ on the Signal Synchronization Block (SSB). Further, the UE derives from the SSB the necessary information required to access the cell. In particular, the UE obtains the Physical Cell Identity (PCI) of the cell, which can be retrieved from the SSB. The SSB contains two synchronization signals: the PSS (Primary Synchronization Signal) and the SSS (Secondary Synchronization Signal). The PSS contains the physical layer identity (integer from 0 to 2) and the SSS contains the group number (integer from 0 to 335). The PCI value is obtained through a combination of these two values (physical layer identity + 3 x group number) providing an integer from 0 to 1007. Thus, the PCI value is not a unique identifier because of this limited range. A PCI collision occurs when a cell has a neighbour cell with the same PCI, while a PCI confusion occurs when a cell has two different neighbour cells with the same PCI for the two neighbour cells. In PCI planning, neighbouring, or adjacent, cells cannot be allocated the same PCI. Indeed, PCI collision or confusion with neighbouring cells having the same PCI may introduce a synchronization delay for a UE performing cell search in an overlapping area of the cells. Additionally, it may lead to a high error rate and / or decoding failure of physical channels scrambled using the PCI, and may also generate some handover failure. As a consequence, PCI planning algorithms aim to avoid PCI collision or confusion by maximizing the PCI re-use distance, i.e. the physical separation between two cells having the same PCI value. Furthermore, PCI collision or confusion may also arise in the following cases: - If two neighboring cells have the same PCI Modulo 3 result, the same PSS are used by the cells with the consequence of UE synchronization delay, - If two neighboring cells have the same PCI Modulo 4 result, it may introduce interference with a Demodulation Reference Signal (DMRS), - If two neighboring cells have the same PCI Modulo 30 result, it may introduce inter-cell uplink interference. In case of a mobile base station, like a mobile lAB-node or Vehicle Mounted Relay (VMR), the risk of PCI collision and confusion is high compared to a topology formed of stationary base stations, and even with advanced PCI planning algorithm it may nevertheless prove difficult, or even impossible, to avoid PCI collision or confusion when the mobile base station moves in a large area. Therefore, there is a need to be able to change the PCI value of one or several cell(s) controlled by a mobile base station, while the mobile base station is serving UEs. Additionally, it would be beneficial to avoid service interruption at the UEs served by a mobile base station when the PCI value of a serving cell is changed. Besides, the detection or prediction of PCI collision or confusion shall be performed in an efficient and reliable manner to avoid unnecessary change of PCI values and to select an optimal new PCI value to assign. The present invention aims to address some of the above identified issues with wireless communication systems incorporating mobile base stations. Summary According to a first aspect of the invention there is provided a method of determining or predicting a Physical Cell Identity, PCI, conflict at a radio access network, RAN, node of a wireless network, the RAN node comprising a Distributed Unit, DU, managed by a first RAN node Central Unit, CU, and a Mobile Termination, MT, managed by a second RAN node CU, the method, at the first RAN node CU, comprising the steps of: receiving a PCI report, wherein the PCI report comprises a list of PCI values of neighbouring cells in the vicinity of the RAN node; and determining or predicting a PCI conflict based on the PCI report and a PCI value of a cell controlled by the DU of the RAN node. The step of receiving a PCI report may comprise receiving a PCI report from the DU of the RAN node. The PCI report may comprise a list of PCI values of neighbouring cells in the vicinity of the RAN node detected by the MT of the RAN node. The step of receiving a PCI report may comprise receiving a PCI report from the second RAN node CU. The PCI report received from the second RAN node CU may comprise a list of PCI values of cells assigned by the second RAN node CU. The PCI report received from the second RAN node CU may comprise a list of PCI values of neighbouring cells in the vicinity of the RAN node detected by a MT of a further RAN node managed by the second RAN node CU. The PCI report may include a proposed PCI value, wherein the proposed PCI value does not conflict with a PCI value of a cell controlled by the DU of the RAN node. The PCI values of neighbouring cells in the vicinity of the RAN node detected by the MT of the RAN node or the MT of the further RAN node may be PCI values detected by the MT as part of a measurement report. The MT of the RAN node may have a Radio Resource Control, RRC, connection with the second RAN node CU. In this case, the second RAN node CU may be referred to as an RRC terminating donor-CU. The RAN node may be a mobile lAB-node. According to a second aspect of the invention there is provided a method of avoiding a PCI conflict at a radio access network, RAN, node of a wireless network, the RAN node comprising a Distributed Unit, DU, managed by a first RAN node Central Unit, CU, and a Mobile Termination, MT, managed by a second RAN node CU, the method, at the first RAN node CU, comprising the steps of: determining or predicting a PCI conflict according to the first aspect; and performing a PCI change procedure for a cell controlled by the DU of the RAN node. The method may further comprise the step of: notifying the second RAN node CU of the PCI change procedure. The method may further comprise the step of: notifying a core network of the wireless network of the PCI change procedure. According to a third aspect of the invention there is provided method of avoiding a Physical Cell Identity, PCI, conflict at a radio access network, RAN, node of a wireless network, the RAN node comprising a Distributed Unit, DU, managed by a first RAN node Central Unit, CU, and a Mobile Termination, MT, managed by a second RAN node CU, the method, at the second RAN node CU, comprising the step of: sending, to the first RAN node CU, a PCI setting message indicating a new PCI value to set at the RAN node. The PCI setting message may be a PCI change request to the first RAN node CU indicating the new PCI value to set at the RAN node. The PCI setting message may be a PCI response sent in response to a PCI request, received from the first RAN node CU, requesting a new PCI value to set at the RAN node. The PCI request may include a current PCI value set at the RAN node and wherein the new PCI value is different from the current PCI value. The new PCI value may be selected so as to not conflict with a PCI value of a cell controlled by the RAN node. The method may further comprise, after the step of sending a PCI setting message to the first RAN node CU indicating the new PCI value to set at the RAN node: receiving, at the second RAN node CU, a PCI set report from the first RAN node CU indicating that the new PCI value has been set at the RAN node. According to a fourth aspect of the invention there is provided a method of providing information for the determination or prediction of a PCI conflict at a radio access network, RAN, node of a wireless network to a first RAN node Central Unit, CU, the RAN node comprising a Distributed Unit, DU, managed by the first RAN node CU, and a Mobile Termination, MT, managed by a second RAN node CU, the method, at the second RAN node CU, comprising the steps of: creating a PCI report comprising a list of PCI values of neighbouring cells in the vicinity of the RAN node; and sending the PCI report to the first RAN node CU. The PCI report may comprise a list of PCI values of cells assigned by the second RAN node CU. The PCI report may comprise a list of PCI values of neighbouring cells in the vicinity of the RAN node detected by a MT of a further RAN node managed by the second RAN node CU. The PCI values of neighbouring cells in the vicinity of the RAN node detected by the MT of the further RAN node may be PCI values detected by the MT as part of a measurement report. The PCI report may include a proposed PCI value, wherein the proposed PCI value does not conflict with a PCI value of a cell controlled by the DU of the RAN node. The PCI report may comprise a list of PCI values of neighbouring cells in the vicinity of the RAN node detected by the MT of the RAN node. The MT of the RAN node may have a Radio Resource Control, RRC, connection with the second RAN node CU. The RAN node may be a mobile lAB-node. The method may further comprise the step of: receiving, from the first RAN node CU, a notification that a PCI change procedure has been performed. The method may further comprise the step of: notifying a core network of the wireless network of the PCI change procedure. The method may further comprise the step of: determining a potential conflict of PCI values between a PCI value of a cell controlled by the DU of the RAN node and a PCI value of the PCI report, wherein the step of sending the PCI report to the first RAN node CU is performed based on a potential conflict of PCI values being determined. The first RAN node CU may be a F1 donor-CU (or equivalently an F1 terminating donor-CU) for the RAN node, and the second RAN node CU is a non-F1 donor-CU (or an RRC donor-CU or equivalently an RRC terminating donor-CU) for the RAN node. According to a fifth aspect of the invention there is provided a method of providing information for the determination or prediction of a Physical Cell Identity, PCI, conflict at a radio access network, RAN, node of a wireless network to a first RAN node Central Unit, CU, the RAN node comprising a Distributed Unit, DU, managed by the first RAN node CU, and a Mobile Termination, MT, managed by a second RAN node CU, the method, at the DU, comprising the steps of: receiving, from the MT of the RAN node, a measurement report; creating a PCI report, comprising a list of PCI values of neighbouring cells in the vicinity of the RAN node, based on the measurement report; and sending the PCI report to the first RAN node CU. According to a sixth aspect of the invention there is provided a method of providing information of a Physical Cell Identity, PCI, conflict at a radio access network, RAN, node of a wireless network to a first RAN node Central Unit, CU, the RAN node comprising a Distributed Unit, DU, managed by the first RAN node CU, and a Mobile Termination, MT, managed by a second RAN node CU, the method, at the MT, comprising the steps of: creating a measurement report comprising a list of PCI values of neighbouring cells in the vicinity of the RAN node; and sending the measurement report to the DU of the RAN node. According to a seventh aspect of the invention there is provided an apparatus for a radio access network, RAN, node Central Unit, CU, node of a wireless network, the apparatus comprising: one or more processing units configured to perform a method according to the first, second, third or fourth aspect. According to a eighth aspect of the invention there is provided an apparatus for a distributed unit, DU, of a radio access network, RAN, node of a wireless network, the apparatus comprising: one or more processing units configured to perform a method according to the fifth aspect. According to an ninth aspect of the invention there is provided an apparatus for a Mobile Termination, MT, of a radio access network, RAN, node of a wireless network, the apparatus comprising: one or more processing units configured to perform a method according to the sixth aspect. According to a tenth aspect of the invention there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method according to any of the first to sixth aspects. According to a eleventh aspect of the invention there is provided a computer-readable medium carrying a computer program according to the tenth aspect. Brief Description of the Drawings Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram illustrates an exemplary communication system in which the present invention may be implemented according to one or more embodiments; Figures 2a and 2b schematically illustrate stacks of some protocol layers involved into IAB operations; Figure 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit (PDU) or packet; Figure 4 is a schematic diagram illustrating an example of an IAB communication system (or IAB network system) in which the present invention may be implemented according to one or more embodiments; Figure 5 is a schematic diagram illustrating another example of an IAB communication system (or IAB network system) in which the present invention may be implemented according to one or more embodiments; Figure 6 is a schematic diagram illustrating another example of an IAB communication system (or IAB network system) in which the present invention may be implemented according to one or more embodiments; Figures 7a is a schematic diagram illustrating an example of lAB-node architecture enabling a smooth intra-CU PCI change without service interruption for the UEs served by an lAB-node; Figure 7b is a schematic diagram illustrating an example of lAB-node architecture enabling a smooth intra-CU PCI change or a smooth inter-CU PCI change without service interruption for the UEs served by an lAB-node; Figure 8 is a flowchart of an example of steps to perform the intra-CU PCI change procedure, in order to change the PCI of one or several cells controlled by an lAB-node without service interruption for the served UEs; Figure 9 is a flowchart of an example of steps to perform the DU migration of an lAB-node including the inter-CU PCI change procedure without service interruption for the served UEs; Figure 10 is a flowchart of an example of steps to provide information to the lAB-donor-CU controlling the DU of an lAB-node for the detection or prediction of PCI collision or confusion at a cell (or cells) of the lAB-node, according to embodiments of the invention; Figure 11a is a flowchart of an example method of the procedure to perform the activation of a logical DU and / or cell(s); Figure 11b is a flowchart of an example method of the procedure to setup a logical DU according to an embodiment of the invention; Figure 11c is a flowchart of an example method of the procedure to remove a logical DU; Figure 11 d is a flowchart of an example method of the procedure used by a RAN node DU to report detected PCI values to a RAN Node CU according to an embodiment of the invention; Figure 12a is a flowchart of an example method of the procedure used by a RAN Node CU to report information related to PCI value(s) to another RAN Node CU according to embodiments of the invention; Figure 12b is a flowchart of an example method of the procedure used by a RAN Node CU to report new usage of PCI value(s) to the core network; Figure 12c is a flowchart of an example method of the procedure used by the core network to indicate a list of PCI value(s) that can be used by a RAN Node CU; Figure 12d is a flowchart of an example method of the procedure used by a RAN Node CU to request the migration of a RAN node to another RAN Node CU, according to an embodiment of the invention; Figure 13 is a schematic diagram of a wireless communication device in accordance with one or more embodiments of the present invention; Figure 14a is a flowchart illustrating an example method for managing at a donor-CU an assistance to detect or predict potential PCI collision or confusion according to embodiments of the invention; Figure 14b is a flowchart illustrating an example method for managing at a donor-CU the change of PCI value at a RAN node DU following the detection or prediction of potential PCI collision or confusion, according to embodiments of the invention; Figure 15a is a flowchart illustrating an example method for managing at a RAN node an assistance to detect or predict potential PCI collision or confusion according to an embodiment of the invention; Figure 15b is a flowchart illustrating another example method for managing at a donor-CU the change of PCI value at a RAN node DU following the detection or prediction of potential PCI collision or confusion, according to embodiments of the invention; Figure 16 is a flowchart of an example of steps to set PCI at the DU of an lAB-node during the network integration of the lAB-node; Figure 17 is a flowchart of an example of steps to change PCI at the DU of an lAB-node following the detection or prediction of potential PCI conflict; Figure 18 is a flowchart of an example of steps to change PCI at the DU of an lAB-node during the DU migration. Detailed Description Figure 1 illustrates an example communication system 100 in which the present invention may be implemented according to one or more embodiments. As depicted, the system 100 is a wireless communication system, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network supporting mobile lAB-node. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having mobile base station. The system 100 comprises a plurality of UEs (User Equipment) 132, 133, 131 and 134, a remote core network 110, a main Base Station 120, and two Integrated Access and Backhaul (IAB) stations or IAB nodes 121 and 122 (also referred to in the following as lAB-nodes), and a mobile Integrated Access and Backhaul (IAB) station 123 mounted on a vehicle 105. The main Base Station 120, also referred to as the lAB-donor 120, is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, lAB-donor 120 is a 5G NR (referred to as a gNB) with additional functionality to support IAB features, as defined in 3GPP TS 38.300 V17.2.0 specification document. In order to extend the network coverage of lAB-donor 120 and reach the remote UEs 132, 133 and 131, IAB stations 121 and 122, also referred to as lAB-nodes 121 and 122, have been installed by the operator. By acting as relaying nodes between the lAB-donor 120 and the UEs 132 and 133, lAB-nodes 121 and 122 allow overcoming the reachability issue resulting from presence of building 108, which is an obstacle to the propagation of radio waves and hence to the direct attachment and further communications between the UEs and the lAB-donor 120. This is particularly true when the communications between the lAB-donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena. The lAB-donor 120 also serves UE 134, which is directly connected to it. The mobile IAB station 123, also referred to as mobile lAB-node (or mlAB node 123), is an lAB-node that is mounted on vehicle 105, also provides network coverage and capacity extension, allowing the lAB-donor 120 to reach onboard remote UEs, like remote UE 135, as well as surrounding UEs or UEs in the vicinity of the lAB-node 123, like remote UE 136. The lAB-donor 120 and the lAB-nodes 121 and 122 are thus forming a backhaul network or IAB network, or IAB topology, which accommodates UEs 132, 133, 131, 134, 135 and 136. The terms IAB network and IAB topology will be used interchangeably in the following. The specification of the Integrated Access and Backhaul (IAB) is spread over several 3GPP standard documents, including: - TS 38.300 RAN architecture (V17.2.0), - TS 38.321 MAC protocol (V17.2.0), - TS 38.331 Radio Resource Control (RRC) protocol (V17.2.0), - TS 38.340 Backhaul Adaptation Protocol Layer (V17.2.0), - TS 38.401 RAN architecture (V17.2.0), - TS 38.423 Xn Application Protocol (V17.2.0), - TS 38.473 F1 Application Protocol (V17.2.0). As lAB-donor 120 and lAB-nodes 121, 122 and 123 are respectively connected to UEs 134, 131, 132, 133, 135 and 136, they are considered as Access lAB-nodes for their respectively connected UEs. The lAB-donor 120 is a logical node that provides the NR-based wireless backhaul and consists of a central unit (CU orgNB-CU functionality) and connected donor distributed unit(s) (DU orgNB-DU functionality). The lAB-donor-CU ordonor-CU (also referred to in the following as IAB-donor-CU) hosts higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, for controlling operation of one or more DUs and each of the one or more lAB-donor-DUs or donor DUs (also referred to in the following as lAB-donor DU) includes lower layer protocols, such as the RLC, MAC and physical layer protocols. The lAB-donor-CU or donor-CU and lAB-donor DU or donor DU may be located far from the other or may be located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. It aims at terminating the NR access interface to the UEs and next-hop lAB-nodes, and at terminating the F1 protocol to the lAB-donor gNB-CU functionality as shown in Figure 2, discussed below. The IAB nodes, which may serve multiple radio sectors, are wireless backhauled to the lAB-donor 120, via one or multiple hops over intermediate IAB nodes. They form a directed acyclic graph (DAG) topology with the lAB-donor at its root. The IAB nodes consist of an IAB-DU and an IAB-MT (lAB-Mobile Termination). The gNB-DU functionality on an lAB-node is also referred to as IAB-DU and allows the downstream (toward the UE) connection to the next-hop IAB. The IAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non Access Stratum (NAS) functionalities to connect to the gNB-DU of an upstream lAB-node (including the lAB-donor 120 in which case it connects to the lAB-donor gNB-CU, hence to the core network 110, for instance for initialization, registration and configuration). In this DAG topology, the neighbour node on the lAB-DU’s interface is referred to as child node and the neighbour node on the lAB-MT’s interface is referred to as parent node. The direction toward the child node is further referred to as downstream while the direction toward the parent node is referred to as upstream. The lAB-donor 120 performs centralized resource, topology and route management for the whole IAB topology. This includes configuring the lAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data packets. In the example of the Figure 1, the DU part of lAB-donor 120, lAB-nodes 121, 122, and mobile lAB-node 123 controls respectively the cells 140, 141, 142 and 143. The coverage of different cells creates some overlapping areas where a UE can detect the Signal Synchronization Block (SSB) from different DUs (being DU parts of lAB-nodes, lAB-donors, mobile lAB-nodes, or legacy base stations). The Physical Cell Identity (PCI) value conveyed in each SSB helps the UE to differentiate the cells. PCI planning algorithms aim to avoid PCI collision and confusion (e.g. by avoiding the re-use of the PCI same value for adjacent cells). In cellular networks, the PCI values can be assigned either in a centralized or distributed way. When centralized assignment is used, the Operations Administration and Maintenance (OAM) system, which has a complete knowledge and control of the PCIs planning, will instruct a base station to use a dedicated PCI for each cell the base station controls. When the distributed solution is used, the OAM system assigns a list of possible PCIs to a base station, but the final choice of a PCI is done by the base station itself. The base station may request a report, sent either by UEs or by other base stations in the neighborhood, to know which PCIs are already used. Then, the base station will randomly select a PCI value from the remaining values in the list of possible PCIs provided by the OAM system. Usually the DU activates / deactivates cell(s) under the control of the donor-CU which is controlling the DU. See, for example, TS 38.473 section 8.2.3.2. Thus, it is the CU of a base station that sets the PCI for each of the DU(s) of the base station (a CU may control several DUs). Similarly, in an IAB topology, it is the lAB-donor-CU that sets the PCI for each cell in the IAB topology it controls. The lAB-donor-CU shall indicate to each donor-DU and to each DU of an IAB-node or mobile lAB-node, the PCI to use for the one or several cell(s) controlled by the DU. Even though the description focuses on IAB framework, the invention is not limited to lAB-node. For instance, it may also apply to mobile base station relay (MBSR), or to non-terrestrial networks where RAN node is embedded in a satellite or a drone. Figures 2a and 2b schematically illustrate stacks of some protocol layers involved into IAB operations. F1 interface supports the exchange of signalling information between the endpoints, as well as the data transmission to the respective endpoints. From a logical standpoint, F1 interface is a point-to-point interface between the endpoints. In 5G NR, F1-C is the functional interface in the Control Plane (CP) between the lAB-donor -CU and an lAB-node -DU (e.g. of lAB-node 2), and between the lAB-donor-CU and an lAB-donor DU. F1-U is the functional interface in the User Plane (UP) forthe same units. F1-C and F1-U are shown by reference 212 in Figure 2a. In this example, F1-U and F1-Care carried overtwo backhaul hops (from lAB-donor to IAB-node1 and then from IAB-node1 to IAB-node2). In the User Plane, boxes 210 at the lAB-donor-CU and the lAB-node DU refer to the GTP-U layer and boxes 211 refer to the UDP layer. GTP-U stands for GPRS Tunnelling Protocol User Plane. GTP-U Tunnels are used to carry encapsulated PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints (referto 3GPP TS 29.281 formore details), here boxes 210 at the lAB-donor-CU and the lAB-node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol providing a best effort datagram service and fit to use with an IP protocol. In the Control Plane, boxes 210 indicate the F1AP (F1 Application Protocol) layer and boxes 211 indicate the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS38.473 and TS 38.401) provides signalling services between the IAB-donor-CU and the lAB-node DU, or UE associated services. These services are for example initialization, configuration, and so on. The well-known SCTP layer provides reliable, in sequence transport of messages with congestion control. F1-U and F1-C rely on an IP transport layer between the lAB-donor-CU and the lAB-node DU as defined in 3GPP TS 38.401. The transport between the lAB-donor DU and the lAB-donor-CU also uses an IP transport Layer over various media, like for example wires or optical fiber when the lAB-donor-CU is remote from the lAB-donor DU, or locally in a virtual instantiation of the lAB-donor-CU and the lAB-donor DU on the same physical machine. lAB-specific transport between lAB-donor-CU and lAB-donor-DU is specified in 3GPP TS 38.401. L1 and L2 on the Figure stand respectively for the transport and physical layers appropriate to the medium in use. The IP layer can also be used for non-F1 traffic, such as Operations, Administration and Maintenance traffic. On the wireless backhaul, the IP layer is itself carried over the backhaul adaptation protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is specified in TS 38.340. The lAB-DU’s IP traffic is routed over the wireless backhaul via the BAP sublayer. In a downstream direction, upper layer packets are encapsulated by the BAP sublayer at the lAB-donor DU, thus forming BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layer or entity (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the destination lAB-node (which may be an access lAB-node should the upper layer packets in the BAP packets be intended for a UE). In an upstream direction, upper layer packets are encapsulated by the BAP sublayer at an initiator lAB-node (which may be an access lAB-node should the upper layer packets come from a UE), thus forming BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layer (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the lAB-donor DU. On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header of the BAP packets, and which is set by the BAP sublayer of the emitting IAB-donor-DU or initiator lAB-node (e.g. a network node in the IAB network generating the BAP packets). Figure 3 illustrates the format of a BAP Data Protocol Data Unit (PDU) or packet 300. It is specified in the standardized version paragraph 6.2 of 3GPP TS38.340 release 17.2.0. A header 30 includes fields 301 to 306. Field 301, named D / C field, is a Boolean indicating whether the corresponding BAP packet is a BAP Data packet or a BAP Control packet. Fields 302-304 are 1 -bit reserved fields, preferably set to 0 (to be ignored by the receiver). Fields 305 and 306 indicate together the BAP routing ID for the BAP packet. BAP address field 305, also referred to as DESTINATION field, is located in the leftmost 10 bits while BAP path identity field 306, also referred to as PATH field, is located in the rightmost 10 bits. Field 305 carries the BAP address (i.e. on the BAP sublayer) of the destination lAB-node or lAB-donor DU for the BAP packet. For the purpose of routing, each lAB-node and lAB-donor DU is configured (by an lAB-donor-CU which controls the IAB network or topology to which the lAB-node and lAB-donor DU belong) with a designated BAP address. Field 306 carries a path ID identifying the routing path the BAP packet should follow to this destination in the IAB topology. The routing paths, including their path IDs, are configured in the same way the BAP address is configured. The BAP header is added to the packet when it arrives from upper layers to the BAP layer, and it is stripped off by the BAP layer when it has reached its destination node. The selection of the packet’s BAP routing ID is configured by the lAB-donor-CU. For instance, when the BAP packet is generated by an lAB-node, i.e. either by the lAB-donor for downstream transmission or by an initiator lAB-node for upstream transmission (which may be an access lAB-node should the upper layer packets come from a UE), the BAP header with the BAP Routing ID is built by this lAB-node according to a configuration table defined in 3GPP TS 38.340. This table is called Downlink Traffic to Routing ID Mapping Configuration table in the lAB-donor or Uplink Traffic to Routing ID Mapping Configuration table in the initiator lAB-node. In intermediate lAB-nodes, the BAP header fields are already specified in the BAP packet to forward. As mentioned above, these configuration tables defining the BAP paths (hence the routing strategy and the configuration of the lAB-nodes given the IAB network topology) are usually defined by the lAB-donor-CU controlling the IAB network and transmitted to the lAB-nodes to configure them. To process the transport of messages over the 5G NR radio medium, three more sublayers (RLC, MAC and PHY) are implemented at each lAB-node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for the segmentation or reconstruction of packets. It is also responsible for requesting retransmissions of missing packets. The RLC layer is further described in TS38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for the user data and for the mapping of logical channel to the transport channels. The MAC also handles a part of the Hybrid Automated Repetition request scheme. The MAC layer is detailed in TS 38.321. On the emitter side or transmitter side, the MAC encapsulates the data packet issued from the RLC. It adds a header carrying information necessary to the MAC function. On the receiver side, the MAC decapsulates the data packet issued from the PHY, deletes its header and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (the air) by converting the stream of information into physical modulation signals, modulating a carrier frequency at the emitter side. At the receiver side the PHY sublayer converts the physical modulation signals back to a stream of information. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, TS 38.214. To pass messages towards the user or control plane, two other sublayers are used in the UE and lAB-donor-CU: the PDCP (Packet Data Convergence Protocol) sublayer and either the SDAP (Service Data Adaptation Protocol) sublayer for the User Plane communications or the RRC (Radio Resource Control) sublayer for the Control Plane communications. The PDCP sublayer handles IP Headercompression / decompression, ciphering / deciphering, and handles the integrity on the data packet if necessary. It mandatorily numbers the packets on the emitter side and reorders the packets on the receiver side. The PDCP sublayer is described in 3GPPTS38.323. SDAP sublayer 220 for the User Plane handles the Quality of Service. It is described in TS38.324. On the UE side, the SDAP sublayer exchanges the payload data with the user’s application (voice, video, etc... - not shown in the Figure). On the lAB-donor side, the SDAP sublayer exchanges the data with the Core Network 110 (Internet traffic, Cloud, etc..). RRC sublayer 220 for the Control Plane handles the configuration of the protocol entities of the User Plane protocol stack. It is described in TS38.331. It is responsible for the handling of, inter alia, broadcasting information necessary to a UE to communicate with a cell; transmitting paging messages, managing connection, including setting up bearers; mobility functions; measurement configuration and reporting; devices capabilities. The interface (for both CP and UP) between nodes using the layers PDCP, RLC, MAC and PHY is referenced NR-Uu. This mainly concerns the interface with the UE. The interface (for both CP and UP) between nodes using the layers BAP, RLC, MAC and PHY is named BackHaul RLC Channel (BH RLC channel). This mainly concerns the interfaces between the lAB-nodes. NR-Uu is the interface between the UE and the radio access network, i.e. its access IAB-node (for both CP and UP). Figure 2b comes from 3GPP TS 38.300 V17.2.0 and illustrates the protocol stack for the support of lAB-MT’s RRC and NAS connections. The Non-Access Stratum (NAS) protocol handles the messages between the core network and a user equipment, here an lAB-node. It manages the establishment of communication sessions and maintains communications with the user equipment as it moves. The 5G NAS is described in 3GPP TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the Core Network that receives all connection and session related information from the UEs connected to the IAB node, as well as similar information for the lAB-node. AMF is only responsible for handling connection and mobility management tasks. The IAB-MT establishes signalling Radio Bearers SRBs (bearers carrying RRC and NAS messages) with the lAB-donor-CU. These SRBs are transported between the IAB-MT and its parent node(s) over NR-Uu interface(s). Figure 4 illustrates an example of a wireless communication system (or IAB network) 400 in which embodiments and examples of embodiments of the present invention may be implemented. In one example implementation, the radio links between the IAB nodes and IAB donor DU nodes (referred to as BH radio links) are operated over the millimeter wave frequency band (i.e. above 30 GHz), which is highly sensitive to radio channel disturbance. An IAB network will also be referred to as an IAB topology or topology and so in this application, the terms IAB network and IAB topology and topology will be used interchangeably. IAB communication system 400 is composed of two IAB networks or IAB topologies 4001 and 4002 with each IAB topology comprising a set of IAB nodes (e.g. the set may comprise a plurality of IAB nodes or at least one IAB node) and a lAB-donor-CU for controlling or managing the plurality of IAB nodes. The set of IAB nodes may include one or more lAB-nodes, such as initiator lAB-nodes which generate BAP packets and also intermediate or relay lAB-nodes. The set of IAB nodes may also include one or more IAB donor DUs. Each of the IAB nodes communicate with at least one other IAB node over a wireless backhaul (BH) link. Although Figure 4 shows two IAB topologies 4001 and 4002, the present invention is not limited to two IAB topologies 4001 and 4002 and may be implemented in an IAB communication system comprising more than two IAB topologies with each topology comprising a set of IAB nodes and a IAB donor-CU as discussed above. IAB topology 4001 includes lAB-donor-CU 401 (identified as Donor1-CU in Figure 4), its associated lAB-donor-DUs, lAB-donor-DU 403 (identified as Donor1-DU1 in Figure 4) and IAB-donor-DU 404 (identified as Donor1-DU2 in Figure 4), and a plurality of lAB-nodes 410, 420, 430, and 460, similar to lAB-nodes 121 and 122, and lAB-node 470, similar to mobile lAB-node 123. All lAB-nodes can be access nodes serving UEs like the UE 480 served by the mobile lAB-node 470. The IAB topology 4001 is transparent for the UE 480 that connects to the donor-CU 401 through the DU part or unit mDU 472 of the mobile lAB-node 470. IAB topology 4002 includes lAB-donor-CU 402 (identified as Donor2-CU in Figure 4), and its associated lAB-donor-DU 405 (identified as Donor2-DU1 in Figure 4), and a plurality of lAB-nodes 440 and 450, similar to lAB-nodes 121 and 122. The IAB network 400 can provide network path diversity through several lAB-donor-DUs and different IAB networks or topologies. As discussed above, each IAB node comprises a Mobile Termination (MT) part or unit, controlled and configured by the IAB donor-CU using RRC messaging as defined in 3GPP TS 38.331, and a Distributed Unit (DU) part, controlled and configured by the IAB donor-CU using F1-AP messaging as defined in 3GPP TS 38.473. For example, lAB-node 410 comprises a MT part or unit 411 and a DU part or unit 412. A wired backhaul IP network interconnects the lAB-donor-CUs 401 and 402, and the IAB-donor-DUs 403, 404 and 405 through wired link 406. For instance, this wired link consists of optical fiber cable(s). lAB-Donor-CU 401, lAB-Donor-DUs 403 and 404, lAB-nodes 410, 420, 430, 460, 470 and lAB-node 470 are part of the same IAB network or IAB topology 4001, which is controlled (e.g. configured and / or managed) by lAB-Donor-CU 401. lAB-Donor-CU 402, lAB-Donor-DU 405 and lAB-nodes 440 and 450 are part of the same IAB network or IAB topology 4002, which is configured and managed or controlled by lAB-Donor-CU 402. All the donor DUs 403, 404, 405, and the DUs of lAB-nodes 412, 422, 462, 472, 442, 452, handle one or several cells not represented in the figure. In this example, the mobile lAB-node 470 is first single connected to the lAB-node 460 through the link 4060. Assuming the mobile lAB-node 470 is moving in the direction of lAB-node 430, the mobile lAB-node 470 may have the opportunity to be dual-connected with the lAB-node 430 as a second parent lAB-node through the link 4030. Instead of dual-connectivity, the mobile lAB-node 470 may be migrated to the lAB-node 430 by the donor-CU 401, then the mobile lAB-node 470 will be single connected to the lAB-node 430 through the link 4030, and it will no longer be connected to the lAB-node 460. When moving in the direction of lAB-node 430 and also of lAB-node 410, a PCI used by the mobile lAB-node 470 for one of its cells may be in conflict with one or several PCI value(s) used in the lAB-node 410 (for instance). The donor-CU 401 can detect this potential PCI collision based on the knowledge of the proximity of the mobile lAB-node 470 to the cell(s) controlled by lAB-node 410 (i.e. according to the new connection to the lAB-node 430). Indeed, the mobile lAB-node 410 may report to the donor-CU 401 the presence of a new cell managed, for instance by the lAB-node 430, through a measurement report including the PCI of the cell. Therefore, the donor-CU 401 may trigger the procedure for PCI change described with the Figure 8 (intra-CU PCI change). As an alternative method for the detection of PCI collision, the donor-CU 401 may send a notification to the core network (not represented in the Figure) of the new location of the cell(s) controlled by the mobile lAB-node 470, using the procedure described in the Figure 12b. In return, the core network may indicate to the donor-CU 401 the potential PCI collision and an update of the PCI value or of the list of PCI values that can be assigned to the cell(s) of the mobile lAB-node 470. The response of the core network can be performed with the procedure described with the Figure 12c. However, this alternative method is less efficient as it requires the exchange of information with the core network. Figure 5 illustrates another example of an IAB communication system (or IAB network system) 500 in which embodiments and examples of embodiments of the present invention may be implemented. It is similar to the system 400 described in the Figure 4 with two IAB topologies 5001 and 5002. IAB topology 5001 includes lAB-donor-CU 501 (identified as Donor1-CU in Figure 5), its associated lAB-donor-DUs, lAB-donor-DU 503 (identified as Donor1-DU1 in Figure 5) and lAB-donor-DU 504 (identified as Donor1-DU2 in Figure 5), a plurality of lAB-nodes 510, 520, 530, and 560, similar to lAB-nodes 121 and 122, and lAB-node 570, similar to mobile lAB-node 123. IAB topology 5002 includes lAB-donor-CU 502 (identified as Donor2-CU in Figure 5), and its associated lAB-donor-DU 505 (identified as Donor2-DU1 in Figure 5), and a plurality of lAB-nodes 540 and 550, similar to lAB-nodes 121 and 122. The IAB topology 5001 is transparent for the UE 580 that connects to the donor-CU 501 through the DU part or unit mDU 572 of the mobile lAB-node 570. Figure 5 may illustrate the result of the mMT 471 migration (or handover) of the IAB node 470 in Figure 4 (i.e. the lAB-node 570 in Figure 5), which is now connected to the lAB-node 430 (i.e. the lAB-node 530 in Figure 5) through the link 5030, and it is no longer connected to the lAB-node 460 (i.e. the lAB-node 560 in Figure 5). While the mobile lAB-node is moving in the direction of lAB-topology 5002 and the lAB-node 550, several scenarios are possible according to the IAB framework. As a first scenario, the topology redundancy procedure may be applied, as described in TS 38.401 V17.2.0 section 8.17.2.1, where a dual connectivity is established for the lAB-node 570 with two parent lAB-nodes 530 and 550 belonging to two different IAB topologies. When the lAB-node 570 is initially connected to a single IAB topology (e.g. IAB topology 4001), the MT part or unit mMT 571 of lAB-node 570 periodically performs a cell search procedure, as defined in 3GPP TS 38.300, trying to detect a PSS (Primary Synchronization Signal) and a SSS (Secondary Synchronization Signal). The mMT 571 may report to the donor-CU 501 the presence of a new cell managed, for instance by the lAB-node 550, through a measurement report including the PCI of the cell as computed with PSS and PSS signals. Based on the analysis of the measurement report, the donor-CU 501 may request to the donor-CU 502 the establishment of a dual connectivity for the lAB-node 570 with an additional connection through the lAB-node 550. The donor-CU 502 may accept the request and proceed to the connection of the lAB-node 570 according to the procedure described in TS 37.340 V17.2.0 section 10.2. As a result, the lAB-node 570, still belonging to IAB topology 5001, is now also connected to lAB-node 550, which belongs to IAB topology 5002, and it may be referred to as a boundary node between IAB topology 5001 and IAB topology 5002. Actually, the lAB-node 570 retains its F1 connection and its RRC connection to the donor-CU 501, which can be referred to as the F1 -terminating lAB-donor-CU, and the lAB-node 570 has another RRC connection to the donor-CU 502, which can be referred to as the non-F1-terminating lAB-donor-CU or RRC terminating lAB-donor-CU. As the lAB-node or boundary node 570 is part of the IAB topology 5001 (from the F1 connection point of view), it is controlled (e.g. configured and / or managed) by the lAB-Donor-CU 501 of IAB topology 5001. When moving in the direction of lAB-node 550 and also of lAB-node 540, a PCI used by the mobile lAB-node 570 for one of its cells may be in conflict with the PCI value(s) used in the IAB- node 550 or 540. Thanks to the measurement reports received from the mMT 571, and assuming the donor-CU 501 is informed about the PCI values set in the IAB topology 5002 (for instance with the procedure described in Figure 12a), the donor-CU 501 can detect the potential PCI collision following the new connection of the mobile lAB-node 570 in a cell controlled by the lAB-node 550. Therefore, the donor-CU 501 may trigger the procedure for PCI change described with the Figure 8 (intra-CU PCI change) according to embodiments of the invention. As a second scenario in the Figure 5, the BH link or BH radio link 5030 may also experience radio link deficiency due to some unexpected interference or shadowing phenomena. For such reasons, the lAB-node 570 may lose the connection with the lAB-node 530 and declare a Radio Link Failure (RLF) for the BH link 5030. Then, the lAB-node 570 will try to reestablish the connection with the same ora different parent lAB-node (ordonor-DU). Thus, the lAB-node 570 may try to join the IAB topology 5002 managed by lAB-donor-CU 502 with a connection through the new parent lAB-node 550 with the BH link 5050. In this case, the inter-CU backhaul RLF recovery procedure may be applied, as described in TS 38.401 V17.2.0 section 8.17.4, which enables recovery of an lAB-node to another parent node underneath a different lAB-donor-CU, when the IAB-MT of the lAB-node declares a backhaul RLF. In such procedure, the donor-CU 502 sends to the donor-CU 501 a request to retrieve the context of the lAB-node 570. Based on the response from the donor-CU 501, the donor-CU 502 may accept the connection of the lAB-node 570, which becomes a boundary node still belonging to the IAB topology 5001. In this case, the lAB-node 570 retains its F1 connection to the donor-CU 501 which can be referred to as the Flterminating lAB-donor-CU, and the lAB-node 570 has a RRC connection to the donor-CU 502, which can be referred to as the non-F1-terminating lAB-donor-CU or equivalently as the RRC terminating lAB-donor-CU. In the following embodiments the terms ‘non-F1-terminating donor CU’ or ‘non-F1 donor CU’ are typically used to describe a donor-CU to which an lAB-node has an RRC connection but it will be understood that the terms ‘RRC terminating donor-CU’ or ‘RRC donor-CU’ are equivalents. As a third scenario in the Figure 5, the lAB-node 570, which is single connected to the parent lAB-node 530, may be partially migrated toward the IAB topology 5002, meaning its RRC connection is migrated from an old parent node to a new parent node, where the old and the new parent nodes are served by different lAB-donor-CUs. Indeed, based on the measurement report provided by the lAB-node 570, the donor-CU 501 may detect that the lAB-node 570 would have a better connection through a cell managed by the lAB-node 550 belonging to the IAB topology 5002. Then, the donor-CU 501 may trigger the IAB Inter-CU Topology Adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1. In this procedure, the donor-CU 501 sends a handover request for the lAB-node 570 along with information for the donor-CU 502 to establish a RRC connection to the lAB-node 570. Based on this information, the donor-CU 502 may accept the handover request and proceed to the admission of the lAB-node 570, which becomes a boundary node still belonging to the IAB topology 5001, with F1 connection to the donor-CU 501 and RRC connection to the donor-CU 502. In this third scenario, the IAB topology 5001 may be referred to as the source IAB network or source IAB topology, and the topology 5002 may be referred to as the target IAB network or target IAB topology. Also, the donor-CU 501 may be referred to as the source lAB-Donor-CU or source donor-CU, and the donor-CU 502 may be referred to as the target lAB-Donor-CU or target donor-CU. In the second and the third scenario, when moving in the direction of lAB-node 550 and also of lAB-node 540, a PCI used by the mobile lAB-node for one of its cells may be in conflict with the PCI value(s) used in the lAB-node 550 or 540. Even though the donor-CU 501 may be informed about the PCI values set in the IAB topology 5002 (for instance with the procedure described in Figure 12a), the donor-CU 501 cannot accurately detect the potential PCI collision or confusion following the new connection of the mobile lAB-node 570 in a cell controlled by the lAB-node 550. Indeed, the measurement reports sent by the mMT 571 are no longer received by the donor-CU 501, but they are received by the donor-CU 502. Therefore, the donor-CU 501 may trigger the procedure for PCI change described with the Figure 8 (intra-CU PCI change) when it is not necessary and / or it may assign a new PCI value that is not appropriate according to the position of the lAB-node 570. For instance, some cells in the vicinity may not yet been visible by the lAB-node 570, and may have PCI values in conflict with PCI value(s) used by the lAB-node 570. Besides, it can be noted that the donor-CU 502 may not know the PCI value(s) used by the mDU 572 as this DU is controlled by the donor-CU 1, thus the donor-CU 502 cannot detect PCI collision or confusion at the lAB-node 570. Assistance for PCI collision or confusion detection can be provided to the donor-CU 501 using the procedures described with the Figure 10. In all the three scenarios described above, the UE 580 still connects to the donor-CU 501 through the DU part or unit mDU 572 of the mobile lAB-node 570. In case the lAB-node 570 has some child lAB-node(s), such child lAB-node still belongs to the IAB topology 5001, and it is still fully controlled (through F1 and RRC connections) by the donor-CU 501. Figure 6 illustrates another example of an IAB communication system (or IAB network system) 600 in which embodiments and examples of embodiments of the present invention may be implemented. It is similar to the system 500 described in the Figure 5, but with three IAB topologies 6001, 6002 and 6003. IAB topology 6001 includes lAB-donor-CU 601 (identified as Donor1-CU in Figure 6), its associated lAB-donor-DUs, lAB-donor-DU 603 (identified as Donorl-DU1 in Figure 6) and lAB-donor-DU 604 (identified as Donor1-DU2 in Figure 6), and a plurality of lAB-nodes 610, 620, 630, and 660, similar to lAB-nodes 121 and 122. IAB topology 6002 includes lAB-donor-CU 602 (identified as Donor2-CU in Figure 6), its associated lAB-donor-DU 605 (identified as Donor2-DU1 in Figure 6), and a plurality of lAB-nodes 640 and 650, similar to lAB-nodes 121 and 122. IAB topology 6003 includes lAB-donor-CU 607 (identified as Donor3-CU in Figure 6), its associated lAB-donor-DU 606 (identified as Donor3-DU1 in Figure 6), an lAB-node 690, similar to lAB-node 121, and lAB-node 670, similarto mobile lAB-node 123. The IAB topology 6003 is transparent for the UE 680 that connects to the donor-CU 607 through the DU part or unit mDU 672 of the mobile lAB-node 670. Figure 6 may illustrate the result of the DU migration of the IAB node 570 in Figure 5 (i.e. the lAB-node 670 in Figure 6), which now belongs to the IAB topology 6003 in Figure 6. In the context of DU migration, the IAB-DU part or unit mDU 672 of lAB-node 670 is migrated to the target donor-CU 607. The DU migration is appropriate for a mobile lAB-node that moves and may cross several IAB topologies along its journey. The DU migration of the mobile lAB-node 670 as described with the Figure 9 may require a change to the PCI value(s) used by the mobile lAB-node 670, ensuring that the new PCI value(s) do not generate PCI conflicts. The procedure for the DU migration of a mobile lAB-node is described with the Figure 9 (inter-CU PCI change) according to embodiments of the invention. At the DU migration of the lAB-node 670, the served UEs, like UE 680, also migrate from the source donor-CU (or source F1 donor-CU or source F1 terminating donor-CU) 601 to the target donor-CU (or target F1 donor-CU or target F1 terminating donor-CU) 602. UE migration may be performed through a procedure (described at the Figure 9), which is based on the handover procedure described in TS 38.300 V17.2.0 section 9.2.3.2. In this example, the mMT 671 of the lAB-node 671 remains connected to the donor-CU 602, which is the non-F1donor-CU (ornon-F1 terminating donor-CU IRRC donor-CU IRRC terminating donor-CU) for the lAB-node 670. Figure 7a illustrates an example of lAB-node architecture 700 enabling a smooth intra-CU PCI change without service interruption for the UEs served by an lAB-node. An Intra-CU PCI change procedure, as described with the Figure 8, applies to an lAB-node with a DU that is not migrating toward a new lAB-donor-CU. While the description of some examples of the present invention focuses on a PCI change for a mobile lAB-node, the present invention does not preclude applications of the intra-CU PCI change procedure fora stationary lAB-node. Thus, the lAB-node 701 may be a mobile lAB-node like the mobile lAB-node 470 (also 570, 670), or an lAB-node like the lAB-node 460 (also 560, 660). The lAB-node 701 comprises an IAB-MT part or unit 710 and an IAB-DU part or unit 711. Before the PCI change, a UE 702 is for instance in the cell 731 and connected to a donor-CU (not represented), through IAB-DU 711 with the access link 721. The IAB-DU 711 may control several other cells not represented in the figure. Upon detection that the PCI of the cell 731 may be in conflict with other PCIs in the vicinity of the cell 731, the donor-CU may trigger the PCI change procedure described at the Figure 8. In this procedure, a new cell 732 controlled by IAB-DU 711 is activated, on which the UE 702 may also connect to the donor-CU through IAB-DU 711 and with the access link 722. In one example, a cell in the vicinity of the cell 731 may correspond to a cell adjacent to the cell 731, and which covers a geographical area that may partly or completely overlap with the geographical area covered by the cell 731. In another example, a cell in the vicinity of the cell 731 may correspond to a cell not adjacent to the cell 731 but adjacent to a third cell that is also adjacent to the cell 731. The activation of the cell 732 is triggered by the donor-CU, for instance with the procedure described with reference to Figure 11a. During the activation procedure, the donor-CU indicates to the IAB-DU 711 the PCI value to be used for the cell 732. Still referring to the procedure described at the Figure 8, once the handover of UEs, like UE 702, is completed from the cell 731 to the cell 732, then the cell 732 may be deactivated. The deactivation of a cell is triggered by the donor-CU with the procedure described with reference to Figure 11a, after the detection of the completion of UEs handover. Figure 7b illustrates another example of lAB-node architecture 750 enabling a smooth intra-CU PCI change or a smooth inter-CU PCI change without service interruption for the UEs served by an lAB-node. Intra-CU PCI change procedure, as described with reference to Figure 8, applies to an lAB-node with a DU that is not migrating. Inter-CU PCI change procedure, as described with reference to Figure 9, applies to an lAB-node with a DU that is migrating toward a different IAB-donor-CU. While a PCI change may be only necessary fora mobile lAB-node, the invention does not preclude applications of the intra-CU PCI change procedure and the inter-CU PCI change procedure fora stationary lAB-node. Thus, the lAB-node 751 may be a mobile lAB-node like the mobile lAB-node 470 (also 570, 670), or an lAB-node like the lAB-node 460 (also 560, 660). The lAB-node 751 comprises an IAB-MT part or unit 760, an IAB-DU1 part or unit 761, and an IAB-DU2 part or unit 762. Both IAB-DU 1 and IAB-DU2 are logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one embodiment, they share the same physical layer (i.e. the same hardware resources), while in another embodiment they rely on separated physical layers. In this example, IAB-DU1 761, when activated, controls the cell 781 and IAB-DU2 762, when activated, controls the cell 782. Both IAB-DU1 761 and IAB-DU2 762 may handle several other cells not represented in the figure. Only one logical DU is sufficient for IAB operations, except at the intra-CU PCI change, at the inter-CU PCI change, or at the DU migration without PCI change of the lAB-node 751, when both logical DUs are active. For intra-CU PCI change, both logical DUs terminates a F1 interface with a same donor-CU. For inter-CU PCI change, one of the logical DU terminates the F1 interface with a source donor-CU, while the other logical DU terminates the F1 interface with a target donor-CU. The architecture of the Figure 7b may be used for intra-CU PCI change, in case the processing load of the logical DU IAB-DU1 761 is high because of a high number of cells. In this case, the processing load of IAB-DU1 761 may be alleviated by the activation of the second logical DU IAB-DU2 762 during the PCI change phase. In case of intra-CU PCI change and before the operation, a UE 752 is for instance in the cell 781 and connected to a donor-CU (not represented), through IAB-DU1 761 with the access link 771. Upon detection that the PCI of the cell 781 may be in conflict with other PCIs in the vicinity of the cell 781, the donor-CU may trigger the PCI change procedure, where the logical DU IAB-DU2 762 is activated with the new cell 782, on which the UE 752 may also connect to the donor-CU through the access link 772. The activation of the logical DU IAB-DU2 762 with the cell 782 is triggered by the donor-CU, for instance with the procedure described with the Figure 11a. During the activation procedure, the donor-CU indicates to the IAB-DU1 761 the PCI value to be used for the cell 782. Referring to the procedure described at the Figure 8, once the handoverof UEs, like UE 752, from the cell 781 to the cell 782 is completed, then the cell 781 is deactivated. The deactivation of the cell is triggered by the donor-CU with the procedure described with the Figure 11c, after the detection of the completion of UEs handover. When activating the logical DU IAB-DU2 762, the donor-CU may activate as many cells as the number of cells controlled by the logical DU IAB-DU1 761. Then, all the UEs connected through the logical DU IAB-DU1 are handed over via a cell controlled by the logical DU IAB-DU2 762. Once the handoverof all UEs is completed, the donor-CU deactivates the logical DU IAB-DU1 761, along with all the cells it was controlling. The deactivation of the logical DU IAB-DU1 761 is triggered by the donor-CU, for instance with the procedure described with the Figure 11c, after the detection of the completion of UEs handover. In case of inter-CU PCI change and before the operation, a UE 752 is for instance in the cell 781 and connected to a source donor-CU through the logical DU IAB-DU1 761 with the access link 771, while the logical DU IAB-DU2 762 is deactivated. During the PCI change procedure described with the Figure 9, the logical DU IAB-DU2 762 is activated and connects to a target donor-CU, on which the UE 752 may also connect to through the logical DU IAB-DU2 762 with the cell 782 and the access link 772. The activation of the logical DU IAB-DU2 762 may be triggered by the lAB-node, then the setup is achieved with the procedure described with the Figure 11b. The target donor-CU may indicate the PCI value to be used for the cell(s), like the cell 782, to be activated with the second logical DU, for instance with the procedure described with the Figure 11 b. Still referring to the procedure described at the Figure 9, once the handover of UEs, like UE 752, from the cell 781 to the cell 782 is completed, then the cell 781 is deactivated. The deactivation of the cell is triggered by the source donor-CU with the procedure described with the Figure 11a, after the detection of the completion of UEs handover. When activating the logical DU IAB-DU2 762, the target donor-CU may activate as many cells as the number of cells controlled by the logical DU IAB-DU1 761. Then, all the UEs connected through the logical DU IAB-DU1 761 are handed over a cell controlled by the logical DU IAB-DU2 762. Once the handover of all UEs is completed, the source donor-CU deactivates the logical DU IAB-DU1 761, along with all the cells it was controlling. The deactivation of the logical DU IAB-DU1 761 is triggered by the source donor-CU, for instance with the procedure described with the Figure 11c, after the detection of the completion of UEs handover. Figure 8 is a simplified flowchart 800 illustrating an example of steps to perform the intra-CU PCI change procedure, in order to change the PCI of one or several cells controlled by an IAB-node without service interruption for the served UEs. It is based on the architecture of an lAB-node described in the Figure 7a or 7b. This figure shows a UE 801 like the UE 580, a donor-CU 803 like the donor-CU 501, the core network (5GC) 802 like the core network 110. This figure also shows an lAB-node 808 like the lAB-node 701 of the Figure 7a, composed of an IAB-MT part or unit 804 and an IAB-DU1 part or unit 805, or like the lAB-node 751 of the Figure 7b, composed of an IAB-MT part or unit 804, an IAB-DU1 part or unit 805, and an IAB-DU2 part or unit 806. IAB-DU1 and IAB-DU2 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one embodiment, they share the same physical layer (i.e. the same hardware resources), while in another embodiment they rely on separated physical layers. At the beginning of the flowchart, the UE 801 is served by the lAB-node 808 through a cell controlled by IAB-DU1 805, while in case of the architecture of the Figure 7b is used, the logical DU IAB-DU2 806 is inactive. The user data in the downstream direction are provided by the 5GC 802 to the donor-CU 803 through the bearer 820, then they are transmitted to the logical DU IAB-DU1 805 through the backhaul bearer 821, and finally to the UE 801 through the data radio bearer 822. User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. After the decision by the donor-CU 803 to change the PCI value for one or several cells controlled by the lAB-node and having determined the new PCI value(s) to be used, the first step 811 corresponds to the activation of cell(s) using the new PCI value(s). The new cell(s) are controlled by the logical DU IAB-DU1 805 in case of the architecture of the Figure 7a is used, or they are controlled by the logical DU IAB-DU2 806 in case of the architecture of the Figure 7b is used. In this latter case, the step 811 includes the activation of the logical DU IAB-DU2. In all cases, there may be as many cells created as the number of PCI values to change, or as many cells as the number of cells controlled by the logical DU IAB-DU1 805. For instance, the procedure described with the Figure 11a is used for the activation of the logical DU IAB-DU2 806 and for the activation of the cell(s). The next step 812 consists in the handover of UEs served by the IAB node, from a cell controlled by the logical DU IAB-DU1 805 having a first PCI value, to a cell using a new, second, PCI value, controlled either by the logical DU IAB-DU1 805 (case of the architecture in Figure 7a), or by the logical DU IAB-DU2 806 (case of the architecture in Figure 7b). The UE handover procedure corresponds to the procedure described in TS 38.401 V17.2.0 section 8.2.1.2. In case of an lAB-node using the architecture of the Figure 7a, once the handover is completed for the UE 801, the user data in the downstream direction are transmitted by the core network 802 to the donor-CU 803 through the bearer 820, then they are transmitted to the logical DU IAB-DU1 805 through the backhaul bearer 821, and finally to the UE 801 through the new data radio bearer 823 in the new cell. User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. In case of an lAB-node 808 using the architecture of the Figure 7b, once the handover is completed for the UE 801, the user data in the downstream direction are transmitted by the core network 802 to the donor-CU 803 through the bearer 820, then they are transmitted to the logical DU IAB-DU2 806 through the backhaul bearer 824, and finally to the UE 801 through the data radio bearer 825 in the new cell. User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. At step 813, once the handover is completed for all UEs served in the cell with the first PCI, then the cell may be deactivated. The procedure described with the Figure 11a may be used for the cell deactivation. In case of an lAB-node 808 using the architecture of the Figure 7b, when the handover is completed for all UEs served by the logical DU IAB-DU1 805, then this logical DU may be deactivated. The procedure described with the Figure 11c may be used. The deactivation of the cell(s) controlled by the logical DU IAB-DU1 805 may be performed at the same time. Figure 9 is a simplified flowchart 900 illustrating an example of steps to perform the DU migration of an lAB-node including the inter-CU PCI change procedure without service interruption for the served UEs. It is based on the architecture of an lAB-node described int the Figure 7b. The lAB-node that may be a mobile lAB-node. This figure shows a UE 901 like the UE 580, a source donor-CU 903 like the donor-CU 501, a target donor-CU 907 like the donor-CU 502, and the core network (5GC) 902 like the core network 110. This figure also shows an lAB-node 908, like the lAB-node 751, comprising an IAB-MT part or unit 904, an IAB-DU1 part or unit 905, and an IAB-DU2 part or unit 906. IAB-DU1 and IAB-DU2 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one embodiment, they share the same physical layer (i.e. the same hardware resources), while in another embodiment they rely on separated physical layers. The IAB-MT 904 may have been migrated (or handed over) to another donor-CU not represented on Figure 9, which is the non-F1 donor-CU (or RRC terminating donor CU) for the lAB-node. At the beginning of the flowchart, the UE 901 is served by the lAB-node through a cell controlled by IAB-DU1 905, while the logical DU IAB-DU2 806 is inactive. The user data in the downstream direction are provided by the 5GC 902 to the donor-CU 903 through the bearer 920, then they are transmitted to the logical DU IAB-DU1 905 through the backhaul bearer 921, and finally to the UE 901 through the data radio bearer 922. User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. The step 911 corresponds to the activation of the second logical DU IAB-DU2 906 in the IAB node including the activation of one or several cells controlled by the IAB-DU2 906. A request for activation of the second logical DU IAB-DU2 906 may be sent by the source donor-CU 903 to the lAB-node, through the first logical DU IAB-DU1 905 and using the procedure described in Figure 11 a. Then, the setup of the IAB-DU2 906 may be achieved using the procedure described in Figure 11 b. The target donor-CU 907 receiving a setup request from IAB-DU2 906, will respond with a request to create new cell(s) controlled by IAB-DU2 906. There may be as many cells created as the number of cells controlled by the logical DU IAB-DU1 905. To complete the step 911, the target donor-CU 907 may inform the source donor-CU 903 about the activation of the second logical DU IAB-DU2 906 and of the cell(s), for instance with the procedure described in Figure 12a. After activation of the second logical DU and newcell(s) in the IAB node (step 911), the next step 912 consists in the handover of UEs served by the IAB node, from a cell controlled by the first logical DU mlAB-DU1 905 to a cell controlled by the second logical DU IAB-DU2 906. The UE handover is based on the procedures described in TS 38.300 V17.2.0 section 9.2.3. The step 914 can be triggered by the source donor-CU 903 after the notification of the activation of cell(s) in the second logical DU IAB-DU2 906, received at the end of the step 913. Alternately, it may be triggered when the source donor-CU 903 receives a measurement report from the UE indicating that the UE receives radio signals in a cell controlled by the IAB-DU2 906. For smooth UEs handover, the PCI value(s) of the cell(s) activated in the second logical DU IAB-DU2 906 should not be in conflict with the PCI value(s) used for the cell(s) controlled by the first logical DU IAB-DU1 905, nor with the PCI values of the cells in the vicinity of the lAB-node 908. As the target donor-CU 907 does not have information regarding the PCI values used by the first logical DU IAB-DU1 905, the target donor-CU 907 cannot effectively determine non-conflicting PCI values to be used for the cell(s) to be controlled by the second logical DU IAB-DU2 906 without additional assistance. Such assistance may be provided to the target donor-CU 907 using one of the procedures described in Figures 11b, 12a and 12d. Once the handover is completed for the UE 901, the transport migration step 913 is executed. First, the source donor-CU 903 may release the traffic (user traffic, control traffic) related to the UE 901 through the IAB-DU1 905. If the traffic was offloaded in an IAB topology controlled by a nonFI donor-CU (or RRC terminating donor-CU), the source donor-CU 903 may request a traffic release to the non-F1 donor-CU. Then, the target donor-CU 707 has to setup the data path(s) to / from the migrated lAB-node, either in its own topology if there is a backhaul path to reach the lAB-node in the IAB topology controlled by the target donor-CU 907, or through the IAB topology of the non-F1 donor-CU of the lAB-node if there is no backhaul path to reach the lAB-node in the IAB topology controlled by the target donor-CU 907. In this latter case, the target donor-CU 907 may trigger the transport migration and path switch procedure including the request of traffic migration to the non-F1 donor-CU of the lAB-node, and the path switch procedure toward the core network 902. Following the step 913, the user data in the downstream direction are transmitted by the core network 902 to the target donor-CU 907 through the bearer 924, then they are transmitted to the logical DU IAB-DU2 906 through the backhaul bearer 925, and finally to the UE 901 through the data radio bearer 926 in the new cell. User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. Once the handover is completed for all UEs served in a cell controlled by the first logical DU IAB-DU1 905, then the cell may be deactivated. The procedure described with the Figure 11c may be used for the cell deactivation. When the handover is completed for all UEs served by the logical DU IAB-DU1 905, then this logical DU may be deactivated. The procedure described with the Figure 11c may be used. The deactivation of the cell(s) controlled by the logical DU IAB-DU1 905 may be performed at the same time. Figure 10 is a flowchart 1000 of an example of steps to provide information to the lAB-donor-CU controlling the DU of an lAB-node for the detection or prediction of PCI collision or confusion at a cell (or cells) of the lAB-node, according to embodiments of the invention. This figure shows a F1 donor-CU 1003 like the donor-CU 501,anon-F1 donor-CU (orRRC terminating donor-CU) 1007 like the donor-CU 502, and the core network (5GC) 1002 like the core network 110. This figure also shows an lAB-node 1008, like the lAB-node 570, comprising an IAB-MT part or unit 1004, an IAB-DU part or unit 1005. The F1 donor-CU (or F1 terminating donor-CU) 1003 terminates the F1 connection with the lAB-node and thus controls the IAB-DU 1005. The F1 donor-CU 1003 is also the donor-CU that assigns the PCI value(s) in the cell(s) controlled by the IAB-DU 1005. It is assumed that the IAB-MT 1004 has been migrated to the non-F1 donor-CU (or non-F1 terminating donor-CU I RRC terminating donor-CU) 1007, which therefore terminates the RRC connection with the lAB-node. In particular, the non-F1 donor-CU 1007 regularly receives the measurement report 1011 from the IAB-MT, reporting a list of cell(s) detected in the vicinity of the lAB-node and including the PCI value associated with the detected cell(s). To assist the F1 donor-CU 1003 to detecta potential PCI collision or confusion, the non-F1 donor-CU 1007 may send a PCI configuration report message 1012 to the F1 donor-CU 1003. According to one aspect of the invention, this message may relay to the F1 donor-CU 1003 the information (or part of information) received in the measurement report 1011. At least, the message 1012 includes the list of PCI values detected by the IAB-MT 1004. In addition, the message 1012 may also include a list of PCI values that are already configured in the vicinity of the lAB-node but that have not been detected by the IAB-MT 1004. For example, the message 1012 may include PCI values reported to the non-F1 donor-CU 1007 from other IAB nodes in the topology of the non-F1 donor-CU 1007 and / or PCI values assigned by the non-F1 donor CU 1007. This PCI configuration report message 1012 may be sent each time a measurement report 1011 is received, or when a change is detected in the list of PCI values reported by the IAB-MT 1004. According to another aspect of the invention, the PCI configuration report message 1012 may indicate a potential PCI conflict for at least one PCI value used by the IAB-DU 1005. It may also include a list of PCI values that may be assigned for each PCI value with a potential conflict. This method assumes that the non-F1 donor-CU 1007 is able to detect or predict a potential PCI conflict at the lAB-node, and thus that it knows the PCI value(s) used for the cell(s) controlled by the IAB-DU 1005. This may be the case if the F1 donor-CU 1003 has informed the non F1 donor-CU 1007 about the PCI values used by the IAB-DU 1005, for instance using one of the procedures described with the Figures 12a and 12d. A potential PCI conflict at the lAB-node can be detected by the non-F 1 donor-CU 1007 by comparing the PCI values used by the IAB-DU 1005 with the PCI values detected by the IAB-MT 1004 (as reported in the measurement report 1011), and also optionally using information of PCI values configured for the cells in the vicinity of the lAB-node. In this case, the PCI configuration report message 1012 may be sent only when a potential PCI conflict is detected or predicted. The PCI configuration report message 1012 may be the message 1203 described in Figure 12a. Upon reception of the PCI configuration report message 1012, the F1 donor-CU 1003 may use the reported information to trigger a PCI change procedure 1010. In case the non-F1 donor-CU 1007 has reported a list of PCI values detected by the IAB-MT 1004 (and optionally a list of configured PCI values in the vicinity of the lAB-node), the F1 donor-CU 1003 uses the information to detect or predict a potential conflict at the lAB-node. In case the non-F1 donor-CU 1007 has reported a potential PCI conflict and has proposed PCI value(s) as replacement, the F1 donor-CU 1003 can directly execute the PCI change procedure 1010 as described with the figure 8. Then, the F1 donor-CU 1003 may send the PCI change report message 1014 to the non-F1 donor-CU 1007 to indicate the new value(s) configured for the cell(s) controlled by the IAB-DU 1005. The message 1014 may be sent to other donor-CUs, and it may be the message 1203 in Figure 12a. The F1 donor-CU 1003 may send the PCI change report message 1015 to the core network 1002. The PCI change report message 1015 may be the message 1213 described in Figure 12b. As an alternative method to provide information to the F1 donor-CU 1003 for the detection or prediction of PCI collision or confusion, the lAB-node may send to the F1 donor-CU 1003 a PCI measurement report message 1013. This message 1013 may include the list of PCI values detected by the IAB-MT 1004 (and first provided to the IAB-DU 1005 by the IAB-MT 1004). The message 1013 may be sent at the same time as the measurement report 1011 provided by the IAB-MT 1004 to the non-F1 donor-CU 1007. It may also be sent when a change is detected in the list of PCI values reported by the IAB-MT 1004. The PCI measurement report message 1013 may be the message 1133 described in Figure 11d. Upon reception of the PCI measurement report message 1013, the F1 donor-CU 1003 may use the reported information to detect or predict a potential conflict at the lAB-node and to trigger the PCI change procedure 1010. After the execution of this procedure 1010, the F1 donor-CU 1003 may report the PCI change to other donor-CUs (including the non-F1 donor-CU 1007) with the message 1014, and it may report the PCI change to the core network 1002 with the message 1015. In any case, the PCI configuration report message 1012, and the PCI change report message 1015 shall include the identification of the lAB-node. For instance, these messages may include the information elements F1 -Terminating lAB-donor UE XnAP ID and non-F1 -Terminating lAB-donor UEXnAP ID, both defined at the first MT migration of the lAB-node 601. As specified in TS 38.423 section 9.2.3.16, the NG-RAN node UEXnAP ID uniquely identifies a UE over the Xn interface within the NG-RAN node. Thus, each donor-CU assigns a value to each IAB node in its IAB topology (as the IAB-MT is considered as a UE). The F1 donor-CU 1003 will have assigned the identifier F1 -Terminating lAB-donor UE XnAP ID to the lAB-node when it was admitted in its IAB topology. At MT migration (also called MT handover) the non-F1 donor-CU 1007 will assign the identifier non-F1-Terminating lAB-donor UE XnAP ID to IAB node. Both identifiers are exchanged in handover request / acknowledge messages at the MT migration of the lAB-node. Besides, the PCI change report message 1015 and the PCI change report message 1014 when directed to several donor-CUs may include the identification of the lAB-node. The identifier may be the identifier gNB-DU ID of the active logical DU (IAB-DU 1005 in Figure 10). As specified in TS 38.473 section 9.3.1.19: the gNB-DU ID uniquely identifies the gNB-DU at least within a gNB-CU. Figure 11a is a flowchart 1100 illustrating an example of the procedure to perform the activation of a logical DU and / or cell(s). It is also used to deactivate cell(s). This figure shows: - a RAN Node DU 1101, that may bean lAB-Node DU like IAB-DU 711,761,672, or 1005. - a RAN Node CU 1102, that may be a gNB-CU, or an lAB-Donor-CU like lAB-donor-CU 601 or 1003. The message CONFIGURATION REQUEST 1103 is sent by the RAN Node CU 1102 to the RAN Node DU 1101 either to request the activation of new cell(s) controlled by the RAN Node DU 1101, or to request the activation of a second logical DU, or to request the deactivation of cell(s) controlled by the RAN Node DU 1101. The RAN Node DU 1101 acknowledges the request with the message CONFIGURATION RESPONSE 1104 sent to the RAN Node CU 1102. Figure 11a may correspond to the procedure gNB-CU Configuration Update described in TS 38.473 V17.2.0 section 8.2.5, and the message 1103 may correspond to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10, while the message 1104 may correspond to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.11. The message GNB-CU CONFIGURATION UPDATE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated with the PCI value(s) to be used. The cell(s) to be activated refer to cell(s) controlled by the RAN Node DU 1101 receiving the request. The message GNB-CU CONFIGURATION UPDATE also includes the Information Element (IE) Cells to be Deactivated List to indicate the list cell(s) to be deactivated. The cell(s) to be deactivated refer to cell(s) controlled by the RAN Node DU 1101 receiving the request. A new IE Second DU Activation may be added in the message 1103 in the form of a Boolean to request the activation of a second logical DU. Besides a new IE Target RAN Node CU may be added to identify the RAN Node CU with which a F1 connection shall be setup. The IE Target RAN Node CU may correspond to the Transport Network Layer (TNL) address (i.e. the IP address) or to the Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3. To complete the setup of the new logical DU, the procedure described in Figure 11b may be used. Figure 11 b is a flowchart 1110 illustrating an example of the procedure to setup a logical DU according to an embodiment of the invention. This figure shows: - a RAN Node DU 1111, that may be an lAB-Node DU like IAB-DU 711,761,672, or 1005. - a RAN Node CU 1112, that may an lAB-Donor-CU like lAB-donor-CU 607. The message SETUP REQUEST 1113 is sent by the RAN Node DU 1101 to the RAN Node CU 1102 to request the F1 setup for the logical DU. It may be sent after an activation request as described in the Figure 11a. The RAN Node CU 1112 answers with the message SETUP RESPONSE 1114 sent to the RAN Node DU 1111. The Figure 11b may correspond to the procedure F1 setup described in TS 38.473 V17.2.0 section 8.2.3, and the message 1113 may correspond to the message F1 SETUP REQUEST described in TS 38.473 V17.2.0 section 9.2.1.4, while the message 1114 may correspond to the message F1 SETUP RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.5. The message F1 SETUP RESPONSE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated with the PCI value(s) to be used. The cell(s) to be activated refer to cell(s) controlled by the RAN Node DU 1111 receiving the response. According to one embodiment of the invention, the message 1113 may indicate that the setup request is related to a DU migration and it may include the list of PCI values used by the RAN Node embedding the RAN Node DU 1111. Based on this information, the RAN Node CU 1112 may respond in the message 1114 with a number of cell(s) to activate corresponding to the number of PCI values reported in the message 1113. Also, the RAN Node CU 1112 may assign the new PCI value(s) to be used for the cell(s) to activate in a manner such that the new PCI value(s) does not create a conflict with the reported PCI values. Figure 11 c is a flowchart 1120 illustrating an example of the procedure to remove a logical DU. This figure shows: - a RAN Node DU 1121, that may bean lAB-Node DU like IAB-DU 711,761,672 or 1005. - a RAN Node CU 1122, that may be an lAB-Donor-CU like lAB-donor-CU 601 or 1003. The message REMOVAL REQUEST 1123 is sent by the RAN Node CU 1122 to the RAN Node DU 1121 to request the removal of the logical DU. The RAN Node DU 1121 answers with the message REMOVAL RESPONSE 1114 sent to the RAN Node CU 1122. The Figure 11c may correspond to the procedure F1 removal described in TS 38.473 V17.2.0 section 8.2.8, and the message 1123 may correspond to the message F1 REMOVAL REQUEST described in TS 38.473 V17.2.0 section 9.2.1.16, while the message 1114 may correspond to the message F1 REMOVAL RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.7. Figure 11 d is a flowchart 1130 illustrating an example of the procedure used by a RAN node DU to report detected PCI values to a RAN Node CU according to an embodiment of the invention. This figure shows: - a RAN Node DU 1131, that may be an lAB-Node DU like IAB-DU 711,761,572 or 1005. - a RAN Node CU 1132, that may be an lAB-Donor-CU like lAB-donor-CU 501 or 1003. The message CONFIGURATION UPDATE 1133 is sent by the RAN Node DU 1131 to the RAN Node CU 1132 to report the PCI value(s) detected by the co-located Mobile Termination (MT) in the RAN node embedding the RAN Node DU 1131. The RAN Node CU 1132 may answer with the message CONFIGURATION UPDATE RESPONSE 1134 to acknowledge the message 1133. The message 1133 may be the message GNB-DU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.7, while the message 1134 may be the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.8. According to an embodiment of the invention, a new information element (IE) Cells Detected List may be added in GNB-DU CONFIGURATION UPDATE message to indicate the list of PCI values detected by the MT of the RAN node embedding the RAN Node DU 1131. Figure 12a is a flowchart 1200 illustrating an example of the procedure used by a RAN Node CU to report or to request information related to PCI value(s) to another RAN Node CU according to embodiments of the invention. This figure shows two RAN Node CUs, RAN Node CUa 1201 and RAN Node CUb 1202, that may be lAB-donor-CUs like lAB-donor-CU 501,502, 601,602, or 607. The message CONFIGURATION UPDATE 1203 is sent by the RAN Node CUa 1201 to the RAN Node CUb 1202 to indicate new PCI(s) usage in cell(s) managed by the RAN Node CUa 1201. Thus, the message 1203 may include the information element Cells Activated List to indicate the list of new cell(s) with the PCI(s) used, and another IE Cells Deactivated List to indicate the list of removed cell(s) with the PCI(s) no more used. The message CONFIGURATION UPDATE 1203 may be considered to be a PCI setting message, where this message includes at least one new PCI value to be set at the RAN node. The RAN Node CUb 1202 may answer with the message CONFIGURATION UPDATE RESPONSE 1204 to acknowledge the message 1203. According to one embodiment of the invention, the message 1203 is also used to report the PCI value(s) detected by the Mobile Termination (MT) of a RAN node, where the MT has a RRC connection with the RAN Node CUa 1201 (which is the non-F1 donor CU or RRC terminating donor-CU for the RAN node), and where the co-located Distributed Unit (DU) in the RAN node has a F1 connection with RAN Node CUb 1202. Therefore, the message 1203 may include: An IE non-F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN Node CUa 1201, An IE F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN Node CUb 1202, An IE Cells Detected List to indicate the list of PCI values detected by the MT of the identified RAN node, According to another embodiment of the invention, the message 1203 is also used to report the potential PCI conflict for PCI value(s) used at the Distributed Unit (DU) of a RAN node, where the co-located Mobile Termination (MT) in the RAN node has a RRC connection with the RAN Node CUa 1201 (which is the non-F1 donor CU or RRC terminating donor-CU for the RAN node), and where the DU of the RAN node has a F1 connection with RAN Node CUb 1202. Therefore, the message 1203 may include: An IE non-F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN Node CUa 1201, An IE F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN Node CUb 1202, An IE Conflict Cells List to indicate the list of PCI values with potential PCI conflict at the identified RAN node, An IE New Cells List to indicate the list of PCI values that may be used to replace the PCI values in the Conflict Cells List IE. According to another embodiment of the invention, the message 1203 is also used to request PCI value(s) to be used at the Distributed Unit (DU) of a RAN node, where the co-located Mobile Termination (MT) in the RAN node has a RRC connection with the RAN Node CUb 1202 (which is the non-F1 donor CU for the RAN node), and where the DU of the RAN node has a F1 connection with RAN Node CUa 1202. Therefore, the message 1203 may include: An IE non-F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN NodeCUb 1202, An IE F1 -Terminating UEXnAP ID to identify the RAN node as assigned by the RAN Node CUa 1201, An IE Number Of Cells to indicate a number of requested PCI values to be provided by the RAN Node CUb 1202 and to be used at the identified RAN node, An IE Cells To Set List to indicate the current PCIs used at the cells for which new PCI values are requested. As a response to this request, the message 1204 may include: An IE non-F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN NodeCUb 1202, An IE F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN Node CUa 1201, An IE New Cells List to indicate the list of PCI values that may be used at the cells for which new PCI values were requested in the message 1203, According to another embodiment of the invention, the message 1203 is also used to report PCI value(s) newly set at the Distributed Unit (DU) of a RAN node, where the co-located Mobile Termination (MT) in the RAN node has a RRC connection with the RAN Node CUb 1202 (which is the non-F1 donor CU for the RAN node), and where the DU of the RAN node has a F1 connection with RAN Node CUa 1202. Therefore, the message 1203 may include: An IE non-F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN NodeCUb 1202, An IE F1 -Terminating UE XnAP ID to identify the RAN node as assigned by the RAN Node CUa 1201, An IE Cells Set List to indicate the PCIs newly set at the cells of the identified RAN node. According to one embodiment of the invention, the message 1203 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE described in TS 38.423 V17.2.0 section 9.1.3.4, and which may include the lEs or some of the lEs listed above. The message 1204 may be the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.3.5. According to another embodiment of the invention, the message 1203 corresponds to the message MOBILITY CHANGE REQUEST described in TS 38.423 V17.2.0 section 9.1.3.22, and which may include the lEs or some of the lEs listed above. The message 1204 may be the message MOBILITY CHANGE REQUEST ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.3.23. According to another embodiment of the invention, the message 1203 corresponds to the message ERROR INDICATION described in TS 38.423 V17.2.0 section 9.1.3.12, and which may include the lEs or some of the lEs listed above. Figure 12b is a flowchart 1210 illustrating an example of the procedure used by a RAN Node CU to report new usage of PCI value(s) to the core network. This figure shows: - a RAN NodeCU 1211 that may bean lAB-donor-CU like lAB-donor-CU 501,601, 1003. - the core network (5GC) 1212, like the core network 110, or 1002. The message CONFIGURATION UPDATE 1213 is sent by the RAN Node CU 1211 to the core network 1212 to indicate new PCI(s) usage in cell(s) managed by the RAN Node CU 1211. According to one embodiment of the invention, the message 1213 may correspond to the message UPLINK RAN CONFIGURATION TRANSFER described in TS 38.413 V17.2.0 section 9.2.7.1, which may include a new IE Cells Activated List to indicate the list of new cell(s) with the PCI(s) used, and another new IE Cells Deactivated List to indicate the list of removed cell(s) with the PCI(s) no more used. According to another embodiment of the invention, the message 1213 may include a new IE to indicate the location of a cell, for instance with a list of neighbor cells for a dedicated cell. For instance, this new IE Neighbor Cells List is used to report the new list of neighbor cells for a cell controlled by a mobile IAB node, or a mobile RAN Node DU, when it has moved. Figure 12c is a flowchart 1220 illustrating an example of the procedure used by the core network to indicate a list of PCI value(s) that can be used by a RAN Node CU. This figure shows: - a RAN Node CU 1221 that may be an lAB-donor-CU like lAB-donor-CU 501,601, 1003. - the core network (5GC) 1222, like the core network 110 or 1002. The message CONFIGURATION UPDATE 1213 is sent by the core network 1222 to the RAN Node CU 1221 to indicate new PCI(s) to be used in cell(s) managed by the RAN Node CU 1221. According to one embodiment of the invention, the message 1223 corresponds to the message DOWNLINK RAN CONFIGURATION TRANSFER described in TS 38.413 V17.2.0 section 9.2.7.2, which may include a new IE PCIs List to indicate the list of PCIs that can be used. According to one embodiment of the invention, the message 1223 may include a new IE Cells List, containing a list of cells, and for each cell an IE PCIs List indicates a list of PCIs that can be used for this cell. Figure 12d is a flowchart 1230 illustrating an example of the procedure used by a RAN Node CU to request the migration of a RAN node to another RAN Node CU, according to an embodiment of the invention. This figure shows two RAN Node CUs, RAN Node CUa 1231 and RAN Node CUb 1232, that may be lAB-donor-CUs like lAB-donor-CU 501,502, 601,602, or 607. The message MIGRATION REQUEST 1233 is sent by the RAN Node CUa 1201 to the RAN Node CUb 1202 either to request the Mobile Termination (MT) migration (or handover) of a RAN node, or to request Distributed Unit (DU) migration of a RAN node. The message MIGRATION RESPONSE 1234 is sent by the RAN Node CUb 1202 to the RAN Node CUa 1202 to acknowledge or reject the request. According to one embodiment of the invention, the message 1233 is used to inform the RAN Node CUb 1232 about the PCI values used in the DU of the RAN node to migrate. Thus, the message 1203 may include the information element Cells Activated List to indicate the list of cell(s) with the PCI(s) used in the DU of the RAN node to migrate. The message 1233 may correspond to the HANDOVER REQUEST message described in TS 38.423 V17.2.0 section 9.1.1.1, which may include the new IE Cells Activated List to indicate the list of used PCIs. The message 1234 may be the message HANDOVER REQUEST ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.1.2 in case of positive answer from the RAN Node CUb 1232, or the message HANDOVER PREPARATION FAILURE described in TS 38.423 V17.2.0 section 9.1.1.3 in case of negative answer from the RAN Node CUb 1232. Figure 13 shows a schematic representation of an example communication device (apparatus) or station, in accordance with one or more example embodiments of the present disclosure. The communication device 1300 may preferably be a device such as a micro-computer, a workstation, or a light portable device. The communication device 1300 comprises a communication bus 1313 to which there are preferably connected: - a central processing unit 1311, such as a microprocessor, denoted CPU; - memory for storing data and computer programs containing instructions for the operation of the communication device 1300. The computer programs may contain a number of different program elements (modules) or sub-routines containing instructions for a variety of operations and for implementing the invention. For example, the program elements include an element to implement a BAP entity which as discussed above is for routing data packets to a node in the IAB topology; and - at least one communication interface 1302 for communicating with other devices or nodes in a wireless communication system, such as a wireless communication system 100 according to the release 16 for 5G NR. The at least one communication interface 1302 may be connected to a communication network 1303, such as a radio access network of the system 100, over which digital data packets or frames or control frames are transmitted. The frames are written from a FIFO sending memory in RAM 1312 to the communication interface for transmission or are read from the communication interface for reception and writing into a FIFO receiving memory in RAM 1312 under the control of a software application running in the CPU 1311. Each of a donor-CU, a donor DU and an IAB node may comprise such a communication device 1300. The central processing unit 1311 may be a single processing unit or processor or may comprise two or more processing units or processors carrying out the processing required for the operation of the communication device 1300. The number of processors and the allocation of processing functions to the central processing unit 1311 is a matter of design choice for a skilled person. The memory may include: - a read only memory 1307, denoted ROM, for storing computer programs for implementing the invention; - a random-access memory 1312, denoted RAM, for storing the executable code of methods according to one or more embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to one or more embodiments of the invention. Optionally, the communication device 1300 may also include the following components: - a data storage means 1304 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; - a disk drive 1305 fora disk 1306, the disk drive being adapted to read data from the disk 1306 or to write data onto said disk; - a screen 1309 for displaying decoded data and / or serving as a graphical interface with the user, by means of a keyboard 1310 or any other pointing means. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 1300 or connected to it. The representation of the bus is not limiting and in particular, the central processing unit is operable to communicate instructions to any element of the communication device 1300 directly or by means of another element of the communication device 1300. The disk 1306 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented. The executable code may optionally be stored either in read only memory 1307, on the hard disk 1304 or on a removable digital medium such as for example a disk 1306 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 1303, via the interface 1302, in order to be stored in one of the storage means of the communication device 1300, such as the hard disk 1304, before being executed. The central processing unit 1311 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 1304 or in the read only memory 1307, are transferred into the random-access memory 1312, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention. In a preferred embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). In an example implementation, the communication device (apparatus) is a programmable device / apparatus which uses software to implement the invention. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “central processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC or other logic element). Figure 14a is a flowchart 1400 illustrating an example method for managing at a donor-CU (Central Unit) the provision of information to detect or predict potential PCI collision or confusion according to embodiments of the invention. It may be executed by an lAB-donor-CU like IAB-donor-CU 502 or 1007. At step 1401, the donor-CU receives a measurement report from a RAN node MT (Mobile Termination) comprising a list of PCI values for the neighboring cell(s) detected by the RAN node MT in the vicinity. At step 1402, the donor-CU may determine the potential conflict(s) of PCI value between cell(s) of the RAN node Distributed Unit (DU) and other neighboring cell(s) in the vicinity of the RAN node embedding the DU and the co-located MT that has reported PCI values in step 1401. At step 1403, the donor-CU sends a PCI configuration report to the donor-CU controlling the RAN node DU. The PCI configuration report may include the list of PCI values reported by the RAN node MT at step 1401 and the list of PCI values configured by the donor CU for other cells in the vicinity. The PCI configuration report may indicate to the donor CU controlling the RAN node DU a potential PCI conflict as detected or predicted at step 1402. The PCI configuration report may include a list of PCI value that may be used instead of the PCI value(s) with potential conflict. At step 1404, the donor-CU may receive a PCI change report from the donor-CU controlling the RAN node DU indicating new PCI value(s) assigned to the cell(s) of the RAN node DU. Figure 14b is a flowchart 1410 illustrating an example method for managing at a donor-CU (Central Unit) the change of PCI value at a RAN node Distributed Unit (DU) following the detection or prediction of potential PCI collision or confusion, according to embodiments of the invention. It may be executed by an lAB-donor-CU like lAB-donor-CU 501 or 1003. At step 1411, the donor-CU receives a PCI configuration report from the donor-CU controlling a RAN node Mobile Termination (MT), for which the donor-CU controls the co-located DU in the RAN node. The PCI configuration report may include the list of PCI values reported by the RAN node MT and the list of PCI values configured by the donor CU controlling the RAN node MT for other neighboring cells in the vicinity. The PCI configuration report may indicate a potential PCI conflict between cell(s) of the RAN node DU and other cell(s) in the vicinity of the RAN node embedding the DU and the co-located MT. The PCI configuration report may include a list of PCI values that may be used instead of the PCI value(s) with potential conflict. At step 1412, the donor-CU may determine the potential conflict of PCI value between a cell of the RAN node DU and other cell(s) in the vicinity, by using the information received at step 1411. At step 1413, the donor-CU performs a PCI change procedure for the RAN node in case of detected or predicted PCI conflict. The donor-CU selects a new suitable value to replace each PCI value with potential conflict. At step 1414, the donor-CU may send to the donor-CU controlling the RAN node MT a PCI change report indicating new PCI value(s) assigned to the cell(s) of the RAN node DU. At step 1415, the donor-CU may send to core network (5GC) a PCI change report indicating new PCI value(s) assigned to the cell(s) of the RAN node DU. Figure 15a is a flowchart 1500 illustrating an example method for managing at a RAN node the provision of information to detect or predict potential PCI collision or confusion according to an embodiment of the invention. It may be executed by a RAN node Distributed Unit (DU) like the lAB-node DU 572, 1005. At step 1501, the RAN node DU receives a measurement report from the co-located Mobile Termination (MT) in the RAN node embedding the RAN node DU. The measurement report includes a list of PCI value for the cell(s) detected by the RAN node MT in the vicinity. At step 1502, the RAN node DU sends a PCI measurement report to the donor-CU (Central Unit) controlling the RAN node DU. This PCI measurement report includes the list of PCI value(s) received at step 1501. Figure 15b is a flowchart 1510 illustrating another example method for managing at a donor-CU (Central Unit) the change of PCI value at a RAN node Distributed Unit (DU) following the detection or prediction of potential PCI collision or confusion, according to embodiments of the invention. It may be executed by an lAB-donor-CU like lAB-donor-CU 501 or 1003. At step 1511, the donor-CU receives a PCI measurement report from the RAN node DU controlled by the donor-CU. The PCI measurement report includes a list of PCI values for the neighboring cell(s) detected by the co-located Mobile Termination (MT) in the vicinity of the RAN node embedding the MT and the DU. At step 1512, the donor-CU determines the potential conflict of PCI value(s) between cell(s) of the RAN node DU and other neighboring cell(s) in the vicinity, by using the information received at step 1511. At step 1513, the donor-CU performs a PCI change procedure for the RAN node in case of detected or predicted PCI conflict. The donor-CU selects a new suitable value to replace each PCI value with potential conflict. At step 1514, the donor-CU may send to the donor-CU controlling the RAN node MT a PCI change report indicating new PCI value(s) assigned to the cell(s) of the RAN node DU. At step 1515, the donor-CU may send to core network (5GC) a PCI change report indicating new PCI value(s) assigned to the cell(s) of the RAN node DU. Figure 16 is a simplified flowchart 1600 illustrating an example of steps to set PCI at the DU of an lAB-node during the network integration of the lAB-node, which may be a mobile lAB-node. This figure shows a F1 donor-CU 1603 like the donor-CU 501, a non-F1 donor-CU (or RRC terminating donor-CU) 1607 like the donor-CU 502, and an lAB-node 1608, like the lAB-node 701, comprising an IAB-MT part or unit 1604 and an IAB-DU part or unit 1605. This figure considers the situation where the lAB-node 1608 has been powered on and is integrating the RAN. At the beginning of the flowchart, the lAB-node 1608 has already established a RRC connection with the donor-CU 1607 that has become the non-F1 donor-CU (or RRC terminating donor-CU) for the lAB-node 1608. This situation assumes that the lAB-node 1608 is physically located in the IAB topology controlled by the donor-CU 1607, with the IAB-MT 1604 connected to a parent lAB-node belonging to that topology (for instance with the lAB-node 550 and the backhaul link 5050 in the figure 5). As a consequence, the IAB-MT 1604 regularly sends a measurement report 1611 to the non-F1 donor-CU 1607, providing information related to the cells detected in the vicinity of the lAB-node 1608, and including the PCIs of these neighboring cells. To complete its network integration, the lAB-node 1608 has to establish a F1 connection with a donor-CU, which may be different from the non-F1 donor-CU 1607. Indeed, there may be a limited number of lAB-donor-CUs that support mobile lAB-nodesas F1 terminating lAB-donor-CUs, and the lAB-node 1608 may be pre-configured to select the donor-CU 1603 as the F1 donor-CU to connect to at power on. The F1 setup procedure is initiated at step 1610wherethe IAB-DU 1605 sends a F1 setup request message (not represented on figure 16) to the F1 donor-CU 1603, which may include an identifier of the non-F1 donor-CU 1607 as well as an identifier assigned by the non-F1 donor-CU 1607 for the IAB-MT 1604. The identifier of the non-F1 donor-CU 1607 may be the Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3. The identifier for the IAB-MT 1604 may be a NG-RAN node UE XnAP ID specified in TS 38.423 section 9.2.3.16 (then the identifier refers to as non-F1 terminating UE XnAP ID). These identifiers may have been previously provided by the non-F1 donor-CU 1607 to the lAB-node 1608 through a RRC message (for instance with the RRCReconfiguration message specified in TS 38.331). Upon reception of the F1 setup request from the IAB-DU 1605, the F1 donor-CU may send the PCI request message 1612 to the non-F1 donor-CU 1607 to request PCI(s) to use at the IAB-DU 1605. Indeed, the lAB-node 1608 is physically located in the IAB topology controlled by the non-F1 donor-CU 1607, thus the non-F1 donor-CU 1607 knows the PCIs already used by the IAB-nodes belonging to that topology (i.e. with a DU controlled by the non-F1 donor-CU 1607). Moreover, the non-F1 donor-CU 1607 can obtain the PCIs used in adjacent IAB topologies or in adjacent legacy cells (using for instance the standardized procedure NG-RAN NODE CONFIGURATION UPDATE specified in TS 38.423). Besides, the non-F1 donor-CU 1607 can obtain the PCIs used in any mobile lAB-node in operation and currently crossing its IAB topology (as explained with the figures 16, 17, 18). Finally, by receiving the measurement reports from the IAB-MT 1604 (with messages like the message 1611), the non-F1 donor-CU 1607 accurately knows in which part of its IAB topology the lAB-node 1608 is located. Thus, the non-F1 donor-CU 1607 appears to be the most appropriate CU to select one or several suitable PCIs to use at the IAB-DU 1605 (i.e. PCIs that will not be in conflict with other PCIs used in the cells in the vicinity of the lAB-node 1608). In the PCI request message 1612, the F1 donor-CU 1603 may request several PCIs as the IAB-DU 1605 may have to control several cells. The number of cells at the IAB-DU 1605 may be pre-configured, and it may depend on the type of antenna used at the IAB-DU 1605. For instance, with a 3-sector antenna with a coverage of 120 degree per sector, the IAB-DU 1605 may handle 3 cells and thus will use 3 PCIs. The number of cells to be activated at the IAB-DU 1605 may be included in the F1 setup request sent by the IAB-DU 1605 to the F1 donor-CU 1603 and in the PCI request message 1612. In the PCI request message 1612, the F1 donor-CU 1603 may also include the non-F1 terminating UE XnAP ID identifying the IAB-MT 1604 at the non-F1 donor-CU 1607. Besides, the F1 donor-CU 1603 may also generate a UE XnAP ID for the IAB-MT 1604 (then the identifier refers to as F1 terminating UE XnAP ID), which would also be included in the PCI request message 1612. The PCIs to be used by the IAB-DU 1605 may be selected by the non-F1 donor-CU 1607 at step 1620. The selection may be based on a list of available PCIs provided by the Operations Administration and Maintenance (OAM) system, and the selected PCIs should avoid potential PCI conflict with PCIs used in the vicinity of the lAB-node 1608. In response to the PCI request message 1612, the non-F1 donor-CU 1607 sends the PCI response message 1613 to the F1 donor-CU 1603 providing PCI(s) to be used at the IAB-DU 1605. The PCI response message 1613 is an example of a PCI setting message, as this message includes at least one new PCI value to be set at the RAN node, i.e. lAB-node 1608. Then at step 1630, the F1 donor-CU 1603 can complete the F1 setup procedure with the IAB-DU 1605 by sending a F1 setup response (message not represented at the figure 16) to the IAB-DU 1605. Then, the IAB-DU 1605 can activate the necessary cell(s) by applying the PCI(s) provided by the F1 donor-CU 1603 in the F1 setup response message. Finally, the F1 donor-CU 1603 may send the PCI set report message 1614 to the non-F1 donor-CU 1607 to confirm the new PCI setting at the lAB-node 1608. The non-F1 donor-CU 1607 may acknowledge the reception of the message 1614 with a PCI set acknowledge message (not represented in the figure 16). The messages PCI request 1612 and PCI response 1613 may be a newXnAP procedure, or they may respectively correspond to the messages 1203 and 1204 in the figure 12a (e.g. messages NG-RAN NODE CONFIGURATION UPDATE and NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0). The message PCI set report 1614 may be a newXnAP procedure, or it may correspond to the message 1203 in the figure 12a (e.g. message NG-RAN NODE CONFIGURATION UPDATE). Later, while the lAB-node 1608 is moving, the IAB-MT 1604 may have to be handed over toward a cell controlled by a parent lAB-node belonging to another lAB-donor-CU. In that case, the non-F1 donor-CU 1607 becomes the source non-F1 donor-CU for the MT handover (or migration), and this CU will send a handover request to the target non-F1 donor-CU. To maintain the knowledge of PCI(s) at the IAB-DU 1605 of the lAB-node 1608, the F1 donor-CU 1603 will indicate the list of PCI(s) used at the IAB-DU 1605 in the handover request message sent to the target non-F1 donor-CU. This message is described at the figure 12d with the message 1233. Figure 17 is a simplified flowchart 1700 illustrating an example of steps to change PCI at the DU of an lAB-node, which may be a mobile lAB-node, following the detection or prediction of potential PCI conflict. This figure shows a F1 donor-CU 1703 like the donor-CU 501, a non-F1 donor-CU (or RRC terminating donor-CU) 1707 like the donor-CU 502, a UE 1701 like the UE 580, and an lAB-node 1708, like the lAB-node 701, comprising an IAB-MT part or unit 1704 and an IAB-DU part or unit 1705. This figure considers the situation where the lAB-node 1708 has established a RRC connection with the donor-CU 1707 that has become the non-F1 donor-CU (or RRC terminating donor-CU) for the lAB-node 1708. This situation assumes that the lAB-node 1708 is physically located in the IAB topology controlled by the donor-CU 1707, with the IAB-MT 1704 connected to a parent lAB-node belonging to that topology (for instance with the lAB-node 550 and the backhaul link 5050 in the figure 5). As a consequence, the IAB-MT 1704 regularly sends measurement report 1711 to the non-F1 donor-CU 1707, providing information related to the cells detected in the vicinity of the lAB-node 1708, and including PCIs of these neighbouring cells. Besides, the lAB-node 1708 has established a F1 connection with the donor-CU 1703 that has become the F1 donor-CU for the lAB-node 1708, and which may be different from the non-F1 donor-CU 1707. The lAB-node 1708 may serve UEs (such as the UE 1701) that regularly send a measurement report 1712 to the F1 donor-CU 1703, providing information related to the cells detected in the vicinity of the lAB-node 1708, and including PCIs of these neighbouring cells. However, these measurement reports may not be sufficient to allow the F1 donor-CU 1703 to detect PCI conflict(s) for cell(s) used at the IAB-DU 1705. Firstly, the lAB-node 1708 may not serve UEs during some time, and secondly, as the PCI conflict is already present when it is reported, a UE may experience some difficulties to maintain the connection with the lAB-node 1708. Another consequence is that the F1 donor-CU 1703 may not accurately know the location of the lAB-node 1708 in the IAB topology controlled by the non-F1 donor-CU 1707. Thus, the F1 donor-CU 1703 may not be able to predict PCI conflict(s) for cell(s) used at the IAB-DU 1705. It can also be noted that for PCI conflict prediction, the F1 donor-CU 1703 would have to obtain the PCIs used in the IAB topology controlled by the non-F1 donor-CU 1703, the PCIs used in adjacent IAB topologies and in adjacent legacy cells, and the PCIs used in other mobile lAB-nodes in operation and currently crossing the IAB topology controlled by the non-F1 donor-CU 1707. This would require a lot of protocol messages, for instance using the standardized procedure NG-RAN NODE CONFIGURATION UPDATE specified in TS 38.423. Then, the F1 donor-CU 1703 would have to maintain and to analyze this amount of information for each mobile lAB-node controlled by the F1 donor-CU 1703 and located in an IAB topology controlled by a different non-F1 donor-CU. This may consume a large amount of processing resources at the F1 donor-CU. As the lAB-node 1708 is physically located in the IAB topology controlled by the non-F1 donor-CU 1707, the non-F1 donor-CU 1707 knows the PCIs already used by the lAB-nodes belonging to that topology (i.e. with a DU controlled by the non-F1 donor-CU 1707). Moreover, the non-F1 donor-CU 1707 can obtain the PCIs used in adjacent IAB topologies or in adjacent legacy cells (using for instance the standardized procedure NG-RAN NODE CONFIGURATION UPDATE specified in TS 38.423). Besides, the non-F1 donor-CU 1707 can obtain the PCIs used in any mobile lAB-node in operation and currently crossing its IAB topology (as explained with the figures 16, 17, 18). Finally, by receiving the measurement reports from the IAB-MT 1704 (with messages like the message 1711), the non-F1 donor-CU 1707 accurately knows in which part of its IAB topology the lAB-node 1708 is located. Thus, the non-F1 donor-CU 1707 appears to be the most appropriate CU to detect or to predict PCI conflict(s) in its IAB topology, in particular for cell(s) used at the IAB-DU 1705, and to select one or several suitable PCIs as replacement (i.e. PCIs that will not be in conflict with other PCIs used in the cells in the vicinity of the lAB-node 1708). When a situation with PCI conflict(s) at the IAB-DU 1705 is detected or predicted by the nonFI donor-CU 1707, this donor-CU may select new PCI(s) to replace the one(s) with PCI conflict (step 1710 for PCI selection). Then, the non-F1 donor-CU 1707 sends the PCI change request message 1713 to the F1 donor-CU 1703 providing PCI(s) to be replaced and new PCI(s) to be used at the IAB-DU 1705. The F1 donor-CU 1703 may acknowledge the PCI change request message 1713 with the message 1714 (PCI change acknowledge). The PCI change request message 1713 is an example of a PCI setting message, as this message includes at least one new PCI value to be set at the RAN node, i.e. lAB-node 1708. Then at step 1720, the F1 donor-CU 1703 applies a PCI change procedure, for instance the one described with the figure 8. Finally, the F1 donor-CU 1703 may send the PCI set report message 1715 to the non-F1 donor-CU 1707 to confirm the new PCI setting at the lAB-node 1708. The non-F1 donor-CU 1707 may acknowledge the reception of the message 1715 with a PCI set acknowledge message (not represented in the figure 17). The messages PCI change request 1713 and PCI change acknowledge 1714 may be a new XnAP procedure, or they may respectively correspond to the messages 1203 and 1204 in the figure 12a (e.g. messages NG-RAN NODE CONFIGURATION UPDATE and NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0). The message PCI set report 1715 may be a new XnAP procedure, or it may correspond to the message 1203 in the figure 12a (e.g. message NG-RAN NODE CONFIGURATION UPDATE). In case the PCI conflict detected or predicted concerns two mobile cells from two mobile lAB-nodes with two different F1 donor-CUs, the non-F1 donor-CU 1707 (common to both mobile lAB-nodes) will select new PCI(s) at step 1710 for only one mobile lAB-node, and it will send a PCI change request message 1713 to the corresponding F1 donor-CU. This avoids changing PCI(s) at both mobile lAB-nodes. Figure 18 is a simplified flowchart 1800 illustrating an example of steps to change PCI at the DU of an lAB-node, which may be a mobile lAB-node, during the DU migration of the IAB node. This figure shows a UE 1801 like the UE 680, and an lAB-node 1808, like the lAB-node 751, comprising an IAB-MT part or unit 1804, a first IAB-DU1 part or unit 1805, and a second IAB-DU2 part or unit 1806. a source F1 donor-CU 1803 like the donor-CU 601, a non-F1 donor-CU (or RRC terminating donor-CU) 1807 like the donor-CU 602, and a target F1 donor-CU 1809 like the donor-CU 603. This figure considers the situation where the lAB-node 1808 has established a RRC connection with the donor-CU 1807 that has become the non-F1 donor-CU (or RRC terminating donor-CU) for the lAB-node 1808. This situation assumes that the lAB-node 1808 is physically located in the IAB topology controlled by the donor-CU 1807, with the IAB-MT 1804 connected to a parent lAB-node belonging to that topology (for instance with the lAB-node 650 and the backhaul link6050 in the figure 6). As a consequence, the IAB-MT 1804 regularly sends measurement report 1811 to the non-F1 donor-CU 1807, providing information related to the cells detected in the vicinity of the lAB-node 1808, and including PCIs of these neighbouring cells. Besides, the lAB-node 1808 has established a F1 connection with the donor-CU 1803 that became the F1 donor-CU for the lAB-node 1808, and which may be different from the non-F1 donor-CU 1807. At this stage only the first logical DU IAB-DU1 1805 is active (and the second logical IAB-DU2 1806 is inactive). The lAB-node 1808 may serve UEs (such as the UE 1801) that regularly send a measurement report 1812 to the F1 donor-CU 1803, providing information related to the cells detected in the vicinity of the lAB-node 1808, and including PCIs of these neighbouring cells. However, as described with the figure 17, these measurement reports may not be sufficient to allow the F1 donor-CU 1803 to detect PCI conflict(s) forcell(s) used at the IAB-DU1 1805, and the F1 donor-CU 1803 may not be able to predict PCI conflict(s) as well. Also, as explained at the figures 16 and 17, the non-F1 donor-CU 1807 appears to be the most appropriate CU to detect or to predict PCI conflict(s) in its IAB topology, in particular for cell(s) used at the IAB-DU1 1805, and to select one or several suitable PCIs as replacement (i.e. PCIs that will not be in conflict with other PCIs used in the cells in the vicinity of the lAB-node 1808). The figure 18 also assumes that the F1 donor-CU 1803 has decided to perform a DU migration of the lAB-node 1808, meaning that the F1 donor-CU 1803 becomes the source F1 donor-CU for the DU migration, the second logical DU IAB-DU2 1806 will be activated to establish a F1 connection with a target F1 donor-CU, the UEs served by the lAB-node 1808 will be handed over from the first (or source) logical DU IAB-DU1 1805 to the second (or target) logical DU IAB-DU2 1806, and that finally the first logical DU IAB-DU1 1805 will be deactivated. In the example of the figure 18, the target F1 donor-CU for the DU migration is the donor-CU 1809. The DU migration involves that new cells are activated at the second logical DU IAB-DU2 1806, with the same number of cells as the number of active cells at the first logical DU IAB-DU1 1805. The coverage of each activated cell should have the same coverage as a cell at the first logical DU IAB-DU1 1805. The PCI of each activated should be selected so as to avoid PCI collision with other cell(s) in the neighbourhood of the lAB-node 1808, which may include the active cell(s) at the first logical DU IAB-DU1 1805. As previously explained, the non-F1 donor-CU 1807 is the most appropriate CU to select the suitable PCI(s) to be used at the second logical DU IAB-DU2 1806. When the source F1 donor-CU 1803 launches the DU migration with the F1 setup preparation (step 1810), the F1 donor-CU 1803 sends a F1 setup triggering message to the lAB-node 1808, which will activate the second logical DU IAB-DU2 1806, and send, in turn, a F1 setup request message to the target F1 donor-CU 1809. The F1 setup request message (not represented in the figure 18), may include an identifier of the non-F1 donor-CU 1807, an identifier of the lAB-node 1808 known at this CU, the number of cells to be activated at the IAB-DU2 1806 and the list of PCIs used at the IAB-DU1 1805. Upon reception of this F1 setup request, the target F1 donor-CU 1809 may send a PCI request message 1813 to the non-F1 donor-CU 1807 to request PCI(s) to be used at the IAB-DU2 1806. In the PCI request message 1813, the target F1 donor-CU 1809 may also include the nonFI terminating UEXnAP ID identifying the IAB-MT 1804 at the non-F1 donor-CU 1807. Besides, target the F1 donor-CU 1809 may also generate a UE XnAP ID for the IAB-MT 1804 (then the identifier refers to as F1 terminating UE XnAP ID), which would also be included in the PCI request message 1813. The PCIs to be used by the IAB-DU 1806 may be selected by the non-F1 donor-CU 1807 at step 1820. The selection may be based on a list of available PCIs provided by the Operations Administration and Maintenance (OAM) system, and the selected PCIs should avoid potential PCI conflict with PCIs used in the vicinity of the lAB-node 1808 (including the active cell(s) at the IAB-DU1 1805). In response to the PCI request message 1813, the non-F1 donor-CU 1807 sends the PCI response message 1814 to the target F1 donor-CU 1809 providing PCI(s) to be used at the IAB-DU2 1806. The PCI response message 1814 is an example of a PCI setting message, as this message includes at least one new PCI value to be set at the RAN node, i.e. lAB-node 1808. Then at step 1830, the target F1 donor-CU 1809 can complete the F1 setup procedure with the IAB-DU2 1806 by sending a F1 setup response (message not represented at the figure 18) to the IAB-DU2 1806. Then, the IAB-DU2 1806 can activate the necessary cell(s) by applying the PCI(s) provided by the target F1 donor-CU 1809 in the F1 setup response message. In the step 1830, the lAB-node 1808 may inform the source F1 donor-CU 1803 about the completion of the new F1 setup along with the PCI(s) used for the cell(s) activated at the IAB-DU2 1806. After executing the handover of UEs served by the lAB-node 1808 from the cell(s) at the IAB-DU1 1805 to the cell(s) at the IAB-DU2 1806, the source F1 donor-CU 1803 may deactivate the IAB-DU1 1805 (and thus deactivated the cell(s) at this DU). In the meantime, the target F1 donor-CU 1809 may send the PCI set report message 1814 to the non-F1 donor-CU 1807 to confirm the new PCI setting at the lAB-node 1808. The non-F1 donor-CU 1807 may acknowledge the reception of the message 1814 with a PCI set acknowledge message (not represented in the figure 18). The messages PCI request 1813 and PCI response 1814 may be a newXnAP procedure, or they may respectively correspond to the messages 1203 and 1204 in the figure 12a (e.g. messages NG-RAN NODE CONFIGURATION UPDATE and NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0). The message PCI set report 1815 may be a newXnAP procedure, or it may correspond to the message 1203 in the figure 12a (e.g. message NG-RAN NODE CONFIGURATION UPDATE). In other words and as a summary about PCI conflict detection / prediction, the MT of a mobile lAB-node (mlAB-MT) can be served by a non-F1 donor-CU (or RRC terminating donor-CU) different from the F1 donor-CU (or F1 terminating donor-CU) serving the DU (mlAB-DU). Besides, to avoid PCI collision, this is the F1 donor-CU that can reconfigure the PCI fora cell of the mlAB-DU: once a PCI collision is detected or predicted, the F1 donor-CU has to set a new suitable PCI at the mlAB-DU with an appropriate PCI change procedure. There are still some open issues, especially: howto avoid PCI collision in the scenario with Xn between mlAB-DU’s donor and mlAB-MT’s donor, and whether PCI collision between mobile IAB cells can be predicted based on existing UE measurement report. When the F1 donor-CU of a mobile lAB-node is different from the non-F1 donor-CU (or RRC terminating donor-CU), the F1 donor-CU may be able to receive the necessary information to detect a PCI conflict (i.e. collision or confusion). Indeed, the F1 donor-CU can request to the nonFI donor-CU and to other CUs around the non-F1 donor-CU, the information related to the cells served by these CUs. In other words, the F1 donor-CU can request the RRC terminating donor-CU and other CUs to provide information related to the cells served by these CUs. Moreover, when the mobile lAB-node serves UEs, the F1 donor-CU receives the measurement reports from these UEs. However, this may not be sufficient to detect a PCI conflict. First, the F1 donor-CU may not have an accurate knowledge of the IAB topology controlled by the non-F1 donor-CU (or RRC terminating donor-CU) (e.g. which cells are adjacent to each other). Besides, when the mobile lAB-node does not serve UEs (for instance an empty bus or train), the F1 donor-CU does not receive any measurement report. Last but not least, in case another mobile cell from another mobile lAB-node controlled by a different F1 donor-CU is present in the IAB topology controlled by the non-F1 donor-CU (or RRC terminating donor-CU), the F1 donor-CU may detect a PCI conflict between two mobile cells (i.e. between the two mobile lAB-nodes) from UE measurement reports (at the condition there are UEs able to send measurement report(s) despite the PCI conflict), but the F1 donor-CU has no clue to predict a PCI conflict. Thus, it can be observed that a F1 (terminating) donor-CU of a mobile lAB-node may be able to detect PCI conflict between mobile cells from UE measurement reports, but the F1 (terminating) donor-CU cannot predict this PCI conflict. To predict a PCI conflict (e.g. between two mobile lAB-nodes), the F1 donor-CU requires (additional) information, which may be provided by the non-F1 donor-CU I RRC terminating donor CU (or by the RRC terminating donor CU and by the F1 terminating donor-CU of the other mobile lAB-node). However, when a F1 terminating donor-CU served several mobile lAB-nodes with their MT migrated in different IAB topologies, the amount of information to be collected and to be processed by the F1 donor-CU may increase drastically. Also, we have to consider the case where two F1 donor-CUs decide and apply PCI change at the same time for two mobile cells with PCI conflict. This may lead to another conflict after the PCI change at both mobile lAB-nodes. Thus, the case where both F1 donor-CUs decide to change the PCI fortheir respective mobile cell at the same time has also to be considered. On the other hand, the RRC terminating donor-CU of a mobile lAB-node can have an accurate knowledge of the environment of the mobile lAB-node, it receives the measurement report from the mlAB-MT, and it controls the mlAB-MT handover. The PCI(s) used at a mobile lAB-node can be provided to the RRC terminating donor-CU by the F1 terminating donor-CU. Also at MT migration, the PCI(s) used at the mobile lAB-node can be provided to the target RRC terminating donor-CU by the source RRC terminating donor-CU. As a consequence, the non-F1 donor-CU I RRC terminating donor-CU of a mobile lAB-node appears as the most appropriate CU to analyse the situation, to predict a PCI conflict, and to request a F1 donor-CU to change a PCI when necessary. Indeed, the non-F1 donor-CU of a mobile lAB-node has the accurate knowledge of the environment, it also receives the measurement report from the mlAB-MT, and it controls the mlAB-MT handover. Actually, the information that is missing at the non-F1 donor-CU is the PCI(s) used at the mobile lAB-node. Thus, it can be observed that the non-F1 donor-CU I RRC terminating donor-CU of a mobile lAB-node is able to detect and to predict a PCI conflict (collision / confusion) with a cell at the mobile lAB-node as soon as this CU knows the PCI(s) used for the mobile lAB-node’s cell(s). Then, the RRC terminating donor-CU of a mobile lAB-node can detect and predict a PCI conflict (collision / confusion) at a cell of the mobile lAB-node. To provide the used PCI(s) at a mobile lAB-node to the non-F1 donor-CU, it is proposed that at MT handover of the mobile lAB-node, the source non-F1 donor-CU informs the target non-F1 donor-CU, e.g. with the handover request. When the non-F1 donor-CU of a mobile lAB-node is different from the F1 donor-CU, the nonFI donor-CU of a mobile lAB-node is informed about the PCI(s) used at the mobile lAB-node at the MT handover request. This also applies to consecutive MT handovers. About PCI conflict avoidance, there are different situations to consider for a mobile lAB-node: at network integration, at DU migration, and during normal operation (including after MT handover). Thus, assuming the RRC terminating donor-CU of a mobile lAB-node can detect and predict a PCI conflict at a cell of the mobile lAB-node, there are different situations to consider for PCI conflict avoidance: at network integration, at DU migration, and during normal operation of the mobile lAB-node. At network integration: When the mlAB MT and the co-located mlAB-DU integrate to different donor-CUs, the mobile lAB-node is physically in the IAB topology controlled by the non-F1 donor-CU I RRC terminating donor-CU (which may not know which donor-CU is the F1 donor-CU). It should be up to the F1 donor-CU to request the non-F1 donor-CU to provide the PCI(s) to set at the mlAB-DU. Then, the F1 terminating donor-CU may request the RRC terminating donor-CU to provide suitable PCI(s) to set at the mlAB-DU. This handshake procedure should be executed to be able to complete the F1 setup procedure between the F1 donor-CU and the mlAB-DU. At DU migration: New PCI(s) may need to be set for the cell(s) at the target logical DU of the mobile lAB-node. The target F1 donor-CU of the DU migration should request the non-F1 donor-CU to provide the PCI(s) to set at the target logical DU. This handshake procedure should be executed to be able to complete the F1 setup procedure between the target F1 donor-CU and the target logical DU. This handshake procedure may be the same as the one used for the case of network integration. In other words, the target F1 terminating donor-CU of the DU migration may have to set new PCI(s) for the cell(s) at the target logical mlAB-DU. Then, the target F1 terminating donor-CU may request the RRC terminating donor-CU to provide suitable PCI(s) to set at the target logical mlAB-DU. This procedure may be the same as the one used for network integration. During normal operation: When the non-F1 donor-CU detects or predicts a PCI conflict (collision / confusion) at a mobile lAB-node, the non-F1 donor-CU should request the F1 donor-CU to change the PCI(s) used at the mlAB-DU, and the non-F1 donor-CU should provide the new PCI(s) to set. After executing the PCI change procedure, the F1 donor-CU should inform the result to the non-F1 donor-CU. In other words, when the RRC terminating donor-CU detects or predicts a PCI conflict (collision / confusion) at a mobile lAB-node, the RRC terminating donor-CU may request the F1 terminating donor-CU to change the PCI(s) used at the mlAB-DU including the transmission of suitable PCI(s) to set. After executing the PCI change procedure, the F1 terminating donor-CU may inform the outcome to the RRC terminating donor-CU. In case the conflict concerns two mobile cells from two mobile lAB-nodes connected to two different F1 donor-CUs, the RRC terminating donor-CU (common to both mobile lAB-nodes) should request a PCI change to only one of the F1 donor-CUs. In case the conflict concerns two mobile cells from two mobile lAB-nodes with two different F1 donor-CUs, the non-F1 donor-CU I RRC terminating donor-CU (common to both mobile lAB-nodes) should request PCI change to only one F1 donor-CU, i.e. it should request a PCI change to only one of the F1 donor-CUs. Thus, it is proposed that: A XnAP procedure is used between the F1 donor-CU and the non-F1 donor-CU of a mobile lAB-node to allow the F1 donor-CU to request new PCI(s) to set for cell(s) at the mobile lAB-node. In other words, a XnAP procedure may be used between the F1 terminating donor-CU and the RRC terminating donor-CU of a mobile lAB-node to allow the F1 terminating donor-CU to request new PCI value(s) to set at mlAB-DU’s cell(s). A XnAP procedure is used between the F1 donor-CU and the non-F1 donor-CU of a mobile lAB-node to allow the non-F1 donor-CU to request the F1 donor-CU to set new PCI(s) for cell(s) at the mobile lAB-node. In otherwords, a XnAP procedure may be used between the F1 terminating donor-CU and the RRC terminating donor-CU of a mobile lAB-node to allow the RRC terminating donor-CU to request the F1 terminating donor-CU to set new PCI value(s) at mlAB-DU’s cell(s). A XnAP procedure is used between the F1 donor-CU and the non-F1 donor-CU / RRC terminating donor-CU of a mobile lAB-node to allow the F1 donor-CU to inform the nonFI donor-CU / RRC terminating donor-CU about the result of a PCI change procedure. While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. Byway of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiberoptic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiberoptic cable, twisted pair, DSL, orwireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

28 07 251. A method of avoiding a Physical Cell Identity, PCI, conflict at a radio access network, RAN, node of a wireless network, the RAN node comprising a Distributed Unit, 5 DU, managed by a first RAN node Central Unit, CU, and a Mobile Termination, MT,managed by a second RAN node CU, the method, at the second RAN node CU, comprising the step of:sending, to the first RAN node CU, a PCI setting message indicating a new PCI value to set at the RAN node.

102. A method according to claim 1, wherein the PCI setting message is a PCI change request to the first RAN node CU indicating the new PCI value to set at the RAN node.

3. A method according to claim 1, wherein the PCI setting message is a PCI response 15 sent in response to a PCI request, received from the first RAN node CU, requesting a newPCI value to set at the RAN node.

4. A method according to claim 3, wherein the PCI request includes a current PCI value set at the RAN node and wherein the new PCI value is different from the current PCI 20 value.

5. A method according to claim 1, wherein the new PCI value does not conflict with a PCI value of a cell controlled by the RAN node.25 6. A method according to claim 1, wherein the method further comprises, after thestep of sending a PCI setting message to the first RAN node CU indicating the new PCI value to set at the RAN node:receiving, at the second RAN node CU, a PCI set report from the first RAN node CU indicating that the new PCI value has been set at the RAN node.

307. An apparatus for a radio access network, RAN, node Central Unit, CU, node of a wireless network, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 1 to 6.

358. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 7.

9. A computer-readable medium carrying a computer program according to claim 8.28 07 25

Images