A communication method, apparatus, and system

Abstract

Embodiments of the present application provide a communication method, device and system, relating to the technical field of communication, which is applied to an integrated access and backhaul network, a second CU and a first MT of a first IAB node exist a radio resource control connection, the method comprises: after a first DU of the first IAB node is migrated from a first CU to a third CU, the third CU receives a first message; the third CU, according to the first message, exempts from carrying out transmission migration management negotiation with the second CU about the first IAB node. Based on the scheme, the related process of the third CU initiating IAB transmission migration management to the second CU in the process that the UE served by the first IAB node is switched from the first CU to the third CU along with the first DU can be reasonably avoided, so that the signaling overhead of Xn interface and F1 interface can be saved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication method, apparatus, and system. Background Technology

[0002] The fifth-generation mobile communication technology (5G) introduces integrated access and backhaul (IAB) technology. The access link and backhaul link of IAB nodes (also known as relay nodes) can both adopt wireless transmission schemes to provide wireless access services for user equipment (UE).

[0003] During the process of an IAB node providing radio access services to a UE, the IAB node typically switches to the IAB host base station providing access and backhaul services based on factors such as network coverage or load balancing. This handover process generates a large amount of signaling interaction within the IAB network, resulting in significant signaling overhead.

[0004] Therefore, how to reduce the signaling data generated by IAB nodes switching IAB host base stations, so as to reduce the signaling overhead of the overall IAB network, is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a communication method, apparatus, and system that, by transmitting a first message generated in the integrated IAB network backhaul, enables the third centralized unit (CU) of the third IAB host and / or the first CU of the first IAB host to avoid negotiating the transmission migration management of the first IAB node with the second CU of the second IAB host, thereby saving the signaling overhead caused in the negotiation process.

[0006] In a first aspect, a communication method is provided, which is applied to an integrated access backhaul (IAB) network, wherein a second CU and a first mobile terminal (MT) of a first IAB node have a radio resource control (RRC) connection. The method includes: after the first distributed unit (DU) of the first IAB node migrates from the first CU to a third CU, the third CU receives a first message; based on the first message, the third CU is exempt from negotiating the transmission migration management of the first IAB node with the second CU.

[0007] It should be understood that since the first CU mentioned above is the CU of the source IAB host node of the first IAB node, and the first DU of the first IAB node and each IAB host CU are connected through the F1 interface, the first CU can be called the source F1 endpoint CU; similarly, since the third CU mentioned above is the CU of the target IAB host node of the first IAB node, the third CU can be called the target F1 endpoint CU; in addition, the first MT of the first IAB node is connected to the second CU, and the second CU will maintain the RRC connection for the first MT, so the second CU can be called the RRC endpoint CU.

[0008] For example, the second CU and the first CU mentioned above can be the same CU, that is, the RRC endpoint CU of the first IAB node can also be the source F1 endpoint CU of the first IAB node; or, the second CU and the third CU mentioned above can be the same CU, that is, the RRC endpoint CU of the first IAB node can also be the target F1 endpoint CU of the first IAB node.

[0009] For example, during the handover process of a UE served by the first IAB node following the first DU, if the third CU does not need to initiate a service negotiation process with the second CU of the IAB node for the UE's services, then the third CU needs to be aware of this.

[0010] For example, after receiving the first message, the third CU decides not to negotiate the transmission migration management of the first IAB node with the second CU. Services between the third CU and the first IAB node continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0011] For example, the aforementioned first message can be included in a notification message exchanged between the RRC endpoint CU (second CU) of the first IAB node and the target F1 endpoint CU (third CU) in the form of an explicit information element (IE), or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned first message can be used directly to indicate that the third CU does not need to negotiate with the second CU of the first IAB node regarding the transmission migration management of the first IAB node, or it can be used to indicate that the aforementioned first MT does not need to switch the RRC endpoint CU (i.e., the second CU), or it can be used to indicate that the radio backhaul link path of the service of the aforementioned first DU remains unchanged.

[0012] For example, the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU after the first CU gives the corresponding instruction, or the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU based on the operation administration and maintenance (OAM) configuration (which may also be pre-configured).

[0013] For example, after the third CU receives the first message, the third CU sends a first feedback message to the second CU, which indicates that the third CU has successfully received the first message from the second CU.

[0014] Based on the above technical solution, it is possible to reasonably avoid the situation where the third CU initiates the relevant IAB transport migration management process (such as the IAB transport migration management process, which is used to request the relevant configuration of the radio backhaul link for the services of the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, the third CU sends a third message to the second CU, the third message indicating that the third CU has established a connection with the first IAB node through the third F1 interface, and the third message carries the first MT identifier.

[0016] For example, before the third CU sends the third message to the second CU, the third CU receives a first request message (e.g., an F1 setup request message) from the first IAB node. This first request message is used to establish an F1 interface between the first IAB node and the third CU. Subsequently, the third CU can send a response message (e.g., an F1 setup response message) to the first IAB node, thus establishing an F1 interface with the first IAB node.

[0017] For example, the aforementioned third F1 interface includes the third control plane F1-C interface and the third user plane F1-U interface.

[0018] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is the third CU, so as to ensure that the second CU can conduct accurate signaling interaction with the third CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the third CU belongs to, so as to send the above first message to the third CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, before establishing a connection between the third CU and the first DU, the third CU receives a second message from the first IAB node. The second message is used to instruct the first IAB node to request to establish an F1 interface with the third CU. The second message carries a first MT identifier and a second CU identifier. The first MT identifier includes at least one of the following: the backhaul adaptation protocol (BAP) address assigned by the second CU to the first MT, and the user equipment UEXn application protocol (AP) identifier assigned by the second CU to the first MT. The second CU identifier includes at least one of the following: the IP address of the second CU, and the gNB identifier of the base station where the second CU is located.

[0020] Based on the above technical solution, the third CU, which is the target F1 endpoint CU of the first IAB node, can know that the first DU of the first IAB node was previously connected to the second CU. Furthermore, the first MT of the first IAB node is connected to the second CU.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the first message includes the identifier of the first IAB node. After the first DU migrates from the first CU to the third CU, the third CU, based on the first message, is exempt from transmission migration management negotiation regarding all services transmitted by the first IAB node.

[0022] For example, all services that the first IAB node participates in transmitting refer to the services that the DU of the first IAB node participates in transmitting, including: services transmitted through the first IAB node (such as the services of the child nodes of the IAB node or the UE), and the services of the DU of the first IAB node itself.

[0023] For example, the first message mentioned above includes an "All traffic indication." Based on this indication, the target F1 endpoint CU (third CU) of the first IAB node does not need to initiate the relevant IAB transmission migration management procedure to the RRC endpoint CU for all services of the first DU of the first IAB node (e.g., F1-U services, F1-C services, non-F1 services, etc. of the first DU b). (This procedure is used to request the second CU to configure the radio backhaul link for the services of the first IAB node in its subordinate radio backhaul network.) This "All traffic indication" can be explicitly included in the first message or implicitly contained within it. For example, in one possible implicit manner, if the first message only contains the identifier of the first IAB node and does not contain any UE identifier, it can be considered an implicit "All traffic indication."

[0024] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, the first message includes the identifier of the first UE, which is served by the first IAB node. After the first UE switches from the first CU to the third CU following the first DU, the third CU, based on the first message, is exempt from negotiating with the second CU regarding the transmission migration management of the services of the first UE.

[0026] For example, the first message also includes the identifier of the first data radio bearer (DRB) or the first signaling radio bearer (SRB) of the first UE. After the first UE switches from the first CU to the third CU along with the first DU, the third CU, based on the first message, is exempt from negotiating the transmission migration management of the first DRB or the first SRB of the first UE with the second CU.

[0027] For example, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0028] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0029] In conjunction with the first aspect, in some implementations of the first aspect, the first DU includes a first DU a and a first DU b, the first DU a is connected to the first CU via a first F1 interface, and the first DU b is connected to the third CU via a third F1 interface.

[0030] It should be understood that the first DU a and the first DU b are connected to different IAB host CUs, such as the first CU and the third CU. The first DU a is connected to the first CU and the first DU b is connected to the third CU. Then the first DU b can initiate an F1 connection establishment request to the third CU and then establish the third F1 interface, or target F1 interface, between the first DU b and the third CU.

[0031] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0032] In conjunction with the first aspect, in some implementations of the first aspect, the first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

[0033] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0034] In conjunction with the first aspect, in some implementations of the first aspect, the third CU receives a fourth message from the first CU, the fourth message including first quality of service (QoS) mapping information of the downlink service of the first CU, the first QoS mapping information corresponding to the service of the first F1-C interface control plane or the non-F1 service or the first DRB of the first UE, the first QoS mapping information including at least one of the following: differentiated services code point (DSCP) and flow label.

[0035] For example, the first message mentioned above may also carry the first QoS mapping information mentioned above.

[0036] Based on the above technical solution, during the process of establishing the entire service path of the F1 interface user plane, the third CU can also obtain the QoS label information of the negotiated service, enabling the third CU to accurately provide service data to the first IAB node. Furthermore, by carrying the identifier corresponding to the first IAB node, the CU3 can know that it is the first DU of the first IAB node serving the first UE, facilitating subsequent negotiation processes between the CU3 and the first DU regarding the establishment and modification of the first UE's F1 interface context.

[0037] In conjunction with the first aspect, in some implementations of the first aspect, the fourth message mentioned above also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first CU and the uplink tunnel endpoint identifier (TEID) of the first CU.

[0038] For example, the fourth message may also include the identifier of the first IAB node that provides services to the first UE. For example, the target cell identifier of the first UE, where the target cell of the first UE is the cell served by the first IAB node (i.e., the cell served by the first DU, specifically the identifier of the cell served by the logical DU b connected to the target F1 endpoint CU); or, the identifier of the first DU to which the first UE is connected, which may be the IP address of the first DU or the gNB-DU identifier (gNB-DU ID) of the first DU. If the first IAB node is connected to different CUs (first CU and third CU) through different logical DUs (first DU a and first DU b), then the identifier of the first DU may specifically be the identifier of the first DU b that establishes an F1 connection with the third CU (the IP address or gNB-DU ID of the first DU b); or, the BAP address of the first IAB node.

[0039] For example, the fourth message mentioned above may also include the identifier of the first UE and the identifier of the first DRB, corresponding to the first uplink endpoint information of the F1-U interface tunnel of the first DRB. The identifier of the first UE may be the UE identifier used by the first UE when performing XnAP handover, such as the UE XnAP ID assigned to the first UE by the first CU, and / or the UE XnAP ID assigned to the first UE by the third CU.

[0040] Based on the above technical solution, the third CU can update the tunnel endpoint information of the F1-U service (traffic), enabling the third CU to accurately provide service data to the first IAB node.

[0041] In conjunction with the first aspect, in some implementations of the first aspect, the third CU generates second uplink endpoint information corresponding to the first DRB of the first UE, the second uplink endpoint information including the IP address of the third CU and the uplink TEID of the third CU; the third CU sends first update information to the first IAB node, the first update information including the second uplink endpoint information.

[0042] For example, if the third CU is in a configuration where the CP and UP are separate, and the third CU includes the third CU-CP and the third CU-UP, then the third CU-CP sends a first notification message to the third CU-UP. This first notification message instructs the third CU-UP to establish an uplink tunnel endpoint for the second F1-U interface. This first notification message can be a bearer context setup request message or other messages from the E1 interface.

[0043] It should be understood that after the third CU receives the first notification information, it can enable the third CU-UP to establish the uplink tunnel endpoint of the GPRS tunneling protocol user plane (GTP-U) of the F1-U interface corresponding to the first DRB, that is, the uplink tunnel endpoint of the second F1-U interface.

[0044] For example, the first notification information mentioned above includes at least one of the following: the identifier of the first UE, the identifier of the first DRB, and the first downlink endpoint information of the first F1-U interface tunnel corresponding to the first DRB. The first downlink endpoint information includes the IP address of the first downlink endpoint and the downlink tunnel endpoint identifier TEID of the first F1-U interface. The downlink TEID of the first F1-U may be the downlink TEID at the first DU.

[0045] For example, the first notification information may also include the first uplink endpoint information (original uplink endpoint information) of the first F1-U interface tunnel corresponding to the UE DRB, which is informed by the second CU to the third CU. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink TEID of the first F1-U interface.

[0046] For example, the third CU-UP sends a second notification message to the third CU-CP, which contains the uplink tunnel endpoint information of the second F1-U interface.

[0047] For example, the uplink tunnel endpoint information of the second F1-U interface mentioned above includes the IP address of the second uplink endpoint and the uplink TEID of the second F1-U interface tunnel.

[0048] For example, the second notification information mentioned above may also include the identifier of the first UE and the identifier of the first DRB.

[0049] It should be understood that the second uplink endpoint information of the second F1-U interface tunnel can also be referred to as the new uplink endpoint information.

[0050] For example, if the first notification information includes the first uplink endpoint information corresponding to the first DRB, the second notification information may include the first uplink endpoint information in addition to the second uplink endpoint information.

[0051] For example, if the third CU is not in a CP and UP separation configuration, then the steps proposed in the example above do not need to be performed. The second uplink endpoint information can be determined automatically using the known information.

[0052] For example, the first update information may also include corresponding first uplink endpoint information for each second uplink endpoint information. After receiving the first update information, the first IAB node can directly replace the first uplink endpoint information of the F1-U interface tunnel corresponding to the first DRB with the second uplink endpoint information. In this way, the third CU can send multiple first update information for different DRBs of multiple UEs to the first IAB node at one time, which can improve the efficiency of configuration update.

[0053] Based on the above technical solution, the third CU can easily obtain the new uplink tunnel endpoint information of the F1-U interface corresponding to the first DRB, and then further notify the first IAB node. In addition, the third CU can also obtain the first QoS mapping information corresponding to the first DRB, which facilitates providing reasonable QoS guarantees and routing for data packets transmitted through the first DRB during downlink transmission.

[0054] Secondly, a communication method is provided, which is applied to an integrated access backhaul (IAB) network, wherein a second CU and a first MT of a first IAB node have an RRC connection. The method includes: after the first DU of the first IAB node migrates from the first CU to the third CU, the first CU receives a fifth message; based on the fifth message, the first CU is exempt from negotiating with the second CU regarding the release of services of the first IAB node.

[0055] For example, the services of the first IAB node can be the services of the first IAB node itself (e.g., non-UE-related services transmitted between the first DU and the F1terminating CU, or the OAM services of the first DU), or the services of the UE served by the first IAB node.

[0056] For example, during the handover process of a UE served by the first IAB node following the first DU, if the first CU does not need to initiate negotiations with the second CU of the IAB node regarding the release of the services of the first IAB node for the UE's services, then the first CU needs to be aware of this matter.

[0057] For example, after receiving the fifth message, the first CU decides not to negotiate with the second CU regarding the release of services from the first IAB node. Services between the first CU and the first IAB node continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0058] For example, the aforementioned fifth message can be included in a notification message exchanged between the RRC endpoint CU (second CU) of the first IAB node and the source F1 endpoint CU (first CU) in the form of an IE (Exhibited Message), or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned fifth message can be used directly to indicate that the first CU does not need to negotiate with the second CU of the first IAB node regarding the release of the first IAB node's services, or it can be used to indicate that the first MT does not need to switch the RRC endpoint CU (i.e., the second CU), or it can be used to indicate that the radio backhaul link path of the first DU's services remains unchanged.

[0059] For example, the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU after the first CU gives the corresponding instruction, or the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU based on the OAM configuration (which may also be pre-configured).

[0060] For example, after the first CU receives the fifth message, the first CU sends a second feedback message to the second CU, which indicates that the first CU has successfully received the fifth message from the second CU.

[0061] Based on the above technical solution, it is possible to reasonably avoid the situation where the third CU initiates the relevant procedures for IAB transport migration management (such as the IAB transport migration management procedure, which is used to request the relevant configuration of the radio backhaul link for the service of releasing the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU. This can save the signaling overhead of the Xn interface and F1 interface.

[0062] In conjunction with the second aspect, in some implementations of the second aspect, before a connection is established between the third CU and the first DU, the first CU sends a sixth message to the second CU, the sixth message being used to indicate that the first DU of the first IAB node will migrate from the first CU to the third CU.

[0063] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the source F1 endpoint CU is the first CU, so as to ensure that the second CU can conduct accurate signaling interaction with the first CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the first CU belongs to, so as to send the above-mentioned fifth message to the first CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0064] In conjunction with the second aspect, in some implementations of the second aspect, the aforementioned fifth message includes the identifier of the first IAB node. After the first DU of the first IAB node migrates from the first CU to the third CU, the first CU, based on the aforementioned fifth message, is exempt from transmission migration management negotiation regarding the release of all services in which the aforementioned first IAB node participates in transmission.

[0065] For example, all services that the first IAB node participates in transmitting refer to the services that the DU of the first IAB node participates in transmitting, including: services transmitted through the first IAB node (such as the services of the child nodes of the IAB node or the UE), and the services of the DU of the first IAB node itself.

[0066] For example, when the second CU and the third CU are the same CU, in an implicit manner, when the first DU initiates an F1 connection establishment request to the target F1 endpoint CU (second CU), it can carry the BAP address assigned to the first MT by the RRC terminating CU (second CU) in the F1 setup request message. This allows the second CU to know that the first DU, which is co-deployed with the first MT, is about to request the establishment of an F1 interface. Since the second CU has previously received a handover request from the first MT, it can know that the first IAB node has performed a partial migration before connecting to the second CU. Therefore, when the second CU receives the F1 connection establishment request from the first DU, which is co-deployed with the first MT, it can know that the first DU of the first IAB node is also about to migrate to the second CU. Alternatively, in an explicit manner, when the first DU initiates an F1 connection establishment request to the target F1 endpoint CU (second CU), it can carry explicit indication information in the F1 setup request message to indicate that the DU of the first IAB node wishes to migrate to the second CU.

[0067] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0068] In conjunction with the second aspect, in some implementations of the second aspect, the fifth message includes the identifier of the first UE, which is served by the first IAB node. After the first UE switches from the first CU to the third CU along with the first DU, the first CU, based on the fifth message, is exempt from negotiating with the second CU regarding the release of the services of the first UE.

[0069] For example, the fifth message also includes the identifier of the first data radio bearer (DRB) or the identifier of the first signaling radio bearer (SRB) of the first UE. After the first UE switches from the first CU to the third CU along with the first DU, the first CU, based on the fifth message, is exempt from negotiating with the second CU regarding the release of the first DRB or the first SRB of the first UE.

[0070] For example, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0071] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0072] In conjunction with the second aspect, in some implementations of the second aspect, the first DU includes a first DU a and a first DU b, the first DU a being connected to the first CU via a first F1 interface, and the first DU b being connected to the third CU via a third F1 interface.

[0073] It should be understood that the first DU a and the first DU b are connected to different IAB host CUs, such as the first CU and the third CU. The first DU a is connected to the first CU and the first DU b is connected to the third CU. Then the first DU b can initiate an F1 connection establishment request to the third CU and then establish the third F1 interface, or target F1 interface, between the first DU b and the third CU.

[0074] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0075] In conjunction with the second aspect, in some implementations of the second aspect, the first DU mentioned above includes a first DU a and a first DU b, and the identifier of the first IAB node includes the identifier of the first DU a.

[0076] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0077] In conjunction with the second aspect, in some implementations of the second aspect, the first CU sends a fourth message to the third CU, the fourth message including the first QoS mapping information of the downlink service of the first CU, the first QoS mapping information corresponding to the service or non-F1 service of the first F1-C interface control plane or the first DRB of the first UE, the first QoS mapping information including at least one of the following: DSCP, flow label.

[0078] For example, the first message mentioned above may also carry the first QoS mapping information mentioned above.

[0079] For example, the fourth message may also include the identifier of the first IAB node that provides services to the first UE. For example, the target cell identifier of the first UE, where the target cell of the first UE is the cell served by the first IAB node (i.e., the cell served by the first DU, specifically the identifier of the cell served by the logical DU b connected to the target F1 endpoint CU); or, the identifier of the first DU to which the first UE is connected, which may be the IP address of the first DU or the gNB-DU identifier (gNB-DU ID) of the first DU. If the first IAB node is connected to different CUs (first CU and third CU) through different logical DUs (first DU a and first DU b), then the identifier of the first DU may specifically be the identifier of the first DU b that establishes an F1 connection with the third CU (the IP address or gNB-DU ID of the first DU b); or, the BAP address of the first IAB node.

[0080] Based on the above technical solution, during the process of establishing the entire service path of the F1 interface user plane, the third CU can also obtain the QoS label information of the negotiated service, enabling the third CU to accurately provide service data to the first IAB node.

[0081] In conjunction with the second aspect, in some implementations of the second aspect, the fourth message mentioned above also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE, the first uplink endpoint information including the IP address of the first CU and the uplink tunnel endpoint identifier TEID of the first CU.

[0082] For example, the fourth message mentioned above may also include the identifier of the first UE and the identifier of the first DRB, corresponding to the first uplink endpoint information of the F1-U interface tunnel of the first DRB. The identifier of the first UE may be the UE identifier used by the first UE when performing XnAP handover, such as the UE XnAP ID assigned to the first UE by the first CU, and / or the UE XnAP ID assigned to the first UE by the third CU.

[0083] For example, after receiving the fourth message, the third CU generates first update information based on the fourth message and sends the first update information to the first IAB node. This first update information includes the second uplink endpoint information. For each second uplink endpoint information, the first update information may also include corresponding first uplink endpoint information. Upon receiving the first update information, the first IAB node can directly replace the first uplink endpoint information of the F1-U interface tunnel corresponding to the first DRB with the second uplink endpoint information. In this way, the third CU can send multiple first update information messages for different DRBs of multiple UEs to the first IAB node at once, improving the efficiency of configuration updates.

[0084] Based on the above technical solution, the third CU can update the tunnel endpoint information of F1-U traffic, enabling the third CU to accurately provide service data to the first IAB node.

[0085] Thirdly, a communication method is provided, which is applied to an integrated access backhaul (IAB) network. The method includes: a second CU establishing an RRC connection with a first MT of a first IAB node; after a first DU of the first IAB node migrates from the first CU to the third CU, the second CU sends a fifth message to the first CU and a first message to the third CU. The fifth message is used to instruct the first CU to waive the negotiation with the second CU regarding the release of services of the first IAB node, and the first message is used to instruct the third CU to waive the negotiation with the second CU regarding the transmission migration management of the first IAB node.

[0086] For example, the services of the first IAB node can be the services of the first IAB node itself (e.g., non-UE-related services transmitted between the first DU and the F1 endpoint CU, or the OAM services of the first DU), or the services of the UE served by the first IAB node.

[0087] For example, the second CU and the first CU mentioned above can be the same CU, that is, the RRC endpoint CU of the first IAB node can also be the source F1 endpoint CU of the first IAB node; or, the second CU and the third CU mentioned above can be the same CU, that is, the RRC endpoint CU of the first IAB node can also be the target F1 endpoint CU of the first IAB node.

[0088] For example, during the handover process of a UE served by the first IAB node following the first DU, if the third CU does not need to initiate a service negotiation process with the second CU of the IAB node for the UE's services, then the third CU needs to be aware of this.

[0089] For example, after receiving the first message, the third CU decides not to negotiate the transmission migration management of the first IAB node with the second CU. Services between the third CU and the first IAB node continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0090] For example, the aforementioned first message can be included in a notification message exchanged between the RRC endpoint CU (second CU) of the first IAB node and the target F1 endpoint CU (third CU) in the form of an IE (Exhibited Message), or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned first message can be used directly to indicate that the third CU does not need to negotiate with the second CU of the first IAB node regarding the transmission migration management of the first IAB node, or it can be used to indicate that the aforementioned first MT does not need to switch the RRC endpoint CU (i.e., the second CU), or it can be used to indicate that the radio backhaul link path of the service of the aforementioned first DU remains unchanged.

[0091] For example, the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU after the first CU gives the corresponding instruction, or the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU based on the OAM configuration (which may also be pre-configured).

[0092] For example, after the third CU receives the first message, the third CU sends a first feedback message to the second CU, which indicates that the third CU has successfully received the first message from the second CU.

[0093] For example, during the handover process of a UE served by the first IAB node following the first DU, if the first CU does not need to initiate negotiations with the second CU of the IAB node regarding the release of the services of the first IAB node for the UE's services, then the first CU needs to be aware of this matter.

[0094] For example, after receiving the fifth message, the first CU decides not to negotiate with the second CU regarding the release of services from the first IAB node. Services between the first CU and the first IAB node continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0095] For example, the aforementioned fifth message can be included in a notification message exchanged between the RRC endpoint CU (second CU) of the first IAB node and the source F1 endpoint CU (first CU) in the form of an IE (Exhibited Message), or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned fifth message can be used directly to indicate that the first CU does not need to negotiate with the second CU of the first IAB node regarding the release of the first IAB node's services, or it can be used to indicate that the first MT does not need to switch the RRC endpoint CU (i.e., the second CU), or it can be used to indicate that the radio backhaul link path of the first DU's services remains unchanged.

[0096] For example, the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU after the first CU gives the corresponding instruction, or the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU based on the OAM configuration (which may also be pre-configured).

[0097] For example, after the first CU receives the fifth message, the first CU sends a second feedback message to the second CU, which indicates that the first CU has successfully received the fifth message from the second CU.

[0098] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating IAB transport migration management procedures (such as the IAB transport migration management procedure, which is used to request the second CU to configure the radio backhaul link for the services of the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU. It is also possible to avoid the first CU initiating IAB transport migration management procedures (which is used to request the second CU to release the configuration of the radio backhaul link for the services of the first IAB node in its radio backhaul network) to the second CU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0099] In conjunction with the third aspect, in some implementations of the third aspect, the second CU receives a sixth message from the first CU, the sixth message being used to indicate that the first DU of the first IAB node will migrate from the first CU to the third CU; the second CU sends the fifth message to the first CU according to the sixth message and the first connection state, the first connection state including that the first MT maintains an RRC connection with the second CU before and after the first DU migrates from the first CU to the third CU.

[0100] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the source F1 endpoint CU is the first CU, so as to ensure that the second CU can conduct accurate signaling interaction with the first CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the first CU belongs to, so as to send the above-mentioned fifth message to the first CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0101] In conjunction with the third aspect, in some implementations of the third aspect, the second CU receives a third message from the third CU, the third message indicating that the third CU has established a connection with the first IAB node through the third F1 interface; the second CU sends the first message to the third CU according to the third message and the first connection status, the first connection status including that the first MT maintains an RRC connection with the second CU before and after the first DU migrates from the first CU to the third CU.

[0102] For example, since whether the first MT needs to switch the IAB host CU can be determined by the RRC endpoint CU, if the first MT does not need to be switched, the second CU, which is the RRC endpoint CU, can send the first message or the fifth message mentioned above to the third CU after learning that the F1 interface connection between the first IAB node and the third CU has been successfully established.

[0103] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is the third CU, so as to ensure that the second CU can conduct accurate signaling interaction with the third CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the third CU belongs to, so as to send the above first message to the third CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0104] In conjunction with the third aspect, in some implementations of the third aspect, the aforementioned fifth message includes a first IAB node identifier, and the aforementioned fifth message is used to instruct the aforementioned first CU to waive the transmission migration management negotiation regarding the release of all services in which the aforementioned first IAB node participates in transmission.

[0105] For example, all services that the first IAB node participates in transmitting refer to the services that the DU of the first IAB node participates in transmitting, including: services transmitted through the first IAB node (e.g., services of the IAB node's child nodes or UEs), and services of the first IAB node's DU itself.

[0106] For example, when the second CU and the third CU are the same CU, in an implicit manner, when the first DU initiates an F1 connection establishment request to the target F1 endpoint CU (second CU), it can carry the BAP address assigned to the first MT by the RRC terminating CU (second CU) in the F1 setup request message. This allows the second CU to know that the first DU, which is co-deployed with the first MT, is about to request the establishment of an F1 interface. Since the second CU has previously received a handover request from the first MT, it can know that the first IAB node has performed a partial migration before connecting to the second CU. Therefore, when the second CU receives the F1 connection establishment request from the first DU, which is co-deployed with the first MT, it can know that the first DU of the first IAB node is also about to migrate to the second CU. Alternatively, in an explicit manner, when the first DU initiates an F1 connection establishment request to the target F1 endpoint CU (second CU), it can carry explicit indication information in the F1 setup request message to indicate that the DU of the first IAB node wishes to migrate to the second CU.

[0107] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0108] In conjunction with the third aspect, in some implementations of the third aspect, the fifth message includes the identifier of the first UE, which is served by the first IAB node, and the fifth message is used to instruct the first CU to waive the need to negotiate with the second CU regarding the release of services for the first UE.

[0109] For example, the fifth message also includes the identifier of the first DRB or the identifier of the first SRB of the first UE. The fifth message is used to instruct the first CU to waive the negotiation with the second CU regarding the release of the first DRB or the first SRB of the first UE.

[0110] For example, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0111] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0112] In conjunction with the third aspect, in some implementations of the third aspect, the aforementioned first message includes a first IAB node identifier, and the aforementioned first message is used to instruct the aforementioned third CU to waive the transmission migration management negotiation for all services involving the aforementioned first IAB node in transmission.

[0113] For example, the first message mentioned above includes an "All traffic indication." Based on this indication, the target F1 endpoint CU (third CU) of the first IAB node does not need to initiate the relevant IAB transmission migration management procedure to the RRC endpoint CU for all services of the first DU of the first IAB node (e.g., F1-U services, F1-C services, non-F1 services, etc. of the first DU b). (This procedure is used to request the second CU to configure the radio backhaul link for the services of the first IAB node in its subordinate radio backhaul network.) This "All traffic indication" can be explicitly included in the first message or implicitly contained within it. For example, in one possible implicit manner, if the first message only contains the identifier of the first IAB node and does not contain any UE identifier, it can be considered an implicit "All traffic indication."

[0114] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0115] In conjunction with the third aspect, in some implementations of the third aspect, the first message includes the identifier of the first UE, which is served by the first IAB node, and the first message is used to instruct the third CU to waive the negotiation with the second CU regarding the transmission migration management of the services of the first UE.

[0116] For example, the first message may also include the identifier of the first DRB or the identifier of the first SRB of the first UE. The first message is used to instruct the third CU to waive the transmission migration management negotiation with the second CU regarding the first DRB or the first SRB of the first UE.

[0117] For example, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0118] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0119] In conjunction with the third aspect, in some implementations of the third aspect, the first DU includes a first DU a and a first DU b, the first DU a being connected to the first CU via a first F1 interface, and the first DU b being connected to the third CU via a third F1 interface.

[0120] It should be understood that the first DU a and the first DU b are connected to different IAB host CUs, such as the first CU and the third CU. The first DU a is connected to the first CU and the first DU b is connected to the third CU. Then the first DU b can initiate an F1 connection establishment request to the third CU and then establish the third F1 interface, or target F1 interface, between the first DU b and the third CU.

[0121] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0122] In conjunction with the third aspect, in some implementations of the third aspect, the first DU mentioned above includes the first DU a and the first DU b, the first IAB node identifier in the fifth message mentioned above includes the identifier of the first DU a, and the first IAB node identifier in the first message mentioned above includes the identifier of the first DU b.

[0123] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0124] In conjunction with the third aspect, in some implementations of the third aspect, the second CU receives a fourth message sent by the first CU, the fourth message including the first QoS mapping information of the downlink service of the first CU, the first QoS mapping information corresponding to the service of the first F1-C interface control plane or the non-F1 service or the first DRB of the first UE, the first QoS mapping information including at least one of the following: DSCP, flow label; the second CU sends the fourth message to the third CU.

[0125] For example, the fourth message may also include the identifier of the first IAB node that provides services to the first UE. For example, the target cell identifier of the first UE, where the target cell of the first UE is the cell served by the first IAB node (i.e., the cell served by the first DU, specifically the identifier of the cell served by the logical DU b connected to the target F1 endpoint CU); or, the identifier of the first DU to which the first UE is connected, which may be the IP address of the first DU or the gNB-DU identifier (gNB-DU ID) of the first DU. If the first IAB node is connected to different CUs (first CU and third CU) through different logical DUs (first DU a and first DU b), then the identifier of the first DU may specifically be the identifier of the first DU b that establishes an F1 connection with the third CU (the IP address or gNB-DU ID of the first DU b); or, the BAP address of the first IAB node.

[0126] Based on the above technical solution, during the process of establishing the entire service path of the F1 interface user plane, the third CU can also obtain the QoS label information of the negotiated service, enabling the third CU to accurately provide service data to the first IAB node. In conjunction with the third aspect, in some implementations of the third aspect, when the second CU and the first CU are the same CU, the second CU generates the fourth message and sends it to the third CU.

[0127] In conjunction with the third aspect, in some implementations of the third aspect, the aforementioned fourth message also includes first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE, wherein the first uplink endpoint information includes the IP address of the first CU and the uplink TEID of the first CU.

[0128] For example, the fourth message mentioned above may also include the identifier of the first UE and the identifier of the first DRB, corresponding to the first uplink endpoint information of the F1-U interface tunnel of the first DRB. The identifier of the first UE may be the UE identifier used by the first UE when performing XnAP handover, such as the UE XnAP ID assigned to the first UE by the first CU, and / or the UE XnAP ID assigned to the first UE by the third CU.

[0129] Based on the above technical solution, the third CU can update the tunnel endpoint information of F1-U traffic, enabling the third CU to accurately provide service data to the first IAB node. Fourthly, a communication method is provided, applied to an integrated access backhaul (IAB) network. The method includes: a first MT of the first IAB node establishing an RRC connection with the second CU; a first DU of the first IAB node migrating from the first CU to the third CU; the first IAB node receiving a seventh message from the second CU, the seventh message instructing the first MT to maintain an RRC connection with the second CU during the migration of the first DU from the first CU to the third CU; the first IAB node determining a first message and a fifth message based on the seventh message, the first message instructing the third CU to waive the transmission migration management negotiation with the second CU regarding the first IAB node, and the fifth message instructing the first CU to waive the negotiation with the second CU regarding the release of services of the first IAB node; the first IAB node sending the first message to the third CU and the fifth message to the first CU.

[0130] It should be understood that since the first CU mentioned above is the CU of the source IAB host node of the first IAB node, and the first DU of the first IAB node and each IAB host CU are connected through the F1 interface, the first CU can be called the source F1 endpoint CU; similarly, since the third CU mentioned above is the CU of the target IAB host node of the first IAB node, the third CU can be called the target F1 endpoint CU; in addition, the first MT of the first IAB node is connected to the second CU, and the second CU will maintain the RRC connection for the first MT, so the second CU can be called the RRC endpoint CU.

[0131] For example, the second CU and the first CU mentioned above can be the same CU, that is, the RRC endpoint CU of the first IAB node can also be the source F1 endpoint CU of the first IAB node; or, the second CU and the third CU mentioned above can be the same CU, that is, the RRC endpoint CU of the first IAB node can also be the target F1 endpoint CU of the first IAB node.

[0132] For example, during the handover process of a UE served by the first IAB node following the first DU, if the third CU does not need to initiate a service negotiation process with the second CU of the IAB node for the UE's services, then the third CU needs to be aware of this.

[0133] For example, after receiving the first message, the third CU decides not to negotiate the transmission migration management of the first IAB node with the second CU. Services between the third CU and the first IAB node continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0134] For example, the aforementioned first message can be included in a notification message exchanged between the RRC endpoint CU (second CU) of the first IAB node and the target F1 endpoint CU (third CU) in the form of an IE (Exhibited Message), or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned first message can be used directly to indicate that the third CU does not need to negotiate with the second CU of the first IAB node regarding the transmission migration management of the first IAB node, or it can be used to indicate that the aforementioned first MT does not need to switch the RRC endpoint CU (i.e., the second CU), or it can be used to indicate that the radio backhaul link path of the service of the aforementioned first DU remains unchanged.

[0135] For example, the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU after the first CU gives the corresponding instruction, or the first IAB node may initiate the aforementioned F1 connection establishment request to the third CU based on the OAM configuration (which may also be pre-configured).

[0136] For example, after the third CU receives the first message, the third CU sends a first feedback message to the second CU, which indicates that the third CU has successfully received the first message from the second CU.

[0137] Based on the above technical solution, it is possible to reasonably avoid the situation where the third CU initiates the relevant IAB transport migration management process (such as the IAB transport migration management process, which is used to request the relevant configuration of the radio backhaul link for the services of the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0138] In conjunction with the fourth aspect, in some implementations of the fourth aspect, after the first DU of the first IAB node migrates from the first CU to the third CU, the first IAB node sends a third message to the second CU. The third message indicates that a connection has been established between the first IAB node and the third CU through the third F1 interface. The third message carries the first MT identifier.

[0139] For example, the aforementioned third F1 interface includes the third control plane F1-C interface and the third user plane F1-U interface.

[0140] It should be understood that specific examples can be found in the foregoing examples regarding third messages.

[0141] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is the third CU, so as to ensure that the second CU can conduct accurate signaling interaction with the third CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the third CU belongs to, so as to send the above first message to the third CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0142] In conjunction with the fourth aspect, in some implementations of the fourth aspect, before establishing a connection between the first DU and the third CU, the first IAB node sends a second message to the third CU. The second message is used to instruct the first IAB node to request the establishment of an F1 interface with the third CU. The second message carries a first MT identifier and a second CU identifier. The first MT identifier includes at least one of the following: the Backhaul Adaptation Protocol (BAP) address assigned to the first MT by the second CU, and the User Equipment (UE) Application Protocol (AP) identifier assigned to the first MT by the second CU. The second CU identifier includes at least one of the following: the IP address of the second CU, and the gNB identifier of the base station where the second CU is located.

[0143] It should be understood that specific examples can be found in the foregoing examples regarding the second message.

[0144] Based on the above technical solution, the third CU, which is the target F1 endpoint CU of the first IAB node, can know that the first DU of the first IAB node was previously connected to the second CU. Furthermore, the first MT of the first IAB node is connected to the second CU.

[0145] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the fifth message includes the identifier of the first IAB node, and the fifth message is used to instruct the first CU to waive the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

[0146] It should be understood that specific examples can be found in the examples provided above regarding the fifth message.

[0147] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0148] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the fifth message includes the identifier of the first UE, which is served by the first IAB node, and the fifth message is used to instruct the first CU to waive the need to negotiate with the second CU regarding the release of services for the first UE.

[0149] It should be understood that specific examples can be found in the examples provided above regarding the fifth message.

[0150] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0151] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first message includes a first IAB node identifier, and the first message is used to instruct the third CU to waive the transmission migration management negotiation for all services involving the first IAB node in transmission.

[0152] It should be understood that specific examples can be found in the foregoing examples regarding the first message.

[0153] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0154] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first message includes the identifier of the first UE, which is served by the first IAB node, and the first message is used to instruct the third CU to waive the negotiation with the second CU regarding the transmission migration management of the services of the first UE.

[0155] It should be understood that specific examples can be found in the foregoing examples regarding the first message.

[0156] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0157] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first DU includes a first DU a and a first DU b, wherein the first DU a is connected to the first CU through a first F1 interface; and the first DU b is connected to the third CU through a third F1 interface.

[0158] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0159] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first DU mentioned above includes the first DU a and the first DU b, the first IAB node identifier in the fifth message mentioned above includes the identifier of the first DU a, and the first IAB node identifier in the first message mentioned above includes the identifier of the first DU b.

[0160] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0161] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first IAB node receives a first update message from the third CU, the first update message including second uplink endpoint information corresponding to the first DRB of the first UE, the second uplink endpoint information including the IP address of the third CU and the uplink TEID of the third CU; the first IAB node updates the uplink TEID and uplink mapping configuration of the F1-U corresponding to the first DRB according to the first update message.

[0162] It should be understood that specific examples can be found in the foregoing examples regarding the fourth message.

[0163] Based on the above technical solution, the entire business path of the F1 interface user plane is opened up, enabling the first IAB node to accurately receive accurate business data.

[0164] In conjunction with the fourth aspect, in some implementations of the fourth aspect, when the first CU and the second CU are the same CU, the first IAB node sends the first message to the third CU; or, when the second CU and the third CU are the same CU, the first IAB node sends the fifth message to the first CU.

[0165] Based on the above technical solution, the second CU can have a dual role, increasing the flexibility of the solution.

[0166] Fifthly, a communication device is provided, which is applied to an integrated access backhaul (IAB) network, wherein a second CU and a first MT of a first IAB node have an RRC connection, and the device is specifically applied to a third CU, comprising: a receiving unit, configured to receive a first message after the first DU of the first IAB node migrates from the first CU to the third CU; and a processing unit, configured to, based on the first message, eliminate the need for negotiation with the second CU regarding the transmission migration management of the first IAB node.

[0167] Based on the above technical solution, it is possible to reasonably avoid the situation where the third CU initiates the relevant IAB transport migration management process (such as the IAB transport migration management process, which is used to request the relevant configuration of the radio backhaul link for the services of the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0168] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the above-mentioned apparatus further includes: a sending unit for sending a third message to the second CU, the third message indicating that the third CU has established a connection with the first IAB node through the third F1 interface, the third message carrying the first MT identifier.

[0169] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is the third CU, so as to ensure that the second CU can conduct accurate signaling interaction with the third CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the third CU belongs to, so as to send the above first message to the third CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0170] In conjunction with the fifth aspect, in some implementations of the fifth aspect, before establishing a connection between the third CU and the first DU, the receiving unit is further configured to receive a second message from the first IAB node. The second message is used to instruct the first IAB node to request the establishment of an F1 interface with the third CU. The second message carries a first MT identifier and a second CU identifier. The first MT identifier includes at least one of the following: the BAP address assigned to the first MT by the second CU, and the UE XnAP identifier assigned to the first MT by the second CU. The second CU identifier includes at least one of the following: the IP address of the second CU, and the gNB identifier of the base station where the second CU is located.

[0171] Based on the above technical solution, the third CU, which is the target F1 endpoint CU of the first IAB node, can know that the first DU of the first IAB node was previously connected to the second CU. Furthermore, the first MT of the first IAB node is connected to the second CU.

[0172] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the first message includes the identifier of the first IAB node. After the first DU migrates from the first CU to the third CU, the processing unit is further configured to, based on the first message, exempt from transmission migration management negotiation regarding all services transmitted by the first IAB node.

[0173] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0174] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the first message includes the identifier of the first UE, which is served by the first IAB node. After the first UE switches from the first CU to the third CU following the first DU, the processing unit is further configured to, based on the first message, avoid negotiating with the second CU regarding the transmission migration management of the services of the first UE.

[0175] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0176] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the first DU includes a first DU a and a first DU b, the first DU a is connected to the first CU via a first F1 interface, and the first DU b is connected to the third CU via a third F1 interface.

[0177] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0178] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the first DU mentioned above includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

[0179] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0180] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the receiving unit is further configured to receive a fourth message from the first CU, the fourth message including first QoS mapping information of downlink services of the first CU, the first QoS mapping information corresponding to services or non-F1 services of the first F1-C interface control plane or the first DRB of the first UE, the first QoS mapping information including at least one of the following: DSCP, flow label.

[0181] Based on the above technical solution, during the process of establishing the entire service path of the F1 interface user plane, the third CU can also obtain the QoS label information of the negotiated service, enabling the third CU to accurately provide service data to the first IAB node.

[0182] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the fourth message mentioned above also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE, wherein the first uplink endpoint information includes the IP address of the first CU and the uplink TEID of the first CU.

[0183] Based on the above technical solution, the third CU can update the tunnel endpoint information of F1-U traffic, enabling the third CU to accurately provide service data to the first IAB node.

[0184] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to generate second uplink endpoint information corresponding to the first DRB of the first UE, the second uplink endpoint information including the IP address of the third CU and the uplink TEID of the third CU; the sending unit is further configured to send first update information to the first IAB node, the first update information including the second uplink endpoint information.

[0185] Based on the above technical solution, the third CU can easily obtain the new uplink tunnel endpoint information of the F1-U interface corresponding to the first DRB, and then further notify the first IAB node. In addition, the third CU can also obtain the first QoS mapping information corresponding to the first DRB, which facilitates providing reasonable QoS guarantees and routing for data packets transmitted through the first DRB during downlink transmission.

[0186] In a sixth aspect, a communication device is provided, which is applied to an integrated access backhaul (IAB) network, wherein a second CU and a first MT of a first IAB node have an RRC connection. The device is specifically applied to the first CU in the IAB network and includes: a receiving unit, configured to receive a fifth message after the first DU of the first IAB node migrates from the first CU to the third CU; and a processing unit, configured to, based on the fifth message, eliminate the need for negotiation with the second CU regarding the release of services of the first IAB node.

[0187] Based on the above technical solution, it is possible to reasonably avoid the situation where the third CU initiates the relevant procedures for IAB transport migration management (such as the IAB transport migration management procedure, which is used to request the relevant configuration of the radio backhaul link for the service of releasing the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU. This can save the signaling overhead of the Xn interface and F1 interface.

[0188] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the above-mentioned apparatus further includes: a sending unit, configured to send a sixth message to the second CU before establishing a connection between the third CU and the first DU, the sixth message being used to indicate that the first DU of the first IAB node will migrate from the first CU to the third CU.

[0189] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the source F1 endpoint CU is the first CU, so as to ensure that the second CU can conduct accurate signaling interaction with the first CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the first CU belongs to, so as to send the above-mentioned fifth message to the first CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0190] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the fifth message includes the identifier of the first IAB node. After the first DU of the first IAB node migrates from the first CU to the third CU, the processing unit is further configured to, according to the fifth message, exempt from transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

[0191] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0192] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the fifth message includes the identifier of the first UE, which is served by the first IAB node. After the first UE switches from the first CU to the third CU following the first DU, the processing unit is further configured to, based on the fifth message, waive the need to negotiate with the second CU regarding the release of the services of the first UE.

[0193] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0194] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the first DU includes a first DU a and a first DU b, the first DU a being connected to the first CU via a first F1 interface, and the first DU b being connected to the third CU via a third F1 interface.

[0195] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0196] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the first DU mentioned above includes a first DU a and a first DU b, and the identifier of the first IAB node includes the identifier of the first DU a.

[0197] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0198] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the aforementioned sending unit is further configured to send a fourth message to the aforementioned third CU, the fourth message including the first QoS mapping information of the downlink service of the aforementioned first CU, the first QoS mapping information corresponding to the service of the first F1-C interface control plane or the non-F1 service or the first DRB of the first UE, the first QoS mapping information including at least one of the following: DSCP, flow label.

[0199] Based on the above technical solution, during the process of establishing the entire service path of the F1 interface user plane, the third CU can also obtain the QoS label information of the negotiated service, enabling the third CU to accurately provide service data to the first IAB node.

[0200] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the fourth message mentioned above also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE, the first uplink endpoint information including the IP address of the first CU and the uplink TEID of the first CU.

[0201] Based on the above technical solution, the third CU can update the tunnel endpoint information of F1-U traffic, enabling the third CU to accurately provide service data to the first IAB node.

[0202] In a seventh aspect, a communication apparatus is provided for use in an integrated access backhaul (IAB) network. The apparatus is applied to a second control unit (CU). The apparatus includes: an operation unit for establishing an RRC connection with a first MT of a first IAB node; and a transmission unit for sending a fifth message to the first CU and a first message to the third CU after the first DU of the first IAB node migrates from the first CU to the third CU. The fifth message instructs the first CU to waive negotiation with the second CU regarding the release of services from the first IAB node, and the first message instructs the third CU to waive negotiation with the second CU regarding transmission migration management of the first IAB node.

[0203] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating IAB transport migration management procedures (such as the IAB transport migration management procedure, which is used to request the second CU to configure the radio backhaul link for the services of the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU. It is also possible to avoid the first CU initiating IAB transport migration management procedures (which is used to request the second CU to release the configuration of the radio backhaul link for the services of the first IAB node in its radio backhaul network) to the second CU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0204] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the above apparatus further includes: a receiving unit, configured to receive a sixth message from the first CU, the sixth message indicating that the first DU of the first IAB node will migrate from the first CU to the third CU; and a processing unit, configured to send the fifth message to the first CU according to the sixth message and a first connection state, the first connection state including that the first MT maintains an RRC connection with the second CU before and after the first DU migrates from the first CU to the third CU.

[0205] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the source F1 endpoint CU is the first CU, so as to ensure that the second CU can conduct accurate signaling interaction with the first CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the first CU belongs to, so as to send the above-mentioned fifth message to the first CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0206] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the receiving unit is further configured to receive a third message from the third CU, the third message indicating that the third CU has established a connection with the first IAB node through the third F1 interface; the processing unit is further configured to send the first message to the third CU according to the third message and the first connection status, the first connection status including that the first MT maintains an RRC connection with the second CU before and after the first DU migrates from the first CU to the third CU.

[0207] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is the third CU, so as to ensure that the second CU can conduct accurate signaling interaction with the third CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the third CU belongs to, so as to send the above first message to the third CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0208] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the fifth message includes a first IAB node identifier, and the fifth message is used to instruct the first CU to waive the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

[0209] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0210] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the fifth message includes an identifier of a first UE served by the first IAB node, and the fifth message is used to instruct the first CU to waive the need to negotiate with the second CU regarding the release of services for the first UE.

[0211] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0212] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the aforementioned first message includes a first IAB node identifier, and the aforementioned first message is used to instruct the aforementioned third CU to waive the transmission migration management negotiation for all services involving the aforementioned first IAB node in transmission.

[0213] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0214] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the first message includes the identifier of the first UE, which is served by the first IAB node, and the first message is used to instruct the third CU to waive the negotiation with the second CU regarding the transmission migration management of services for the first UE, the first DRB, or the first SRB.

[0215] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0216] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the first DU includes a first DU a and a first DU b, the first DU a being connected to the first CU via a first F1 interface, and the first DU b being connected to the third CU via a third F1 interface.

[0217] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0218] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the first DU mentioned above includes a first DU a and a first DU b, the first IAB node identifier in the fifth message mentioned above includes the identifier of the first DU a, and the first IAB node identifier in the first message mentioned above includes the identifier of the first DU b.

[0219] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the receiving unit is further configured to receive a fourth message sent by the first CU, the fourth message including first QoS mapping information of the downlink service of the first CU, the first QoS mapping information corresponding to the service of the first F1-C interface control plane or the non-F1 service or the first DRB of the first UE, the first QoS mapping information including at least one of the following: DSCP, flow label; the sending unit is further configured to send the fourth message to the third CU, so that the third CU generates second uplink endpoint information based on the fourth message and sends a first update message to the first IAB node, the first update message including the second uplink endpoint information, the second uplink endpoint information including the IP address of the third CU and the uplink TEID of the third CU.

[0220] Based on the above technical solution, during the process of establishing the entire service path of the F1 interface user plane, the third CU can also obtain the QoS label information of the negotiated service, enabling the third CU to accurately provide service data to the first IAB node.

[0221] In conjunction with the seventh aspect, in some implementations of the seventh aspect, when the second CU and the first CU are the same CU, the processing unit is further configured to generate the fourth message; the sending unit is further configured to send the fourth message to the third CU.

[0222] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the fourth message mentioned above also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE, the first uplink endpoint information including the IP address of the first CU and the uplink TEID of the first CU.

[0223] Based on the above technical solution, the third CU can update the tunnel endpoint information of F1-U traffic, enabling the third CU to accurately provide service data to the first IAB node.

[0224] Eighthly, a communication apparatus is provided for use in an integrated access backhaul (IAB) network, specifically for use in a first IAB node. The apparatus includes: an operation unit for establishing an RRC connection between a first MT and a second CU; and for migrating a first DU from the first CU to a third CU; a receiving unit for receiving a seventh message from the second CU, the seventh message instructing the first MT to maintain an RRC connection with the second CU during the migration of the first DU from the first CU to the third CU; a processing unit for determining a first message and a fifth message based on the seventh message, the first message instructing the third CU to waive the transmission migration management negotiation with the second CU regarding the first IAB node, and the fifth message instructing the first CU to waive the negotiation with the second CU regarding the release of services from the first IAB node; and a sending unit for sending the first message to the third CU and the fifth message to the first CU.

[0225] Based on the above technical solution, it is possible to reasonably avoid the situation where the third CU initiates the relevant IAB transport migration management process (such as the IAB transport migration management process, which is used to request the relevant configuration of the radio backhaul link for the services of the first IAB node in the IAB network under the jurisdiction of the second CU) during the process of the UE serving the first IAB node following the first DU from the first CU to the third CU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0226] In conjunction with the eighth aspect, in some implementations of the eighth aspect, after the first DU of the first IAB node migrates from the first CU to the third CU, the sending unit is further configured to send a third message to the second CU, the third message indicating that a connection has been established between the first IAB node and the third CU through the third F1 interface, the third message carrying the first MT identifier.

[0227] Based on the above technical solution, the second CU, which is the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is the third CU, so as to ensure that the second CU can conduct accurate signaling interaction with the third CU in subsequent processes. For example, the second CU can know which IAB host CU in the IAB network the third CU belongs to, so as to send the above first message to the third CU in the future, thereby avoiding the need to initiate unnecessary service migration management negotiations.

[0228] In conjunction with the eighth aspect, in some implementations of the eighth aspect, before establishing a connection between the first DU and the third CU, the sending unit is further configured to send a second message to the third CU. The second message is used to instruct the first IAB node to request to establish an F1 interface with the third CU. The second message carries a first MT identifier and a second CU identifier. The first MT identifier includes at least one of the following: the Backhaul Adaptation Protocol (BAP) address assigned by the second CU to the first MT, and the User Equipment (UE) Application Protocol (AP) identifier assigned by the second CU to the first MT. The second CU identifier includes at least one of the following: the IP address of the second CU, and the gNB identifier of the base station where the second CU is located.

[0229] Based on the above technical solution, the third CU, which is the target F1 endpoint CU of the first IAB node, can know that the first DU of the first IAB node was previously connected to the second CU. Furthermore, the first MT of the first IAB node is connected to the second CU.

[0230] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the fifth message mentioned above includes a first IAB node identifier, and the fifth message is used to instruct the first CU to waive the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

[0231] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0232] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the fifth message includes an identifier of the first UE that is served by the first IAB node, and the fifth message is used to instruct the first CU to waive the need to negotiate with the second CU regarding the release of services of the first UE, the first DRB, or the first SRB.

[0233] Based on the above technical solution, it is possible to reasonably avoid the first CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0234] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the first message includes a first IAB node identifier, and the first message is used to instruct the third CU to waive the transmission migration management negotiation for all services involving the first IAB node in transmission.

[0235] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0236] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the first message includes an identifier of the first UE that is served by the first IAB node, and the first message is used to instruct the third CU to waive the transmission migration management negotiation with the second CU regarding the first UE, the first DRB, or the first SRB.

[0237] Based on the above technical solution, it is possible to reasonably avoid the third CU initiating the IAB transmission migration management process to the second CU during the process of the UE serving the first IAB node switching from the first CU to the third CU following the first DU, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0238] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the first DU includes a first DU a and a first DU b, wherein the first DU a is connected to the first CU through a first F1 interface; and the first DU b is connected to the third CU through a third F1 interface.

[0239] Based on the above technical solution, the service migration of the first DU of the first IAB node can be realized, and the first MT of the first IAB node can maintain an RRC connection with the second CU during the handover of the first DU.

[0240] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the first DU mentioned above includes the first DU a and the first DU b, the first IAB node identifier in the fifth message mentioned above includes the identifier of the first DU a, and the first IAB node identifier in the first message mentioned above includes the identifier of the first DU b.

[0241] Based on the above technical solution, the third CU can know that the first DU of the first IAB node has established a connection with it, so as to ensure that subsequent services can be executed normally.

[0242] In conjunction with the eighth aspect, in some implementations of the eighth aspect, the receiving unit is further configured to receive a first update message from the third CU, the first update message including second uplink endpoint information corresponding to the first DRB of the first UE, the second uplink endpoint information including the IP address of the third CU and the uplink TEID of the third CU; the processing unit is further configured to update the uplink TEID and uplink mapping configuration of the F1-U corresponding to the first DRB according to the first update message.

[0243] Based on the above technical solution, the entire business path of the F1 interface user plane is opened up, enabling the first IAB node to accurately receive accurate business data.

[0244] In conjunction with the eighth aspect, in some implementations of the eighth aspect, when the first CU and the second CU are the same CU, the sending unit is further configured to send the first message to the third CU; or, when the second CU and the third CU are the same CU, the sending unit is further configured to send the fifth message to the first CU.

[0245] Based on the above technical solution, the second CU can have a dual role, increasing the flexibility of the solution.

[0246] In a ninth aspect, a communication device is provided, which is used to implement the method in any possible implementation of the method design of the first aspect, or to implement the method in any possible implementation of the method design of the second aspect, or to implement the method in any possible implementation of the method design of the third aspect, or to implement the method in any possible implementation of the method design of the fourth aspect.

[0247] In a tenth aspect, a communication device is provided, characterized in that it includes a processor coupled to a memory for storing computer programs or instructions, the processor for executing the computer programs or instructions in the memory such that a method in any possible implementation of the method design of the first aspect is executed, or a method in any possible implementation of the method design of the second aspect is executed, or a method in any possible implementation of the method design of the third aspect is executed, or a method in any possible implementation of the method design of the fourth aspect is executed.

[0248] Eleventhly, a computer-readable storage medium is provided, storing a computer program or instructions for implementing the method in any possible implementation of the method design of the first aspect, or the method in any possible implementation of the method design of the second aspect, or the method in any possible implementation of the method design of the third aspect, or the method in any possible implementation of the method design of the fourth aspect.

[0249] In a twelfth aspect, a computer program product is provided, comprising a computer program or instructions that, when executed by a computer, cause a device to perform a method in any possible implementation of the method design of the first aspect, or a method in any possible implementation of the method design of the second aspect, or a method in any possible implementation of the method design of the third aspect, or a method in any possible implementation of the method design of the fourth aspect.

[0250] In a thirteenth aspect, a communication system is provided, comprising a first network device for implementing the method in any possible implementation of the method design in the first aspect; a second network device for implementing the method in any possible implementation of the method design in the second aspect; a third network device for implementing the method in any possible implementation of the method design in the third aspect; and a fourth network device for implementing the method in any possible implementation of the method design in the fourth aspect. Attached Figure Description

[0251] Figure 1 This is a schematic diagram of an IAB standalone network provided in an embodiment of this application.

[0252] Figure 2 This is a schematic diagram of an IAB network user plane and control plane protocol stack provided in an embodiment of this application.

[0253] Figure 3 This is a schematic diagram of a mobile IAB scenario provided in an embodiment of this application.

[0254] Figure 4 This is a schematic diagram of the IAB node DU handover scenario provided in the embodiments of this application.

[0255] Figure 5 This is a schematic diagram illustrating a method for switching IAB hosts between IAB nodes.

[0256] Figure 6 This is a schematic diagram of a negotiation method between CU1 and CU2.

[0257] Figure 7 This is a schematic diagram of an IAB network system architecture provided in an embodiment of this application.

[0258] Figure 8 This is a schematic diagram of a communication method provided in an embodiment of this application.

[0259] Figure 9 This is a schematic diagram of another communication method provided in the embodiments of this application.

[0260] Figure 10 This is a schematic diagram of another communication method provided in the embodiments of this application.

[0261] Figure 11 This is a schematic diagram of another communication method provided in the embodiments of this application.

[0262] Figure 12 This is a schematic diagram of another communication method provided in the embodiments of this application.

[0263] Figure 13 This is a schematic diagram of another communication method provided in the embodiments of this application.

[0264] Figure 14 This is a schematic diagram of another communication method provided in the embodiments of this application.

[0265] Figure 15 This is a schematic diagram of an information sending device 1500 provided in an embodiment of this application.

[0266] Figure 16 This is a schematic diagram of an information receiving device 1600 provided in an embodiment of this application.

[0267] Figure 17 This is a schematic diagram of an information transmission device 1700 provided in an embodiment of this application.

[0268] Figure 18 This is a schematic diagram of an information receiving device 1800 provided in an embodiment of this application. Detailed Implementation

[0269] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0270] In an IAB network, an IAB node can provide radio access services to a UE, and the UE's service data is transmitted by the IAB node to the IAB donor via a radio backhaul link. In this embodiment, the IAB donor can also be referred to as a donor node or a donor base station (donor GNodeB, DgNB).

[0271] In some possible embodiments, an IAB node may include an MT (Mediator) portion and a DU (User Unit) portion. Specifically, when an IAB node faces its parent node (which can be another IAB node or an IAB host), the IAB node can be considered a terminal device, and the IAB node interacts with the parent node as an MT based on the functional logic of the MT portion. When an IAB node faces its child node (which can be another IAB node or a regular UE), the IAB node can be considered a network device, and the IAB node interacts with the child node as a DU based on the functional logic of the DU portion.

[0272] It should be understood that the MT portion of the IAB node has some or all of the functions of the UE.

[0273] In some possible embodiments, the aforementioned IAB host can be an access network element with full base station functionality, or it can be an access network element with separate CU and DU configurations. The IAB host can connect to the core network serving the UE, such as a 5G core network (5G core, 5GC), and provide radio backhaul functionality for the IAB node. The CU of the IAB host can also be in a configuration with separate control plane (CP) and user plane (UP). For example, the CU can include one CU-UP and at least one CU-CP.

[0274] Figure 1 This illustration shows a schematic diagram of an IAB standalone network provided in an embodiment of this application.

[0275] In some possible implementations, multi-hop networking may be employed in IAB networks to ensure network coverage performance. Furthermore, considering the reliability requirements of service transmission, IAB nodes can support dual connectivity (DC) or multi-connectivity to handle potential anomalies in the backhaul link, such as link interruptions, blockages, and load fluctuations, thereby improving transmission reliability. Therefore, IAB networks can support single-hop networking, multi-hop networking, and multi-connectivity networking.

[0276] Therefore, it can be seen that there can be at least one transmission path consisting of multiple links between the UE served by the IAB node and the IAB host. Moreover, a transmission path can contain multiple nodes, such as the UE, one or more IAB nodes, and the IAB host. If the IAB host has a separate CU and DU configuration, then the transmission path also includes the DU and CU portions of the IAB host.

[0277] It should be understood that each IAB node considers the adjacent nodes that provide access and backhaul services to it as its parent nodes, and correspondingly, each IAB node can be considered a child node of its parent node. (Reference) Figure 1 As shown, the parent node of IAB node 1 is the IAB host, which in turn is the parent node of IAB nodes 2 and 3. Furthermore, both IAB nodes 2 and 3 are the parent nodes of IAB node 4. Similarly, the parent node of IAB node 5 is IAB node 2. The UE's uplink data packets can be transmitted to the IAB host via one or more IAB nodes, and then the IAB host sends them to the mobile gateway device, such as the user plane function (UPF) network element in 5GC. Downlink data packets are received by the IAB host from the mobile gateway device and then sent to the UE via IAB nodes. Figure 1 The diagram shows an IAB standalone (SA) networking scenario, where both the IAB node and the UE establish a connection with the network only through the NR standard air interface.

[0278] Figure 1 The IAB standalone networking scenario shown is merely an example. There are many other possible scenarios in IAB scenarios that combine multi-hop and multi-connection.

[0279] In some possible embodiments, reference Figure 1 As shown, an IAB host can form a dual-connection with an IAB node under another IAB host to serve the UE. That is, the UE supports dual connections. The first connection directly accesses the cell served by the IAB host DU, and the second connection establishes a connection with another IAB node X. The IAB host that this IAB node X connects to is different from the IAB host corresponding to the UE in the first connection. And so on, without going into further detail.

[0280] Figure 2 This illustration shows a schematic diagram of an IAB network user plane and control plane protocol stack provided in an embodiment of this application.

[0281] For IAB networks, a new protocol layer, the BAP layer, is introduced in the radio backhaul link portion of the communication system. This layer sits above the radio link control (RLC) layer and is used to implement functions such as packet routing and bearer mapping on the radio backhaul link. It should be understood that below the RLC layer are the media access control (MAC) layer and the physical layer (PHY).

[0282] In an IAB network, a radio resource control (RRC) connection can be established between the MT (Mediator) of an IAB node and the IAB host (specifically, the CU (Combined Unit) of the IAB host). Therefore, the IAB host can send RRC messages to the MT of the IAB node through this RRC connection, and can also receive RRC messages from the MT of the IAB node to perform radio resource management functions.

[0283] In an IAB network, an F1 interface can be established between the DU (User Node) of an IAB node and the IAB host (specifically, the CU of the IAB host). Because this F1 interface is an interface within the IAB network, it is often referred to as F1* for ease of distinction. However, in this embodiment, it is uniformly referred to as the F1 interface. This F1 interface can support user plane protocols, and on the user plane side, it can be abbreviated as F1-U or F1*-U; it can also support control plane protocols, and on the control plane side, it can be abbreviated as F1-C or F1*-C. (Refer to...) Figure 2 In (a), the user plane protocol of the F1 interface may include at least one of the following protocol layers: General Packet Radio Service (GPRS) GTP-U, User Datagram Protocol (UDP), or Internet Protocol (IP), etc.; (See reference) Figure 2 In (b), the control plane protocol of the F1 interface may include at least one of the following protocol layers: F1 application protocol (F1AP), stream control transport protocol (SCTP), or IP protocol layer.

[0284] Through the control plane of the F1 interface, the IAB node and the IAB host can perform interface management, manage the DU of the IAB node, and perform UE context-related configurations. Through the user plane of the F1 interface, the IAB node and the IAB host can perform user plane data transmission and downlink transmission status feedback.

[0285] IAB nodes can exchange data through the backhaul RLC channel, and the DU and CU of the IAB host can exchange data through the host's internal F1 interface.

[0286] Figure 3 A schematic diagram of a mobile IAB scenario provided by an embodiment of this application is shown.

[0287] In some possible embodiments, IAB nodes in the IAB network can be fixedly deployed or deployed on vehicles, such as buses, cars, trains, and ships. Therefore, the location of the IAB node can change as the vehicle moves. In this application, these IAB nodes are referred to as mobile IAB nodes (Mobile IAB nodes) or vehicle-mounted relays (VMRs), and mobile IAB nodes also include MTs and DUs to ensure access services are provided to the UE.

[0288] refer to Figure 3 As shown, a mobile IAB node, specifically a mobile IAB node DU, may have its CU connected to it change during the movement process due to factors such as network coverage or load balancing. That is, the mobile IAB node DU switches the CU of the IAB host it is connected to.

[0289] In some possible embodiments, although the CU connected to the DU of the mobile IAB node changes, the CU connected to the IAB host of the mobile IAB node's MT may remain unchanged.

[0290] In some possible embodiments, the aforementioned switching of the IAB host CU may not necessarily occur only with mobile IAB nodes. For ordinary fixed IAB nodes, for example, based on load balancing factors, the switching of the IAB host CU may also be initiated proactively. This application does not limit this aspect.

[0291] Figure 4 This illustration shows a scenario diagram of IAB node DU switching provided in an embodiment of this application.

[0292] In some possible embodiments, the IAB node DU switching can be achieved through two logical DUs, denoted as DU a and DU b (or simply IAB-DU a and IAB-DU b), which are connected to two different IAB hosts (specifically, they can be connected to two different IAB host CUs). That is, before the DU switching of the IAB node, the IAB node establishes a connection with the source host CU (specifically, through DU a establishing an F1 connection with the target host CU). After the DU switching operation of the IAB node, a connection is established between the IAB node and the target host CU (specifically, through DU b establishing an F1 connection with the target host CU). Since the DU part of the IAB node establishes an F1 connection (or F1 interface) with the IAB host node, the host node connected to the IAB-DU can be called the F1 terminating IAB donor (or simply F1 terminating donor), and the CU of this host can be called the F1 terminating IAB donor CU (or simply F1 terminating CU). Correspondingly, the source host node connected to IAB-DU a can be called the source F1 terminating IAB donor, and the CU of the source host node can be called the source F1 terminating IAB donor CU (or simply source F1 terminating CU). The target host node connected to IAB-DUb can be called the target F1 terminating IAB donor, and the CU of the target host node can be called the target F1 terminating IAB donor CU (or simply target F1 terminating CU).

[0293] In this invention, the switching of the DU of the IAB node can also be regarded as the migration of the DU of the IAB node between different host CUs, which can be simply referred to as the DU migration of the IAB node. Furthermore, in this invention, the host CU connected to the MT portion of the IAB node maintains the RRC connection for that MT. Therefore, the host node to which the IAB-MT is connected can be called the RRC terminating donor (or RRC terminating IAB donor) of the IAB node, and the CU of that host node can be called the RRC terminating CU, RRC terminating donor CU, or RRC terminating IAB donor CU.

[0294] It should be noted that, in the embodiments of this application, regarding the process of an IABDU switching from a source F1 endpoint host node to a target F1 endpoint host node, considering that the source F1 endpoint host node or the target F1 endpoint host node may be a CU-DU separated architecture, the switching of the IABDU can be described as the IABDU switching from the source F1 endpoint CU to the target F1 endpoint CU. The descriptions in the embodiments of this application also frequently use "source F1 endpoint CU" and "target F1 endpoint CU" as examples. If the source F1 endpoint host or the target F1 endpoint host is not a CU-DU separated architecture, then the source / target F1 endpoint CU in the description will be replaced with the corresponding source / target F1 endpoint host node for understanding. Alternatively, if the source / target F1 endpoint CU is a CU-CP and CU-UP separated architecture, then the source / target endpoint CU in the corresponding description can be replaced with the corresponding source / target endpoint CU-CP for understanding. Similarly, if the RRC endpoint host node (or non-F1 terminating IAB donor) of the IAB node is not a CU-DU separated architecture, then the RRC endpoint CU in the description should be replaced with the RRC endpoint host node (or non-F1 terminating IAB donor) for understanding; or, if the RRC endpoint host node (RRC terminating IAB donor, or non-F1 terminating IAB donor) of the IAB node is a CU-CP and CU-UP separated architecture, then the RRC endpoint CU in the corresponding description can be replaced with the RRC endpoint CU-CP (RRC terminating IABdonor CU-CP, or non-F1 terminating IAB donor CU-CP) for understanding.

[0295] During the DU handover operation of an IAB node, the IAB host CU connected to the MT of the IAB node remains unchanged. Based on this premise, the following three handover scenarios can be included:

[0296] Figure 4 (a) in the figure shows a schematic diagram of scenario 1 of IAB node DU switching provided in an embodiment of this application.

[0297] Scenario 1: The DU of the first IAB node switches from the second IAB host (whose CU part is CU2) to the third IAB host (whose CU part is CU3). During this period, the MT (IAB-MT) of the first IAB node is always connected to the second IAB host (whose CU part is CU2).

[0298] In this scenario, CU2 is the source F1 endpoint CU of the first IAB node, and CU3 is the target F1 endpoint CU of the first IAB node. In this scenario, IAB-MT is also connected to CU2, therefore CU2 also maintains the RRC connection of IAB-MT. Thus, in this scenario, CU2 is both the source F1 endpoint CU and the RRC endpoint CU (RRC terminating CU) of the first IAB node. In addition to the CU portion, the IAB host node also has a DU portion (IAB donor DU). The DU portion of the second IAB host is abbreviated as donorDU2, which establishes an F1 interface with CU2. The DU portion of the third IAB host is abbreviated as donorDU3, which establishes an F1 interface with CU3.

[0299] Figure 4 (b) shows a schematic diagram of scenario 2 of IAB node DU switching provided in the embodiments of this application.

[0300] Scenario 2: The DU of the first IAB node switches from the first IAB host (whose CU part is CU1) to the second IAB host (whose CU part is CU2). During this period, the MT (IAB-MT) of the first IAB node is always connected to the second IAB host (whose CU part is CU2).

[0301] In this scenario, CU1 is the source F1 endpoint CU of the first IAB node, and CU2 is the target F1 endpoint CU of the first IAB node. In this scenario, IAB-MT is also connected to CU2, therefore CU2 is both the target F1 endpoint CU of the first IAB node and the RRC terminating endpoint CU of the IAB node. Additionally, the DU portion of the second IAB host is abbreviated as donorDU2, which establishes an F1 interface with CU2 as the DU portion of the second IAB host. The DU portion of the first IAB host is abbreviated as donorDU1, which establishes an F1 interface with CU1 as the DU portion of the first IAB host.

[0302] Figure 4 (c) shows a schematic diagram of scenario 3 of IAB node DU switching provided in the embodiments of this application.

[0303] Scenario 3: The DU of the first IAB node switches from the first IAB host (its CU part is CU1) to the third IAB host (its CU part is CU3). During this period, the MT of the first IAB node is always connected to the second IAB host (its CU part is CU2).

[0304] In this context, CU1 is the source F1 endpoint CU of the first IAB node, CU3 is the target F1 endpoint CU of the first IAB node, and CU2 is the RRC endpoint CU of the first IAB node. Furthermore, the DU portion of the first IAB host is abbreviated as donorDU1, which establishes an F1 interface with CU1; the DU portion of the second IAB host is abbreviated as donorDU2, which establishes an F1 interface with CU2; and the DU portion of the third IAB host is abbreviated as donorDU3, which establishes an F1 interface with CU3.

[0305] It should be noted that in the illustrations of scenarios 1, 2 and 3 above, the first IAB node is directly connected to the DU part of the second IAB host (i.e., donorDU2), and then connected to CU2 through donorDU2. In actual deployment scenarios, the first IAB node may connect to donorDU2 through one or more other IAB nodes (these other IAB nodes can be called intermediate IAB nodes), and then connect to CU2 through donorDU2. This application does not limit this.

[0306] In some possible embodiments, for scenario 1 above, the DU of the first IAB node switches from CU2 to CU3. During this process, the MT of the first IAB node is still connected to the network under the jurisdiction of CU2. Therefore, the DU of the first IAB node (see...) Figure 4 The service shown in (a) of DU (b) requires transmission via the network topology of CU2, i.e., cross-topology transmission. It should be understood that in IAB networking technology, for services requiring cross-topology transmission via IAB nodes, the service must be hosted by the F1 endpoint of the first IAB node (specifically, this could be hosted by the F1 terminating CU, see [link]). Figure 4 The backhaul network topology of CU3 shown in (a) to which the IAB node is connected belongs to the IAB host (this IAB host can be regarded as a non-F1 terminating donor, and its CU part is the non-F1 terminating donor CU, see [reference]). Figure 4 As shown in (a) above, CU2) initiates a service negotiation process to negotiate the QoS requirements of services transmitted across topologies, the configuration in the radio backhaul network topology connected to the IAB node, and the QoS labels to be added to the service data packets. Similarly, when the radio backhaul link configuration related to UE services needs to be released in the radio backhaul network connected to the IAB node due to reasons such as UE switching to another cell, data exchange is also required between the relevant CUs for the services to be released. The QoS labels mentioned in this application can be Differential Service Information and / or Internet Protocol version 6 (IPv6) flow labels. Specifically, Differential Service Information can be DSCP, or the Type of Service (ToS) in the IPv4 header, or the Traffic Class (service type) in the IPv6 header, or the first 6 bits of the Traffic class field in the IPv6 header, etc.

[0307] Therefore, in Scenario 1, an F1 connection needs to be established between DU b and CU3 of the first IAB node. After or during the handover process of the UE served by the first IAB node, CU3 initiates a service negotiation process with CU2. This process is called the IAB Transport Migration Management (IAB) negotiation process. This negotiation process can be executed once after each UE handover (or during each UE handover). Furthermore, this negotiation process also carries the traffic information that needs to be added, which will generate significant signaling overhead. The traffic information can be presented in the form of the following list:

[0308] List of services to be added (Traffic To Be Added List)

[0309] >Proposed Added Item (Traffic To Be Added Item)

[0310] >>Traffic Index

[0311] >>Business Overview (Traffic Profile)

[0312] >>F1 Terminating Topology BH Information

[0313] In some possible embodiments, for scenario 2 above, the DU of the first IAB node switches from CU1 to CU2. Specifically, this can be achieved by establishing an F1 connection between the DU b of the first IAB node and CU2. After the UE served by the first IAB node performs the corresponding handover procedure, CU1, as the original F1 terminating CU, initiates a service deletion negotiation procedure (or service release negotiation procedure) with CU2 (as a non-F1 terminating CU). This negotiation procedure also belongs to the aforementioned IAB transport migration management negotiation procedure. The reason for initiating the service deletion negotiation procedure is that from CU1's perspective, the UE has been switched over, so these traffics of the UE no longer need to be managed by CU1. Therefore, CU1 needs to negotiate with CU2, requesting CU2 to release the configuration information provided for the UE's traffic in the radio backhaul network managed by CU2, which was previously agreed upon with CU1. As can be seen, the negotiation process for deleting the service also carries the traffic information that needs to be deleted. Moreover, this negotiation process can be executed once after each UE handover, which will generate significant signaling overhead. The traffic information can be presented in the form of the following list:

[0314] Select: Traffic Release type

[0315] Full Release

[0316] >>All Traffic Indication

[0317] Partial Release

[0318] >>List of services to be released (Traffic To Be Released List)

[0319] >>>The proposed release of the Traffic To Be Released Item (IE)

[0320] >>>>Traffic Index

[0321] >>>>Return Info List (BH Info List)

[0322] In some possible embodiments, for scenario 3 above, negotiation between the IAB host CUs is also required. The content of the negotiation includes the content that needs to be negotiated in scenarios 1 and 2 above. Correspondingly, the problem of high signaling overhead in scenarios 1 and 2 above also exists.

[0323] Figure 5 A schematic diagram of a method for switching IAB hosts by an IAB node is shown.

[0324] In some possible embodiments, the first IAB node can perform a switchover of the IAB host CU via its MT, see reference. Figure 5 As shown, the MT of the first IAB node switches from CU1 to establish a connection with CU2, but the DU of the first IAB node remains connected to CU1; that is, the DU of the first IAB node does not switch. After the MT of the first IAB node switches, communication between the DU of the first IAB node and CU1 needs to be transmitted through the IAB network under the jurisdiction of CU2, to which the MT is connected. Therefore, CU1 and CU2 also need to negotiate.

[0325] Figure 6 A schematic diagram of a negotiation method between CU1 and CU2 is shown.

[0326] refer to Figure 6 As shown, CU1 (F1 endpoint CU) can send IAB transmission migration management request information to CU2 (non-F1 endpoint CU). After receiving the request, CU2 will return IAB transmission migration management response information to CU1. Then, in the IAB network under the jurisdiction of CU2, backhaul link configuration is performed for the services of the IAB DU. The configuration content may include: routing configuration, radio backhaul (RLC) channel mapping configuration, etc. It should be understood that the aforementioned F1 endpoint CU can be either a source F1 endpoint CU or a destination F1 endpoint CU, and the aforementioned non-F1 endpoint CU can be an RRC endpoint CU. Similarly, when certain services managed by the IAB DU need to be removed, such as UE service termination or UE handover, CU1, which has established an F1 connection with the IAB DU, also needs to initiate an IAB transmission migration management negotiation process with CU2 to request the release of the corresponding services.

[0327] In the above example, the handover of the IAB host CU is achieved through the MT of the IAB node. Although the UEs served by the IAB node do not need to follow the MT to perform the handover, the relevant configuration of all UE services can be completed through a single service negotiation between the IAB host CUs, which will not cause a large signaling overhead. However, for the above scenarios 1, 2 and 3, there are cases where the DU of the IAB node needs to be handed over, which will inevitably involve the handover of UEs. Without considering the optimization of UE group handover, the handover commands for UEs exchanged between the IAB host CUs are performed one UE at a time. Furthermore, in scenarios 1, 2, and 3, the MT of the IAB node does not require handover, and its connected radio backhaul network remains unchanged. However, due to the handover of the DU of the IAB node, the IAB host CU (target F1 terminating CU) connected to the DU after the handover may need to negotiate IAB transport migration management for each UE served by the IAB node. This negotiation is necessary to perform corresponding configuration or deletion of services for the added or removed UE in the radio backhaul network (i.e., the network under the jurisdiction of the RRC terminating CU) connected to the IAB node. Moreover, these processes need to be executed after each UE handover, introducing a large amount of signaling interaction related to the Xn interface between IAB host CUs, as well as reconfiguration signaling interaction by the RRC terminating CU through the F1 interface on the backhaul link traversed by the IAB node in the radio backhaul network under the jurisdiction of the RRC endpoint IAB host, which can easily cause signaling storms.

[0328] In view of this, this application proposes a communication method that optimizes the current communication process to reduce signaling overhead, taking into account the service characteristics of the IAB network in the above-mentioned scenarios 1, 2 and 3.

[0329] Considering the service characteristics of the IAB network in scenarios 1, 2, and 3 above: For scenarios 1 and 3, when the UE follows the DU of the IAB node from the source F1 endpoint CU (CU2 in scenario 1, or CU1 in scenario 3) to the target F1 endpoint CU (CU3 in scenarios 1 and 3), the UE's traffic is still transmitted through the IAB network of CU2, and the QoS requirements of the service do not change. Therefore, the configuration of the radio backhaul network under the jurisdiction of CU2 does not actually need to be changed. For scenarios 2 and 3, when the UE follows the DU of the IAB node from the source F1 endpoint CU (CU1 in scenario 2 and 3) to the target F1 endpoint CU (CU2 in scenario 2, or CU3 in scenario 3), CU1 will request CU2 to release the configuration of the UE's service. After releasing the configuration of the UE's service, CU2 will also reconfigure the radio backhaul link for the UE's service based on the requirements of the target F1 endpoint CU. Since the QoS requirements of the UE's service do not change during this process, the UE's service remains unchanged. Based on this, the communication method proposed in this application embodiment is as follows: in a scenario where the IAB node DU is switching over, but the IAB node MT is always connected to the RRC endpoint CU, the RRC endpoint CU or the IAB node sends an indication message to the target F1 endpoint CU or the source F1 endpoint CU. The indication message indicates that the target F1 endpoint CU or the source F1 endpoint CU does not need to initiate relevant negotiation messages for adding or releasing services to the RRC endpoint CU due to the IAB node DU switching over, thereby saving signaling overhead.

[0330] It should be understood that the embodiments of this application are mainly applied to IAB networks, especially scenarios involving IAB node DU handover. For a description of the specific scenarios, please refer to [link to relevant documentation]. Figure 4 The descriptions of the three corresponding scenarios are not detailed here. In these scenarios, the IAB node is used to serve the UE. The IAB node can be a mobile IAB node or a fixed IAB node. As long as the DU of the IAB node undergoes a switch of the IAB host CU, and the MT of the IAB node does not need to switch its connected IAB host CU, the technical solution proposed in the embodiments of this application can be applied.

[0331] The technical solutions of this application are applicable to various communication networks, such as 5th generation (5G) mobile communication systems like Long Term Evolution (LTE) networks, Enhanced Long Term Evolution (eLTE) networks, and New Radio (NR) networks, as well as 6th generation (6G) communication systems or other future-oriented communication systems. Furthermore, the communication system provided in this application can be used in non-terrestrial networks (NTNs).

[0332] Figure 7 A schematic diagram of an IAB network system architecture applicable to embodiments of this application is shown. The functions of the terminal devices and various network entities are described below.

[0333] UE: Represents a terminal device, which connects to the DU of an IAB node in the IAB network and receives IAB services from the IAB network. Terminal equipment refers to various devices that can provide voice and / or data connectivity to users and can communicate with one or more core networks via a Radio Access Network (RAN). Terminal equipment can also be called a terminal, user equipment (UE), mobile station, mobile terminal, etc. Terminals can be applied to various communication scenarios, such as device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, self-driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, and smart city. Terminal devices can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, aerospace equipment, drones, etc. In the embodiments of this application, the chip used in the above-mentioned devices can also be referred to as a terminal. It should be understood that this application does not limit the terminal device to a UE (User Equipment), and the UE can be replaced with other terminal devices.

[0334] IAB Node: Used to provide IAB services to child nodes or UEs, including the MT part and the DU part.

[0335] IAB Host: A base station that supports communication between IAB nodes, also known as a host base station, including an IAB host CU and at least one IAB host DU. The IAB host CU part may further include an IAB host CU-CP and at least one IAB host CU-UP.

[0336] Master eNB (MeNB): A base station for the LTE standard, referring to the UE or IAB node in the ultra-NR dual connection (EN-DC) mode with 4G as the primary node and 5G as the secondary node.

[0337] 5G base station (GNodeB, gNB): A 5G standard base station, which is either a primary or secondary base station for UE or IAB nodes in EN-DC mode.

[0338] 5GC: 5G core network, used for authentication of terminal devices, mobility management, protocol data unit (PDU) session management, etc., including but not limited to the following network elements:

[0339] Access and mobility management function (AMF): Primarily responsible for terminal device access management, mobility management, network slice selection, and SMF selection; in addition, it is also responsible for transmitting user policies between terminal devices and policy control function (PCF).

[0340] SMF: Primarily responsible for the control plane functions of terminal device session management, including the selection and control of user plane functions (UPF), Internet Protocol (IP) address allocation, session establishment, session QoS management, and obtaining policy and charging control (PCC) policies (from PCF).

[0341] UPF: As the anchor point for protocol data unit (PDU) session connections, it is responsible for filtering data packets from terminal devices, transmitting / forwarding data, controlling rates, generating billing information, and providing connectivity to the data network (DN).

[0342] The 5G core network may also include network elements such as DN, network exposure function (NEF), application function (AF), authentication server function (AUSF), network slice selection function (NSSF), and PCF.

[0343] Evolved Packet Core (EPC): Also known as the 4G core network, it is used for authentication of terminal devices, mobility management, public data network (PDN) connection management, etc., including network elements such as mobility management entity (MME) and packet data gateway (PGW).

[0344] It should be noted that the aforementioned "network element" can also be referred to as an entity, device, apparatus, or module, etc., and this application does not specifically limit it. Furthermore, in this application, for ease of understanding and explanation, the description of "network element" is omitted in some descriptions. For example, the UPF network element is abbreviated as UPF. In this case, "UPF" should be understood as a UPF network element or a UPF entity. The following descriptions of the same or similar cases are omitted.

[0345] It should be noted that, Figure 7 The names of the various network elements included are merely names and do not limit the function of the network element itself. In 5G networks and other future networks, the aforementioned network elements may also have other names, and this application embodiment does not specifically limit this. For example, in 6G networks, some or all of the aforementioned network elements may use the terminology from 5G, or they may have other names, etc. This is uniformly explained here and will not be repeated below.

[0346] It should be noted that, Figure 7 The various network elements in the network do not necessarily have to exist at the same time; the required network elements can be determined based on the needs. Figure 7 The connection relationships between the various network elements are not uniquely determined and can be adjusted according to requirements.

[0347] It is understood that the aforementioned network elements or functions can be network components in hardware devices, software functions running on dedicated hardware, or virtualization functions instantiated on a platform (e.g., a cloud platform).

[0348] refer to Figure 7As shown, each IAB node's DU establishes a connection with the IAB host CU via an F1 interface. This F1 interface comprises two parts: a control plane interface and a user plane interface. The user plane interface is maintained between the IAB node DU and the IAB host CU-UP, while the control plane interface is maintained between the IAB phase DU and the IAB host CU-CP. It should be noted that the F1 interface between the IAB node DU and the IAB host CU... Figure 4 and Figure 7 It is not shown in the middle.

[0349] refer to Figure 7 As shown, when an IAB node operates in SA mode, it can connect to a single parent node or connect to two parent nodes. The parent node of an IAB node can be the IAB host, the IAB host DU in a CU-DU separation architecture, or another IAB node. These two parent nodes can be controlled by the same IAB host or by different IAB hosts.

[0350] A connection between an IAB node's DU and an IAB host can be established by setting up an F1 interface. This IAB host can connect to the 5GC. Specifically, the IAB host CU-CP can connect to control plane network elements in the 5GC, such as the AMF network element, via the control plane's NG interface (i.e., the N2 interface). Similarly, the IAB host CU-UP can connect to user plane network elements in the 5GC, such as the UPF network element, via the user plane's NG interface.

[0351] When the IAB node operates in non-standalone (NSA) mode or EN-DC mode, the IAB host CU-UP can connect to the EPC, such as the serving gateway (SGW), through the user plane S1 interface. The MeNB and the MT of the IAB node are connected through the LTE Uu air interface. The MeNB and the IAB host CU-CP are connected through the X2-C interface. The MeNB is connected to the EPC through the S1 interface, which includes the user plane (S1-U) and the control plane (S1-C).

[0352] In some possible embodiments, Figure 7 The MeNB shown can also be replaced with gNB, correspondingly, Figure 7 The LTE-Uu interface in the 5GC can be replaced with the NR-Uu interface. The gNB can establish user plane and / or control plane interfaces with the 5GC. The gNB and the IAB host provide dual connectivity services for the IAB node. The gNB can act as the primary base station or the secondary base station for the IAB node.

[0353] Based on the aforementioned IAB network system, this application proposes a communication method.

[0354] Figure 8 A schematic diagram of a communication method proposed in an embodiment of this application is shown.

[0355] This communication method is applied to an IAB network, which includes a first IAB node, a first IAB host, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first IAB host includes a first CU, the second IAB host includes a second CU, and the third IAB host includes a third CU. The second CU and the first MT of the first IAB node have an RRC connection.

[0356] After the first DU of the first IAB node migrates from the first CU to the third CU, the following steps will be performed:

[0357] S810: The aforementioned third CU receives the first message;

[0358] In some possible embodiments, the first message mentioned above may come from a second CU.

[0359] S820: Based on the first message, the third CU is exempt from negotiating with the second CU regarding the transmission migration management of the first IAB node.

[0360] In some possible embodiments, the transmission migration management negotiation process in S820 above may specifically be a business negotiation process for initiating the addition of services.

[0361] In addition, after the first DU of the first IAB node migrates from the first CU to the third CU, the following steps will be performed:

[0362] S830: The first CU mentioned above receives the fifth message;

[0363] In some possible embodiments, the aforementioned fifth message may originate from the second CU.

[0364] S840: According to the fifth message mentioned above, the first CU is exempt from negotiating with the second CU regarding the transmission migration management of the first IAB node.

[0365] In some possible embodiments, the transmission migration management negotiation process in S840 above may specifically be a service negotiation process for releasing services.

[0366] It should be understood that in the above scenario, the first CU can be the source F1 endpoint CU, the second CU can be the RRC endpoint CU, and the third CU can be the target F1 endpoint CU.

[0367] It should be understood that the above Figure 8 The corresponding embodiments can be extended to the above-mentioned scenarios 1, 2 and 3. The communication method provided by the embodiments of this application will be further described below in conjunction with the above-mentioned scenarios 1, 2 and 3. Figure 9 A schematic diagram of another communication method provided in an embodiment of this application is shown.

[0368] This communication method is applied to an IAB network, which includes at least a first IAB node, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first DU switches from CU2 (connected to the second IAB host node) to CU3 (connected to the third IAB host node). Before and after the first DU switch, the first MT maintains an RRC connection with the second IAB host node. This connection state is referred to as the first connection state in this embodiment. The switch of the first DU can be achieved by two logical DUs (first DU a and first DU b) connecting to the second and third IAB host nodes respectively, as described above. This scenario corresponds to scenario 1 proposed in the above embodiment.

[0369] The roles of the three CUs (RRC terminating CU, source F1 terminating CU, and target F1 terminating CU) in Scenario 1 can be found in the descriptions above.

[0370] S930: The target F1 endpoint CU (CU3) of the first IAB node receives a first message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0371] It should be understood that, based on the corresponding description of the above embodiments, during the UE's handover process following the first DU, if the UE's services that do not require the target F1 endpoint CU (CU3) to serve the first IAB node initiate a service negotiation process with the first IAB node's RRC endpoint CU (CU2, or non-F1 terminating IAB donor CU), then CU3, as the target F1 endpoint CU, needs to be aware of this. Correspondingly, since whether the first MT needs to switch the IAB host CU can be determined by the RRC endpoint CU, if no handover operation is required for the first MT, then CU2, as the RRC endpoint CU, can send the aforementioned first message to CU3 after learning that the F1 interface connection between the first IAB node and CU3 has been successfully established.

[0372] Therefore, upon receiving the aforementioned first message, CU3 decides not to negotiate the transmission migration management of the first IAB node with CU2. Services between CU3 and the first IAB node will continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0373] Based on the above technical solution, it is possible to reasonably avoid the situation where CU3 initiates IAB transport migration management procedures to CU2 during the process of UE serving the first IAB node switching from CU2 to CU3 with the first DU (such as the IAB transportmigration management procedure, which is used to request the relevant configuration of the radio backhaul link for the service of the first IAB node in the IAB network under the jurisdiction of CU2), thereby saving the signaling overhead of the Xn interface and F1 interface.

[0374] In some possible embodiments, the first message is generated by the RRC endpoint CU (CU2) of the first IAB node after determining that the first MT is always connected to the second IAB host before and after the first DU handover, and is sent to the target F1 endpoint CU (CU3) of the IAB node.

[0375] In some possible embodiments, the first message may include a first IAB node identifier, which includes at least one of the following: a UE XnAP identifier of the first MT, an identifier of the first DU, and a BAP address of the first MT. The first DU identifier may be the identifier of the DU (e.g., the first DU b) that establishes a connection with the target F1 endpoint CU (CU3). The UE XnAP identifier of the first MT may be a UE XnAP ID assigned to the first MT by the RRC endpoint CU of the IAB node.

[0376] Since the RRC endpoint CU (CU2) of the aforementioned IAB node needs to include the aforementioned first DU identifier in the first message, the aforementioned first IAB node needs to send the first DU identifier to the aforementioned CU2 in advance. The first DU identifier can be sent to CU2 by the aforementioned first IAB node through an RRC message or an F1AP message.

[0377] Based on the aforementioned first IAB node identifier, the target F1 endpoint CU (CU3) of the IAB node can determine that the indication information is directed to the first IAB node and the first MT corresponding to that first IAB node, thus ensuring that subsequent services can be executed normally. Furthermore, upon receiving the first message, the target F1 endpoint CU (CU3) is exempt from transmission migration management negotiation regarding all services transmitted by the first IAB node.

[0378] In some possible embodiments, the first message includes an All traffic indication. Based on this All traffic indication, the target F1 endpoint CU (CU3) of the first IAB node does not need to initiate the relevant IAB transmission migration management process to the RRC endpoint CU for all services of the first DU of the first IAB node (e.g., F1-U services, F1-C services, non-F1 services, etc. of the first DU b). (This process is used to request CU2 to configure the radio backhaul link for the services of the first IAB node in its subordinate radio backhaul network.) This "All traffic indication" can be included in the first message explicitly or implicitly. For example, in one possible implicit approach, if the first message only contains the identifier of the first IAB node and does not contain any UE identifier, it can be considered an implicit "All traffic indication".

[0379] It should be understood that the various identifiers proposed in the embodiments of this application can be IDs of different objects, such as the ID of the first IAB node, the ID of the first DU, the UE XnAP ID of the first MT, etc.

[0380] In some possible embodiments, the aforementioned first message can be included in a notification message exchanged between the RRC endpoint CU (CU2) of the IAB node and the target F1 endpoint CU (CU3) in the form of an explicit IE, or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned first message can be used directly to indicate that the target F1 endpoint CU (CU3) does not need to negotiate the transmission migration management of the first IAB node with the RRC endpoint CU (CU2), or it can be used to indicate that the first MT does not need to switch the RRC endpoint CU (i.e., CU2), or it can be used to indicate that the radio backhaul link path of the service of the first DU remains unchanged.

[0381] In some possible embodiments, the first message may also include the identifier of the first UE or the identifier of the bearer corresponding to the first UE. The first UE is the UE served by the first IAB node, and the identifier of the bearer corresponding to the first UE may include the identifier of the first DRB or the identifier of the first SRB. Based on this, the target F1 endpoint CU (CU3) may, based on the first message, skip or eliminate the transmission migration management negotiation process with CU2 regarding the first UE, the first DRB, or the first SRB served by the first IAB node during the handover process of the first UE.

[0382] In some possible embodiments, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0383] In some possible embodiments, the RRC endpoint CU (CU2) may carry QoS information corresponding to F1-C traffic and / or non-F1 traffic in the first message described above; or, CU2 may carry QoS information corresponding to F1-C traffic and / or non-F1 traffic in another message sent to CU3, for example, in step S950. Further, if the first message is directed to the first DRB of the first UE, the first message may also include first QoS mapping information (or a first QoS label; a description of the QoS label can be found above), which includes the values ​​of the DSCP and / or the flow label in IPv6 corresponding to the first DRB of the first UE.

[0384] The aforementioned CU3 receives the first QoS mapping information of downlink services from CU2, and according to the first QoS mapping information, fills the IP header with the appropriate values ​​of DSCP and / or flow label in IPv6 for downlink data packets of the first DRB, or downlink data packets of F1-C services of the first DU, or downlink data packets of non-F1 services of the first DU.

[0385] Based on the above technical solution, the service quality of services provided for the first DU (which may include the services of the first UE) can be guaranteed without CU3 negotiating DU migration management with CU2.

[0386] In some possible embodiments, the following steps need to be performed before executing S930 above:

[0387] S910: Establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU3).

[0388] Specifically, the target F1 endpoint CU (CU3) receives a first request message (e.g., an F1 setup request message) from the first IAB node. This first request message is used to establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU3). Subsequently, the target F1 endpoint CU can send a response message (e.g., an F1 setupresponse message) to the first IAB node, thus establishing an F1 interface with the first IAB node.

[0389] In some possible embodiments, if the first IAB node is connected to different IAB host CUs, such as CU2 and CU3, through different logical DUs, such as the first DU a and the first DU b, where the first DU a is connected to CU2 and the first DU b is connected to CU3, then the first DU b can initiate an F1 connection establishment request to CU3 and then establish a third F1 interface, or target F1 interface, between the first DU b and CU3.

[0390] In some possible embodiments, the first IAB node may initiate the aforementioned F1 connection establishment request to the target F1 endpoint CU (CU3) after receiving a corresponding instruction from the source F1 endpoint CU (CU2 in scenario 1). Alternatively, the first IAB node may initiate the aforementioned F1 connection establishment request to CU3 based on the OAM configuration (which may be pre-configured). This application embodiment does not limit the specific triggering method of the F1 connection establishment request.

[0391] In some possible embodiments, the aforementioned first request information may carry a second message, which includes a first MT identifier and an RRC endpoint CU (CU2) identifier. The first MT identifier includes at least one of the following: the BAP address assigned to the first MT by the RRC endpoint CU (CU2), and the UE XnAP identifier assigned to the first MT by the RRC endpoint CU. The UE XnAP identifier assigned to the first MT by the RRC endpoint CU may be sent to the first MT by the RRC endpoint CU (CU2 in scenario 1) via a first RRC message, or sent to the first DU by the F1 endpoint CU (CU2 in scenario 1) via an F1AP message. The identifier of the RRC endpoint CU includes at least one of the following: the IP address of the RRC endpoint CU (CU2 in scenario 1), and the gNB identifier of the base station where the RRC endpoint CU (CU2 in scenario 1) resides (i.e., the gNB ID of the second IAB host).

[0392] S920: The first IAB node or the target F1 endpoint CU (CU3) sends a third message to the RRC endpoint CU (CU2), which indicates that the third F1 interface between the first IAB node and CU3 has been established.

[0393] In some possible embodiments, the third F1 interface between the CU3 and the first DU is created by triggering the Operation, Maintenance and Management (OAM) configuration. This third F1 interface includes a first control plane F1-C interface and a first user plane F1-U interface. The third message may also carry the identifier of the target F1 endpoint CU (CU3), which includes at least one of the following: the base station identifier or IP address of the target F1 endpoint CU (CU3).

[0394] Based on the aforementioned third message, CU2, the RRC endpoint CU of the first IAB node, can know that the target F1 endpoint CU is CU3, so as to ensure that CU2 can conduct accurate signaling interaction with CU3 in subsequent processes. For example, it can enable the RRC endpoint CU (CU2) to know which IAB host CU in the IAB network the target F1 endpoint CU (CU3) belongs to, so as to send the first message in step 830 to the target F1 endpoint CU in the future, thereby avoiding the initiation of unnecessary service migration management negotiations.

[0395] In some possible embodiments, the third message sent by the target F1 endpoint CU (CU3) to the RRC endpoint CU (CU2) may also include the aforementioned first MT identifier. The first MT identifier includes at least one of the following: the BAP address assigned to the first MT by the RRC endpoint CU (CU2), and the UE XnAP identifier assigned to the first MT by the RRC endpoint CU. If the identifier of the first MT includes the UE XnAPID assigned to the first MT by the RRC endpoint CU, this UE XnAP ID may be sent to the first MT in advance by the RRC endpoint CU (CU2 in scenario 1) via a first RRC message, or it may be sent to the first DU by the F1 endpoint CU (CU2 in scenario 1) via an F1AP message. Then, the first IAB node carries the UE XnAPID assigned to the first MT by the RRC endpoint CU and the identifier of the RRC endpoint CU (e.g., the IP address of CU2, or the gNB ID of the second IAB host node) in the uplink F1 message sent to the target F1 endpoint CU, for example, in the F1 setup request message when initiating an F1 connection establishment request to the target F1 endpoint CU (CU3) in step S910.

[0396] After completing the S930 above, the following steps can be performed:

[0397] S940: Target F1 endpoint CU (CU3) sends a first feedback message to RRC endpoint CU (CU2), which indicates that CU3 has successfully received the first message from CU2.

[0398] Step S940 is optional and can be omitted.

[0399] Based on the above technical solution, while reducing signaling overhead, it is possible to ensure that after the first DU of the first IAB node switches to the target F1 endpoint CU, the target F1 endpoint CU can provide it with corresponding wireless backhaul service.

[0400] Although the target F1 endpoint CU has the capability to provide F1 connection services to the first IAB node, the entire service path of the F1 interface user plane has not yet been established. Therefore, the following steps are required to update the tunnel endpoint information of F1-U traffic and negotiate the QoS label information of the service so that the target F1 endpoint CU can accurately provide service data to the first IAB node.

[0401] S950: The target F1 endpoint CU (CU3) receives a fourth message from the source F1 endpoint CU (CU2). This fourth message includes at least one of the following: first QoS mapping information (or a first QoS label; a description of the QoS label can be found above), QoS information corresponding to F1-C traffic and / or non-F1 traffic, and first uplink endpoint information of the first F1-U interface tunnel. The first QoS mapping information is the value of the DSCP and / or flow label in IPv6 corresponding to the first DRB of the first UE. The first F1-U interface tunnel is the uplink F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint (i.e., the source F1 endpoint CU) and the uplink tunnel endpoint identifier TEID. It should be understood that the first uplink endpoint information of the first F1-U interface tunnel is the uplink endpoint information of each first DRB maintained by the source F1 endpoint host CU (CU2 here), and can also be called the source uplink endpoint information.

[0402] In some possible embodiments, the fourth message may further include the identifier of the first UE and the identifier of the first DRB, corresponding to the first uplink endpoint information of the F1-U interface tunnel of the first DRB. The identifier of the first UE may be the UE identifier used by the first UE when performing XnAP handover, for example, the UE XnAP ID assigned to the first UE by the source F1 endpoint CU (CU2), and / or the UE XnAP ID assigned to the first UE by the target F1 endpoint CU (CU3).

[0403] In some possible embodiments, the fourth message may further include an identifier corresponding to the first IAB node that provides services to the first UE. For example, the target cell identifier of the first UE, where the target cell of the first UE is the cell served by the first IAB node (i.e., the cell served by the first DU, specifically the identifier of the cell served by the logical DU b connected to the target F1 endpoint CU); or, the identifier of the first DU to which the first UE is connected, which may be the IP address of the first DU or the gNB-DU identifier (gNB-DU ID) of the first DU. If the first IAB node is connected to different CUs (CU2, CU3) through different logical DUs (first DU a, first DU b), then the identifier of the first DU may specifically be the identifier (IP address or gNB-DU ID) of the first DU b that establishes an F1 connection with CU3; or, the BAP address of the first IAB node.

[0404] Based on the above technical solution, by carrying the identifier corresponding to the first IAB node, the CU3 can know that the first DU of the first IAB node is serving the first UE, so that the CU3 and the first DU can carry out the negotiation process of establishing and modifying the context of the first UE regarding the F1 interface.

[0405] In some possible embodiments, the first message in S930 above may also replace the fourth message in S950 to carry the first QoS mapping information.

[0406] In some possible embodiments, if the target F1 endpoint CU (CU3) is in a CP and UP separated form, and CU3 includes CU3-CP and CU3-UP, then the following steps can also be performed:

[0407] S960: CU3-CP sends a first notification message to CU3-UP, which instructs CU3-UP to establish an uplink tunnel endpoint for the second F1-U interface.

[0408] In some possible embodiments, the first notification information described above may be a bearer context setup request message or other messages from the E1 interface.

[0409] It should be understood that after CU3 receives the first notification information, it can enable CU3-UP to establish the uplink tunnel endpoint of the GTP-U of the F1-U interface corresponding to the first DRB, that is, the uplink tunnel endpoint of the second F1-U interface.

[0410] In some possible embodiments, the first notification information mentioned above includes at least one of the following: the identifier of the first UE, the identifier of the first DRB, and the first downlink endpoint information of the first F1-U interface tunnel corresponding to the first DRB. The first downlink endpoint information includes the IP address of the first downlink endpoint and the downlink tunnel endpoint identifier TEID of the first F1-U interface. The downlink TEID of the first F1-U may be the downlink TEID at the first DU.

[0411] In some possible embodiments, the first notification information may further include, in S950, the first uplink endpoint information (original uplink endpoint information) of the first F1-U interface tunnel corresponding to the UEDRB of CU3, which is notified by CU2. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink TEID of the first F1-U interface.

[0412] S970: CU3-UP sends a second notification message to CU3-CP, which includes the uplink tunnel endpoint information of the second F1-U interface.

[0413] In some possible embodiments, the uplink tunnel endpoint information of the second F1-U interface mentioned above includes the IP address of the second uplink endpoint and the uplink TEID of the second F1-U interface tunnel.

[0414] In some possible embodiments, the second notification information may further include the identifier of the first UE and the identifier of the first DRB.

[0415] It should be understood that the second uplink endpoint information of the second F1-U interface tunnel can also be referred to as the new uplink endpoint information.

[0416] In some possible embodiments, if the first notification information includes the first uplink endpoint information corresponding to the first DRB, the second notification information may include the first uplink endpoint information in addition to the second uplink endpoint information.

[0417] In some possible embodiments, if CU3 is not in a CP and UP separate configuration, then the above-described S960 and S970 do not need to be executed. CU3 can determine the above-described second uplink endpoint information on its own using the known information.

[0418] S980: The target F1 endpoint CU (CU3) sends a first update message to the first IAB node. The first update message includes the second uplink endpoint information. The first update message is used to instruct the first IAB node to update the uplink tunnel endpoint of the F1-U interface corresponding to the first DRB to the uplink tunnel endpoint information of the second F1-U interface, so as to ensure access and backhaul services for the first UE.

[0419] In some possible embodiments, the first update information may also include corresponding first uplink endpoint information for each second uplink endpoint information. After receiving the first update information, the first IAB node can directly replace the first uplink endpoint information of the F1-U interface tunnel corresponding to the first DRB with the second uplink endpoint information. In this way, the target F1 endpoint CU (CU3) can send multiple first update information for different DRBs of multiple UEs to the first IAB node at one time, which can improve the efficiency of configuration update.

[0420] Based on the above technical solution, it is convenient to target F1 endpoint CU ( Figure 9 The CU3 in the first IAB node obtains the new uplink tunnel endpoint information of the F1-U interface corresponding to the first DRB, and then further notifies the first IAB node. Additionally, the target F1 endpoint CU3 can also... Figure 9 The CU3 in the middle obtains the first QoS mapping information corresponding to the first DRB, which facilitates the provision of reasonable QoS guarantee and routing for data packets transmitted through the first DRB in downlink transmission.

[0421] Figure 10 A schematic diagram of another communication method provided in an embodiment of this application is shown.

[0422] This communication method is applied to an IAB network, which includes at least a first IAB node, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first DU migrates from CU2 (connected to the second IAB host node) to CU3 (connected to the third IAB host node). Before and after the first DU switchover, the first MT maintains an RRC connection with the second IAB host node. This connection state is referred to as the first connection state in this embodiment. The switchover of the first DU can be achieved by two logical DUs (first DU a and first DU b) connecting to the second and third IAB host nodes respectively, as detailed in the foregoing description. This scenario corresponds to scenario 1 proposed in the above embodiment.

[0423] The roles of the three CUs (RRC terminating CU, source F1 terminating CU, and target F1 terminating CU) in Scenario 1 can be found in the descriptions above.

[0424] S1010: Establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU3).

[0425] S1020: The first IAB node or the target F1 endpoint CU (CU3) sends a third message to the RRC endpoint CU (CU2), which indicates that the third F1 interface between the first IAB node and CU3 has been established.

[0426] It should be understood that the content of S1010 and S1020 is the same as that of S910 and S920 above. Therefore, for the embodiments of S2010 and S1020, you can refer to the embodiments corresponding to S910 and S920 above, and will not repeat them here.

[0427] S1030: The target F1 endpoint CU (CU3) of the first IAB node receives a first message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0428] In this application, the services of the first IAB node can be the services of the first IAB node itself (such as non-UE-related services transmitted between the first DU and the F1terminating CU, or the OAM services of the first DU), or the services of the UE served by the first IAB node.

[0429] Therefore, after receiving the first message, CU3 decided not to negotiate the transmission migration management of the first IAB node with CU2, and continued to provide access and backhaul services to the first IAB node through the second IAB host.

[0430] It should be understood that the above-described embodiments regarding the unfolding of the first message can refer to the relevant embodiments corresponding to S930 above, and will not be repeated here. The slight difference is that in this embodiment, the first message can be generated by the first IAB node based on the seventh message from CU2 and sent to CU3.

[0431] In some possible embodiments, the first message is sent to CU3 specifically through the following steps:

[0432] S1032: RRC terminating CU(CU2) sends the seventh message to the first IAB node.

[0433] The seventh message is used to indicate that the first MT does not need to perform a handover in the first time period, which is the period during which the first DU performs a handover and the period during which the UE served by the first IAB node follows the first DU in performing a handover. Alternatively, if the handover process of the first DU includes the process of the UE served by the first IAB node following the first DU in performing a handover, then the first time period can refer to the handover period during which the first DU switches from the source F1 endpoint CU to the target F1 endpoint CU.

[0434] The aforementioned seventh message may be an RRC message sent by CU2 to the first MT, such as an RRC reconfiguration message, which carries specific indication information, such as the information elements displayed in the message.

[0435] S1034: The first IAB node determines the first message based on the seventh message mentioned above and sends the first message to CU3.

[0436] After receiving the first message, CU3 can know that the service of the first DU of the first IAB node does not need to migrate the backhaul link.

[0437] In some possible embodiments, the first message can specifically be used to indicate to CU3 that the first MT does not need to perform a handover, or that the first DU does not need to switch the radio backhaul link. That is, all services of the first DU of the entire first IAB node do not need to switch the radio backhaul link.

[0438] In some possible embodiments, the first message described above may be an F1AP message sent by a first DU to CU3.

[0439] It should be understood that after receiving the first message mentioned above, CU3 decides not to negotiate with CU2 regarding the transmission migration management of the first IAB node, and continues to provide access and backhaul services to the first IAB node through the wireless backhaul network under the jurisdiction of the second IAB host.

[0440] Based on the above technical solution, it is possible to reasonably avoid the process during which CU3 initiates relevant procedures for IAB transport migration management (such as IAB transport migration management procedures) to CU2 to request the configuration of the radio backhaul link for the UE's services in the IAB network under the jurisdiction of CU2, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0441] In some possible embodiments, the first message may include a first IAB node identifier, which includes at least one of the following: a UE XnAP identifier of the first MT, an identifier of the first DU, and a BAP address of the first MT. The first DU identifier may be the identifier of the DU (e.g., the first DU b) that establishes a connection with the target F1 endpoint CU (CU3). The UE XnAP identifier of the first MT may be a UE XnAP ID assigned to the first MT by the RRC endpoint CU of the IAB node.

[0442] In some possible embodiments, if CU2 is the UE XnAP identifier assigned to the first MT of the first IAB node, then in S1032, CU2 needs to send the identifier to the first IAB node in the seventh message.

[0443] Based on the aforementioned first IAB node identifier, CU3 can know that the connection established with it is the first DU of the first IAB node, thus ensuring that subsequent services can be executed normally.

[0444] In some possible embodiments, the first message can be included in a notification message exchanged between the first IAB node and the target F1 endpoint CU (CU3) in the form of explicit information elements, or it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the first message can be used directly to indicate that the target F1 endpoint CU (CU3) does not need to negotiate the transmission migration management of the first IAB node with the IAB node's RRC endpoint CU (CU2), or it can be used to indicate that the first MT does not need to switch the RRC endpoint CU (i.e., CU2), or it can be used to indicate that the radio backhaul link of the first DU's service remains unchanged.

[0445] In some possible embodiments, the first message may also include the identifier of the first UE or the identifier of the bearer corresponding to the first UE. The first UE is the UE served by the first IAB node, and the identifier of the bearer corresponding to the first UE may include the identifier of the first DRB or the identifier of the first signaling radio bearer (SRB). Based on this, the target F1 endpoint CU (CU3) may, based on the first message, skip or eliminate the transmission migration management negotiation process with CU2 regarding the first UE, the first DRB, or the first SRB served by the first IAB node during the handover process of the first UE.

[0446] In some possible embodiments, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0447] Based on the above technical solution, the service quality of services provided for the first DU (which may include the services of the first UE) can be guaranteed without CU3 negotiating DU migration management with CU2.

[0448] After completing S1030 above, the following steps can be performed:

[0449] S1040: CU3 sends a second feedback message to the first IAB node, which indicates that CU3 has received the first message from the first IAB node.

[0450] Based on the above technical solution, while reducing signaling overhead, it is possible to ensure that after the first DU of the first IAB node switches to CU3, CU3 can provide it with corresponding wireless backhaul service.

[0451] Although the CU3 has the capability to provide corresponding wireless backhaul services to the first IAB node, the entire service path has not yet been established. Therefore, the following steps are required to update the tunnel endpoint information of the F1-U traffic so that the CU3 can accurately provide service data to the first IAB node.

[0452] S1050: The target F1 endpoint CU (CU3) receives a fourth message from the source F1 endpoint CU (CU2). This fourth message includes at least one of the following: first QoS mapping information (or a first QoS label; a description of the QoS label can be found above), QoS information corresponding to F1-C traffic and / or non-F1 traffic, and first uplink endpoint information of the first F1-U interface tunnel. The first QoS mapping information is the value of the DSCP and / or flow label in IPv6 corresponding to the first DRB of the first UE. The first F1-U interface tunnel is the uplink F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint (i.e., the source F1 endpoint CU) and the uplink tunnel endpoint identifier TEID. It should be understood that the first uplink endpoint information of the first F1-U interface tunnel is the uplink endpoint information of each first DRB maintained by the source F1 endpoint host CU (CU2 here), and can also be called the source uplink endpoint information.

[0453] In some possible embodiments, if the target F1 endpoint CU (CU3) is in a CP and UP separated form, and CU3 includes CU3-CP and CU3-UP, then the following steps can also be performed:

[0454] S1060: CU3-CP sends a first notification message to CU3-UP, which instructs CU3-UP to establish an uplink tunnel endpoint for the second F1-U interface.

[0455] S1070: CU3-UP sends a second notification message to CU3-CP, which includes the uplink tunnel endpoint information of the second F1-U interface.

[0456] In some possible embodiments, if CU3 is not in a CP and UP separate configuration, then it is not necessary to execute the above-described S1060 and S1070. The above-described second uplink endpoint information can be determined using known information.

[0457] S1080: The target F1 endpoint CU (CU3) sends a first update message to the first IAB node. The first update message includes the second uplink endpoint information. The first update message is used to instruct the first IAB node to update the uplink tunnel endpoint of the F1-U interface corresponding to the first DRB to the uplink tunnel endpoint information of the second F1-U interface, so as to ensure access and backhaul services for the first UE.

[0458] It should be understood that the content of S1050 to S1080 is the same as that of S950 to S980 above. Therefore, for the embodiments of S1050 to S1080, you can refer to the embodiments corresponding to S950 to S980 above, and will not repeat them here.

[0459] Based on the above technical solution, it is convenient to target F1 endpoint CU ( Figure 10 The CU3 in the first IAB node obtains the uplink tunnel endpoint information of the new F1-U interface corresponding to the first DRB, and then further notifies the first IAB node. Additionally, the target F1 endpoint CU3 can also be made... Figure 10 The CU3 in the middle obtains the first QoS mapping information corresponding to the first DRB, which facilitates the provision of reasonable QoS guarantee and routing for data packets transmitted through the first DRB in downlink transmission.

[0460] Figure 11 A schematic diagram of another communication method provided in an embodiment of this application is shown.

[0461] This communication method is applied to an IAB network, which includes at least a first IAB node, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first DU migrates from CU1 (connected to the first IAB host node) to CU2 (connected to the second IAB host node). Before and after the first DU switchover, the first MT maintains an RRC connection with the second IAB host node. This connection state is referred to as the first connection state in this embodiment. The switchover of the first DU can be achieved by having two logical DUs (first DU a and first DU b) connect to the first and second IAB host nodes respectively, as detailed in the foregoing description. This scenario corresponds to scenario 2 proposed in the above embodiment.

[0462] In Scenario 2, the source F1 terminating CU of the first IAB node is CU1, its target F1 terminating CU is CU2, and its RRC terminating CU is CU2. For a description of the roles of the three CUs (RRC terminating CU, source F1 terminating CU, and target F1 terminating CU) in this scenario, please refer to the descriptions in the preceding sections.

[0463] S1130: The source F1 endpoint CU (CU1) of the first IAB node receives a fifth message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0464] It should be understood that, based on the corresponding description of the above embodiments, during the handover process of the UE following the first DU, if the UE's services that do not require the source F1 endpoint CU (CU1) to serve the first IAB node initiate a service negotiation process to the IAB node's RRC endpoint CU (CU2, or non-F1 terminating IAB donor CU) (e.g., for releasing the backhaul link configuration for the UE's services in the network topology under the jurisdiction of CU2), then CU1, as the source F1 endpoint CU, needs to be aware of this. Correspondingly, since whether the first MT needs to switch the IAB host CU can be determined by the RRC endpoint CU, if no handover operation is required for the first MT, then CU2, as the RRC endpoint CU, can send the aforementioned fifth message to the source F1 endpoint CU (CU1) after learning that the F1 interface connection between the first IAB node and the target F1 terminating CU has been successfully established.

[0465] In some possible embodiments, the fifth message described above can specifically be used to indicate to CU1 that the first MT does not need to perform a handover, or that the first DU does not need to switch the radio backhaul link. That is, all services of the first DU of the entire first IAB node do not need to switch the radio backhaul link.

[0466] Therefore, after receiving the fifth message mentioned above, CU1 decides not to negotiate the transmission migration management of the first IAB node with CU2, and the wireless backhaul network under the jurisdiction of the second IAB host can continue to provide access and backhaul services for the first IAB node.

[0467] Based on the above technical solution, it is possible to reasonably avoid the process of CU1 initiating the IAB transmission migration management process to CU2 during the process of the UE serving the first IAB node following the first DU from CU1 to CU2 (this process is used to request CU2 to release the relevant configuration of the radio backhaul link for the service of the first IAB node in its radio backhaul network), thereby saving the signaling overhead of the Xn interface and F1 interface.

[0468] In some possible embodiments, the aforementioned fifth message is generated by the RRC endpoint CU (CU2) of the first IAB node after determining that the first MT is always connected to the second IAB host before and after the first DU handover, and is sent to the source F1 endpoint CU (CU1) of the first IAB node.

[0469] In some possible embodiments, the fifth message described above may include a first IAB node identifier, which includes at least one of the following: a UE XnAP identifier of the first MT, an identifier of the first DU, and a BAP address of the first MT. The identifier of the first DU may be the identifier of a partial DU (e.g., the first DU a) that has established a connection with the source F1 endpoint CU (CU1). Specifically, the identifier of the first DU may be the IP address of the first DU (e.g., the IP address of the first DU a) or the gNB-DUID of the first DU (e.g., the gNB-DU ID of the first DU a). The UE XnAP identifier of the first MT may be a UE XnAP ID assigned to the first MT by the RRC endpoint CU of the first IAB node, and / or a UE XnAP ID assigned to the first MT by the source F1 endpoint CU of the first IAB node.

[0470] Based on the aforementioned first IAB node identifier, the source F1 endpoint CU (CU1) of the first IAB node can know that the indication information is directed to the first IAB node. In addition, after the first DU of the first IAB node migrates from the source F1 endpoint CU (CU1) to the target F1 endpoint CU (CU2), the first CU, based on the aforementioned fifth message, is exempt from the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

[0471] In some possible embodiments, the fifth message includes an "All traffic indication." Based on this indication, the source F1 endpoint CU (CU1) of the first IAB node does not need to initiate any IAB transmission migration management procedures to the RRC endpoint CU for any of the services provided by the first IAB node (this procedure is used to request CU2 to release the relevant configuration of the radio backhaul link for the services served by the first IAB node in its managed radio backhaul network). This "All traffic indication" can be explicitly included in the fifth message or implicitly included. For example, in one possible implicit approach, if the fifth message only contains the identifier of the first IAB node and not any UE identifier, it can be considered an implicit "All traffic indication."

[0472] In some possible embodiments, the aforementioned fifth message can be included in a notification message exchanged between the RRC endpoint CU (CU2) of the first IAB node and the source F1 endpoint CU (CU1) of the first IAB node in the form of explicit information elements. Alternatively, it can be a newly defined special type of message, which itself can serve as indicative information. Furthermore, besides directly indicating that CU1 does not need to negotiate the transmission migration management of the first IAB node with CU2, the aforementioned fifth message can also be used to indicate that the first MT does not need to switch the RRC endpoint CU (i.e., CU2), or to indicate that the radio backhaul link path of the service of the first DU remains unchanged. It can also indicate that CU1 does not need to initiate a service negotiation process for releasing the service for the service served by the first DU.

[0473] In some possible embodiments, the fifth message may also include the identifier of the first UE or the identifier of the bearer corresponding to the first UE. The first UE is the UE served by the first IAB node, and the identifier of the bearer corresponding to the first UE may include the identifier of the first DRB or the identifier of the first SRB. Based on this, the CU1 may, during the handover process of the first UE, skip or eliminate the negotiation with the CU2 regarding the release of the services of the first UE served by the first IAB node, or skip or eliminate the negotiation with the CU2 regarding the release of the first DRB or the first SRB of the first UE.

[0474] In some possible embodiments, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0475] In some possible embodiments, the following steps also need to be performed before executing S1030 above:

[0476] S1110: Establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU2).

[0477] Specifically, the target F1 endpoint CU (CU2) receives a first request message (e.g., an F1 setup request message) from the first IAB node. This first request message is used to establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU2). Subsequently, the target F1 endpoint CU can send a response message (e.g., an F1 setupresponse message) to the first IAB node, thus establishing an F1 interface with the first IAB node.

[0478] In some possible embodiments, if the first IAB node is connected to different IAB host CUs, such as CU1 and CU2, through different logical DUs, such as the first DU a and the first DU b, where the first DU a is connected to CU1 and the first DU b is connected to CU2, then the first DU b can initiate an F1 connection establishment request to CU2 and then establish a third F1 interface, or target F1 interface, between the first DU b and CU2.

[0479] In some possible embodiments, the first IAB node may initiate the aforementioned F1 connection establishment request to the target F1 endpoint CU (CU2) after receiving a corresponding instruction from the source F1 endpoint CU (CU1 in scenario 1). Alternatively, the first IAB node may initiate the aforementioned F1 connection establishment request to CU2 based on the OAM configuration (which may be pre-configured). This application embodiment does not limit the specific triggering method of the F1 connection establishment request.

[0480] S1120: The source F1 endpoint CU (CU1) sends a sixth message to the RRC endpoint CU (CU2), which indicates that the first DU of the first IAB node will migrate from the source F1 endpoint CU (CU1) to the target F1 endpoint CU (CU2).

[0481] In some possible embodiments, S1120 is an optional step. If S1120 is not performed, it can be indicated in S1110 by the following explicit or implicit methods:

[0482] In an implicit manner, when the first DU initiates an F1 connection establishment request to the target F1 endpoint CU (CU2) in S1110, it can carry the BAP address (BAP address) assigned to the first MT by the RRC terminating CU (CU2) in the F1 establishment request message. This allows CU2 to know that the first DU, which is co-deployed with the first MT, is about to request the establishment of an F1 interface. Since CU2 has received the handover request from the first MT beforehand, it can know that the first IAB node has performed a partial migration before connecting to CU2. Therefore, when CU2 receives the F1 connection establishment request from the first DU, which is co-deployed with the first MT, it can know that the first DU of the first IAB node is also about to migrate to CU2.

[0483] Alternatively, in one display method, when the first DU initiates an F1 connection establishment request to the target F1 endpoint CU (CU2) in S1110, it can carry display indication information in the F1 setup request message to indicate that the DU part of the first IAB node wants to migrate to CU2.

[0484] After completing S1130 above, the following steps can be performed:

[0485] S1140: RRC terminating CU(CU2) receives a second feedback message from source F1 endpoint CU(CU1), which indicates that CU1 has successfully received the fifth message from CU2.

[0486] Step S1140 is optional and can be omitted.

[0487] Based on the above technical solution, while reducing signaling overhead, it is possible to ensure that after the first DU of the first IAB node switches to the target F1 endpoint CU (CU2), CU2 can provide it with corresponding wireless backhaul service.

[0488] Although the aforementioned target F1 endpoint CU (CU2) has the capability to provide F1 connection services to the first IAB node, the entire service path of the F1 interface user plane has not yet been established. Therefore, the following steps are required to update the tunnel endpoint information of the F1-U traffic so that the target F1 endpoint CU can accurately provide service data to the first IAB node.

[0489] S1150: The target F1 endpoint CU (CU2) receives a fourth message from the source F1 endpoint CU (CU1), the fourth message including at least one of the following: first uplink endpoint information of the first F1-U interface tunnel. The first F1-U interface tunnel is the uplink F1-U interface tunnel corresponding to the first DRB of the first UE, and the first uplink endpoint information includes the IP address of the first uplink endpoint (i.e., the source F1 endpoint CU) and the uplink tunnel endpoint identifier TEID. It should be understood that the first uplink endpoint information of the first F1-U interface tunnel is the uplink endpoint information of each first DRB maintained by the source F1 endpoint host CU (here, the second CU), and can also be referred to as the source uplink endpoint information.

[0490] In some possible embodiments, the fourth message may further include the identifier of the first UE and the identifier of the first DRB, corresponding to the first uplink endpoint information of the F1-U interface tunnel of the first DRB. The identifier of the first UE may be the UE identifier used by the first UE when performing XnAP handover, for example, the UE XnAP ID assigned to the first UE by the source F1 endpoint CU (CU1), and / or the UE XnAP ID assigned to the first UE by the target F1 endpoint CU (CU2).

[0491] In some possible embodiments, the fourth message may further include an identifier corresponding to the first IAB node that provides services to the first UE. For example, the target cell identifier of the first UE, where the target cell of the first UE is the cell served by the first IAB node (i.e., the cell served by the first DU, specifically the identifier of the cell served by the logical DU b connected to the target F1 endpoint CU); or, the identifier of the first DU to which the first UE is connected, which may be the IP address of the first DU or the gNB-DU identifier (gNB-DU ID) of the first DU. If the first IAB node is connected to different CUs (CU1, CU2) through different logical DUs (first DU a, first DU b), then the identifier of the first DU may specifically be the identifier (IP address or gNB-DU ID) of the first DU b that establishes an F1 connection with CU2; or, the BAP address of the first IAB node.

[0492] Based on the above technical solution, by carrying the identifier corresponding to the first IAB node, the CU2 can know that the first DU of the first IAB node is serving the first UE, so that the CU2 and the first DU can carry out the negotiation process of establishing and modifying the context of the first UE regarding the F1 interface.

[0493] Step S1150 is an optional step and can be omitted.

[0494] In some possible embodiments, if the aforementioned target F1 endpoint CU ( Figure 11 In the case of CU2), which is a form where CP and UP are separated, and CU2 includes CU2-CP and CU2-UP, the following steps can be performed:

[0495] S1160: CU2-CP sends a third notification message to CU2-UP, which instructs CU2-UP to establish an uplink tunnel endpoint for the second F1-U interface.

[0496] In some possible embodiments, the aforementioned third notification information may be a bearer context establishment request message or other messages from the E1 interface.

[0497] It should be understood that after CU2 receives the third notification information, it can enable CU2-UP to establish the uplink tunnel endpoint of the GTP-U of the F1-U interface corresponding to the first DRB, that is, the uplink tunnel endpoint of the second F1-U interface.

[0498] In some possible embodiments, the third notification information mentioned above includes at least one of the following: the identifier of the first UE, the identifier of the first DRB, and the first downlink endpoint information of the first F1-U interface tunnel corresponding to the first DRB. The first downlink endpoint information includes the IP address of the first downlink endpoint and the downlink tunnel endpoint identifier TEID of the first F1-U interface. The downlink TEID of the first F1-U may be the downlink TEID at the first DU.

[0499] In some possible embodiments, the third notification information may also include, in S1150, the first uplink endpoint information (original uplink endpoint information) of the first F1-U interface tunnel corresponding to the UE DRB of CU2, which is informed by CU1. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink TEID of the first F1-U interface.

[0500] S1170: CU2-UP sends a fourth notification message to CU2-CP, which includes the uplink tunnel endpoint information of the second F1-U interface.

[0501] In some possible embodiments, the uplink tunnel endpoint information of the second F1-U interface mentioned above includes the IP address of the second uplink endpoint and the uplink TEID of the second F1-U interface tunnel.

[0502] In some possible embodiments, the second notification information may further include the identifier of the first UE and the identifier of the first DRB.

[0503] It should be understood that the second uplink endpoint information of the second F1-U interface tunnel can also be referred to as the new uplink endpoint information.

[0504] In some possible embodiments, if the third notification information includes the first uplink endpoint information corresponding to the first DRB, the fourth notification information may include the first uplink endpoint information in addition to the second uplink endpoint information.

[0505] In some possible embodiments, if CU2 is not in a CP and UP separate configuration, then the above-described S1160 and S1170 do not need to be executed, and CU2 can determine the above-described second uplink endpoint information on its own.

[0506] S1180: The target F1 endpoint CU (CU2) sends the first update information to the first IAB node. The first update information includes the second uplink endpoint information (i.e., the uplink tunnel endpoint information of the second F1-U interface). The first update information is used to instruct the first IAB node to update the uplink tunnel endpoint of the first F1-U interface corresponding to the first DRB to the uplink tunnel endpoint information of the second F1-U interface, so as to ensure access and backhaul services for the first UE.

[0507] In some possible embodiments, if step S1150 is executed, the first update information may also include corresponding first uplink endpoint information for each second uplink endpoint information. After receiving the first update information, the first IAB node can directly replace the first uplink endpoint information of the F1-U interface tunnel corresponding to the first DRB with the second uplink endpoint information. In this way, the target F1 endpoint CU (CU2) can send multiple first update information for different DRBs of multiple UEs to the first IAB node at one time, which can improve the efficiency of configuration update.

[0508] Based on the above technical solution, it is convenient to target F1 endpoint CU ( Figure 10 The CU2 in the first DRB obtains the new uplink tunnel endpoint information of the F1-U interface corresponding to the first DRB, and then further notifies the first IAB node.

[0509] Figure 12 A schematic diagram of another communication method provided in an embodiment of this application is shown.

[0510] This communication method is applied to an IAB network, which includes at least a first IAB node, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first DU migrates from CU1 (connected to the first IAB host node) to CU2 (connected to the second IAB host node). Before and after the first DU switchover, the first MT maintains an RRC connection with the second IAB host node. This connection state is referred to as the first connection state in this embodiment. The switchover of the first DU can be achieved by having two logical DUs (first DU a and first DU b) connect to the first and second IAB host nodes respectively, as detailed in the foregoing description. This scenario corresponds to scenario 2 proposed in the above embodiment.

[0511] In Scenario 2, the source F1 terminating CU of the first IAB node is CU1, its target F1 terminating CU is CU2, and its RRC terminating CU is CU2. For a description of the roles of the three CUs (RRC terminating CU, source F1 terminating CU, and target F1 terminating CU) in this scenario, please refer to the descriptions in the preceding sections.

[0512] S1210: Establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU2).

[0513] S1220: The source F1 endpoint CU (CU1) sends a sixth message to the RRC endpoint CU (CU2), which indicates that the first DU of the first IAB node will migrate from the source F1 endpoint CU (CU1) to the target F1 endpoint CU (CU2).

[0514] It should be understood that the contents of S1210 and S1220 are the same as those of S1110 and S1120 above. Therefore, for the embodiments of S1210 and S1220, please refer to the embodiments corresponding to S1110 and S1120 above. They will not be repeated here.

[0515] S1230: The source F1 endpoint CU (CU1) of the first IAB node receives a fifth message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0516] In this application, the services of the first IAB node can be the services of the first IAB node itself (such as non-UE-related services transmitted between the first DU and the F1terminating CU, or the OAM services of the first DU), or the services of the UE served by the first IAB node.

[0517] Therefore, after receiving the fifth message mentioned above, CU1 decided not to negotiate with CU2 regarding the transmission migration management of the first IAB node, and instead the second IAB host would directly provide access and backhaul services for the first IAB node.

[0518] It should be understood that the above-described embodiments regarding the unfolding of the fifth message can refer to the related embodiments corresponding to S1130 above, and will not be repeated here. The slight difference is that in this embodiment, the fifth message can be generated by the first IAB node based on the seventh message from CU2 and sent to CU1.

[0519] In some possible embodiments, the fifth message in S1230 above is specifically sent to CU1 through the following steps:

[0520] S1232: RRC terminating CU(CU2) sends the seventh message to the first IAB node.

[0521] The seventh message is used to indicate that the first MT does not need to perform a handover in the first time period, which is the period during which the first DU performs a handover and the period during which the UE served by the first IAB node follows the first DU in performing a handover. Alternatively, if the handover process of the first DU includes the process of the UE served by the first IAB node following the first DU in performing a handover, then the first time period can refer to the handover period during which the first DU switches from the source F1 endpoint CU to the target F1 endpoint CU.

[0522] The aforementioned seventh message could be an RRC message sent by CU2 to the first MT, such as an RRC reconfiguration message, which carries specific indication information, such as the IE to be displayed carried in the message.

[0523] S1234: The first IAB node determines the fifth message based on the seventh message mentioned above and sends the fifth message to CU1.

[0524] After CU1 receives the fifth message mentioned above, it can know that the service of the first DU of the first IAB node does not need to migrate the backhaul link.

[0525] In some possible embodiments, the fifth message described above can specifically be used to indicate to CU1 that the first MT does not need to perform a handover, or that the first DU does not need to switch the radio backhaul link. That is, all services of the first DU of the entire first IAB node do not need to switch the radio backhaul link.

[0526] In some possible embodiments, the fifth message described above may be an F1AP message sent by a first DU (e.g., first DU a) to CU1.

[0527] It should be understood that in scenario 2, CU1, which is the source F1 endpoint CU, has already known in advance that CU2, which is the RRC endpoint CU connected to the first MT, has exchanged service migration negotiation messages for the first DU service. Therefore, CU1 knows which CU is co-deployed with the first MT, so it does not need to carry other identifiers of the first IAB node in S1240.

[0528] It should be understood that after CU1 receives the aforementioned fifth message, it can decide not to negotiate the transmission migration management of the first IAB node with CU2, and instead have the wireless backhaul network under the jurisdiction of the second IAB host directly provide access and backhaul services for the first IAB node.

[0529] Based on the above technical solution, it is possible to reasonably avoid the process of CU1 initiating the IAB transmission migration management process to CU2 during the process of the UE serving the first IAB node following the first DU from CU1 to CU2 (this process is used to request CU2 to release the relevant configuration of the radio backhaul link for the service of the first IAB node in its radio backhaul network), thereby saving the signaling overhead of the Xn interface and F1 interface.

[0530] In some possible embodiments, the aforementioned fifth message may be included in a notification message exchanged between the first IAB node and the source F1 endpoint CU (CU1) in the form of explicit information elements, or it may be a newly defined special type of message, which itself can serve as indicative information. Furthermore, the aforementioned first message may be used directly to indicate that the source F1 endpoint CU (CU1) does not need to negotiate the transmission migration management of the first IAB node with the IAB node's RRC endpoint CU (CU2), or it may be used to indicate that the first MT does not need to switch the RRC endpoint CU (i.e., CU2), or it may be used to indicate that the radio backhaul link of the first DU's service remains unchanged.

[0531] In some possible embodiments, the fifth message may also include the identifier of the first UE or the identifier of the bearer corresponding to the first UE. The first UE is the UE served by the first IAB node, and the identifier of the bearer corresponding to the first UE may include the identifier of the first DRB or the identifier of the first SRB. Based on this, the CU1 may, based on the fifth message, avoid or skip the transmission migration management negotiation with the CU2 regarding the first UE, the first DRB, or the first SRB served by the first IAB node.

[0532] In some possible embodiments, the first UE served by the first IAB node can be multiple, and corresponding to the multiple first UEs, the first DRB or the first SRB can also be multiple.

[0533] It should be understood that after the fifth message from the first IAB node, CU1 decides not to initiate a service negotiation process with CU2 for service deletion, for the services of the first IAB node, the services of a specific UE, or the services of a specific UE's DRB or SRB.

[0534] After completing S1240 above, the following steps can be performed:

[0535] S1240: CU1 sends a third feedback message to the first IAB node, which indicates that CU1 has received the fifth message from the first IAB node.

[0536] Step S1240 is optional and can be omitted.

[0537] Based on the above technical solution, while reducing signaling overhead, it is possible to ensure that after the first DU of the first IAB node switches to the target F1 endpoint CU (CU2), CU2 can provide it with corresponding wireless backhaul service.

[0538] Although the aforementioned target F1 endpoint CU (CU2) has the capability to provide F1 connection services to the first IAB node, the entire service path of the F1 interface user plane has not yet been established. Therefore, the following steps are required to update the tunnel endpoint information of the F1-U traffic so that the target F1 endpoint CU can accurately provide service data to the first IAB node.

[0539] S1250: The target F1 endpoint CU (CU2) receives a fourth message from the source F1 endpoint CU (CU1). This fourth message includes the first uplink endpoint information of the first F1-U interface tunnel. The first F1-U interface tunnel is the uplink F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint (i.e., the source F1 endpoint CU) and the uplink tunnel endpoint identifier TEID. It should be understood that the first uplink endpoint information of the first F1-U interface tunnel is the uplink endpoint information maintained by the source F1 endpoint host CU (here, the second CU) for each first DRB, and can also be referred to as the source uplink endpoint information.

[0540] Step S1250 is an optional step and can be omitted.

[0541] In some possible embodiments, if the aforementioned target F1 endpoint CU ( Figure 12 In the case of CU2), which is a form where CP and UP are separated, and CU2 includes CU2-CP and CU2-UP, the following steps can be performed:

[0542] S1260: CU2-CP sends a third notification message to CU2-UP, which instructs CU2-UP to establish an uplink tunnel endpoint for the second F1-U interface.

[0543] S1270: CU2-UP sends a fourth notification message to CU2-CP, which includes the uplink tunnel endpoint information of the second F1-U interface.

[0544] In some possible embodiments, if CU2 is not in a CP and UP separate configuration, then it is not necessary to execute the above-described S1260 and S1270. The above-described second uplink endpoint information can be determined using known information.

[0545] S1280: The target F1 endpoint CU (CU2) sends a first update information to the first IAB node. The first update information includes the second uplink endpoint information (i.e., the uplink tunnel endpoint information of the second F1-U interface). The first update information is used to instruct the first IAB node to update the uplink tunnel endpoint of the first F1-U interface corresponding to the first DRB to the uplink tunnel endpoint information of the second F1-U interface, so as to ensure access and backhaul services for the first UE.

[0546] It should be understood that the content of S1250 to S1280 is the same as that of S1150 to S1180 above. Therefore, for the embodiments of S1250 to S1280, you can refer to the embodiments corresponding to S1150 to S1180 above, and will not repeat them here.

[0547] Based on the above technical solution, it is convenient to target F1 endpoint CU ( Figure 12The CU2 in the first DRB obtains the uplink tunnel endpoint information of the new F1-U interface corresponding to the first DRB, and then further notifies the first IAB node.

[0548] Figure 13 A schematic diagram of another communication method provided in an embodiment of this application is shown.

[0549] This communication method is applied to an IAB network, which includes at least a first IAB node, a first IAB host, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first DU switches from CU1 connected to the first IAB node to CU3 connected to the third IAB host. Before and after the first DU switch, the first MT maintains an RRC connection with the second IAB host node. This connection state is referred to as the first connection state in this embodiment. The switching of the first DU can be achieved by two logical DUs (first DU a and first DU b) connecting to the first IAB host node and the third IAB host node respectively, as detailed in the foregoing description. This scenario corresponds to scenario 3 proposed in the above embodiment.

[0550] In scenario 3, the source F1 terminating CU of the first IAB node is CU1, its target F1 terminating CU is CU3, and its RRC terminating CU is CU2. For a description of the roles of the three CUs (RRC terminating CU, source F1 terminating CU, and target F1 terminating CU) in this scenario, please refer to the descriptions in the preceding sections.

[0551] It should be understood that scenario 3 can be regarded as a combination of scenario 1 and scenario 2. It is necessary to notify CU1 that the first MT of the first IAB will not switch to CU, and CU1 does not need to initiate a service release negotiation process to CU2 due to the migration of the first DU and the switching of the UE. It is also necessary to notify CU3 that the first MT of the first IAB will not switch, and CU3 does not need to initiate a service addition negotiation process to CU2 due to the migration of the first DU and the switching of the UE.

[0552] S1310: Establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU3).

[0553] S1320: The first IAB node or the target F1 endpoint CU (CU3) sends a third message to the RRC endpoint CU (CU2), which indicates that the third F1 interface between the first IAB node and CU3 has been established.

[0554] In some possible embodiments, in S1320, if the first IAB node sends a third message to CU2, the third message may also carry the identifier of the target F1 endpoint CU (CU3) to inform the RRC endpoint CU (CU2) that the target F1 endpoint CU to which the first IAB node has switched is CU3.

[0555] S1330: The target F1 endpoint CU (CU3) of the first IAB node receives a first message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0556] Therefore, upon receiving the aforementioned first message, CU3 decides not to negotiate the transmission migration management of the first IAB node with CU2. Services between CU3 and the first IAB node will continue to be transmitted via the wireless backhaul network under the jurisdiction of the second IAB host.

[0557] It should be understood that the content of S1310 to S1330 is the same as that of S910 to S930 above. Therefore, for the embodiments of S1310 to S1330, you can refer to the embodiments corresponding to S910 to S930 above, and will not repeat them here.

[0558] S1335: The source F1 endpoint CU (CU1) of the first IAB node receives a fifth message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0559] Therefore, after receiving the fifth message, CU1 does not need to negotiate with CU2 regarding the transport migration management of the first IAB node.

[0560] It should be understood that the content of S1335 is the same as that of S1130 above. Therefore, for the embodiments of S1335, please refer to the embodiments corresponding to S1130 above. They will not be repeated here.

[0561] Based on the above technical solution, it is possible to reasonably avoid the following process during which the UE serving the first IAB node switches from CU1 to CU3, and CU3 initiates the relevant IAB transport migration management process (such as the IAB transportmigration management process, which is used to request the configuration of the radio backhaul link for the service of the first IAB node in the IAB network under the jurisdiction of CU2). It is also possible to avoid CU1 initiating the relevant IAB transport migration management process (which is used to request CU2 to release the configuration of the radio backhaul link for the service of the first IAB node in its radio backhaul network) to CU2, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0562] S1340: Target F1 endpoint CU (CU3) sends a first feedback message to RRC endpoint CU (CU2), which indicates that CU3 has successfully received the first message from CU2.

[0563] Step S1340 is optional and can be omitted.

[0564] S1345: Source F1 endpoint CU (CU1) sends a second feedback message to RRC terminating CU (CU2), which indicates that CU1 has successfully received the fifth message from CU2.

[0565] Step S1345 is optional and can be omitted.

[0566] It should be understood that the embodiments of this application do not limit the execution order between the two sets of steps {S1330 and S1340} and {S1335 and S1345}. These two sets of steps can be performed one after the other or simultaneously.

[0567] Based on the above technical solution, while reducing signaling overhead, it is possible to ensure that after the first DU of the first IAB node switches to CU2, CU2 can provide it with corresponding wireless backhaul service.

[0568] Although the CU2 mentioned above has the capability to provide corresponding wireless backhaul services to the first IAB node, the entire service path has not yet been established. Therefore, it is necessary to update the tunnel endpoint information of F1-U traffic and negotiate the QoS label information of the service through the following steps, so that the target F1 endpoint CU can accurately provide service data to the first IAB node.

[0569] In one possible implementation, if there is no Xn interface between CU1 and CU3 for direct interaction, then S1350 and S1352 can be executed as follows.

[0570] In one possible implementation, if there is an Xn interface between CU1 and CU3 for direct interaction, then the following S1354 can be executed.

[0571] S1350: CU1 sends a fourth message to CU2. The fourth message includes the first uplink endpoint information of the first F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink tunnel endpoint identifier (TEID) of the first F1-U interface.

[0572] It should be understood that the first uplink endpoint information of the first F1-U interface tunnel is the uplink endpoint information of each first DRB maintained by the source F1 endpoint CU (here, the first CU), which can also be called the original uplink endpoint information.

[0573] In some possible embodiments, the fourth message may also include the identifier of the first UE and the identifier of the first DRB, wherein the identifier of the first UE may be the UE identifier used by the first UE when performing NGAP handover, for example, AMF UE NGAPID.

[0574] In some possible embodiments, the fourth message may further include the identifier of the first IAB node that provides access services to the first UE. For example, the target cell identifier of the first UE, where the target cell of the first UE is the cell served by the first IAB node (i.e., the cell served by the first DU, specifically the identifier of the cell served by the logical DU b connected to the target F1 endpoint CU); or, the identifier of the first DU to which the first UE is connected, which may be an IP address or the gNB-DU identifier (gNB-DU ID) of the first DU. If the first IAB node is connected to different CUs (CU1, CU3) through different logical DUs (first DU a, first DU b), then the identifier of the first DU may specifically be the identifier of the first DU b that establishes an F1 connection with CU3; or, the BAP address of the first IAB node.

[0575] Based on the above technical solution, by carrying the identifier corresponding to the first IAB node, the CU3 can know that the first DU of the first IAB node is serving the first UE, so that the CU3 and the first DU can carry out the negotiation process of establishing and modifying the context of the first UE regarding the F1 interface.

[0576] S1352: CU2 sends the aforementioned fourth message to CU3.

[0577] In some possible embodiments, the aforementioned fourth message can be carried by other notification messages, which may include first QoS mapping information. This first QoS mapping information is the QoS label corresponding to the first DRB of the first UE, specifically including the values ​​of DSCP and / or flow label. After receiving the first QoS mapping information, the CU3 can, based on this first QoS mapping information, fill the IP header with appropriate DSCP and / or IPv6 flow label values ​​for the downlink data packets of the first DRB.

[0578] Based on the above technical solution, the service quality of the services provided to the first UE can be guaranteed without CU3 negotiating DU migration management with CU2.

[0579] S1354: CU1 sends a fourth message to CU3. The fourth message includes the first uplink endpoint information of the first F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink tunnel endpoint identifier (TEID) of the first F1-U interface.

[0580] It should be understood that the first uplink endpoint information of the first F1-U interface tunnel is the uplink endpoint information of each first DRB maintained by the source F1 endpoint host CU (CU1 here), which can also be called the original uplink endpoint information.

[0581] In some possible embodiments, the fourth message may further include the identifier of the first UE and the identifier of the first DRB, corresponding to the first uplink endpoint information of the F1-U interface tunnel of the first DRB. The identifier of the first UE may be the UE identifier used by the first UE when performing XnAP handover, for example, the UE XnAP ID assigned to the first UE by the source F1 endpoint CU (CU1), and / or the UE XnAP ID assigned to the first UE by the target F1 endpoint CU (CU2).

[0582] In some possible embodiments, the fourth message may also include the first QoS mapping information, the content of which can be found in the description in step S1352.

[0583] S1360: CU3-CP sends the aforementioned first notification information to CU3-UP, which is used to instruct CU3-UP to establish the uplink tunnel endpoint of the second F1-U interface.

[0584] S1370: CU3-UP sends the aforementioned second notification information to CU3-CP, which includes the uplink tunnel endpoint information of the second F1-U interface.

[0585] S1380: The target F1 endpoint CU (CU3) sends a first update message to the first IAB node. The first update message includes the second uplink endpoint information (i.e., the uplink tunnel endpoint information of the second F1-U interface). The first update message is used to instruct the first IAB node to update the uplink tunnel endpoint of the first F1-U interface corresponding to the first DRB to the uplink tunnel endpoint information of the second F1-U interface, so as to ensure access and backhaul services for the first UE.

[0586] In some possible embodiments, if steps S1350, S1352, or S1354 are executed, the first update information may also include the corresponding first uplink endpoint information for each second uplink endpoint information. After receiving the first update information, the first IAB node can directly replace the first uplink endpoint information of the F1-U interface tunnel corresponding to the first DRB with the second uplink endpoint information. In this way, the target F1 endpoint CU (CU3) can send multiple first update information for different DRBs of multiple UEs to the first IAB node at one time, which can improve the efficiency of configuration update.

[0587] It should be understood that the content of S1360 to S1380 is basically the same as that of S960 to S980 above. Therefore, for the embodiments of S1360 to S1380, you can refer to the embodiments corresponding to S960 to S980 above, and will not repeat them here.

[0588] Based on the above technical solution, it is convenient to target F1 endpoint CU ( Figure 13 The CU3 in the first IAB node obtains the uplink tunnel endpoint information of the new interface corresponding to the first DRB, and then further notifies the first IAB node. Additionally, the target F1 endpoint CU ( Figure 13 The CU3 in the middle obtains the first QoS mapping information corresponding to the first DRB, which facilitates the provision of reasonable QoS guarantee and routing for data packets transmitted through the first DRB in downlink transmission.

[0589] Figure 14 A schematic diagram of another communication method provided in an embodiment of this application is shown.

[0590] This communication method is applied to an IAB network, which includes at least a first IAB node, a first IAB host, a second IAB host, and a third IAB host. The first IAB node includes a first DU and a first MT. The first DU switches from establishing a connection with CU1 of the first IAB node to establishing a connection with CU3 of the third IAB host, while the first MT always maintains a connection with the second IAB host. In this embodiment, this connection state is referred to as the first connection state. Therefore, this scenario corresponds to scenario 3 proposed in the above embodiment.

[0591] S1410: Establish an F1 interface between the first IAB node and the target F1 endpoint CU (CU3).

[0592] S1420: The first IAB node or the target F1 endpoint CU (CU3) sends a third message to the RRC endpoint CU (CU2), which indicates that the third F1 interface between the first IAB node and CU3 has been established.

[0593] It should be understood that the content of S1410 to S1420 is the same as that of S1310 to S1320 above. Therefore, for the embodiments of S1410 to S1420, you can refer to the embodiments corresponding to S1310 to S1320 above, and will not repeat them here.

[0594] S1430: The target F1 endpoint CU (CU3) of the first IAB node receives a first message, which is used to indicate that the service of the first IAB node does not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the service of the first IAB node.

[0595] In some possible embodiments, the first message in S1430 above is specifically sent to CU3 through the following steps:

[0596] S1432: RRC terminating CU(CU2) sends the seventh message to the first IAB node.

[0597] S1434: The first IAB node determines the first message based on the seventh message mentioned above and sends the first message to CU3.

[0598] It should be understood that the contents of S1430, S1432, and S1434 are the same as those of S1030, S1032, and S1034 above. Therefore, for the embodiments of S1430, S1432, and S1434, you can refer to the embodiments corresponding to S1030, S1032, and S1034 above, and they will not be repeated here.

[0599] S1435: The source F1 endpoint CU (CU1) of the first IAB node receives a fifth message, which is used to indicate that the services of the first IAB node do not need to migrate the radio backhaul link, or to indicate that there is no need to initiate the IAB transmission migration management process to the RRC terminating CU for the services of the first IAB node.

[0600] In some possible embodiments, the fifth message described above is sent to CU1 specifically through the following steps:

[0601] S1437: RRC terminating CU (CU2) sends the seventh message to the first IAB node. In one possible approach, step S1437 can be the same as step S1432, or S1437 can be replaced by S1432.

[0602] S1439: The first IAB node determines the fifth message based on the seventh message mentioned above and sends the fifth message to CU1.

[0603] It should be understood that the contents of S1435, S1437, and S1439 are the same as those of S1230, S1232, and S1234 above. Therefore, for the embodiments of S1435, S1437, and S1439, you can refer to the embodiments corresponding to S1230, S1232, and S1234 above, and they will not be repeated here.

[0604] Based on the above technical solution, it is possible to reasonably avoid the following process during which the UE serving the first IAB node switches from CU1 to CU3, and CU3 initiates the relevant IAB transport migration management process (such as the IAB transportmigration management process, which is used to request the configuration of the radio backhaul link for the service of the first IAB node in the IAB network under the jurisdiction of CU2). It is also possible to avoid CU1 initiating the relevant IAB transport migration management process (which is used to request CU2 to release the configuration of the radio backhaul link for the service of the first IAB node in its radio backhaul network) to CU2, thereby saving the signaling overhead of the Xn interface and F1 interface.

[0605] S1440: CU3 sends a second feedback message to the first IAB node, indicating that CU3 has received the first message from the first IAB node. This step S1440 is optional and can be omitted.

[0606] S1445: CU1 sends a third feedback message to the first IAB node, indicating that CU1 has received the fifth message from the first IAB node. This step S1445 is optional and can be omitted.

[0607] It should be understood that the contents of S1440 and S1445 are the same as those of S1340 and S1345 above. Therefore, for the embodiments of S1440 and S1445, you can refer to the embodiments corresponding to S1340 and S1345 above, and will not repeat them here.

[0608] It should be understood that the embodiments of this application do not limit the execution order between the two sets of steps {S1430 and S1440} and {S1435 and S1445}. These two sets of steps can be performed one after the other or simultaneously.

[0609] Based on the above technical solution, while reducing signaling overhead, it is possible to ensure that after the first DU of the first IAB node switches to CU2, CU2 can provide it with corresponding wireless backhaul service.

[0610] Although the CU2 mentioned above has the capability to provide corresponding wireless backhaul services to the first IAB node, the entire service path has not yet been established. Therefore, it is necessary to update the tunnel endpoint information of F1-U traffic and negotiate the QoS label information of the service through the following steps, so that the target F1 endpoint CU can accurately provide service data to the first IAB node.

[0611] If there is no Xn interface between CU1 and CU3 for direct interaction, then execute S1450 and S1452 as follows.

[0612] If there is an Xn interface between CU1 and CU3 for direct interaction, then the following S1454 is executed.

[0613] S1450: CU1 sends a fourth message to CU2. The fourth message includes the first uplink endpoint information of the first F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink tunnel endpoint identifier (TEID) of the first F1-U interface.

[0614] S1452: CU2 sends the aforementioned fourth message to CU3.

[0615] S1454: CCU1 sends a fourth message to CU3. The fourth message includes the first uplink endpoint information of the first F1-U interface tunnel corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first uplink endpoint and the uplink tunnel endpoint identifier (TEID) of the first F1-U interface.

[0616] It should be understood that the contents of S1450, S1452, and S1454 are the same as those of S1350, S1352, and S1354 above. Therefore, for the embodiments of S1450, S1452, and S1454, you can refer to the embodiments corresponding to S1350, S1352, and S1354 above, and they will not be repeated here.

[0617] S1460: CU3-CP sends the aforementioned first notification information to CU3-UP, which instructs CU3-UP to establish an uplink tunnel endpoint for the second F1-U interface.

[0618] S1470: CU3-UP sends the aforementioned second notification information to CU3-CP, which includes the uplink tunnel endpoint information of the second F1-U interface.

[0619] S1480: The target F1 endpoint CU (CU3) sends a first update message to the first IAB node. The first update message includes the second uplink endpoint information (i.e., the uplink tunnel endpoint information of the second F1-U interface). The first update message is used to instruct the first IAB node to update the uplink tunnel endpoint of the first F1-U interface corresponding to the first DRB to the uplink tunnel endpoint information of the second F1-U interface, so as to ensure access and backhaul services for the first UE.

[0620] It should be understood that the content of S1460 to S1480 is the same as that of S1360 to S1380 above. Therefore, for the embodiments of S1460 to S1480, you can refer to the embodiments corresponding to S1360 to S1380 above, and will not repeat them here.

[0621] Based on the above technical solution, it is convenient to target F1 endpoint CU ( Figure 14 The CU3 in the first IAB node obtains information about the uplink tunnel endpoint of the new F1-U interface corresponding to the first DRB, and then further notifies the first IAB node. Additionally, the target F1 endpoint CU3 can also be made... Figure 14 The CU3 in the middle obtains the first QoS mapping information corresponding to the first DRB, which facilitates the provision of reasonable QoS guarantee and routing for data packets transmitted through the first DRB in downlink transmission.

[0622] This application also provides an apparatus for implementing any of the above methods, for example, an apparatus for sending information, which may be an apparatus integrated with the above. Figures 9 to 14 The sub-modules in the first IAB node, first IAB host, second IAB host, and third IAB host described in the embodiments include units (or means) for implementing any of the above communication methods.

[0623] Figure 15 This is a schematic diagram of a communication device 1500 provided in an embodiment of this application. The device is used in an integrated access backhaul (IAB) network, where the RRC endpoint CU in the IAB network has an RRC connection with the first MT of the first IAB node. Specifically, the communication device 1500 is applied to the aforementioned target F1 endpoint CU and includes:

[0624] The receiving unit 1510 is configured to receive a first message after the first DU of the first IAB node migrates from the source F1 target CU to the target F1 endpoint CU;

[0625] Processing unit 1520 is configured to, based on the first message, avoid negotiating the transmission migration management of the first IAB node with the RRC endpoint CU.

[0626] In some possible embodiments, the above-described apparatus further includes: a sending unit 1530, configured to send a third message to the RRC endpoint CU, the third message indicating that the target F1 endpoint CU has established a connection with the first IAB node through a third F1 interface, the third message carrying the first MT identifier.

[0627] In some possible embodiments, before establishing a connection between the target F1 endpoint CU and the first DU, the receiving unit 1510 is further configured to receive a second message from the first IAB node. The second message is configured to instruct the first IAB node to request to establish an F1 interface with the target F1 endpoint CU. The second message carries a first MT identifier and an RRC endpoint CU identifier. The first MT identifier includes at least one of the following: the BAP address assigned to the first MT by the RRC endpoint CU, and the UE XnAP identifier assigned to the first MT by the RRC endpoint CU. The RRC endpoint CU identifier includes at least one of the following: the IP address of the RRC endpoint CU, and the gNB identifier of the base station where the RRC endpoint CU is located.

[0628] In some possible embodiments, the first message includes a first IAB node identifier. After the first DU migrates from the source F1 endpoint CU to the target F1 endpoint CU, the processing unit 1520 is further configured to, based on the first message, exempt from transmission migration management negotiation regarding all services transmitted by the first IAB node.

[0629] In some possible embodiments, the first message includes the identifier of the first UE or the identifier of the bearer corresponding to the first UE. The first UE is served by the first IAB node. The identifier of the bearer corresponding to the first UE includes the identifier of the first DRB or the identifier of the first SRB. After the first UE follows the first DU to switch from the source F1 endpoint CU to the target F1 endpoint CU, the processing unit 1520 is further configured to, according to the first message, avoid negotiating the transmission migration management with the RRC endpoint CU regarding the first UE, the first DRB, or the first SRB.

[0630] In some possible embodiments, the first DU includes a first DU a and a first DU b, wherein the first DU a has a connection with the source F1 endpoint CU based on a first F1 interface, and the first DU b has a connection with the target F1 endpoint CU based on a third F1 interface.

[0631] In some possible embodiments, the first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

[0632] In some possible embodiments, the receiving unit 1510 is further configured to receive a fourth message from the source F1 endpoint CU, the fourth message including the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB, the first uplink endpoint information including the IP address of the source F1 endpoint CU and the uplink tunnel endpoint identifier TEID of the source F1 endpoint CU.

[0633] In some possible embodiments, the fourth message may further include first QoS mapping information of the downlink service of the source F1 endpoint CU, the first QoS mapping information corresponding to the service or non-F1 service of the first F1-C interface control plane, and the first QoS mapping information including at least one of the following: the Differentiated Service Code Point (DSCP) corresponding to the first DRB, and the value of the flow label corresponding to the first DRB.

[0634] In some possible embodiments, the processing unit 1520 is further configured to generate second uplink endpoint information according to the fourth message, the second uplink endpoint information including the IP address of the target F1 endpoint CU and the uplink TEID of the target F1 endpoint CU; the sending unit 1530 is further configured to send first update information to the first IAB node, the first update information including the second uplink endpoint information.

[0635] Figure 16 This is a schematic diagram of a communication device 1600 provided in an embodiment of this application. The device is used in an integrated access backhaul (IAB) network, where a second CU in the IAB network has an RRC connection with a first MT of a first IAB node. Specifically, the communication device 1600 is applied to the aforementioned source F1 endpoint CU and includes:

[0636] The receiving unit 1610 is configured to receive the fifth message after the first DU of the first IAB node migrates from the source F1 endpoint CU to the target F1 endpoint CU.

[0637] Processing unit 1620 is configured to, based on the aforementioned fifth message, waive the need to negotiate with the aforementioned RRC endpoint CU regarding the release of the aforementioned first IAB node service.

[0638] In some possible embodiments, the above apparatus further includes: a sending unit 1630, configured to send a sixth message to the RRC endpoint CU before establishing a connection between the target F1 endpoint CU and the first DU, the sixth message being configured to indicate that the first DU of the first IAB node will migrate from the source F1 endpoint CU to the target F1 endpoint CU.

[0639] In some possible embodiments, the fifth message includes the identifier of the first IAB node. After the first DU of the first IAB node migrates from the source F1 endpoint CU to the target F1 endpoint CU, the processing unit 1520 is further configured to, according to the fifth message, exempt the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

[0640] In some possible embodiments, the fifth message includes the identifier of the first UE or the identifier of the bearer corresponding to the first UE, the first UE being served by the first IAB node, and the identifier of the bearer corresponding to the first UE including the identifier of the first DRB or the identifier of the first SRB. After the first UE follows the first DU from the source F1 endpoint CU to the target F1 endpoint CU, the processing unit 1620 is further configured to, according to the fifth message, avoid negotiating with the RRC endpoint CU regarding the release of services of the first UE, the first DRB, or the first SRB.

[0641] In some possible embodiments, the first DU includes a first DU a and a first DU b, the first DU a having a connection with the source F1 endpoint CU based on a first F1 interface, and the first DU b having a connection with the target F1 endpoint CU based on a third F1 interface.

[0642] In some possible embodiments, the first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

[0643] In some possible embodiments, the sending unit 1630 is further configured to send a fourth message to the target F1 endpoint CU, the fourth message including first uplink endpoint information of the first F1-U interface tunnel corresponding to the first DRB, the first uplink endpoint information including the IP address of the source F1 endpoint CU and the uplink tunnel endpoint identifier TEID of the source F1 endpoint CU, so that the target F1 endpoint CU generates second uplink endpoint information based on the fourth message and sends a first update message to the first IAB node, the first update message including the second uplink endpoint information, the second uplink endpoint information including the IP address of the target F1 endpoint CU and the uplink TEID of the target F1 endpoint CU.

[0644] In some possible embodiments, the fourth message may also include first QoS mapping information of the downlink service of the source F1 endpoint CU, the first QoS mapping information corresponding to the service of the first F1-C interface control plane or the non-F1 service, and the first QoS mapping information includes at least one of the following: the Differentiated Service Code Point (DSCP) corresponding to the first DRB, and the value of the flow label corresponding to the first DRB.

[0645] Figure 17 This is a schematic diagram of a communication device 1700 provided in an embodiment of this application. The device is used in an integrated IAB (Internet Access Backhaul) network, and specifically, the communication device 1700 is applied to the aforementioned RRC endpoint CU, including:

[0646] Operation unit 1710 is used to establish an RRC connection with the first MT of the first IAB node;

[0647] The sending unit 1720 is configured to, after the first DU of the first IAB node migrates from the source F1 endpoint CU to the target F1 endpoint CU, send a fifth message to the source F1 endpoint CU and send a first message to the target F1 endpoint CU. The fifth message is used to instruct the source F1 endpoint CU to waive the negotiation with the RRC endpoint CU regarding the release of the first IAB node's services, and the first message is used to instruct the target F1 endpoint CU to waive the negotiation with the RRC endpoint CU regarding the transmission migration management of the first IAB node.

[0648] In some possible embodiments, the communication device 1700 further includes a receiving unit 1730, configured to receive a sixth message from the source F1 endpoint CU, the sixth message being configured to indicate that the first DU of the first IAB node will migrate from the source F1 endpoint CU to the target F1 endpoint CU.

[0649] Processing unit 1740 is configured to send the fifth message to the source F1 endpoint CU according to the sixth message and the first connection state. The first connection state includes the first MT maintaining an RRC connection with the RRC endpoint CU before and after the first DU migrates from the source F1 endpoint CU to the target F1 endpoint CU.

[0650] In some possible embodiments, the receiving unit 1730 is further configured to receive a third message from the target F1 endpoint CU, the third message indicating that the target F1 endpoint CU has established a connection with the first IAB node through the third F1 interface.

[0651] The processing unit 1740 is further configured to send the first message to the target F1 endpoint CU according to the third message and the first connection state, wherein the first connection state includes the first MT maintaining an RRC connection with the RRC endpoint CU before and after the first DU migrates from the source F1 endpoint CU to the target F1 endpoint CU.

[0652] In some possible embodiments, the fifth message includes a first IAB node identifier, and the fifth message is used to instruct the source F1 endpoint CU to waive the transport migration management negotiation regarding the release of all services in which the first IAB node participates in the transmission.

[0653] In some possible embodiments, the fifth message includes the identifier of the first UE or the identifier of the bearer corresponding to the first UE, the first UE being served by the first IAB node, and the identifier of the bearer corresponding to the first UE including the identifier of the first DRB or the identifier of the first SRB. The fifth message is used to instruct the source F1 endpoint CU to waive the need to negotiate with the RRC endpoint CU regarding the release of services for the first UE, the first DRB, or the first SRB.

[0654] In some possible embodiments, the first message includes a first IAB node identifier, and the first message is used to instruct the target F1 endpoint CU to waive the transmission migration management negotiation for all services involving the first IAB node.

[0655] In some possible embodiments, the first message includes the identifier of the first UE or the identifier of the bearer corresponding to the first UE, the first UE being served by the first IAB node, and the identifier of the bearer corresponding to the first UE including the identifier of the first DRB or the identifier of the first SRB. The first message is used to instruct the target F1 endpoint CU to avoid negotiating the transmission migration management with the RRC endpoint CU regarding the first UE, the first DRB, or the first SRB.

[0656] In some possible embodiments, the first DU includes a first DU a and a first DU b, the first DU a having a connection with the source F1 endpoint CU based on a first F1 interface, and the first DU b having a connection with the target F1 endpoint CU based on a third F1 interface.

[0657] In some possible embodiments, the first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

[0658] In some possible embodiments, the receiving unit 1730 is further configured to receive a fourth message sent by the source F1 endpoint CU, the fourth message including the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB, the first uplink endpoint information including the IP address of the source F1 endpoint CU and the uplink tunnel endpoint identifier TEID of the source F1 endpoint CU.

[0659] The aforementioned sending unit 1720 is further configured to send the aforementioned fourth message to the aforementioned target F1 endpoint CU, so that the aforementioned target F1 endpoint CU generates second uplink endpoint information based on the aforementioned fourth message, and sends a first update message to the aforementioned first IAB node. The first update message includes the aforementioned second uplink endpoint information, which includes the IP address of the aforementioned target F1 endpoint CU and the uplink TEID of the aforementioned target F1 endpoint CU.

[0660] In some possible embodiments, when the RRC endpoint CU and the source F1 endpoint CU are the same CU, the processing unit 1730 is further configured to generate the fourth message; the sending unit 1720 is further configured to send the fourth message to the target F1 endpoint CU.

[0661] In some possible embodiments, the fourth message may further include first QoS mapping information of the downlink service of the source F1 endpoint CU, the first QoS mapping information corresponding to the service or non-F1 service of the first F1-C interface control plane, and the first QoS mapping information including at least one of the following: the Differentiated Service Code Point (DSCP) corresponding to the first DRB, and the value of the flow label corresponding to the first DRB.

[0662] Figure 18 This is a schematic diagram of a communication device 1800 provided in an embodiment of this application. The device is used in an integrated IAB (Internet Access Backhaul) network, and specifically, the communication device 1800 is applied to the aforementioned first IAB node, including:

[0663] Operation unit 1810 is used to establish an RRC connection between the first MT and the RRC endpoint CU; and to migrate the first DU from the source F1 endpoint CU to the target F1 endpoint CU;

[0664] The receiving unit 1820 is configured to receive a seventh message from the aforementioned RRC endpoint CU, the seventh message being configured to instruct the aforementioned first MT to maintain an RRC connection with the aforementioned RRC endpoint CU during the migration of the aforementioned first DU from the source F1 endpoint CU to the target F1 endpoint CU;

[0665] Processing unit 1830 is used to determine a first message and a fifth message based on the seventh message mentioned above. The first message is used to instruct the target F1 endpoint CU to waive the transmission migration management negotiation with the RRC endpoint CU regarding the first IAB node. The fifth message is used to instruct the source F1 endpoint CU to waive the negotiation with the RRC endpoint CU regarding the release of the first IAB node service.

[0666] The sending unit 1840 is used to send the first message to the target F1 endpoint CU and to send the fifth message to the source F1 endpoint CU.

[0667] In some possible embodiments, after the first DU of the first IAB node migrates from the source F1 endpoint CU to the target F1 endpoint CU, the sending unit 1840 is further configured to send a third message to the RRC endpoint CU, the third message being used to indicate that a connection has been established between the first IAB node and the target F1 endpoint CU through the third F1 interface, the third message carrying the first MT identifier.

[0668] In some possible embodiments, before establishing a connection between the first DU and the target F1 endpoint CU, the sending unit 1840 is further configured to send a second message to the target F1 endpoint CU. The second message is used to instruct the first IAB node to request to establish an F1 interface with the target F1 endpoint CU. The second message carries a first MT identifier and an RRC endpoint CU identifier. The first MT identifier includes at least one of the following: the Backhaul Adaptation Protocol (BAP) address assigned by the RRC endpoint CU to the first MT, and the User Equipment (UE) Application Protocol (AP) identifier assigned by the RRC endpoint CU to the first MT. The RRC endpoint CU identifier includes at least one of the following: the IP address of the RRC endpoint CU, and the base station (gNB) identifier where the RRC endpoint CU is located.

[0669] In some possible embodiments, the fifth message includes a first IAB node identifier, and the fifth message is used to instruct the source F1 endpoint CU to waive the transport migration management negotiation regarding the release of all services in which the first IAB node participates in the transmission.

[0670] In some possible embodiments, the fifth message includes the identifier of the first UE or the identifier of the bearer corresponding to the first UE, the first UE being served by the first IAB node, and the identifier of the bearer corresponding to the first UE including the identifier of the first DRB or the identifier of the first SRB. The fifth message is used to instruct the source F1 endpoint CU to waive the need to negotiate with the RRC endpoint CU regarding the release of services of the first UE, the first DRB, or the first SRB.

[0671] In some possible embodiments, the first message includes a first IAB node identifier, and the first message is used to instruct the target F1 endpoint CU to waive the transmission migration management negotiation for all services involving the first IAB node.

[0672] In some possible embodiments, the first message includes the identifier of the first UE or the identifier of the bearer corresponding to the first UE, the first UE being served by the first IAB node, and the identifier of the bearer corresponding to the first UE including the identifier of the first DRB or the identifier of the first SRB. The first message is used to instruct the target F1 endpoint CU to avoid negotiating the transmission migration management with the RRC endpoint CU regarding the first UE, the first DRB, or the first SRB.

[0673] In some possible embodiments, the first DU includes a first DU a and a first DU b, wherein the first DU a is connected to the source F1 endpoint CU via a first F1 interface; and the first DU b is connected to the target F1 endpoint CU via a third F1 interface.

[0674] In some possible embodiments, the first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

[0675] In some possible embodiments, the receiving unit 1820 is further configured to receive a first update message from the target F1 endpoint CU, the first update message including second uplink endpoint information, the second uplink endpoint information including the IP address of the target F1 endpoint CU and the uplink TEID of the target F1 endpoint CU;

[0676] The aforementioned processing unit 1830 is further configured to update the uplink TEID and uplink mapping configuration of the F1-U corresponding to the first DRB according to the aforementioned first update message.

[0677] In some possible embodiments, when the source F1 endpoint CU and the RRC endpoint CU are the same CU, the sending unit 1840 is further configured to send the first message to the target F1 endpoint CU; or,

[0678] When the aforementioned RRC endpoint CU and the aforementioned target F1 endpoint CU are the same CU, the aforementioned sending unit 1840 is also used to send the aforementioned fifth message to the aforementioned source F1 endpoint CU.

[0679] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0680] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0681] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0682] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0683] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0684] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory, magnetic disks, or optical disks.

[0685] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method, characterized in that, The method is applied to an integrated access backhaul (IAB) network, where the second centralized unit (CU) and the first mobile terminal (MT) of the first IAB node have a Radio Resource Control (RRC) connection. The method includes: After the first distributed unit (DU) of the first IAB node migrates from the first CU to the third CU, the third CU receives the first message; Based on the first message, the third CU is exempt from negotiating the transmission migration management of the first IAB node with the second CU.

2. The method according to claim 1, characterized in that, The method further includes: The third CU sends a third message to the second CU, the third message indicating that the third CU has established a connection with the first IAB node through the third F1 interface, and the third message carries the first MT identifier.

3. The method according to claim 1 or 2, characterized in that, Before establishing a connection between the third CU and the first DU, the method further includes: The third CU receives a second message from the first IAB node. The second message is used to instruct the first IAB node to request the establishment of an F1 interface with the third CU. The second message carries a first MT identifier and a second CU identifier. The first MT identifier includes at least one of the following: the Backhaul Adaptation Protocol (BAP) address assigned by the second CU to the first MT, and the User Equipment (UE) Application Protocol (AP) identifier assigned by the second CU to the first MT. The second CU identifier includes at least one of the following: the Internet Protocol (IP) address of the second CU, and the gNB identifier of the base station where the second CU is located.

4. The method according to any one of claims 1 to 3, characterized in that, The first message includes a first IAB node identifier, and the exemption from negotiating the transport migration management with the second CU regarding the first IAB node includes: After the first DU migrates from the first CU to the third CU, the third CU, based on the first message, exempts the transmission migration management negotiation for all services involving the first IAB node in transmission.

5. The method according to any one of claims 1 to 3, characterized in that, The first message includes the identifier of a first user equipment (UE), which is served by the first IAB node. The exemption from transport migration management negotiation with the second CU regarding the first IAB node includes: After the first UE follows the first DU to switch from the first CU to the third CU, the third CU, based on the first message, is exempt from negotiating the transmission migration management of the first UE's services with the second CU.

6. The method according to any one of claims 1 to 5, characterized in that, The first DU includes a first DU a and a first DU b. The first DU a is connected to the first CU via a first F1 interface, and the first DU b is connected to the third CU via a third F1 interface.

7. The method according to any one of claims 4 to 6, characterized in that, The first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU b.

8. The method according to any one of claims 5 to 7, characterized in that, The method further includes: The third CU receives a fourth message from the first CU. The fourth message includes first QoS mapping information for downlink services of the first CU. The first QoS mapping information corresponds to services or non-F1 services of the first F1-C interface control plane or the first data radio bearer (DRB) of the first UE. The first QoS mapping information includes at least one of the following: Differentiated Service Code Point (DSCP) and Flow Label.

9. The method according to claim 8, characterized in that, The fourth message also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first CU and the uplink tunnel endpoint identifier (TEID) of the first CU.

10. The method according to any one of claims 5 to 9, characterized in that, The method further includes: The third CU generates second uplink endpoint information corresponding to the first DRB of the first UE. The second uplink endpoint information includes the IP address of the third CU and the uplink TEID of the third CU. The third CU sends first update information to the first IAB node, the first update information including the second uplink endpoint information.

11. A communication method, characterized in that, The method is applied to an integrated access backhaul (IAB) network, where the second CU and the first MT of the first IAB node have an RRC connection. The method includes: After the first DU of the first IAB node migrates from the first CU to the third CU, the first CU receives the fifth message; According to the fifth message, the first CU is exempt from negotiating with the second CU regarding the release of the first IAB node services.

12. The method according to claim 11, characterized in that, Before establishing a connection between the third CU and the first DU, the method further includes: The first CU sends a sixth message to the second CU, the sixth message being used to instruct the first DU of the first IAB node to migrate from the first CU to the third CU.

13. The method according to claim 11 or 12, characterized in that, The fifth message includes the identifier of the first IAB node, and the exemption from negotiation with the second CU regarding the release of services of the first IAB node includes: After the first DU migrates from the first CU to the third CU, the first CU, based on the fifth message, is exempt from transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

14. The method according to any one of claims 11 to 13, characterized in that, The fifth message includes the identifier of the first UE, which is served by the first IAB node. The exemption from negotiating with the second CU regarding the release of services from the first IAB node includes: After the first UE follows the first DU to switch from the first CU to the third CU, the first CU, based on the fifth message, is exempt from negotiating with the second CU regarding the release of the first UE's services.

15. The method according to any one of claims 11 to 14, characterized in that, The first DU includes a first DU a and a first DU b. The first DU a is connected to the first CU via a first F1 interface, and the first DU b is connected to the third CU via a third F1 interface.

16. The method according to any one of claims 13 to 15, characterized in that, The first DU includes a first DU a and a first DU b, and the first IAB node identifier includes the identifier of the first DU a.

17. The method according to any one of claims 14 to 16, characterized in that, The method further includes: The first CU sends a fourth message to the third CU. The fourth message includes the first QoS mapping information of the downlink service of the first CU. The first QoS mapping information corresponds to the service of the first F1-C interface control plane or the service of a non-F1 interface or the first DRB of the first UE. The first QoS mapping information includes at least one of the following: DSCP, Flow Label.

18. The method according to claim 17, characterized in that, The fourth message also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first CU and the uplink tunnel endpoint identifier (TEID) of the first CU.

19. A communication method, characterized in that, The method is applied to an integrated access backhaul (IAB) network, and the method includes: The second CU establishes an RRC connection with the first MT of the first IAB node; After the first DU of the first IAB node migrates from the first CU to the third CU, the second CU sends a fifth message to the first CU and a first message to the third CU. The fifth message is used to instruct the first CU to waive the negotiation with the second CU regarding the release of the first IAB node's services, and the first message is used to instruct the third CU to waive the negotiation with the second CU regarding the transmission migration management of the first IAB node.

20. The method according to claim 19, characterized in that, The fifth message sent from the second CU to the first CU includes: The second CU receives a sixth message from the first CU, the sixth message being used to indicate that the first DU of the first IAB node will migrate from the first CU to the third CU; The second CU sends the fifth message to the first CU according to the sixth message and the first connection state. The first connection state includes the first MT maintaining an RRC connection with the second CU before and after the first DU migrates from the first CU to the third CU.

21. The method according to claim 19 or 20, characterized in that, The second CU sending a first message to the third CU includes: The second CU receives a third message from the third CU, the third message indicating that the third CU has established a connection with the first IAB node through the third F1 interface; The second CU sends the first message to the third CU according to the third message and the first connection state. The first connection state includes the first MT maintaining an RRC connection with the second CU before and after the first DU migrates from the first CU to the third CU.

22. The method according to any one of claims 19 to 21, characterized in that, The fifth message includes the identifier of the first IAB node, and the fifth message is used to instruct the first CU to waive the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

23. The method according to any one of claims 19 to 22, characterized in that, The fifth message includes the identifier of the first UE, which is served by the first IAB node, and is used to instruct the first CU to waive the need to negotiate with the second CU regarding the release of services for the first UE.

24. The method according to any one of claims 19 to 23, characterized in that, The first message includes the identifier of the first IAB node, and the first message is used to instruct the third CU to waive the transmission migration management negotiation for all services involving the first IAB node.

25. The method according to any one of claims 19 to 24, characterized in that, The first message includes the identifier of the first UE, which is served by the first IAB node, and the first message is used to instruct the third CU to waive the transmission migration management negotiation with the second CU regarding the services of the first UE.

26. The method according to any one of claims 19 to 25, characterized in that, The first DU includes a first DU a and a first DU b. The first DU a is connected to the first CU via a first F1 interface, and the first DU b is connected to the third CU via a third F1 interface.

27. The method according to any one of claims 22 to 26, characterized in that, The first DU includes a first DU a and a first DU b. The first IAB node identifier in the fifth message includes the identifier of the first DU a, and the first IAB node identifier in the first message includes the identifier of the first DU b.

28. The method according to any one of claims 23 to 27, characterized in that, The method further includes: The second CU receives a fourth message sent by the first CU. The fourth message includes the first QoS mapping information of the downlink service of the first CU. The first QoS mapping information corresponds to the service of the first F1-C interface control plane or the service of a non-F1 interface or the first DRB of the first UE. The first QoS mapping information includes at least one of the following: DSCP, Flow Label. The second CU sends the fourth message to the third CU.

29. The method according to claim 28, characterized in that, The method further includes: When the second CU and the first CU are the same CU, the second CU generates the fourth message and sends the fourth message to the third CU.

30. The method according to claim 28 or 29, characterized in that, The fourth message also includes the first uplink endpoint information of the user plane tunnel of the first F1-U interface corresponding to the first DRB of the first UE. The first uplink endpoint information includes the IP address of the first CU and the uplink tunnel endpoint identifier (TEID) of the first CU.

31. A communication method, characterized in that, The method is applied to an integrated access backhaul (IAB) network, and the method includes: The first MT of the first IAB node establishes an RRC connection with the second CU; The first DU of the first IAB node migrates from the first CU to the third CU; The first IAB node receives a seventh message from the second CU, the seventh message being used to instruct the first MT to maintain an RRC connection with the second CU during the migration of the first DU from the first CU to the third CU; The first IAB node determines the first message and the fifth message based on the seventh message. The first message is used to instruct the third CU to waive the negotiation with the second CU regarding the transmission migration management of the first IAB node. The fifth message is used to instruct the first CU to waive the negotiation with the second CU regarding the release of the services of the first IAB node. The first IAB node sends the first message to the third CU and the fifth message to the first CU.

32. The method according to claim 31, characterized in that, After the first DU of the first IAB node migrates from the first CU to the third CU, the method further includes: The first IAB node sends a third message to the second CU, the third message indicating that a connection has been established between the first IAB node and the third CU through the third F1 interface, and the third message carries the first MT identifier.

33. The method according to claim 31 or 32, characterized in that, Before establishing a connection between the first DU and the third CU, the method further includes: The first IAB node sends a second message to the third CU. The second message is used to instruct the first IAB node to request to establish an F1 interface with the third CU. The second message carries a first MT identifier and a second CU identifier. The first MT identifier includes at least one of the following: the BAP address assigned to the first MT by the second CU, and the UE Xn application protocol AP identifier assigned to the first MT by the second CU. The second CU identifier includes at least one of the following: the IP address of the second CU, and the gNB identifier of the base station where the second CU is located.

34. The method according to any one of claims 31 to 33, characterized in that, The fifth message includes the identifier of the first IAB node, and the fifth message is used to instruct the first CU to waive the transmission migration management negotiation regarding the release of all services in which the first IAB node participates in transmission.

35. The method according to any one of claims 31 to 34, characterized in that, The fifth message includes the identifier of the first UE, which is served by the first IAB node, and is used to instruct the first CU to waive the need to negotiate with the second CU regarding the release of services for the first UE.

36. The method according to any one of claims 31 to 35, characterized in that, The first message includes the identifier of the first IAB node, and the first message is used to instruct the third CU to waive the transmission migration management negotiation for all services involving the first IAB node.

37. The method according to any one of claims 31 to 36, characterized in that, The first message includes the identifier of the first UE, which is served by the first IAB node, and the first message is used to instruct the third CU to waive the transmission migration management negotiation with the second CU regarding the services of the first UE.

38. The method according to any one of claims 31 to 37, characterized in that, The first DU includes a first DU a and a first DU b. The migration of the first DU of the first IAB node from the first CU to the third CU includes: The first DU a and the first CU establish a connection through the first F1 interface; The first DU b and the third CU are connected via the third F1 interface.

39. The method according to any one of claims 34 to 38, characterized in that, The first DU includes a first DU a and a first DU b. The first IAB node identifier in the fifth message includes the identifier of the first DU a, and the first IAB node identifier in the first message includes the identifier of the first DU b.

40. The method according to any one of claims 35 to 39, characterized in that, The method further includes: The first IAB node receives a first update message from the third CU. The first update message includes second uplink endpoint information corresponding to the first DRB of the first UE. The second uplink endpoint information includes the IP address of the third CU and the uplink TEID of the third CU. The first IAB node updates the uplink TEID and uplink mapping configuration of the F1-U corresponding to the first DRB according to the first update message.

41. A communication device, characterized in that, Used to implement the method as described in any one of claims 1 to 10, or, used to implement the method as described in any one of claims 11 to 18, or, used to implement the method as described in any one of claims 19 to 30, or, used to implement the method as described in any one of claims 31 to 40.

42. A communication device, characterized in that, The method includes a processor coupled to a memory for storing computer programs or instructions, the processor for executing the computer programs or instructions in the memory such that the method of any one of claims 1 to 10 is performed, or the method of any one of claims 11 to 18 is performed, or the method of any one of claims 19 to 30 is performed, or the method of any one of claims 31 to 40 is performed.

43. A computer-readable storage medium, characterized in that, The device contains a computer program or instructions for implementing the method of any one of claims 1 to 10, or the method of any one of claims 11 to 18, or the method of any one of claims 19 to 30, or the method of any one of claims 31 to 40.

44. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a computer, cause the apparatus to perform the method of any one of claims 1 to 10, or the method of any one of claims 11 to 18, or the method of any one of claims 19 to 30, or the method of any one of claims 31 to 40.

45. A communication system, characterized in that, include: A first network device is configured to perform the method as described in any one of claims 1 to 10; A second network device is configured to perform the method as described in any one of claims 11 to 18; A third network device is configured to perform the method as described in any one of claims 19 to 30; A fourth network device for performing the method as described in any one of claims 31 to 40.

Images